1. 从零搭建AI工程能力为什么“会调包”和“会做工程”是两回事很多人第一次接触AI项目时路径都差不多装个Python环境pip install几个库找一份开源notebook把模型跑通看到输出结果就觉得自己“入门AI”了。但真正到了要交付一个能用的系统时问题就全冒出来了——模型在本地跑得好好的放到服务器上就崩推理速度慢得离谱用户等三秒就关页面显存不够、并发一上来就OOM日志里全是看不懂的报错排查半天发现是数据预处理阶段埋的雷。这就是“ai-engineering-from-scratch”这个标题背后真正要解决的问题不是教你从零训练一个GPT而是教你从零建立一套能支撑AI应用落地的工程能力。它涵盖的范围比“调包”广得多包括环境管理、数据处理流水线、模型服务化、性能优化、监控与迭代。适合谁看适合那些已经能跑通demo、但一遇到真实场景就卡壳的开发者也适合想从传统后端转向AI工程方向的工程师。我见过太多团队在AI项目上栽跟头不是因为算法不够先进而是因为工程底座太薄。一个推荐模型离线指标AUC 0.85上线后CTR反而跌了最后发现是特征在线计算和离线计算逻辑不一致。这种问题不是调参能解决的它属于AI工程范畴。所以这篇内容我会围绕“从零构建”这个核心把AI工程里最容易被忽视、但最致命的环节一个个拆开讲包括我实际踩过的坑和验证过的方案。2. 环境与依赖管理别让“在我机器上能跑”成为团队噩梦2.1 为什么conda和pip混用迟早出事刚入行的时候我也觉得环境管理是小事直到有一次帮同事复现一个实验他的requirements.txt里写着torch1.12.0但我装完跑起来就报CUDA版本不匹配。查了半天才发现他用conda装了cudatoolkit又用pip装了torch两者链接的CUDA运行时不是同一个。这种问题在单人开发时可能碰不到一旦团队协作或者换机器部署就是灾难。AI工程和普通后端开发最大的区别在于依赖不只是Python包还包括CUDA驱动、cuDNN、NCCL这些系统级组件。pip只能管Python层面的依赖conda能管一部分二进制依赖但两者混用时环境变量的优先级、动态链接库的搜索路径都可能出问题。我的建议是在一个项目里只选一种包管理工具。如果团队里有人习惯conda那就统一用conda并且用conda env export --no-builds导出环境文件避免build号绑定平台。2.2 用Docker做可复现环境的最小实践真正要保证“从零搭建”的环境可复现Docker是绕不开的。但很多人的Dockerfile写得很随意比如直接FROM python:3.9然后pip install一堆最后镜像大到几个G构建一次要十几分钟。我自己的做法是分阶段构建FROM nvidia/cuda:11.8.0-cudnn8-devel-ubuntu22.04 AS builder # 安装编译依赖构建Python包 ... FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04 # 只拷贝运行时需要的文件 COPY --frombuilder /opt/venv /opt/venv这样最终镜像能控制在2G以内而且运行时不需要devel版本的CUDA减少攻击面。还有一个细节不要把模型权重打进镜像。我见过有人把几个G的模型文件塞进Docker镜像结果每次更新模型都要重新构建、重新推送CI/CD流水线直接瘫痪。正确做法是把模型文件挂载到volume或者启动时从对象存储拉取。2.3 依赖版本锁定的坑与技巧pip freeze requirements.txt是很多人的标准操作但它有个致命问题会把所有间接依赖的精确版本都锁死导致在不同Python版本或不同操作系统上无法安装。比如numpy1.21.0在Python 3.10上可能没有预编译wheelpip就会尝试从源码编译然后因为缺少Fortran编译器而失败。我的做法是维护两个文件requirements.in写直接依赖不带版本或只带大版本然后用pip-compile生成requirements.txt。这样既能锁定版本保证可复现又能在需要时灵活升级。对于AI项目还要特别注意torch和tensorflow的版本与CUDA版本的对应关系这个对应表在官方文档里都有但很多人不看装完跑不起来才去查。提示如果你的项目需要同时支持CPU和GPU环境不要在一个requirements.txt里写死torchx.x.xcu118这种带本地版本号的写法。可以用环境变量区分或者在Docker构建时通过build arg传入。3. 数据流水线AI工程里最脏最累但最重要的部分3.1 为什么你的模型上线后效果暴跌离线评估AUC 0.9上线后效果惨不忍睹这种情况十有八九是训练/服务特征不一致导致的。训练时用Pandas做特征工程上线时用Java或Go重写一遍两边逻辑稍微有点差异比如缺失值填充方式不同、时间窗口对齐方式不同模型输入分布就变了。这个问题在业界有个专门的名字叫Training-Serving Skew是AI工程最经典的坑之一。解决思路不是“让两边代码保持一致”因为人总会犯错。更好的做法是把特征计算逻辑统一到一个地方训练和推理都调用同一份代码。如果服务端是Python可以直接复用如果是其他语言可以考虑用ONNX或PMML把特征处理也导出成模型的一部分。我自己的项目里特征工程全部用Spark或Flink写好离线训练和在线推理都通过同一个UDF调用虽然性能不是最优但一致性有保障。3.2 数据版本管理别再用文件名区分了train_data_v2_final_20240301.csv这种命名方式我敢说每个AI团队都出现过。问题是当你需要回滚到某个版本或者想复现三个月前的一次实验时根本找不到对应的数据。更麻烦的是数据预处理代码改了之后旧数据和新代码不匹配跑出来的结果无法解释。数据版本管理工具像DVC、LakeFS、Pachyderm都能解决这个问题但引入成本不低。如果团队规模小可以用一个简单方案每次数据预处理都输出到一个带哈希值的目录哈希值由原始数据路径预处理代码git commit参数配置共同计算得出。然后在训练脚本里记录这个哈希值。这样虽然原始但至少能追溯。我试过用DVC管理几十G的数据集配合S3兼容存储体验不错但要注意DVC的缓存目录不要放在项目根目录否则git status会卡死。3.3 数据加载的性能陷阱训练时GPU利用率只有30%剩下70%的时间在等数据加载——这是AI工程里最常见的性能问题。原因通常有几个DataLoader的num_workers设得太小、数据预处理在Python里做成了瓶颈、磁盘IO太慢。我的调优顺序是这样的先把数据全部读进内存如果内存够看GPU利用率是否上去如果还不行检查预处理里有没有PIL、cv2这种CPU密集操作考虑用DALI或torchvision的GPU加速版本最后才考虑换SSD或增加num_workers。有个细节num_workers不是越大越好设成CPU核心数就行设太大反而会因为进程切换开销导致性能下降。另外如果用了IterableDataset要注意每个worker的数据分片逻辑否则可能重复采样或漏采样。4. 模型服务化从notebook到高并发API的距离4.1 为什么Flask单进程是灾难很多教程教人用Flask写一个/predict接口然后app.run()就完事了。这在demo阶段没问题但一旦有并发请求Flask默认的单进程单线程模型会让请求排队延迟飙升。更严重的是Python的GIL导致CPU密集的推理任务无法真正并行多线程也没用。正确的做法是用异步框架多进程。FastAPIUvicorn是现在比较主流的选择Uvicorn可以启动多个worker进程每个进程独立处理请求。但要注意如果模型加载在全局变量里每个worker都会加载一份显存占用会翻倍。所以要么用共享内存要么把模型服务拆成独立的推理服务API层只做请求转发。我自己的生产环境用的是Triton Inference Server它支持动态批处理、多模型并发、GPU共享虽然学习曲线陡一点但省去了很多自己造轮子的时间。如果不想引入这么重的组件至少要做到模型预热启动时先跑几次推理、超时控制避免慢请求拖垮整个服务、健康检查区分存活和就绪状态。4.2 批处理与动态批处理的取舍在线推理和离线推理最大的区别是在线请求是零散到达的如果每个请求都单独跑一次模型GPU利用率极低。动态批处理Dynamic Batching的思路是把短时间内到达的多个请求合并成一个batch一起送进GPU这样吞吐量能提升几倍甚至几十倍。但动态批处理有个代价延迟会增加。因为要等一个时间窗口比如10ms来收集请求。对于延迟敏感的场景这个窗口要设得很小批处理效果就有限。我的经验是如果QPS低于50动态批处理收益不大不如直接单请求推理如果QPS上百那批处理是必须的。Triton里可以通过max_batch_size和dynamic_batching配置来调优具体参数要根据模型大小和GPU型号实测。4.3 模型版本管理与灰度发布模型上线不是覆盖旧文件就完事了。你需要能随时回滚需要能A/B测试需要能灰度放量。这些能力在传统后端里很成熟但在AI服务里经常被忽略。一个简单可行的方案是模型文件按版本号存放服务启动时通过环境变量指定版本。比如/models/recommendation/v1.2.3/model.onnxAPI层根据请求头里的用户分组决定调用哪个版本。灰度发布时先让1%的用户走新版本观察指标没问题再逐步放量。这里的关键是监控要跟上否则新版本出问题了你都不知道。至少要有请求量、延迟P99、错误率、模型输出分布比如预测均值和方差这几个指标。5. 性能优化让推理速度从秒级降到毫秒级5.1 模型量化精度换速度的账怎么算把一个FP32的BERT模型直接部署推理延迟可能在200ms以上量化到INT8后能降到50ms左右但精度会掉多少这取决于模型和任务。我的经验是分类任务对量化不敏感生成任务对量化很敏感。做量化时不要只看离线指标一定要在真实数据上评估而且要看业务指标不是只看准确率。ONNX Runtime和TensorRT都支持训练后量化PTQ只需要少量校准数据。如果PTQ掉点太多可以考虑量化感知训练QAT但成本高很多。有个坑要注意量化后的模型在不同硬件上表现可能不一样比如在V100上校准的量化参数放到T4上可能就不准了。所以量化校准要在目标部署硬件上做。5.2 算子融合与图优化深度学习框架在推理时会把多个算子融合成一个减少kernel launch开销和内存访问。比如ConvBNReLU可以融合成一个算子。这些优化在TensorRT和ONNX Runtime里都是自动的但前提是你的模型图是“干净”的。什么叫干净就是没有多余的reshape、transpose、cast操作。我见过一个模型因为训练代码里有个不必要的permute导致推理时多了一次内存拷贝延迟增加了15ms。排查这种问题可以用Netron可视化模型图或者用ONNX Runtime的profiling工具看每个算子的耗时。如果发现某个算子耗时异常再去看它前后有没有可以消除的冗余操作。5.3 显存优化从OOM到稳定运行显存不够是AI工程里最常见的报错。除了换更大显存的卡还有很多工程手段可以缓解。比如梯度检查点用时间换显存、混合精度训练FP16比FP32省一半显存、ZeRO优化器把优化器状态分片到多卡。推理阶段可以用KV Cache量化、PagedAttentionvLLM里的技术来降低显存占用。但要注意这些技术都有适用场景。混合精度训练在有些模型上会导致梯度溢出需要配合loss scaling。梯度检查点会增加计算量训练时间可能翻倍。所以不要盲目上先profile找到真正的瓶颈再针对性优化。我自己的习惯是先用最小的batch size跑通然后逐步增大观察显存变化曲线这样能快速定位是模型参数占显存还是激活值占显存。6. 监控与迭代上线只是开始6.1 模型性能监控的四个层次模型上线后你需要监控的不只是“服务是否存活”。我通常把监控分成四个层次层次监控内容工具示例基础设施层GPU利用率、显存、温度、网络IOPrometheus Node Exporter服务层QPS、延迟P50/P99、错误率Grafana 自定义指标模型层输入分布、输出分布、特征缺失率埋点日志 统计脚本业务层CTR、转化率、用户停留时长业务数据库 BI工具很多团队只做到前两层结果模型效果下降了也不知道。比如输入特征里某个字段突然大量缺失模型输出就会偏移但服务本身没报错。所以模型层的监控是必须的至少要对关键特征做分布统计和训练时的分布做对比。6.2 数据漂移检测的简单实现数据漂移Data Drift是指线上数据的分布和训练数据不一致。检测方法有很多PSI、KL散度、KS检验都可以。我常用的是PSI因为它对样本量不敏感计算也简单。具体做法是把训练数据里每个特征的分布分成10个桶线上数据也分同样的桶然后计算PSI。PSI小于0.1说明分布稳定0.1到0.25之间需要关注大于0.25就说明漂移严重需要考虑重新训练。这个计算可以每天跑一次结果推到监控面板上。如果某个特征的PSI突然升高就去排查上游数据源是不是变了。我遇到过因为上游业务系统改了一个字段的默认值导致模型效果下降的情况就是靠PSI发现的。6.3 模型重训练的触发条件模型不是训练一次就一劳永逸的。什么时候该重新训练我的经验是看三个信号数据漂移超过阈值、业务指标持续下降、新数据积累到一定量。这三个条件满足任意一个就可以触发重训练流程。重训练流程要尽量自动化包括数据拉取、预处理、训练、评估、模型导出、灰度发布。但不要全自动上线一定要有人工审核环节。我见过全自动上线导致模型把“点击”预测成“不点击”的严重事故原因是训练数据里混入了脏数据。所以自动化可以做到“训练出模型并评估”但“上线”这一步要卡住至少要有指标对比和人工确认。7. 一些让我少踩坑的工程习惯7.1 日志里一定要记录请求ID和模型版本线上出问题时最怕的是不知道这个请求用的是哪个模型版本、输入是什么、输出是什么。我的做法是每个请求生成一个唯一ID日志里记录请求ID、模型版本、输入摘要不要全量记录注意隐私、输出摘要、耗时。这样排查问题时可以快速定位。如果用了Triton它自带请求ID和统计信息直接对接日志系统就行。7.2 配置文件与代码分离不要把学习率、batch size、模型路径这些硬编码在代码里。用配置文件YAML或JSON管理代码里只读配置。这样切换环境时不用改代码也方便做实验对比。我习惯用Hydra管理配置它支持配置组合、命令行覆盖、多实验并行比手写argparse方便很多。7.3 写单元测试尤其是数据预处理AI项目里最值得写单元测试的地方是数据预处理。因为这部分逻辑复杂、容易出错、而且出错后很难发现。测试用例要覆盖正常输入、缺失值、异常值、边界条件。我自己的项目里数据预处理函数的测试覆盖率要求达到90%以上模型训练部分的测试可以少一些但至少要有smoke test保证能跑通。7.4 不要忽视小文件IO训练时如果有大量小文件比如几万张图片磁盘IO会成为瓶颈。解决方案是把小文件打包成TFRecord或WebDataset格式或者用内存文件系统。我试过把一个包含5万张小图片的数据集从逐个读取改成WebDataset的tar包训练速度提升了3倍。这个优化在数据加载阶段做比换GPU划算得多。7.5 版本回滚要能一键完成上线新模型时一定要准备好回滚方案。最简单的做法是模型文件按版本存放服务启动时通过环境变量指定版本回滚时只需要改环境变量并重启。如果用了Kubernetes可以通过修改Deployment的image tag来回滚。关键是回滚操作要演练过不要等到出事了才发现回滚脚本跑不通。8. 从零到一之后持续迭代的工程化思路搭建起一套能用的AI工程体系后下一步是让它持续运转、持续改进。这里有几个方向值得投入自动化特征工程减少人工特征维护成本、在线学习让模型快速适应新数据、模型压缩与蒸馏降低推理成本、多模型融合提升效果上限。但不要一次性全上根据业务需求和团队能力逐步推进。我自己的节奏是先保证稳定性和可观测性再优化性能最后才追求效果提升。因为一个不稳定的系统效果再好也没用。而一个稳定但效果一般的系统至少能产生业务价值然后在此基础上迭代。AI工程和算法研究的区别就在这里工程追求的是在约束条件下持续交付价值而不是单点指标的最优。最后分享一个我经常用来判断AI工程成熟度的问题如果现在要把这个模型从A服务器迁移到B服务器你需要多长时间如果答案是“半天”甚至“一天”说明环境管理和依赖管理还有很大优化空间。如果答案是“十分钟”那你的AI工程底座已经比较扎实了。这个问题的答案比任何架构图都更能反映真实水平。
从零搭建AI工程能力：环境管理、数据流水线与模型服务化实战
1. 从零搭建AI工程能力为什么“会调包”和“会做工程”是两回事很多人第一次接触AI项目时路径都差不多装个Python环境pip install几个库找一份开源notebook把模型跑通看到输出结果就觉得自己“入门AI”了。但真正到了要交付一个能用的系统时问题就全冒出来了——模型在本地跑得好好的放到服务器上就崩推理速度慢得离谱用户等三秒就关页面显存不够、并发一上来就OOM日志里全是看不懂的报错排查半天发现是数据预处理阶段埋的雷。这就是“ai-engineering-from-scratch”这个标题背后真正要解决的问题不是教你从零训练一个GPT而是教你从零建立一套能支撑AI应用落地的工程能力。它涵盖的范围比“调包”广得多包括环境管理、数据处理流水线、模型服务化、性能优化、监控与迭代。适合谁看适合那些已经能跑通demo、但一遇到真实场景就卡壳的开发者也适合想从传统后端转向AI工程方向的工程师。我见过太多团队在AI项目上栽跟头不是因为算法不够先进而是因为工程底座太薄。一个推荐模型离线指标AUC 0.85上线后CTR反而跌了最后发现是特征在线计算和离线计算逻辑不一致。这种问题不是调参能解决的它属于AI工程范畴。所以这篇内容我会围绕“从零构建”这个核心把AI工程里最容易被忽视、但最致命的环节一个个拆开讲包括我实际踩过的坑和验证过的方案。2. 环境与依赖管理别让“在我机器上能跑”成为团队噩梦2.1 为什么conda和pip混用迟早出事刚入行的时候我也觉得环境管理是小事直到有一次帮同事复现一个实验他的requirements.txt里写着torch1.12.0但我装完跑起来就报CUDA版本不匹配。查了半天才发现他用conda装了cudatoolkit又用pip装了torch两者链接的CUDA运行时不是同一个。这种问题在单人开发时可能碰不到一旦团队协作或者换机器部署就是灾难。AI工程和普通后端开发最大的区别在于依赖不只是Python包还包括CUDA驱动、cuDNN、NCCL这些系统级组件。pip只能管Python层面的依赖conda能管一部分二进制依赖但两者混用时环境变量的优先级、动态链接库的搜索路径都可能出问题。我的建议是在一个项目里只选一种包管理工具。如果团队里有人习惯conda那就统一用conda并且用conda env export --no-builds导出环境文件避免build号绑定平台。2.2 用Docker做可复现环境的最小实践真正要保证“从零搭建”的环境可复现Docker是绕不开的。但很多人的Dockerfile写得很随意比如直接FROM python:3.9然后pip install一堆最后镜像大到几个G构建一次要十几分钟。我自己的做法是分阶段构建FROM nvidia/cuda:11.8.0-cudnn8-devel-ubuntu22.04 AS builder # 安装编译依赖构建Python包 ... FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04 # 只拷贝运行时需要的文件 COPY --frombuilder /opt/venv /opt/venv这样最终镜像能控制在2G以内而且运行时不需要devel版本的CUDA减少攻击面。还有一个细节不要把模型权重打进镜像。我见过有人把几个G的模型文件塞进Docker镜像结果每次更新模型都要重新构建、重新推送CI/CD流水线直接瘫痪。正确做法是把模型文件挂载到volume或者启动时从对象存储拉取。2.3 依赖版本锁定的坑与技巧pip freeze requirements.txt是很多人的标准操作但它有个致命问题会把所有间接依赖的精确版本都锁死导致在不同Python版本或不同操作系统上无法安装。比如numpy1.21.0在Python 3.10上可能没有预编译wheelpip就会尝试从源码编译然后因为缺少Fortran编译器而失败。我的做法是维护两个文件requirements.in写直接依赖不带版本或只带大版本然后用pip-compile生成requirements.txt。这样既能锁定版本保证可复现又能在需要时灵活升级。对于AI项目还要特别注意torch和tensorflow的版本与CUDA版本的对应关系这个对应表在官方文档里都有但很多人不看装完跑不起来才去查。提示如果你的项目需要同时支持CPU和GPU环境不要在一个requirements.txt里写死torchx.x.xcu118这种带本地版本号的写法。可以用环境变量区分或者在Docker构建时通过build arg传入。3. 数据流水线AI工程里最脏最累但最重要的部分3.1 为什么你的模型上线后效果暴跌离线评估AUC 0.9上线后效果惨不忍睹这种情况十有八九是训练/服务特征不一致导致的。训练时用Pandas做特征工程上线时用Java或Go重写一遍两边逻辑稍微有点差异比如缺失值填充方式不同、时间窗口对齐方式不同模型输入分布就变了。这个问题在业界有个专门的名字叫Training-Serving Skew是AI工程最经典的坑之一。解决思路不是“让两边代码保持一致”因为人总会犯错。更好的做法是把特征计算逻辑统一到一个地方训练和推理都调用同一份代码。如果服务端是Python可以直接复用如果是其他语言可以考虑用ONNX或PMML把特征处理也导出成模型的一部分。我自己的项目里特征工程全部用Spark或Flink写好离线训练和在线推理都通过同一个UDF调用虽然性能不是最优但一致性有保障。3.2 数据版本管理别再用文件名区分了train_data_v2_final_20240301.csv这种命名方式我敢说每个AI团队都出现过。问题是当你需要回滚到某个版本或者想复现三个月前的一次实验时根本找不到对应的数据。更麻烦的是数据预处理代码改了之后旧数据和新代码不匹配跑出来的结果无法解释。数据版本管理工具像DVC、LakeFS、Pachyderm都能解决这个问题但引入成本不低。如果团队规模小可以用一个简单方案每次数据预处理都输出到一个带哈希值的目录哈希值由原始数据路径预处理代码git commit参数配置共同计算得出。然后在训练脚本里记录这个哈希值。这样虽然原始但至少能追溯。我试过用DVC管理几十G的数据集配合S3兼容存储体验不错但要注意DVC的缓存目录不要放在项目根目录否则git status会卡死。3.3 数据加载的性能陷阱训练时GPU利用率只有30%剩下70%的时间在等数据加载——这是AI工程里最常见的性能问题。原因通常有几个DataLoader的num_workers设得太小、数据预处理在Python里做成了瓶颈、磁盘IO太慢。我的调优顺序是这样的先把数据全部读进内存如果内存够看GPU利用率是否上去如果还不行检查预处理里有没有PIL、cv2这种CPU密集操作考虑用DALI或torchvision的GPU加速版本最后才考虑换SSD或增加num_workers。有个细节num_workers不是越大越好设成CPU核心数就行设太大反而会因为进程切换开销导致性能下降。另外如果用了IterableDataset要注意每个worker的数据分片逻辑否则可能重复采样或漏采样。4. 模型服务化从notebook到高并发API的距离4.1 为什么Flask单进程是灾难很多教程教人用Flask写一个/predict接口然后app.run()就完事了。这在demo阶段没问题但一旦有并发请求Flask默认的单进程单线程模型会让请求排队延迟飙升。更严重的是Python的GIL导致CPU密集的推理任务无法真正并行多线程也没用。正确的做法是用异步框架多进程。FastAPIUvicorn是现在比较主流的选择Uvicorn可以启动多个worker进程每个进程独立处理请求。但要注意如果模型加载在全局变量里每个worker都会加载一份显存占用会翻倍。所以要么用共享内存要么把模型服务拆成独立的推理服务API层只做请求转发。我自己的生产环境用的是Triton Inference Server它支持动态批处理、多模型并发、GPU共享虽然学习曲线陡一点但省去了很多自己造轮子的时间。如果不想引入这么重的组件至少要做到模型预热启动时先跑几次推理、超时控制避免慢请求拖垮整个服务、健康检查区分存活和就绪状态。4.2 批处理与动态批处理的取舍在线推理和离线推理最大的区别是在线请求是零散到达的如果每个请求都单独跑一次模型GPU利用率极低。动态批处理Dynamic Batching的思路是把短时间内到达的多个请求合并成一个batch一起送进GPU这样吞吐量能提升几倍甚至几十倍。但动态批处理有个代价延迟会增加。因为要等一个时间窗口比如10ms来收集请求。对于延迟敏感的场景这个窗口要设得很小批处理效果就有限。我的经验是如果QPS低于50动态批处理收益不大不如直接单请求推理如果QPS上百那批处理是必须的。Triton里可以通过max_batch_size和dynamic_batching配置来调优具体参数要根据模型大小和GPU型号实测。4.3 模型版本管理与灰度发布模型上线不是覆盖旧文件就完事了。你需要能随时回滚需要能A/B测试需要能灰度放量。这些能力在传统后端里很成熟但在AI服务里经常被忽略。一个简单可行的方案是模型文件按版本号存放服务启动时通过环境变量指定版本。比如/models/recommendation/v1.2.3/model.onnxAPI层根据请求头里的用户分组决定调用哪个版本。灰度发布时先让1%的用户走新版本观察指标没问题再逐步放量。这里的关键是监控要跟上否则新版本出问题了你都不知道。至少要有请求量、延迟P99、错误率、模型输出分布比如预测均值和方差这几个指标。5. 性能优化让推理速度从秒级降到毫秒级5.1 模型量化精度换速度的账怎么算把一个FP32的BERT模型直接部署推理延迟可能在200ms以上量化到INT8后能降到50ms左右但精度会掉多少这取决于模型和任务。我的经验是分类任务对量化不敏感生成任务对量化很敏感。做量化时不要只看离线指标一定要在真实数据上评估而且要看业务指标不是只看准确率。ONNX Runtime和TensorRT都支持训练后量化PTQ只需要少量校准数据。如果PTQ掉点太多可以考虑量化感知训练QAT但成本高很多。有个坑要注意量化后的模型在不同硬件上表现可能不一样比如在V100上校准的量化参数放到T4上可能就不准了。所以量化校准要在目标部署硬件上做。5.2 算子融合与图优化深度学习框架在推理时会把多个算子融合成一个减少kernel launch开销和内存访问。比如ConvBNReLU可以融合成一个算子。这些优化在TensorRT和ONNX Runtime里都是自动的但前提是你的模型图是“干净”的。什么叫干净就是没有多余的reshape、transpose、cast操作。我见过一个模型因为训练代码里有个不必要的permute导致推理时多了一次内存拷贝延迟增加了15ms。排查这种问题可以用Netron可视化模型图或者用ONNX Runtime的profiling工具看每个算子的耗时。如果发现某个算子耗时异常再去看它前后有没有可以消除的冗余操作。5.3 显存优化从OOM到稳定运行显存不够是AI工程里最常见的报错。除了换更大显存的卡还有很多工程手段可以缓解。比如梯度检查点用时间换显存、混合精度训练FP16比FP32省一半显存、ZeRO优化器把优化器状态分片到多卡。推理阶段可以用KV Cache量化、PagedAttentionvLLM里的技术来降低显存占用。但要注意这些技术都有适用场景。混合精度训练在有些模型上会导致梯度溢出需要配合loss scaling。梯度检查点会增加计算量训练时间可能翻倍。所以不要盲目上先profile找到真正的瓶颈再针对性优化。我自己的习惯是先用最小的batch size跑通然后逐步增大观察显存变化曲线这样能快速定位是模型参数占显存还是激活值占显存。6. 监控与迭代上线只是开始6.1 模型性能监控的四个层次模型上线后你需要监控的不只是“服务是否存活”。我通常把监控分成四个层次层次监控内容工具示例基础设施层GPU利用率、显存、温度、网络IOPrometheus Node Exporter服务层QPS、延迟P50/P99、错误率Grafana 自定义指标模型层输入分布、输出分布、特征缺失率埋点日志 统计脚本业务层CTR、转化率、用户停留时长业务数据库 BI工具很多团队只做到前两层结果模型效果下降了也不知道。比如输入特征里某个字段突然大量缺失模型输出就会偏移但服务本身没报错。所以模型层的监控是必须的至少要对关键特征做分布统计和训练时的分布做对比。6.2 数据漂移检测的简单实现数据漂移Data Drift是指线上数据的分布和训练数据不一致。检测方法有很多PSI、KL散度、KS检验都可以。我常用的是PSI因为它对样本量不敏感计算也简单。具体做法是把训练数据里每个特征的分布分成10个桶线上数据也分同样的桶然后计算PSI。PSI小于0.1说明分布稳定0.1到0.25之间需要关注大于0.25就说明漂移严重需要考虑重新训练。这个计算可以每天跑一次结果推到监控面板上。如果某个特征的PSI突然升高就去排查上游数据源是不是变了。我遇到过因为上游业务系统改了一个字段的默认值导致模型效果下降的情况就是靠PSI发现的。6.3 模型重训练的触发条件模型不是训练一次就一劳永逸的。什么时候该重新训练我的经验是看三个信号数据漂移超过阈值、业务指标持续下降、新数据积累到一定量。这三个条件满足任意一个就可以触发重训练流程。重训练流程要尽量自动化包括数据拉取、预处理、训练、评估、模型导出、灰度发布。但不要全自动上线一定要有人工审核环节。我见过全自动上线导致模型把“点击”预测成“不点击”的严重事故原因是训练数据里混入了脏数据。所以自动化可以做到“训练出模型并评估”但“上线”这一步要卡住至少要有指标对比和人工确认。7. 一些让我少踩坑的工程习惯7.1 日志里一定要记录请求ID和模型版本线上出问题时最怕的是不知道这个请求用的是哪个模型版本、输入是什么、输出是什么。我的做法是每个请求生成一个唯一ID日志里记录请求ID、模型版本、输入摘要不要全量记录注意隐私、输出摘要、耗时。这样排查问题时可以快速定位。如果用了Triton它自带请求ID和统计信息直接对接日志系统就行。7.2 配置文件与代码分离不要把学习率、batch size、模型路径这些硬编码在代码里。用配置文件YAML或JSON管理代码里只读配置。这样切换环境时不用改代码也方便做实验对比。我习惯用Hydra管理配置它支持配置组合、命令行覆盖、多实验并行比手写argparse方便很多。7.3 写单元测试尤其是数据预处理AI项目里最值得写单元测试的地方是数据预处理。因为这部分逻辑复杂、容易出错、而且出错后很难发现。测试用例要覆盖正常输入、缺失值、异常值、边界条件。我自己的项目里数据预处理函数的测试覆盖率要求达到90%以上模型训练部分的测试可以少一些但至少要有smoke test保证能跑通。7.4 不要忽视小文件IO训练时如果有大量小文件比如几万张图片磁盘IO会成为瓶颈。解决方案是把小文件打包成TFRecord或WebDataset格式或者用内存文件系统。我试过把一个包含5万张小图片的数据集从逐个读取改成WebDataset的tar包训练速度提升了3倍。这个优化在数据加载阶段做比换GPU划算得多。7.5 版本回滚要能一键完成上线新模型时一定要准备好回滚方案。最简单的做法是模型文件按版本存放服务启动时通过环境变量指定版本回滚时只需要改环境变量并重启。如果用了Kubernetes可以通过修改Deployment的image tag来回滚。关键是回滚操作要演练过不要等到出事了才发现回滚脚本跑不通。8. 从零到一之后持续迭代的工程化思路搭建起一套能用的AI工程体系后下一步是让它持续运转、持续改进。这里有几个方向值得投入自动化特征工程减少人工特征维护成本、在线学习让模型快速适应新数据、模型压缩与蒸馏降低推理成本、多模型融合提升效果上限。但不要一次性全上根据业务需求和团队能力逐步推进。我自己的节奏是先保证稳定性和可观测性再优化性能最后才追求效果提升。因为一个不稳定的系统效果再好也没用。而一个稳定但效果一般的系统至少能产生业务价值然后在此基础上迭代。AI工程和算法研究的区别就在这里工程追求的是在约束条件下持续交付价值而不是单点指标的最优。最后分享一个我经常用来判断AI工程成熟度的问题如果现在要把这个模型从A服务器迁移到B服务器你需要多长时间如果答案是“半天”甚至“一天”说明环境管理和依赖管理还有很大优化空间。如果答案是“十分钟”那你的AI工程底座已经比较扎实了。这个问题的答案比任何架构图都更能反映真实水平。
