1. 从零构建AI工程能力为什么我劝你别再当“调包侠”“ai-engineering-from-scratch”这个标题第一次看到的时候我愣了几秒。不是因为它有多复杂恰恰相反——它戳中了一个我观察了很久的行业现象现在市面上讲AI的文章和课程绝大多数都在教你怎么调用API、怎么用现成的框架搭一个demo但很少有人认真讲清楚从一行数学公式到一个能扛住线上流量的推理服务中间到底要填多少坑。我自己在这个领域摸爬滚打了七八年带过团队也面过不少人。一个很深的感受是能跑通一个notebook的人很多但能把模型真正部署到生产环境、能定位推理延迟的瓶颈、能在数据分布漂移时快速响应的人少之又少。这个项目标题的核心价值就在于它强调“from scratch”——从零开始不是从pip install开始而是从理解每一个组件为什么存在、解决什么问题开始。这篇文章适合谁看如果你是刚入行的算法工程师正在从“跑通模型”向“交付系统”过渡那这篇内容能帮你少走至少半年的弯路。如果你是有经验的开发者想转AI工程方向这里面的很多工程细节是你在论文里看不到的。甚至如果你只是对AI系统怎么运转感到好奇我也会尽量用生活化的类比把原理讲清楚。我打算把整个AI工程能力拆成几个核心模块来讲数据管道的设计、模型训练的基础设施、推理服务的优化、以及监控和迭代的闭环。每个模块我都会讲清楚“为什么这么做”和“具体怎么做”中间会穿插我自己踩过的坑和总结出来的实操技巧。文章会比较长但如果你能耐心看完至少对AI工程的全貌会有一个扎实的认知。2. 数据管道AI工程里最不起眼但最要命的部分2.1 为什么数据管道值得你花30%的时间很多人做AI项目第一反应是选模型、调参数但真正做过生产系统的人都知道数据管道才是那个“平时不出声一出事就是大事”的环节。我见过太多团队模型在实验室里指标漂亮得不行一上线效果直接打七折排查到最后发现是特征计算逻辑在训练和推理时不一致。数据管道的核心任务其实就三件事把原始数据变成模型能吃的格式、保证训练和推理时的数据处理逻辑一致、以及让这个过程可重复可追溯。听起来简单但每一条背后都有大量的工程细节。举个例子假设你在做一个电商推荐系统原始数据是用户的行为日志。从日志到模型输入中间至少要经过日志采集、数据清洗、特征提取、特征存储、样本拼接这几个步骤。每一步都可能引入偏差。比如日志采集时如果用了异步上报就可能丢事件特征提取时如果用了不同的时间窗口训练和推理的结果就会对不上。我个人的经验是在项目初期就把数据管道的版本管理做起来。每次数据处理的逻辑变更都要有记录并且能够回滚。这个习惯在后期排查问题时能救命。2.2 从原始数据到训练样本的完整链路让我用一个具体的场景来拆解这条链路。假设我们要做一个用户流失预测模型输入是用户最近30天的行为数据输出是未来7天流失的概率。第一步是数据采集。这里的关键是保证事件的完整性和时序正确性。我通常会用消息队列来缓冲原始事件比如Kafka或者Pulsar这样即使下游处理慢了数据也不会丢。采集的时候一定要带上事件时间戳而不是处理时间戳否则后续做时间窗口聚合时会出大问题。第二步是数据清洗。这一步要处理的是脏数据重复事件、字段缺失、格式错误。我的做法是写一套可配置的清洗规则每条规则都有明确的输入输出和异常处理逻辑。比如对于缺失的用户ID是丢弃还是填充默认值这个决策要基于业务理解来做不能拍脑袋。第三步是特征提取。这是最考验工程能力的地方。以“最近30天购买次数”这个特征为例你需要决定是按自然日还是按滚动窗口时区怎么处理如果用户30天前刚好有一笔订单边界怎么算这些细节在训练时如果不注意推理时就会出偏差。第四步是特征存储。我强烈建议把离线特征和在线特征统一管理。常见的做法是用特征平台比如Feast或者自己搭一套。核心思想是特征的注册、计算、存储、读取有一套统一的接口训练时从离线存储读推理时从在线存储读但计算逻辑是同一套代码。第五步是样本拼接。把特征和标签拼在一起生成训练样本。这里要注意样本的时间范围要和特征的时间窗口对齐避免数据泄漏。比如你用未来7天的流失作为标签那特征就不能包含这7天内的任何信息。2.3 数据版本管理与可复现性数据版本管理是很多团队容易忽略的环节。模型有版本代码有版本但数据往往没有。这就导致一个问题三个月后你想复现一个实验发现数据已经变了根本跑不出同样的结果。我的做法是给每个数据集打上版本标签记录它的生成时间、依赖的上游数据版本、以及处理逻辑的代码commit。这样任何时候都能追溯到某个模型是用哪份数据训练的。工具方面DVC或者LakeFS都是不错的选择核心是养成习惯。另外数据质量监控也要从第一天就做起来。最基本的监控包括数据量是否在合理范围、字段的分布是否发生漂移、空值率是否突增。这些指标一旦异常就要触发告警。我见过一个团队因为上游数据源改了字段格式导致模型输入全是空值线上跑了三天才发现损失惨重。3. 模型训练的基础设施别让你的GPU闲着3.1 训练环境的搭建原则训练环境的核心诉求就两个可复现和高效。可复现意味着任何人拿到你的代码和数据都能跑出同样的结果高效意味着GPU利用率要尽可能高别让昂贵的算力浪费在等数据上。我推荐的做法是用容器化来管理训练环境。Docker镜像里锁定所有依赖的版本包括CUDA、PyTorch、以及各种工具库。这样换一台机器环境完全一致。镜像的构建脚本也要纳入版本管理每次变更都有记录。训练任务的调度我倾向于用Kubernetes。原因很简单资源隔离做得好任务排队和优先级管理方便而且能很方便地做分布式训练。当然如果你的团队规模小用Slurm或者直接SSH到机器上跑也不是不行但扩展性会差一些。一个很实用的技巧在训练脚本里加上环境检查的逻辑。启动时打印出GPU型号、驱动版本、CUDA版本、关键库的版本这样出问题时一眼就能看出是不是环境不一致导致的。3.2 分布式训练的关键决策点当模型大到单卡放不下或者数据量大到单卡训练太慢时就需要分布式训练。这里有几个关键决策点。第一是并行策略的选择。数据并行适合模型能放进单卡的情况每张卡跑不同的数据batch梯度做all-reduce。模型并行适合单卡放不下模型的情况把模型的不同层放到不同的卡上。流水线并行是模型并行的一种优化把模型切成多个阶段不同阶段在不同卡上并行执行。实际中往往是混合使用。第二是通信后端的选择。NCCL是NVIDIA GPU集群上的标准选择性能最好。但如果你的集群里有不同型号的GPU或者有部分CPU节点可能需要考虑其他方案。通信效率直接决定了分布式训练的加速比这个在选型时要重点评估。第三是checkpoint的策略。分布式训练时checkpoint的保存和加载比单卡复杂得多。要保证所有rank的状态一致还要考虑保存的频率和存储的开销。我的经验是保存频率不要太高否则IO会成为瓶颈但也不能太低否则故障恢复时损失太大。一般每几个小时保存一次比较合理。3.3 GPU利用率优化的实操技巧GPU利用率低是训练中最常见的浪费。我总结了几条实操技巧。首先是数据加载的优化。用多进程的DataLoadernum_workers设置成CPU核心数的2到4倍。如果数据在远程存储上考虑提前缓存到本地SSD。数据增强尽量在GPU上做或者用NVIDIA的DALI库能大幅减少CPU瓶颈。其次是混合精度训练。用FP16或者BF16代替FP32显存占用能减少近一半训练速度也能提升。但要注意数值稳定性有些操作在低精度下会溢出需要用loss scaling来缓解。第三是梯度累积。当显存不够大batch size上不去时可以用梯度累积来模拟大batch。比如实际batch size是32累积4步再更新一次参数等效于batch size 128。这对训练稳定性有帮助但会稍微增加训练时间。第四是算子融合和编译优化。PyTorch 2.0的torch.compile能把模型图编译成更高效的算子实测下来训练速度能有20%到50%的提升。TensorRT和ONNX Runtime在推理侧也有类似的效果。4. 推理服务从模型文件到线上接口4.1 推理框架的选型逻辑模型训练完只是第一步怎么把它变成一个能对外提供服务的接口这里面有很多选择。常见的推理框架有TorchServe、Triton Inference Server、ONNX Runtime、TensorFlow Serving等。选型的核心考量有几个支持的模型格式、性能表现、易用性、以及社区活跃度。Triton在这方面做得比较全面支持TensorFlow、PyTorch、ONNX、TensorRT等多种后端还能做模型集成和动态批处理。如果你的团队主要用PyTorchTorchServe上手会更快一些。ONNX Runtime在CPU上的性能很好适合边缘部署的场景。我的建议是如果是从零开始搭优先考虑Triton。它的功能最完整社区也活跃遇到问题容易找到解决方案。如果已经有现成的服务框架那就尽量复用别为了追新而引入不必要的复杂度。4.2 延迟优化的几个关键手段推理延迟直接影响用户体验尤其是实时场景。优化延迟有几个方向。第一是模型量化。把FP32的权重转成INT8模型大小减少四分之三推理速度能提升2到4倍。但量化会带来精度损失需要做校准来最小化影响。PyTorch的量化工具和TensorRT的INT8校准都比较好用。第二是算子融合。把多个小算子合并成一个大算子减少kernel launch的开销和内存访问。这个在TensorRT和ONNX Runtime里都有自动优化。第三是动态批处理。把多个请求攒在一起推理能显著提升吞吐。Triton的动态批处理功能很成熟配置一下就能用。但要注意批处理会增加单个请求的延迟需要根据业务场景权衡。第四是模型蒸馏。用一个大模型教一个小模型小模型推理更快精度损失可控。这个在资源受限的场景下特别有用。第五是缓存。对于重复的请求直接返回缓存结果。比如推荐系统里热门商品的向量可以缓存在内存里避免重复计算。4.3 服务部署的工程细节推理服务部署时有几个工程细节容易被忽略但很重要。首先是健康检查。服务要暴露一个健康检查接口Kubernetes或者负载均衡器会定期调用。健康检查要能反映服务的真实状态不能只返回一个固定的200。比如要检查模型是否加载成功、GPU是否可用、依赖的服务是否正常。其次是优雅关闭。服务收到终止信号时要先把正在处理的请求处理完再退出。否则用户会看到请求失败。这个在Kubernetes里通过preStop钩子和terminationGracePeriodSeconds来配置。第三是资源限制。给容器设置合理的CPU和内存限制避免一个服务把整个节点拖垮。GPU资源也要做隔离可以用NVIDIA的MIG或者时间片轮转。第四是日志和追踪。每个请求要有唯一的ID日志里要记录请求的输入输出、处理时间、以及调用的下游服务。这样出问题时能快速定位。OpenTelemetry是一个不错的选择能同时做日志、指标和追踪。5. 监控与迭代上线只是开始5.1 模型监控的核心指标模型上线后监控是保证效果稳定的关键。监控的指标分几类。第一类是系统指标QPS、延迟、错误率、GPU利用率、内存占用。这些指标反映服务的健康状态异常时要能快速告警。第二类是数据指标输入数据的分布、空值率、特征的范围。数据分布漂移是模型效果下降的最常见原因。比如训练时用户年龄集中在20到40岁线上突然来了大量50岁以上的用户模型的效果就会打折扣。第三类是模型指标预测值的分布、置信度的分布、以及如果有真实标签的话准确率、召回率等。没有真实标签时可以用一些代理指标比如预测值的均值是否稳定。第四类是业务指标点击率、转化率、用户停留时长等。这些是最终衡量模型价值的指标但反馈周期比较长。5.2 数据漂移的检测与应对数据漂移的检测方法有很多最常用的是统计检验。比如用KS检验比较训练集和线上数据的特征分布用PSIPopulation Stability Index衡量分布的变化程度。PSI小于0.1说明分布稳定0.1到0.25之间说明有轻微变化大于0.25说明变化显著需要关注。检测到漂移后应对策略取决于漂移的原因。如果是上游数据采集逻辑变了那要修数据管道。如果是用户行为真的变了那可能需要重新训练模型。如果是季节性的波动那可以等一等或者用时间加权的训练数据来适应。我的经验是漂移检测要自动化但应对策略要人工确认。自动重训练听起来很美好但如果没有人工审核可能会把有问题的模型推到线上。5.3 模型迭代的闭环流程一个健康的模型迭代流程应该是这样的监控发现效果下降触发告警工程师排查原因确认是数据问题还是模型问题如果是模型问题用最新的数据重新训练新模型在离线评估通过后做小流量的AB测试AB测试确认效果提升后逐步扩大流量最终全量。这个流程里AB测试是关键环节。要注意的是AB测试的样本量要足够否则统计上不显著测试的时间要覆盖完整的业务周期比如至少一周避免周末和工作日的差异要同时看核心指标和护栏指标避免为了提升点击率而损害用户体验。一个常见的坑AB测试时只看了模型指标没看业务指标。模型准确率提升了但业务转化率没变甚至下降了。这种情况往往是模型优化的方向和业务目标不一致需要重新审视目标函数的设计。6. 我踩过的那些坑和总结的经验6.1 训练和推理不一致的排查思路训练和推理不一致是AI工程里最隐蔽也最致命的问题。表现是离线评估指标很好线上效果差很多。排查的思路是从数据入手逐层对比。第一步对比训练和推理时的原始输入。把同一个请求的原始数据分别喂给训练管道和推理管道看中间每一步的输出是否一致。不一致的地方就是问题所在。第二步检查特征计算的时间窗口。训练时用的是历史数据推理时用的是实时数据如果时间窗口的定义有歧义就会出问题。比如“最近7天”是包含今天还是到昨天为止这个要明确。第三步检查预处理的一致性。比如归一化的均值方差训练时是从训练集算的推理时如果重新算或者用了默认值就会不一致。正确的做法是把训练时算好的参数保存下来推理时直接加载。第四步检查模型加载的逻辑。有时候模型保存时包含了额外的层或者后处理逻辑加载时如果没对应上输出就会不同。6.2 资源成本控制的实操方法AI工程的成本大头在GPU上。控制成本有几个实操方法。首先是按需使用。训练任务用抢占式实例成本能降低60%到70%代价是可能被中断。配合checkpoint机制中断后能从最近的检查点恢复影响可控。其次是资源配额。给每个团队或者每个项目设置GPU配额避免某个实验把资源占满。Kubernetes的ResourceQuota和LimitRange能实现这个。第三是自动伸缩。推理服务根据QPS自动调整实例数低峰期缩容高峰期扩容。Kubernetes的HPA配合自定义指标能实现。第四是模型压缩。前面提到的量化、蒸馏、剪枝不仅能提升推理速度也能减少GPU占用间接降低成本。第五是定期清理。训练产生的checkpoint、日志、中间数据如果不清理会占用大量存储。设置生命周期策略自动删除过期的数据。6.3 团队协作中的工程规范AI项目往往是团队协作工程规范很重要。代码规范方面用black和isort做格式化用flake8或者ruff做静态检查用mypy做类型检查。这些工具集成到CI里提交代码时自动运行。实验管理方面用MLflow或者Weights Biases记录每次实验的参数、指标、和产物。这样任何人想复现某个实验都能找到对应的配置。文档方面每个模块要有README说明它的功能、输入输出、依赖关系、以及如何使用。关键的设计决策要有记录解释为什么这么做。代码审查方面AI项目的代码审查要特别关注数据处理逻辑和模型评估逻辑这两块最容易出问题。审查时不仅要看代码写得对不对还要看逻辑是否符合业务预期。7. 从零构建AI工程能力的路线建议如果你现在处于“会跑模型但不懂工程”的阶段我建议按这个顺序来补。先补数据工程的基础。学会用SQL做数据聚合用Spark或者Pandas做大规模数据处理理解数据仓库和特征平台的概念。这块是地基地基不牢后面都是空中楼阁。再补系统设计的能力。理解一个完整的AI系统由哪些组件构成每个组件的职责是什么组件之间怎么交互。可以多看一些开源的推荐系统或者搜索系统的架构设计。然后补运维和监控的知识。学会用Docker和Kubernetes部署服务用Prometheus和Grafana做监控用ELK或者Loki做日志管理。这些技能在线上出问题时能帮你快速定位。最后补性能优化的能力。理解GPU的工作原理知道怎么分析性能瓶颈会用Profiler工具。这块需要一定的实践经验积累急不来。整个过程中最重要的是动手。看再多的文章不如自己搭一个完整的系统跑一遍。从数据采集到模型部署到监控告警全部走通一遍你对AI工程的理解会上一个大台阶。我个人在实际操作中的体会是AI工程能力的核心不是掌握多少工具而是建立起一套系统化的思维方式。遇到问题时能从数据、模型、系统三个层面去分析能找到瓶颈在哪里能设计出可落地的解决方案。这种能力才是“from scratch”真正要培养的东西。