1. 从零搭建AI工程能力为什么“会调包”和“能落地”之间隔着一整条鸿沟很多人对AI工程的第一印象停留在“装个环境、跑个demo、调个API”这个层面。我刚开始接触这块的时候也是这么想的——直到真正接手一个需要上线的项目才发现事情远没有这么简单。模型在notebook里跑得通不代表它能扛住并发本地推理延迟200毫秒不代表部署到生产环境后还能保持这个数字单次调用效果不错不代表批量处理时不会因为内存溢出而崩溃。这些问题的根源在于“调包”和“工程化落地”之间存在一条被大多数人低估的鸿沟。ai-engineering-from-scratch这个方向核心要解决的就是这条鸿沟。它不是教你某个框架的API怎么用而是帮你建立一套从底层到上层的完整认知数据怎么流转、模型怎么加载、推理怎么加速、服务怎么暴露、监控怎么做、成本怎么控。这套东西才是AI工程师和“会跑demo的人”之间的本质区别。这篇文章适合几类人看一是刚入行、想系统补齐工程能力的算法同学二是后端出身、想切入AI方向的工程师三是已经在做AI应用、但总觉得系统“不够稳、不够快、不够省”的开发者。我会按照一个真实项目从零搭建的顺序把每个环节的关键决策、踩过的坑、以及那些文档里不会写的经验尽量讲透。全文不依赖任何特定云平台或商业工具所有方案都可以在本地或自有服务器上复现。2. 环境与依赖管理别让“在我机器上能跑”成为团队噩梦2.1 为什么AI项目的环境问题比普通后端更棘手普通Web项目的依赖无非是框架加数据库驱动版本冲突的概率相对可控。AI项目不一样PyTorch、CUDA、cuDNN、Python版本、各类科学计算库之间存在一张极其复杂的兼容性网。我见过太多次一个同学在本地用Python 3.10 PyTorch 2.1跑得好好的换到服务器上Python 3.8 PyTorch 1.13直接报一堆找不到符号的错误。更麻烦的是很多AI库的版本号并不遵循严格的语义化版本小版本之间也可能有破坏性变更。所以第一件事不是急着写模型代码而是把环境管理这件事当成一个正经的工程问题来对待。我的建议是永远不要在系统Python里装AI依赖。系统Python是给操作系统用的你污染了它后面出问题排查起来会非常痛苦。2.2 用conda做环境隔离用pip-tools锁死版本具体做法上我习惯用conda创建独立环境再用pip-tools做依赖锁定。conda的好处是它能同时管理Python版本和非Python的二进制依赖比如CUDA相关的库这是纯pip做不到的。创建环境的命令很简单conda create -n ai-eng python3.10 -y conda activate ai-eng但光创建环境不够关键是要把依赖“锁死”。很多人习惯直接pip install torch transformers这样装出来的版本是浮动的今天和明天可能就不一样。正确做法是维护一个requirements.in文件只写顶层依赖然后用pip-tools生成带完整版本号的requirements.txtpip install pip-tools pip-compile requirements.in -o requirements.txt pip-sync requirements.txtrequirements.in里可以写得比较宽松比如torch2.0但pip-compile会把它解析成torch2.1.2这样的精确版本连同所有间接依赖一起锁定。这样团队里每个人、每台机器装出来的环境完全一致“在我机器上能跑”这句话就不再是借口了。提示如果你的项目需要GPU支持conda环境里的PyTorch版本要和系统CUDA驱动版本匹配。用nvidia-smi看驱动支持的CUDA最高版本然后去PyTorch官网查对应的安装命令不要凭感觉装。2.3 一个容易被忽略的细节模型权重的版本管理环境锁定了还有一样东西经常被忽略——模型权重。很多人从网上下载一个预训练模型往~/.cache里一放就再也不管了。等到半年后要复现实验发现当初那个模型已经被作者更新了权重文件变了结果对不上。我的做法是把模型权重的哈希值记录在项目里。下载完模型后算一下文件的SHA256写进一个model_manifest.json加载前校验一次。多花两行代码省掉未来无数扯皮。3. 数据管道的搭建AI系统里最脏最累但最不能省的一环3.1 数据管道的三个核心阶段任何AI系统的数据管道本质上都逃不过三个阶段采集与清洗、预处理与特征化、批处理与喂给模型。听起来简单但每个阶段都有大量细节。我见过太多项目模型结构设计得很精巧结果因为数据管道里一个编码问题导致训练时loss一直不收敛排查了两天才发现是某几条样本的文本编码不是UTF-8。采集与清洗阶段核心是“把脏数据挡在门外”。具体包括去重、去噪、格式统一、异常值处理。这里有个经验不要试图在训练脚本里做清洗。清洗逻辑应该独立成一个模块有单独的测试用例因为清洗规则会随着数据源变化而频繁调整混在训练代码里会让整个脚本越来越难维护。3.2 预处理为什么要做成可配置的流水线预处理阶段我强烈建议用“流水线”的思路来组织而不是写一堆散落的函数。所谓流水线就是把每个预处理步骤定义成一个有输入输出的单元然后串起来。这样做的好处是每一步都可以单独测试、单独替换、单独监控。比如文本分类任务流水线可能是分词 - 截断 - 转ID - 加特殊符号 - padding。每一步都是一个独立的类有process方法。为什么强调可配置因为不同模型对输入的要求不一样。BERT要求[CLS]和[SEP]GPT系列不需要有的模型要求固定长度有的支持动态长度。如果预处理逻辑写死了换个模型就得改代码。做成配置驱动后换模型只需要改配置文件代码不动。class Pipeline: def __init__(self, steps): self.steps steps def run(self, data): for step in self.steps: data step.process(data) return data3.3 批处理与内存一个真实的OOM排查案例批处理这块最大的坑是内存。我遇到过一个典型案例一个文本分类任务单条样本处理没问题但batch size设到64就OOM。排查后发现问题不在模型而在数据加载器——它一次性把所有样本的tokenized结果都缓存在内存里数据量一大就爆了。解决方案是改用惰性加载每次只取当前batch需要的数据。这里有个经验值可以参考对于文本任务如果序列长度是512模型参数量在1亿左右单卡16GB显存batch size设16到32比较稳妥。但这只是起点实际要根据nvidia-smi的显存占用动态调整。我习惯在训练脚本里加一个显存监控每100步打印一次峰值显存方便及时发现内存泄漏。注意PyTorch的DataLoader如果设了num_workers0每个worker都会复制一份数据。数据量大时这本身就会吃掉大量内存。一个折中方案是用num_workers2到4配合pin_memoryTrue在内存和速度之间取平衡。4. 模型加载与推理优化从“能跑”到“跑得快”的关键几步4.1 模型加载的三种模式与适用场景模型加载看起来只是from_pretrained一行代码但背后有三种模式适用场景完全不同。第一种是全量加载把整个模型权重读进内存适合训练和需要完整推理的场景。第二种是分片加载把模型按层切分逐层加载适合超大模型在有限内存下推理。第三种是量化加载把权重从FP32转成INT8或INT4内存占用直接降到四分之一甚至八分之一代价是精度略有损失。选择哪种模式取决于你的硬件和精度要求。如果显存充足、追求最高精度全量加载FP16是首选。如果显存紧张量化加载是必选项。我实测下来INT8量化对大多数分类任务的影响在1%以内但推理速度能提升30%到50%内存占用减半性价比很高。4.2 推理加速的四个层次推理加速不是单一技术而是一个从浅到深的层次体系。第一层是算子融合把多个小算子合并成一个大算子减少kernel启动开销。第二层是图优化把计算图里冗余的节点去掉比如常量折叠。第三层是量化降低数值精度。第四层是编译优化用TorchScript或ONNX Runtime把模型编译成更高效的中间表示。对于大多数项目我建议先从ONNX Runtime入手。把PyTorch模型导出成ONNX格式再用ONNX Runtime推理通常能获得1.5到2倍的速度提升而且改动很小。导出命令大致是这样torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{input_ids: {0: batch, 1: seq}}, opset_version14 )dynamic_axes这个参数很关键它让导出的模型支持动态batch和动态序列长度。如果不设模型就只能处理固定形状的输入实际用起来会很受限。4.3 一个反直觉的发现批处理不一定总是更快很多人以为batch size越大吞吐越高。这话在GPU利用率没饱和时成立但一旦饱和继续增大batch只会增加延迟吞吐不再提升。我做过一组测试在单张T4上跑一个BERT-base模型batch size从1加到32吞吐从每秒80条涨到每秒420条但从32加到128吞吐只从420涨到450而单条延迟从76毫秒涨到了280毫秒。对于在线服务这个延迟增长是不可接受的。所以正确的做法是先测出吞吐-延迟曲线再根据业务对延迟的容忍度选batch size。在线服务通常选延迟拐点之前的batch size离线批处理则可以选吞吐最高的点。这个曲线每个模型、每种硬件都不一样必须实测不能拍脑袋。5. 服务化与接口设计让模型真正被业务用起来5.1 为什么FastAPI是AI服务的主流选择模型训练完最终要暴露成接口给业务调用。选什么框架我的答案是FastAPI。原因有三第一它原生支持异步AI推理往往是IO密集和计算密集混合异步能显著提升并发能力第二它自动生成OpenAPI文档前后端联调时省掉大量沟通成本第三它的依赖注入机制很适合管理模型这种“重资源”。一个最小的推理服务大概长这样from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model load_model() class Request(BaseModel): text: str app.post(/predict) async def predict(req: Request): result model.infer(req.text) return {label: result.label, score: result.score}但生产环境不能这么简单。至少要加上请求限流、超时控制、异常兜底、健康检查。限流用slowapi超时用asyncio.wait_for健康检查单独开一个/health接口返回模型加载状态。5.2 模型预热与冷启动问题服务刚启动时第一次推理往往特别慢因为模型权重还在CPU内存里需要先搬到GPU各种缓存也没建立。这个现象叫冷启动。解决办法是预热服务启动后主动用几条假数据跑几次推理把该初始化的都初始化好再开始接收真实请求。预热的数据要覆盖不同的输入长度因为不同长度会触发不同的计算路径。我一般准备三条最短、中等、最长。预热完成后再对外暴露服务。这一步在Kubernetes这类环境里尤其重要否则滚动更新时会有大量请求打到还没预热好的实例上导致超时。5.3 批处理服务化的两种模式在线服务里做批处理有两种模式。一种是客户端批处理调用方一次传多条数据服务端一起处理。这种模式简单但要求调用方能攒批。另一种是服务端动态批处理服务端维护一个队列把短时间内到达的多个请求合并成一个batch一起推理。这种模式对调用方透明但实现复杂需要处理超时和队列积压。我倾向于先用客户端批处理简单可靠。如果QPS很高、单条请求又很小再考虑服务端动态批处理。动态批处理的超时设置很关键设太短攒不到批失去意义设太长延迟增加。经验值是10到20毫秒具体看业务对延迟的敏感度。6. 监控、日志与成本控制上线只是开始6.1 模型服务必须监控的四个指标服务上线后最怕的是“悄无声息地坏掉”。模型不会抛异常但输出可能已经不对了。所以监控要覆盖四个维度延迟、吞吐、错误率、以及模型输出分布。前三个是常规的后端指标第四个是AI服务特有的。输出分布监控怎么做简单做法是统计每个类别的预测占比如果某个类别的占比突然从10%跳到80%大概率有问题。更精细的做法是监控输入数据的分布比如文本长度、token数量如果输入分布发生漂移输出很可能也会漂移。这些指标不需要实时计算每小时跑一次批处理统计就够了。6.2 日志要记什么不要记什么日志方面我的原则是记元数据不记原始数据。什么意思请求ID、时间戳、输入长度、推理耗时、输出类别这些要记。但原始文本、原始图片不要往日志里写一是量大二是涉及隐私。如果确实需要留存原始数据做分析应该写到单独的存储里加访问控制而不是混在应用日志里。日志级别也要控制。DEBUG级别在开发时有用生产环境一定要关掉否则日志量会爆炸。INFO级别记录关键流程WARNING记录可恢复的异常ERROR记录需要人工介入的问题。我见过一个服务因为把每次推理的中间张量都打成DEBUG日志一天写了2TB日志把磁盘写满了。6.3 成本控制的三个抓手AI服务的成本主要来自三块GPU资源、存储、以及网络带宽。GPU是大头。控制GPU成本第一个抓手是提高利用率通过批处理和并发让GPU尽量跑满。第二个抓手是弹性伸缩低峰期缩容高峰期扩容。第三个抓手是模型压缩用蒸馏、剪枝、量化把模型变小小模型能用更便宜的卡甚至CPU。这里有个容易忽略的点空闲实例也在烧钱。一个GPU实例即使不处理请求只要开着就在计费。所以弹性伸缩的缩容策略要激进一点宁可扩容时慢几秒也不要让实例长时间空转。我一般设两个阈值CPU/GPU利用率低于20%持续5分钟就缩容高于70%持续1分钟就扩容。7. 从零搭建的完整路径与个人经验把上面这些串起来一个AI工程项目的完整路径大致是环境隔离与依赖锁定 - 数据管道搭建 - 模型加载与推理优化 - 服务化与接口设计 - 监控与成本控制。每一步都有坑每一步都需要实测没有哪一步能靠“默认配置”蒙混过关。我个人在实际操作中的体会是最容易被低估的是数据管道最容易被高估的是模型本身。很多人把80%的精力花在调模型上结果发现效果提升有限而把数据管道理顺、把推理优化做好带来的收益往往更大。一个清洗干净的数据集比一个花哨的模型结构管用得多一个优化到位的推理服务比换更贵的GPU更省钱。最后分享一个小技巧给每个环节都写一个最小可复现的测试。环境测试、数据管道测试、模型加载测试、接口测试每个测试都独立运行不依赖其他环节。这样出问题时能快速定位是哪个环节坏了而不是在一大坨代码里大海捞针。这个习惯是我踩了无数次坑之后才养成的希望你不用走同样的弯路。