把跑通一个AI服务和工程化落地一个AI服务彻底分开来看是我做这套从零整理时最强烈的感受。标题里的ai-engineering-from-scratch说白了就是希望给那些已经会调模型、会跑notebook但还没亲手把一个模型变成稳定线上服务的人一条完整的、能照着走的路。我在这条路上踩过不少坑也摸索出了一些很实用的套路这篇就把我的完整思路和实操经历摊开来讲希望能帮你省掉几个月的摸索期。1. 先说清楚AI工程到底难在哪从一次代码能跑的假象说起我最早带团队的时候经常遇到一个诡异的现象算法工程师在本地Jupyter Notebook里把模型调得漂漂亮亮离线指标也很能打代码交到工程手里部署上线之后效果却一路下滑甚至直接报错。两边互相看不懂算法说工程没按我的版本来工程说算法代码里全是隐藏的状态依赖。这种撕裂感就是AI工程要解决的问题。1.1 本地能跑和线上能扛差距不在模型而在系统你在notebook里做的推理是数据一次性加载到内存里模型直接调用输出打印在屏幕上。线上服务呢请求是并发进来的数据是会变的模型显存是要被多路复用的进程是会崩溃的数据分布是会漂移的。哪怕你的模型精度再高只要这几层没处理好线上效果照样稀烂。我见过有的团队上线一个文本分类模型在测试集上F1高达0.93上线后业务方反馈一堆错误案例。排查到最后发现线上接口收到的文本是经过脱敏和截断的和训练时用的原始文本根本不是同一种分布。模型本身没错错的是数据链路的断裂。这类问题的本质就是数据和模型之间没有任何形式的一致性约束。训练时一套处理逻辑推理时又写了一套两边各改各的不出问题才是运气好。1.2 从零开始到底是在开始什么这个标题里的from scratch我的理解不是要你不利用任何预训练模型、从反向传播手写一个神经网络而是指你要从一张白纸开始搭建一套能持续迭代的AI工程系统。它包含至少五条线层级核心内容常见载体数据层数据采集、清洗、版本化、Schema校验DVC、Great Expectations、Parquet训练层实验追踪、超参管理、可复现训练MLflow、WB、PyTorch Lightning部署层模型转换、镜像化、服务化、弹性伸缩Docker、ONNX、FastAPI、vLLM观测层指标监控、日志采集、漂移检测Prometheus、Grafana、Evidently治理层权限管理、审批流、多版本共存、回滚Model Registry、Kubernetes这五条线每一条单独拎出来都能写一本书。但如果你从零开始我强烈建议先完整串联一遍再逐个深入。先把一个最小的端到端链路跑通哪怕模型用的是现成的开源模型也要让这条链路具备可以上线的基本素质。2. 从零起步的第1公里环境、数据与算力三个地基很多人学AI工程是从训练开始的这其实是本末倒置。我自己的经验是前面三件事不打牢后边你会在各种奇怪的问题上反复躺枪。2.1 开发环境把在我机器上能跑这句话彻底消灭掉环境不一致是AI工程里最让人头秃的坑。算法同事用Python 3.9你用3.11他装的是CPU版PyTorch你用GPU版模型推断出来的数值都能对不上。解决这个问题的唯一办法就是用工具把环境锁死。我的标准配置是这样的用pyenv管理Python版本项目根目录放一个.python-version内容就是3.11.9谁进来都切到这个版本用uv或者pip-tools管理依赖生成uv.lock文件所有传递依赖的版本都锁死整个开发环境做成Docker镜像Dockerfile里固定python:3.11-slim基础镜像把CUDA、cuDNN版本写死在镜像里而不是依赖宿主机装了什么训练和推理共用同一个镜像从根上避免训练有这依赖推理缺那依赖。有个非常反直觉的细节Docker镜像的体积比你想的更影响开发效率。本地构建模型服务镜像时如果你用基础镜像手动装一堆系统库镜像体积很容易超过3GB传到镜像仓库就能把人急死。我后来改用多阶段构建把编译阶段和运行阶段拆开生产镜像能压到800MB以内拉取时间大幅缩短。2.2 数据规格化先定Schema再谈训练数据是AI最容易被忽视的地基。我见过太多团队数据文件直接用CSV来回传字段类型靠猜日期格式各写各的跑着跑着字段加了几个下游模型训练代码就崩了。更好的做法是统一存储格式能上Parquet就别用CSV自带列式存储和压缩大数据量读写性能差距是数量级的写Schema校验用Great Expectations或者pandera定义每一列的类型、取值范围、非空约束数据进管线之前先过一道校验不满足直接报警数据版本化每次训练用的数据集记录下哈希值哪怕只是改了一个字段版本号也要变。DVC是这方面最常用的工具它不存全量数据只存数据文件的哈希指针配合Git正好用。这一步很多初学者嫌麻烦觉得我数据量小不需要这些。但我可以告诉你一个大概率会发生的事故你某一天手工修改了一份CSV给一个新字段补了值不知不觉间改变了整体分布重新训练后的模型效果忽好忽坏而你完全不知道为什么。这时候再回头想Schema校验和版本管理代价已经高了很多。2.3 算力意识别让GPU账单变成你的天价学费算力这个东西训练之前不规划训练完就后悔。我自己在这上面吃过亏所以现在给自己定了两条硬规矩第一大规模训练之前先小规模试跑。比如打算用100万条数据微调先用1万条跑一个批次确认数据格式没问题、Loss在下降、日志输出正常再放开全量。这个小时级的试跑能避免你浪费几百块的GPU时长的同时还收获一堆报错日志。第二给训练任务设预算上限。主流云厂商都有预算告警机制设置好上限一旦快触顶就自动发通知。别觉得这没必要分布式训练里的野路子代码是什么开销水平账单一出你就清楚了。印象非常深刻的一次我忘了关一个测试用GPU实例连着跑了三天那一个月的成本直接顶平时三个月。从那天起关资源和写代码并列成为我的日常必做事项。3. 训练与微调不是点个开始就行可复现才是准入门槛训练环节很多人的误区是追求指标好看忽略了可复现性。可复现这个东西枯燥不性感但它是工程化训练和实验室训练的分水岭。3.1 实验追踪你的训练记录不是聊天记录早期我做训练实验用的方式是本地新建一个文件夹然后起名model_v2_final、model_v2_final_real、model_v2_final_real_v3。这种命名方式的后遗症用不了几个月你就会彻底想不起来哪个版本用了哪份数据、哪个超参组合。真正工程化的做法是用MLflow这类实验追踪工具。每次训练前把关键信息全部记录进去import mlflow with mlflow.start_run(run_namebert-finetune-batch32-lr2e5): # 记录参数 mlflow.log_param(learning_rate, 2e-5) mlflow.log_param(batch_size, 32) mlflow.log_param(dataset_version, 2025-06-01_v3) mlflow.log_param(base_model, bert-base-chinese) # 训练代码... # 记录指标 mlflow.log_metric(val_f1, 0.923) mlflow.log_metric(val_loss, 0.18) # 记录模型 mlflow.pytorch.log_model(model, model)这么做短期看似乎多写了几行代码但长期带来的好处是你能回答这个模型是怎么来的这个问题。线上模型出问题时第一步不是看代码而是查实验记录搞清楚这个模型用了什么数据、什么基座、什么超参然后再定位问题。这套追溯能力生产环境必备。3.2 大模型微调能不动全量参数就别动针对微调开源大模型我最避讳的做法就是一上来全量微调。全量微调的成本高、训练不稳定、而且一个团队如果微调了很多个垂直模型部署时的显存开销会让人崩溃。现在做微调基本都是参数高效微调的路数其中LoRA和QLoRA是最常见的两个选择。LoRA的原理通俗讲就是不改变原来的模型权重只在你关心的线性层旁边加两条低秩矩阵只训练这两条小矩阵原来的权重冻结不动。这样显存占用小很多训练速度也快而且微调完你得到的其实是一个很小的增量权重文件几MB到几十MB部署时可以动态加载合并也可以单独走一条推理分支。QLoRA更进一步把基座模型的权重先4bit量化在量化后的基座上做LoRA训练效果在大多数指令微调场景下和全量微调的差距已经很小。我在一个法律文书分类项目里验证过全量微调一个7B模型需要4块A100训练时间超过6小时改用QLoRA之后单卡A10G就能跑时间缩到45分钟分类F1只掉了0.8个百分点。这种性价比工程化落地场景下几乎不用犹豫直接选QLoRA。3.3 随机与确定把实验误差从源头掐灭训练可复现最容易被忽略的是随机性。数据加载顺序、数据增强、Dropout、甚至CUDA的某些操作都有随机性。想让一次实验结果能被精确复现至少要固定这几个东西全局随机种子random.seed(42)、numpy.random.seed(42)、torch.manual_seed(42)torch.backends.cudnn.deterministic True把cuDNN切到确定性算法torch.backends.cudnn.benchmark False关闭自动寻找最优算法的逻辑DataLoader用worker_init_fn保证每个子进程的随机种子也固定。顺带说一个不坑你不舒服的细节全量复现要连同硬件一起考虑。A100上跑出来的PyTorch结果和V100上不一定完全一样浮点运算的微小差异是硬件层面的物理事实无法做到逐位一致。所以工程上对复现的定义通常是指指标在合理误差范围内可以再次得到而不是每小数点后六位都一模一样。4. 把模型交到线上用户手里部署链路上的最后一公里问题模型训练好了只相当于你做好了菜端到用户桌上还得过一条繁忙的走廊。这条走廊上的问题才是AI工程最实战的部分。4.1 模型转换不要用训练格式直接上线PyTorch训练出来的.bin或.safetensors格式直接塞进生产服务是不太合适的。一方面它体积大、加载慢另一方面它对部署环境里的Python和PyTorch版本极其敏感稍有不匹配就加载失败。我常用的做法是转成ONNX格式。ONNX就像一个中间语言把模型的计算图固化下来部署时不再需要完整PyTorch框架只要有一个ONNX Runtime的轻量运行时就能跑。实测下来ONNX版本在CPU上的推理速度通常比PyTorch原版快20%-50%显存占用还能降一些。import torch import onnxruntime as ort from transformers import BertForSequenceClassification # 训练好的PyTorch模型 model BertForSequenceClassification.from_pretrained(my_finetuned_bert) # 转出ONNX dummy_input {input_ids: torch.ones(1, 128, dtypetorch.long), attention_mask: torch.ones(1, 128, dtypetorch.long)} torch.onnx.export(model, (dummy_input[input_ids], dummy_input[attention_mask]), model.onnx, opset_version14, input_names[input_ids, attention_mask], output_names[logits])大型语言模型做生成式推理时用vLLM这类专门的推理引擎更合适。它用PagedAttention机制管理显存吞吐量比普通Hugging Face管线提升好几倍。我第一次把7B模型从Transformers管线切到vLLM时在面对相同请求吞吐量的情况下GPU卡数直接砍掉了三分之二效果相当直观。4.2 服务框架FastAPI只是入口稳定靠设计模型部署的服务框架现在基本是FastAPI标准打法异步接口、自带OpenAPI文档、性能也不错。但真正决定稳不稳定不是框架本身而是你这层API的设计超时设置模型推理有波动请求排队多了单次推理可能从50ms升到500ms。如果API不设超时网关等不起就会重复发起请求反而把系统压垮批量推理高并发场景下单条请求循环推理是非常浪费的。更好的方式是把请求攒一小批凑够batch_size或者到时间阈值再统一进模型推理背压机制模型服务处理不过来时要有主动拒绝的逻辑而不是无限接收请求把内存打爆。我见过一个上线事故因为接口没做批量推理又把模型服务的并发上限设成了和网关一样的值结果流量稍大GPU利用率只有个位数延迟却在不停飙升。优化成动态batching以后GPU利用率上到80%相同资源下吞吐翻了几倍延迟反而降了。4.3 版本共存线上模型不是只有一个模型版本管理这件事比代码版本管理要复杂得多。因为模型不是单纯靠Git就能管理的还要管理它的数据版本、训练配置、评估结果。用MLflow的Model Registry可以给每个模型版本打上状态标记Staging、Production、Archived。调用方明确指定版本号而不是每次都用latest。线上同时运行多个模型版本这个场景在工作里非常常见。比如新模型上线总得先切5%流量跑几天看看在线指标没问题再逐步放量有问题立刻切回旧模型。这个机制说起来简单但真踩过坑才知道没有多版本共存能力的模型平台回滚就是一次噩梦。曾经有一次新模型放量后线上投诉率升高我们想把流量切回旧模型结果发现旧模型已经在代码仓库里找不到对应文件了。所以我现在要求所有模型服务必须保留最近两个生产版本的推理接口随时可以秒级切换。5. 上线只是开始监控、回归与AI效果衰减的持久战模型上线后的工作往往比开发期还重。因为模型的输出不是确定性的数据分布会变用户行为会变效果会衰减。这个上线即终点的思维是AI工程里最危险的一种错觉。5.1 数据漂移你的模型正在悄悄变笨数据漂移是模型效果衰减的最大隐形杀手。它分两种一种是特征漂移训练数据的特征分布和线上实时数据的特征分布慢慢拉开差距一种是概念漂移同样一个特征值它对应的业务含义变了比如点击这个动作在界面上改了入口之后行为模式完全不同。检测特征漂移我常用两个指标PSIPopulation Stability Index用来衡量某个特征在两个时间段上的分布差异。一般认为PSI小于0.1是稳定0.1到0.25需要关注超过0.25就是明显漂移KL散度或JS散度适合衡量更精细的概率分布变化。监控到漂移之后怎么办不是立刻重训那是成本最高的选项。第一步先定位漂移源是上游数据源改了还是数据预处理逻辑变了第二步看业务侧有没有发生什么变动比如活动流量、推荐策略调整。确认是真实环境变化后再决定是否需要增量更新或重新收集数据训练。5.2 线上指标离线评估的指标好看不等于线上好用离线评估用的是F1、AUC、准确率这些标准指标但线上业务关心的是转化率、留存率、客诉率、处理时长。两者之间存在很大gap。我在文本审核模型项目里的体会非常深离线AUC高达0.98觉得已经无敌了。上线后业务方反馈漏过的违规内容比拦截掉的还多。后来一查离线测试集里违规和正常的比例是1:9但线上实际比例可能只有1:49。类别先验分布不同AUC这种阈值无关指标依然很漂亮但业务查的是漏报率一算下来完全不能看。所以线上监控至少要有两套口径运维口径请求量、p95/p99延迟、错误率、GPU利用率、内存占用业务口径按业务逻辑定义的预测正确率、拦截率、误杀率、用户投诉率、空结果率。比如做智能客服FAQ推荐用户没点击任何推荐答案的比例就是空结果率。模型效果如果衰减这个数字会上涨比看Loss更直接。5.3 告警不是越响越好要有一套不打扰人的告警规则很多人一上来就把所有监控指标都加了告警结果半夜三点被一条内存使用率78%的短信吵醒告警疲劳之后真正的严重事故反而没人理了。我现在的告警设置原则是只有需要人立刻介入的问题才告警。具体来说就是三层危险告警例如5分钟内错误率连续超过5%或者服务整体不可用。直接钉钉或短信打到人预警告警例如p95延迟连续15分钟超过200ms或者PSI超过0.2但还没到0.25。群消息通知工作日处理记录型告警一些噪音信号比如某个冷门接口错误率偶尔毛刺直接进日志和看板不打搅人。这套分层既能早发现问题又不把人逼疯。真正到线上你才会意识到稳定运行的系统不需要信息轰炸它需要的是关键时刻有人判断。6. 给自己一条可复制的从零路线图和避坑清单最后这部分我想给准备从零开始的你一份可以直接照着走的路线图。不要贪多不要跳步按这个顺序走完你就具备独立工程化一个小模型服务的能力了。6.1 三阶段实践路线阶段一跑通最小闭环。选一个简单任务比如文本分类或小规模FAQ匹配用你熟悉的预训练模型微调然后完成这些环节数据清洗、格式标准化、实验记录、模型保存、FastAPI封装、Docker部署、本地或云端跑通接口。不要一上来就上Kubernetes和自动扩缩容先把链路跑起来。阶段二加上工程底座。给这套链路配上数据版本管理、模型注册、监控看板、CI/CD流水线。哪怕你的项目只有一个人开发也走完这套流程。这一阶段最重要的不是你用了哪些工具而是你形成了每次改动都能追溯、每次上线都能回滚的肌肉记忆。阶段三做一次压测与优化。对你的服务做一轮并发压力测试找到瓶颈是卡在模型推理、数据处理还是机器资源然后针对性优化。这一步的价值是让你对系统的弹性有真实的感觉知道它什么时候会撑不住怎么扩展能撑住。6.2 高频踩坑清单我把自己在多个项目里反复出现的问题整理成一张清单每一条后面都是真实教训坑后果预防训练和推理的特征工程逻辑不一致线上效果莫名其妙差一截把特征处理封装成独立模块训练和推理共用同一个函数/包没有数据版本管理模型复现时找不到原始数据每个数据集记录哈希和版本号DVC存指针GPU显存没做小批量测试就全量跑OOM崩溃浪费大量时间先跑1%数据验证显存上限新模型上线不留旧版本需要回滚时找不到可回滚的东西至少保留两个生产模型版本随时可切换只看离线指标不看业务指标离线98分线上被业务方追着打定义主业务口径监控按业务指标实时看依赖锁在外层代码层版本靠猜部署环境复现失败Python依赖和系统依赖全部固化进Docker镜像用锁文件锁定监控指标全埋了但没人看事故发生了才发现告警早报了几天每周固定Review关键看板把告警按三层分级6.3 最后说一点我的真实体会从零开始做AI工程最反直觉的地方在于它真正的瓶颈往往不是模型能力而是系统思维。模型不好换一个、微调一下成本是可控的系统不稳定数据链路断裂、模型无法复现、上线不能回滚每一个问题都能让你堵上大半周。我见过不少技术很强的算法工程师模型训练一手好牌但工程化一到手就翻车就是因为此前没有完整地把一个系统跑上线的经验。反过来当你把数据、训练、部署、监控这条完整链路亲手走通之后再回到模型本身做优化你的判断维度就已经完全不一样了——你不光知道怎么能提升指标你还会衡量这个提升在工程上值不值得做部署成本能不能cover住线上监控能不能及时发现衰减。这条路的入门门槛确实不低但它远没有传说中那么玄乎。把上面每个环节都亲手过一遍你就拥有了真正的从零到一的AI工程能力而不是停留在调包跑通一个Demo的阶段。希望我的这些经验能让你少走一些我当年走过的弯路。