1. 从零手搓AI工程：为什么我不建议你直接调包
很多人一听到“AI工程”这四个字，第一反应就是打开某个云平台，调一个现成的大模型接口，写几行胶水代码，然后对外宣称自己做了个AI应用。这种玩法在Demo阶段没问题，但一旦你想真正理解AI系统是怎么跑起来的、想在生产环境里做性能调优、想排查那些莫名其妙的输出异常，光会调接口是远远不够的。ai-engineering-from-scratch这个标题背后的核心诉求，其实就是把AI工程从“黑盒调用”拉回到“白盒理解”的层面——从最基础的数学原理、数据管道、模型训练循环，到推理优化、服务部署、监控告警，整条链路自己动手搭一遍。
我之所以强调“从零”，是因为AI工程和传统软件工程有一个本质区别：传统软件的行为是确定性的，输入A必然得到B，出了问题你可以逐行调试；而AI系统的行为是概率性的，同样的输入可能得到不同的输出，模型内部的权重矩阵有几十亿个参数，你不可能靠打日志来定位问题。这就意味着，如果你不理解梯度下降到底在干什么、不理解注意力机制的计算复杂度在哪里、不理解量化对精度的影响有多大，你连“模型为什么变慢了”这种问题都回答不了。所以这篇内容适合那些已经会写Python、用过PyTorch或TensorFlow做简单模型训练，但还没有完整走过一遍AI工程全链路的人。我会按照一个真实项目的推进顺序，把数据准备、模型构建、训练调优、推理加速、服务化部署这几个阶段拆开来讲，每个阶段都告诉你“为什么这么做”以及“我踩过哪些坑”。
2. 数据管道：AI工程里最容易被低估的脏活累活
2.1 为什么数据加载器比模型结构更影响训练速度
刚入门的时候，我总觉得模型结构设计才是AI工程的核心，数据加载嘛，不就是把图片读进来、把文本tokenize一下吗？直到有一次我训练一个图像分类模型，GPU利用率死活上不去，一直在30%到40%之间晃悠，训练一个epoch要等四十多分钟。我一开始以为是模型太复杂，换了更小的网络，结果GPU利用率反而更低了。后来用profiler一查，发现瓶颈根本不在模型计算上，而是数据加载线程在等磁盘IO。当时我用的是最朴素的ImageFolder加默认的DataLoader，num_workers设成了0，也就是说数据加载和模型计算在同一个进程里串行执行。GPU算完一个batch之后，要等CPU把下一个batch的图片从磁盘读出来、解码、做数据增强，然后再传给GPU。这个等待时间远远超过了GPU实际计算的时间。
解决这个问题的思路其实不复杂，但里面有几个关键参数需要根据你的硬件配置来调。num_workers设置成CPU核心数的2到4倍通常是个不错的起点，但也不是越大越好，因为每个worker都会复制一份数据集索引，内存开销会线性增长。pin_memory=True可以让数据加载器把张量直接放到锁页内存里，这样从CPU传到GPU的时候可以用DMA直接拷贝，省掉一次内存复制。prefetch_factor控制每个worker提前预取多少个batch，默认是2，如果你的数据增强操作比较重，可以适当调大。还有一个容易被忽略的点是persistent_workers=True，它可以让worker进程在epoch之间不被销毁重建，对于小数据集来说可能感觉不明显，但对于需要频繁epoch的大规模训练，这个设置能省下不少进程启动的开销。
我后来把数据管道改成了WebDataset的格式，把原始图片打包成tar分片，配合num_workers=8、pin_memory=True、prefetch_factor=4，GPU利用率直接拉到了85%以上，训练时间从四十多分钟降到了十二分钟左右。这个提升幅度比换模型结构带来的收益大得多。所以我的经验是，在动手写模型之前，先把数据管道跑通、跑快，否则你后面所有的调优都是在给数据加载擦屁股。
2.2 数据清洗和增强的工程化处理
数据清洗这件事，学术界和工业界的做法差异非常大。学术数据集像ImageNet、COCO都是经过人工清洗的，你拿来就能用。但真实业务场景里的数据，脏得超乎你想象：图片有重复的、有损坏的、有分辨率极低的、有标注错误的；文本有乱码、有HTML标签残留、有语言混杂的。如果你不把这些脏数据处理掉，模型训练出来的效果会非常不稳定，有时候loss突然飙升，有时候验证集准确率莫名其妙地掉。
我的做法是在数据加载之前加一个预处理管道，用Apache Beam或者Spark做分布式清洗，把重复样本去掉、把损坏文件过滤掉、把标注异常的样本标记出来人工复核。对于图像数据，我还会做一步“感知哈希”去重，用imagehash库计算每张图片的pHash值，相似度超过阈值的只保留一张。这一步能去掉大概5%到10%的冗余数据，对于大规模训练来说，省下的计算资源相当可观。
数据增强这块，很多人喜欢用albumentations或者torchvision.transforms里的随机裁剪、翻转、颜色抖动。这些操作本身没问题，但要注意增强的强度和任务匹配。比如你做医学影像分类，随机裁剪可能会把病灶区域裁掉，导致模型学到错误的特征；你做文本分类，随机删除词语可能会改变句子的情感极性。我的建议是，增强策略一定要在验证集上做消融实验，看看加了某个增强之后验证集指标是涨了还是跌了。不要盲目堆增强操作，有时候少即是多。
还有一个工程上的细节：数据增强最好放在GPU上做，而不是CPU。NVIDIA DALI或者Kornia这类库可以把增强操作搬到GPU上，利用GPU的并行计算能力，进一步减轻CPU的负担。我实测下来，把颜色抖动和归一化放到GPU上之后，数据加载的吞吐量又提升了20%左右。
3. 模型构建：从手写反向传播到模块化设计
3.1 手写一个微型框架到底值不值得
ai-engineering-from-scratch这个标题里，“from scratch”到底要“scratch”到什么程度？我的答案是：你不需要手写CUDA核函数，但你应该手写一遍反向传播。为什么？因为如果你不理解链式法则在计算图上是如何传播的，你就无法理解为什么有些操作会导致梯度消失、为什么detach()会切断梯度流、为什么in-place操作有时候会报错。这些知识在你调参和debug的时候是救命的。
我建议你用一个周末的时间，用NumPy实现一个两层的全连接网络，在MNIST上跑通训练。不需要追求性能，只需要把前向传播、损失计算、反向传播、参数更新这四个步骤写清楚。你会遇到几个经典问题：softmax交叉熵的梯度推导、数值稳定性处理（减去最大值防止指数溢出）、参数初始化（为什么不能用全零初始化）。这些问题在PyTorch里都被封装好了，你调包的时候感觉不到，但一旦你自己写一遍，就会对“模型到底在学什么”有完全不同的认知。
手写框架的另一个好处是，你会对计算图有直观的理解。PyTorch的动态图机制本质上就是在每次前向传播的时候构建一张计算图，反向传播的时候沿着这张图做拓扑排序然后逐节点求导。当你自己用Python字典和列表来维护这张图的时候，你就能理解为什么torch.no_grad()能节省显存、为什么retain_graph=True有时候是必要的、为什么循环神经网络的反向传播会那么慢。
3.2 模块化设计：把模型拆成可复用的组件
手写一遍之后，回到PyTorch做实际项目，你的代码组织方式会完全不一样。我见过很多人的模型代码就是一个巨大的nn.Module，里面堆了几百行forward函数，各种if-else分支，改一个地方就牵一发而动全身。这种写法在实验阶段勉强能用，但一旦你要做消融实验、要换backbone、要加新的head，就会非常痛苦。
我的做法是把模型拆成几个独立的组件：Backbone负责特征提取，Neck负责特征融合，Head负责最终输出。每个组件都是一个独立的nn.Module，通过配置文件来组合。这样我想换ResNet为EfficientNet的时候，只需要改一行配置；想加一个FPN的时候，只需要在Neck里注册一个新的模块。这种设计模式在检测和分割任务里特别常见，但分类和NLP任务同样适用。
还有一个工程上的技巧：用torch.nn.utils.parametrize来做权重归一化或者谱归一化，而不是在forward里手动做。这样你的模型结构保持干净，归一化操作对上层透明，保存和加载state_dict的时候也不会出问题。我早期做GAN训练的时候，在forward里手动做谱归一化，结果保存模型的时候忘了把归一化后的权重还原，加载的时候精度直接崩了。后来改用parametrize，这个问题就再也没出现过。
4. 训练循环：那些教程不会告诉你的调参细节
4.1 学习率调度：不是所有任务都适合余弦退火
学习率是训练过程中最重要的超参数，没有之一。我见过太多人用固定的学习率从头训到尾，然后抱怨模型收敛慢或者震荡大。学习率调度的核心思想是：训练初期用大学习率快速下降，训练后期用小学习率精细搜索。但具体用哪种调度策略，取决于你的任务和优化器。
StepLR是最简单的，每隔几个epoch把学习率乘以一个衰减因子。它的优点是稳定可控，缺点是衰减点需要手动调，而且衰减太突然可能会导致loss反弹。CosineAnnealingLR是这几年比较流行的，学习率按照余弦曲线从最大值平滑降到最小值。它在很多视觉任务上表现不错，但有一个坑：如果你的训练总epoch数设置得不对，余弦周期和实际训练进度不匹配，最后几个epoch的学习率可能还很大，导致模型在最优解附近震荡。
OneCycleLR是我个人比较推荐的，它先让学习率从一个小值线性上升到最大值，然后再降下来。这种策略在训练初期能快速探索参数空间，后期又能稳定收敛。但它的超参数比较多：最大学习率、总步数、上升阶段占比、初始学习率。我的经验是，最大学习率设成用LR Finder找出来的那个值的80%左右，上升阶段占比设成0.3，通常能取得不错的效果。
还有一个容易被忽略的点是warmup。对于Transformer类模型，训练初期的梯度非常大，如果直接用大学习率，模型很容易发散。所以通常会在前几百到几千步里让学习率从0线性增加到设定值。warmup的步数一般设成总训练步数的5%到10%，具体取决于你的batch size和模型大小。
4.2 梯度裁剪和混合精度训练的配合
梯度裁剪是防止梯度爆炸的常用手段，特别是在RNN和Transformer的训练中。torch.nn.utils.clip_grad_norm_是最常用的实现，它把所有参数的梯度拼成一个向量，然后计算这个向量的范数，如果超过阈值就按比例缩放。阈值设多少？我的经验是1.0到5.0之间，具体看任务。如果梯度范数经常超过阈值，说明学习率可能太大了；如果从来没超过，说明裁剪没起作用，可以适当调小阈值。
混合精度训练是另一个提速利器。torch.cuda.amp可以自动把部分计算转成FP16，在保持精度的同时减少显存占用、提升计算速度。但混合精度和梯度裁剪配合的时候有一个坑：FP16的梯度范围比FP32小很多，如果梯度值太小，在FP16下会变成0，导致参数更新失效。所以GradScaler会把loss放大一个因子，让梯度也相应放大，更新参数之前再缩回去。如果你手动做梯度裁剪，一定要在scaler.unscale_之后、scaler.step之前做，否则你裁剪的是放大后的梯度，阈值就不对了。
我实测下来，混合精度训练在V100和A100上能带来1.5到2倍的速度提升，显存占用减少30%到40%。但要注意，有些操作在FP16下数值不稳定，比如softmax、layer norm、loss计算，这些最好保持在FP32下做。torch.cuda.amp.autocast会自动处理这些，但如果你手写了一些自定义操作，需要手动加@torch.cuda.amp.custom_fwd装饰器来指定精度。
5. 推理优化：从训练完到真正能用之间隔着一条河
5.1 模型量化：精度和速度的权衡艺术
训练完一个模型，保存成state_dict，这只是万里长征的第一步。真正部署的时候，你会发现原始模型太大、太慢、太吃显存。量化是最常用的优化手段，它把FP32的权重和激活值转成INT8，模型大小直接缩小到四分之一，推理速度提升2到4倍。但量化不是免费的午餐，精度损失是必然的，关键是怎么把损失控制在可接受范围内。
PyTorch提供了三种量化方式：动态量化、静态量化和量化感知训练。动态量化最简单，只需要一行代码torch.quantization.quantize_dynamic，它只量化权重，激活值在推理时动态量化。这种方式对LSTM和Transformer类模型效果不错，但对CNN的加速效果有限。静态量化需要提供校准数据集，让模型在推理过程中收集激活值的分布，然后确定量化的scale和zero_point。这种方式精度更好，但流程更复杂。量化感知训练是在训练阶段就模拟量化的误差，让模型学会适应量化后的权重，精度最高，但需要重新训练。
我的经验是，对于大多数视觉任务，静态量化能把精度损失控制在1%以内，速度提升2倍左右。如果精度要求特别高，比如医学影像诊断，那就上量化感知训练，虽然麻烦一点，但值得。还有一个坑是：不是所有算子都支持量化，比如某些自定义的激活函数、某些特殊的卷积变体。量化之前一定要用torch.quantization.fuse_modules把Conv+BN+ReLU融合成一个算子，这样量化的时候才能正确处理。
5.2 推理引擎选型：ONNX、TensorRT还是TorchScript
模型训练用PyTorch，推理的时候不一定非要用PyTorch。ONNX是一个开放的模型交换格式，可以把PyTorch模型导出成ONNX，然后用ONNX Runtime或者TensorRT来推理。ONNX Runtime在CPU上表现很好，支持多种硬件后端；TensorRT在NVIDIA GPU上性能最强，但只支持NVIDIA的硬件。
TorchScript是PyTorch自带的推理模式，它把模型编译成静态图，去掉Python解释器的开销。它的优点是和PyTorch生态无缝衔接，不需要额外的转换步骤；缺点是优化程度不如TensorRT，特别是在INT8量化方面。
我一般会先导出ONNX，用onnxsim做图优化，然后用onnxruntime做基准测试。如果速度不满足要求，再考虑转TensorRT。转TensorRT的时候要注意算子兼容性，有些PyTorch算子TensorRT不支持，需要自定义插件或者改写模型结构。还有一个坑是动态shape：TensorRT对动态shape的支持有限，如果你的输入尺寸不固定，需要在构建引擎的时候指定优化profile，否则推理的时候会报错或者性能下降。
6. 服务化部署：让模型真正跑在生产环境里
6.1 用FastAPI搭建推理服务的最小可行方案
模型推理脚本和推理服务是两码事。推理脚本可以慢慢跑，服务必须考虑并发、超时、错误处理、资源隔离。我用得最多的组合是FastAPI加Uvicorn，轻量、异步、性能足够。一个最小的推理服务大概长这样：加载模型到全局变量，定义一个/predict接口，接收JSON请求，做预处理、推理、后处理，返回JSON响应。
但这里面有几个工程细节需要注意。第一，模型加载要放在服务启动的时候，不要放在请求处理函数里，否则每个请求都重新加载模型，延迟会高得离谱。第二，推理过程要加锁或者用队列，因为PyTorch的模型不是线程安全的，多个请求同时推理可能会导致内存错误。第三，要设置合理的超时时间，防止某个请求卡死拖垮整个服务。第四，要加健康检查接口，方便负载均衡器做探活。
我早期做的一个服务，因为没有加推理锁，在并发量上来之后偶尔会崩溃，日志里全是CUDA error。后来改成用一个asyncio.Queue把请求排队，单个worker串行推理，稳定性问题就解决了。当然，串行推理的吞吐量有限，如果要支持高并发，可以用TorchServe或者Triton Inference Server，它们支持动态批处理和模型并行，但部署复杂度也更高。
6.2 监控和日志：模型上线只是开始
模型上线之后，你怎么知道它工作正常？准确率有没有下降？输入分布有没有漂移？这些问题靠人肉看日志是看不过来的。我的做法是至少监控三个层面的指标：系统层面（CPU、GPU、内存、延迟、QPS）、业务层面（请求量、成功率、错误码分布）、模型层面（预测置信度分布、输入特征分布、输出类别分布）。
模型层面的监控最容易被忽略，但恰恰最重要。比如你做了一个情感分类服务，上线之后发现负面情感的预测比例突然从20%涨到了50%，那可能是输入数据分布变了，也可能是模型出了问题。这时候你需要有一个基线，把训练时的输出分布和线上的输出分布做对比，用KL散度或者PSI指标来量化漂移程度。如果漂移超过阈值，就触发告警，人工介入排查。
日志方面，我建议把每次推理的输入、输出、置信度、耗时都记录下来，存到Elasticsearch或者ClickHouse里，方便后续做分析和回溯。但要注意脱敏，不要把用户的敏感信息写进日志。还有一个技巧是采样记录：不需要记录所有请求，按1%或者5%的比例采样就够了，既能反映整体情况，又不会把存储撑爆。
7. 我踩过的那些坑和最后的经验之谈
做AI工程这几年，踩过的坑比写过的代码还多。有一个坑我印象特别深：早期做模型部署的时候，我在本地测试一切正常，上线之后发现推理结果和本地完全不一样。排查了两天才发现，本地用的是PyTorch 1.7，线上环境用的是1.8，两个版本之间某个算子的默认行为变了。从那以后，我所有的项目都会用conda或者docker把环境完全锁定，requirements.txt里精确到patch版本号，Docker镜像的base image也固定digest。
还有一个坑是关于随机种子的。做实验的时候，我设置了torch.manual_seed(42)，但结果每次跑出来都不一样。后来发现是DataLoader的worker_init_fn没有设置，每个worker的随机种子是独立的。还有CUDA的卷积算法是非确定性的，torch.backends.cudnn.deterministic = True可以强制确定性，但会牺牲一点性能。如果你的实验需要严格复现，这两个设置缺一不可。
最后分享一个我个人的习惯：每做一个新项目，我都会先写一个README，把环境配置、数据准备、训练命令、推理命令、已知问题都记下来。这个习惯看起来不起眼，但当你三个月后回头看这个项目，或者要把项目交接给别人的时候，这个README能省下大量沟通成本。AI工程是一个迭代非常快的领域，今天能跑的代码，明天可能就因为某个库的更新而报错。把关键信息文档化，是对自己也是对团队负责。
