去年我把一个内部算法项目推上线的时候被问得最多的一个问题就是“这东西在 notebook 里明明跑得好好的为什么一上服务就四处冒烟”其实答案不复杂——跑通一个模型和做好一个 AI 工程中间隔着一条巨大的河。这条河的名字叫工程化。ai-engineering-from-scratch说的就是从零开始把 AI 这件事做成工程而不是停留在调参和炼丹。它面向的不是纯算法研究员也不是纯后端开发而是那些想独立把模型从 idea 推进到生产环境的人。无论你是刚转行想做 AI 工程的应届生还是已经在做算法、想补齐工程短板的工程师这篇内容都值得你花时间看完。我会把从零搭建一套 AI 工程体系的核心链路拆开讲清楚每一环是什么、为什么需要它、以及我踩过的坑。1. 先想清楚AI工程和“调模型”之间的那条界线1.1 算法工程师和AI工程师到底差在哪儿很多人觉得 AI 工程师就是会写 Python、会调 sklearn 或 PyTorch 的人其实远不止。算法工程师的核心任务是找到“能用的模型”AI 工程师的核心任务是让模型“持续稳定地产生价值”。这两个目标在大多数情况下是冲突的。举个我真实经历过的例子。当时团队里算法同事给了一个效果很不错的文本分类模型精度 92%在测试集上表现近乎完美。但当我准备接入生产环境时发现训练代码跑在 Python 3.7 TensorFlow 1.15 上模型文件 1.2GB单次推理耗时 380ms而且没有做任何预处理封装。这意味着每来一条请求线上服务都要自己处理分词、编码、padding稍有偏差推理结果就完全不一样。这就是典型的“模型可用系统不可用”。算法同事交付的是模型本身AI 工程师要交付的是包含模型在内的完整系统。1.2 工程化的四个核心维度从零做 AI 工程你绕不开以下四个维度我把它们称为 AI 工程的四根柱子可复现性三个月后你还能不能把同一个模型重新训练出来如果做不到所有实验都是无效功。这里涉及代码版本管理、数据版本管理、环境依赖锁定三件事缺一件都白搭。可扩展性数据量翻十倍、调用量翻百倍你的系统还撑得住吗训练管道能不能横向扩展推理服务能不能自动扩缩容这决定了系统能活多久。可观测性模型上线后效果衰减了你能不能在 30 分钟内发现并且快速定位是数据漂移、特征异常还是上游服务问题还是说只能等用户投诉可维护性换一个人来接手你的系统他需要看多少文档、花多长时间才能上手改代码模型要更新你的发布流程顺不顺畅这四根柱子你在做任何 AI 工程决策时都可以拿出来对照如果某个环节撑不住就要停下来补而不是硬着头皮往下走。1.3 为什么“从零开始”和“从模型开始”是两回事常见的错误路径是这样的先选模型再找数据然后训练最后才想部署。这是“从模型开始”的路径。而从零开始做 AI 工程正确路径是反过来先明确业务问题的评估口径再设计数据管道和特征体系然后确定模型的服务化约束延迟、吞吐、成本最后才是算法选型和训练。这个顺序很重要因为它决定了你做事的优先级。举个例子如果业务方告诉你线上推理延迟不能超过 100ms那你一开始就该知道 1.2GB 的 BERT 模型大概率撑不住要么换小模型要么上蒸馏/量化要么做模型缓存。如果你等到模型训练完才开始考虑延迟前面几周的时间基本就白费了。2. 平台与环境的搭建跑通第一个训练任务只是开始2.1 GPU环境一场版本依赖的噩梦先从最基础的算力环境讲起。很多人第一次拿到一台带 GPU 的服务器第一反应是先装驱动、装 CUDA然后迫不及待跑pip install torch。然后……就没有然后了因为版本对不上。我在早期就吃过这个亏。当时装了一个比较新的 PyTorch结果它要求 CUDA 11.8 以上而服务器上驱动只支持到 11.2最后只能卸了重装一通折腾多花了半天时间。理解这个链条很重要GPU 驱动决定你能装什么版本的 CUDACUDA 决定 PyTorch/TensorFlow 能不能用 GPU 加速。三者的关系就像操作系统、运行时和应用程序层层依赖不能乱配。我后来整理了一个相对保守的搭配方案不管是自己做实验还是小团队共用服务器照着配基本不会出大问题PyTorch版本CUDA版本要求GPU驱动最低版本Python建议版本1.13.x11.6/11.7Linux x86_64 驱动 5103.8 - 3.102.0.x11.7/11.8驱动 5153.8 - 3.112.1.x12.1驱动 5303.9 - 3.122.4.x12.4驱动 5353.9 - 3.12注意这里的驱动版本号只是参考实际情况跟你用的发行版、容器镜像、驱动发布时间都有关系。最快的验证方式是在 Python 里跑一句torch.cuda.is_available()再跑一个小矩阵乘法看 GPU 利用率是否正常。2.2 用Docker统一开发与生产环境如果你不想重蹈版本地狱的覆辙尽早引入 Docker 是性价比最高的决定。容器的核心价值不是“虚拟化”而是环境即代码——把 Python 版本、CUDA 版本、依赖库、系统库全部写进 Dockerfile任何人 pull 下来都能复现相同环境。一个基础训练环境的 Dockerfile 大概是这样的FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime WORKDIR /workspace COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src ./src COPY configs ./configs ENV PYTHONPATH/workspace CMD [python, src/train.py]这里有几个细节值得注意。第一基础镜像建议直接用官方 PyTorch 镜像或者 NVIDIA NGC 镜像它们已经把 CUDA 和 cuDNN 匹配好了比自己装省心太多。第二requirements.txt里的每个包都要锁定精确版本号至少锁定到次版本号不然下个月你同事 pull 下来跑出来的结果可能就不一样了。第三代码里不要写死路径用环境变量或者配置项注入否则容器内外路径不一致会让新手直接懵掉。2.3 资源调度从单机到多卡跑通单机训练之后你迟早会遇到多卡并行的问题。这里先不展开分布式训练原理只说顶层决策不要一上来就上分布式。很多人看到数据量大第一反应是“我要用 Horovod / DeepSpeed / 多机多卡”。但分布式训练引入的复杂度是全方位的——网络通信、数据切片、梯度同步、容错恢复。如果你的单卡训练只需要 3 天而搭分布式集群要花一周以上那纯属负优化。我推荐的路线是单卡能跑就先单卡单卡跑不完先试梯度累积、混合精度AMP再不行试单机多卡torchrun就能搞定最后才考虑多机。每一步的增量复杂度都很明确每一步都有收益但没必要一步跨到最复杂那层。3. 数据管道设计AI工程里最容易被低估的“重活”3.1 数据质量直接决定模型天花板给大家算一笔账。一个典型的 AI 项目算法模型的部分通常只占整个系统工作量的 20% 左右数据采集、清洗、标注、特征工程、版本管理这些“脏活累活”占掉 60% 以上的时间。但绝大多数人做项目规划的时候把这 60% 的时间压缩成了一行——“数据准备两周”。轻描淡写的原因很简单数据看着谁都会处理无非是读 CSV、去重、填缺失值。但真正进入生产环境之后你会发现数据管道远比想象中复杂。比如业务库凌晨 2 点做数据归档你的训练管道刚好在那里断掉用户特征有 30% 来自实时埋点这些数据在凌晨是缺失的直接影响次日模型训练分布。3.2 分层设计让每一份数据都有清晰归属我实践下来比较好用的数据管道分层方式是这样的层级内容存储方式职责原始数据层业务库导出的日志、埋点、商品信息对象存储 分区表只追加不修改永久保留清洗层去重、过滤异常、统一时间格式后的数据列式存储Parquet可回溯可重放特征层经过特征工程加工后的宽表/特征库特征存储离线和在线共用同一套特征逻辑训练/测试集按时间或随机方式划分的数据切片快照文件每次实验锁定版本不可覆盖这个设计的好处是每一层都可以独立回溯和重放。如果线上发现特征算错了不需要重新跑到业务库拉全量数据直接从清洗层重算就行。如果训练效果不好怀疑是数据划分问题直接从快照层取出当时那份数据重新调参验证。3.3 数据版本管理可复现性的第一道防线模型训练的输入不只是代码还有数据。你修改了数据清洗逻辑哪怕只是一行代码产出的训练集就已经变了。如果不做数据版本管理就会出现这种情况三月跑出来的模型效果很好但你想复现的时候发现原始表已经被业务方删了、清洗脚本改了三版、特征代码也更新过两次——复现彻底没戏。数据版本管理的最朴素做法是每次生成训练集时把数据的哈希值对全量数据文件算 MD5记录到实验日志里更成熟的做法是对整个数据集目录打标签用专门的数据版本管理工具或系统来管理这样不但能记录哈希还能关联到具体的数据生产时间和生成脚本版本。我个人强烈建议至少做到“哈希记录”这一步因为它是手工可复现的最低成本方案。在你还没有上完整 MLOps 平台之前一条记录里写上“数据目录 文件哈希 生成脚本 commit id”就足够让你在三个月后快速定位当时用的数据长什么样。3.4 离线在线一致性一个让无数学长头疼的坑最后讲一个特别隐蔽但破坏力极高的坑离线特征和在线特征不一致。离线训练时模型用的是全量用户的统计特征比如“该用户过去 7 天浏览次数”在线推理时实时管道从 Redis 里取特征结果发现那条记录的更新逻辑是“用户发生行为后异步写入”有的用户特征停留在 3 天前。这意味着训练时模型看到的是完整的历史统计线上却喂给它过期的特征值效果不崩才怪。根因就是离线特征和在线特征的加工逻辑没有对齐。解决这个问题没有银弹只能从工程上约束离线特征加工脚本和在线特征服务必须共用同一套特征定义代码特征上线前要做一致性校验抽样对比离线和在线产出的特征值特征的写入延迟必须有监控。这些都属于“看起来不难但需要坚持做”的工程纪律。4. 实验追踪与模型管理把“玄学炼丹”变成可复盘的工程4.1 跑完就忘是实验环节的最大浪费早期我做实验习惯很不好改一行参数跑一个新版本看一眼结果感觉不行就换下一个思路。一周下来跑了十几个实验但已经分不清哪个实验对应哪组超参、哪份数据、哪个代码版本。等到某个结果突然看起来不错想回溯它怎么来的整个人直接懵掉。后来我把这个教训总结成一句话不做实验记录等于白跑实验。推荐的实验记录至少包含三部分参数配置完整超参数 数据版本 代码 commit id关键指标训练损失、验证指标、推理耗时、显存占用产物链接模型文件、预测结果样本、日志文件4.2 用工具把记录变成习惯现在有现成的实验追踪工具常见的有 MLflow、Weights BiasesWB、Neptune 等你不需要重复造轮子。我个人的建议是先从 MLflow 入手因为它开源、部署简单、和本地文件/数据库/S3 都能良好集成。一个最小可用的 MLflow 集成代码大致长这样import mlflow mlflow.set_experiment(text-classification) with mlflow.start_run(): # 记录参数 mlflow.log_param(model_name, bert-base-chinese) mlflow.log_param(learning_rate, 2e-5) mlflow.log_param(batch_size, 32) # 训练代码... # 记录指标 mlflow.log_metric(val_accuracy, val_acc) mlflow.log_metric(val_f1, val_f1) # 记录模型文件 mlflow.pytorch.log_model(model, model, registered_model_nametext_cls_v1) # 记录数据/代码版本 mlflow.log_param(data_version, 20240613_v2) mlflow.log_param(code_commit, a1b2c3d4)这种做法能不能让实验效果变好不能。但它能保证你做实验的信息不丢失并且让后来者——包括三个月后的你自己——能够快速理解当时发生了什么。4.3 模型注册与上线评审实验追踪解决的是“我跑过什么”模型管理解决的是“哪个模型在线上运行”。实践中很多人把模型文件直接扔到网盘或者本地目录谁要用谁自己去下载。这种模式在没有协作压力的时候没问题一旦团队超过三个人就开始乱套了——线上服务的模型版本和最新训练出来的版本对不上回滚的时候不知道哪个是稳定版。正规一点的流程是引入模型注册中心。MLflow Model Registry、或者云厂商的模型管理服务都行。核心动作只有两个模型上线前必须从实验版本提升为 Staging再经过线上验证后标记为 Production线上系统明确指定读取 Production 标签的模型而不是直接读文件路径。这样每次发版和回滚都有据可查。5. 推理服务化模型真正开始产生价值的地方5.1 模型上线前后的思维方式切换训练时模型追求的是尽可能高的精度推理服务追求的是在精度、延迟、吞吐、成本之间找到可接受的平衡。这两个目标天然有张力不能照搬训练思维。举个例子训练时你可以用 batch size 128 把 GPU 利用率打满推理时如果业务请求是稀疏的你却非要攒够 128 条才处理用户体验就直接崩了。推理服务必须考虑流式请求的动态到达通常是动态 batching——来多少处理多少每攒几十毫秒或者攒够一定数量就批量推理一次既提升吞吐又控制延迟。5.2 推理框架如何选现在做模型服务化可选方案很多我整理了一个对比表方便你结合自己场景判断方案优点缺点适合场景FastAPI TorchServe轻量、Python技术栈友好、上手快高并发和GPU利用率优化弱中小流量、快速验证NVIDIA Triton支持多框架、动态batching、并发优化强配置较复杂、需要理解GPU调度高吞吐、多模型、生产级TensorFlow Serving生态成熟、性能好主要支持TF模型其他框架适配一般纯TF系重场景自研推理服务完全可控、可定制成本极高踩坑成本高有特殊需求且团队充裕我的建议如果你的业务规模还处于早期用 FastAPI 快速包一层跑通业务闭环是第一优先级如果已经明确进入高并发阶段或者 GPU 是主要成本就直接上 Triton 认真优化。中间态是最难受的不上不下最浪费精力。5.3 推理性能优化从模型到系统的三把刀推理服务上线之后最先要解决的就是“响应为什么这么慢”的问题。我有三个常规优化方向按收益排序第一把刀是模型压缩。方法包括模型量化INT8 通常能带来 2-3 倍加速、知识蒸馏用一个大的教师模型训练一个小的学生模型、剪枝去掉不重要的权重通道。量化是见效最快、改动最小的一步优先尝试。第二把刀是推理系统优化。包括上面提到的动态 batching、模型预热避免第一个请求触发懒加载、多进程并行PyTorch 的torch.multiprocessing配合正确配置可以显著提升吞吐、以及使用 TensorRT 等推理引擎替换原生 PyTorch 推理。有时候只是换一个推理后端延迟就能下降到原来的三分之一。第三把刀是缓存。如果你的业务里存在大量重复请求比如同一用户短时间内重复查询同一商品在推理服务前面加一层结果缓存可以直接跳过模型计算效果立竿见影。不过要留意缓存的时间窗口和一致性策略避免给用户返回过期的推理结果。5.4 模型上线后的监控从部署那一刻才开始很多人把模型部署上线当成项目的终点但实际上线交付之后监控和运维才是长期运营的开始。模型监控和传统后端监控不太一样除了常规的延迟、吞吐、错误率之外还要重点关注数据漂移线上推理数据的分布和训练分布是否发生明显偏移。比如训练时用户年龄集中在 20-30 岁某段时间突然涌入大量 50 岁以上用户模型效果大概率下降。特征失效某个特征列突然返回空或者常量会导致模型输出偏差。特征监控要比模型指标监控更早发现异常。业务指标最终业务方关心的是转化率、留存率、满意度这些模型指标只是中间变量。模型在验证集上掉了一个点对业务影响到底是 0.1% 还是 10%需要通过业务指标联动来判断是否需要立即回滚。在监控报警上我坚持一个原则报警宁可多不能少但不能全是无效报警。每个报警都要配置对应的处理手册否则报警疲劳之后真正重要的问题会被淹没。5.5 灰度发布与回滚降低模型更新的风险模型上线最大的特点是没有“绝对正确”——同一个模型在 A/B 测试里可能对一部分用户更好、对另一部分用户更差。所以模型更新必须走灰度永远不要直接全量替换。一个简单的灰度流程是这样先把新模型部署到预发环境跑通烟雾测试然后切 5% 流量观察业务指标和模型监控指标确认无异常后逐步放大到 10%、30%、50%如果任何阶段指标异常立即切回旧模型这就是模型注册中心里保留 Production 标签版本对回滚的价值。这里还要留意一个细节新旧模型切换期间特征版本、预处理逻辑都要保持一致否则混流状态下数据口径都不统一A/B 对比的结果就没有参考价值。写在最后从零到一我给自己的三点提醒如果让我把做 AI 工程这几年踩过的坑浓缩成几句话我会这么说AI 工程的核心不是模型多先进而是系统多稳定。把数据集版本锁死、把训练环境容器化、把实验记录做完整、把线上监控配齐这四件事做到位你的系统就已经超过大多数团队了。别一开始就追求大模型、分布式、自动化平台先把地基打扎实。另外一个小习惯强烈推荐给你每次上线或复盘后把遇到的问题和解决过程记成文档放到团队知识库里。我自己翻看这些记录时经常发现半年前踩过的坑又有人在前赴后继地踩。一份真实、具体、有上下文的问题记录比 100 条泛泛的规范更管用。最后也是最重要的——保持对业务的敏感。AI 工程做久了容易沉浸在技术细节里忘了模型最终要为业务创造价值。每隔一段时间跳出来问自己一句这个模型在线上真的被用起来了吗它有没有让用户或业务变得更好如果答案是否定的那不管技术多漂亮这个工程都是失败的。