1. 从零手搓AI工程：为什么我不建议你直接调包
很多人一听到“AI工程”这四个字，第一反应就是打开某个云平台，拖几个组件，调几个API，然后跑通一个Demo，就觉得自己已经入门了。我刚开始也是这么想的，直到有一次线上推理服务在高峰期直接雪崩，日志里全是显存溢出和请求超时，我才意识到，那些被封装得严严实实的接口，一旦出了问题，我连从哪里下手排查都不知道。这就是我决定从零开始搭建一套AI工程体系的直接原因，也是“ai-engineering-from-scratch”这个项目最核心的出发点。
所谓从零手搓，并不是说要你去造GPU或者重写CUDA内核，而是指你要亲手把数据加载、模型训练、推理服务、监控告警这条链路完整地走一遍，每一个环节都自己写代码、自己调参数、自己处理异常。这样做的好处非常明显：当推理延迟突然飙升时，你能立刻判断是数据预处理阻塞了主线程，还是模型本身的计算图没有优化好，而不是对着一个黑盒干瞪眼。这个项目适合那些已经会用PyTorch或TensorFlow跑通Demo，但一上生产环境就心里发虚的开发者，也适合想系统理解AI系统全貌的运维和后端同学。
我见过太多团队，模型指标刷得很漂亮，但一上线就各种问题。根本原因在于，训练和推理是两个完全不同的工程场景。训练可以容忍慢，可以容忍偶尔的失败重试，但推理服务对延迟、吞吐、内存占用极其敏感。从零搭建的过程，就是强迫你去面对这些差异，去理解每一个设计决策背后的权衡。比如，为什么批处理大小不能随便设？为什么模型量化有时候反而会变慢？这些问题，只有你自己亲手实现一遍，才能真正搞明白。
接下来的内容，我会按照我实际搭建的顺序，把数据管道、模型训练、推理服务、性能调优这几个核心模块拆开来讲。每个部分我都会说明为什么这么设计，以及我在实操中踩过哪些坑。你可以把这篇文章当成一个施工手册，也可以当成一份避坑指南，根据自己的基础挑着看。
2. 数据管道：别让IO成为你的第一个瓶颈
2.1 为什么我把数据加载单独抽成一个服务
刚开始的时候，我图省事，直接在训练脚本里用DataLoader加载本地图片。小数据集上跑得挺欢，但数据量一上来，问题就暴露了：GPU利用率忽高忽低，有时候直接掉到10%以下。用nvidia-smi一看，GPU在等数据。这就是典型的IO瓶颈。很多人第一反应是加num_workers，但盲目增加进程数会导致内存爆炸，而且如果磁盘IO本身就到了上限，加再多进程也没用。
我的做法是把数据加载单独抽成一个轻量级服务，训练脚本通过本地网络请求去拉数据。这样做的好处有三个：第一，数据预处理可以独立扩展，不会拖累训练主进程；第二，可以方便地做数据缓存和预取；第三，训练和推理可以共用同一套数据接口，保证线上线下一致性。具体实现上，我用FastAPI起了一个服务，内部维护一个内存缓存池，把常用的数据块缓存在内存里，减少磁盘随机读。
这里有个细节需要注意：缓存池的大小不能拍脑袋定。我的经验是，先估算单个样本预处理后的内存占用，然后根据可用内存的70%来反推缓存条目数。比如一个样本预处理后是2MB，机器有32GB内存，那缓存池最多放10000条左右，留出余量给模型和其他进程。超过这个数，系统就开始频繁换页，性能反而下降。
2.2 预处理流水线的并行化陷阱
数据预处理里最耗时的通常是图像解码和增强。我一开始用Python的多进程池来做，结果发现进程间通信的开销比计算本身还大。后来改成用共享内存加向量化操作，性能提升了将近三倍。具体来说，就是把一批图像先读成二进制块，放到共享内存里，然后每个工作进程直接从共享内存读取并解码，避免了大数组在进程间来回拷贝。
另一个坑是数据增强的顺序。很多人习惯先做随机裁剪再做归一化，这本身没问题，但如果你用的是GPU做增强，就要注意显存碎片的问题。我实测下来，把增强操作尽量放在CPU端用NumPy或OpenCV做，然后只把最终张量传到GPU，整体吞吐更稳定。GPU适合做大规模矩阵运算，不适合做大量小规模的条件分支和随机操作。
还有一个容易被忽略的点是数据格式。我强烈建议在预处理阶段就把数据转成适合模型输入的格式，比如把图片统一转成RGB、统一尺寸、统一数据类型。不要指望模型内部去处理各种奇怪的输入格式，那会让你的推理服务变得极其脆弱。我见过一个线上事故，就是因为用户上传了一张CMYK模式的图片，导致整个批次的推理全部失败。如果预处理阶段做了强制转换，这种问题根本不会发生。
2.3 数据版本管理与回滚策略
数据管道还有一个容易被忽视的工程问题：版本管理。模型迭代的时候，数据往往也在变。如果没有版本记录，你根本不知道线上模型是用哪份数据训练的，出了问题也无法复现。我的做法是给每次数据预处理的结果打上哈希标签，训练脚本必须指定数据版本。这样即使数据更新了，旧模型依然可以加载旧版本的数据做验证。
回滚策略也很重要。新数据上线后，如果发现模型指标下降，要能快速切回旧数据。我通常会在数据服务里保留最近三个版本的数据，用不同的路由区分。训练任务通过环境变量指定数据版本，切换只需要改一个配置，不需要重新部署服务。这个设计在紧急情况下能省下大量时间。
3. 模型训练：从能跑到跑得好之间的鸿沟
3.1 混合精度训练不是万能药
混合精度训练现在几乎是标配了，用好了能省显存、提速，但用不好就是灾难。我刚开始用的时候，直接开了amp，结果损失函数里出现了NaN。排查了很久才发现，是某些层的梯度在FP16下溢出了。解决办法是给这些层加梯度缩放，或者干脆把这些层保持在FP32。PyTorch的amp模块提供了自动缩放，但你需要监控缩放因子的变化，如果它一直往下掉，说明模型里有数值不稳定的地方。
另一个经验是，混合精度对batch size很敏感。batch size太小的时候，梯度噪声大，FP16的精度损失会被放大。我一般建议batch size至少到32以上再考虑开混合精度，否则老老实实用FP32。还有，混合精度对某些优化器也不友好，比如Adam的一些变体在FP16下更新量会被截断。如果你发现开了混合精度后收敛变慢，先检查优化器的状态更新是不是在FP32下进行的。
3.2 检查点保存的时机与策略
训练过程中保存检查点，看起来很简单，但里面有不少门道。我一开始是每个epoch存一次，结果磁盘很快就被撑爆了。后来改成按验证指标保存，只保留最好的三个检查点。但这里有个问题：如果验证集本身有波动，可能会错过真正的最优点。我的做法是同时保存“最佳指标”和“最新”两个检查点，最佳指标用于最终部署，最新检查点用于恢复训练。
保存检查点的时候，一定要把优化器的状态也存下来。很多人只存模型参数，结果恢复训练后优化器状态重置，导致训练曲线出现明显抖动。另外，如果用了学习率调度器，调度器的状态也要存。我一般会把所有需要恢复的状态打包成一个字典，用torch.save保存。加载的时候用map_location指定设备，避免因为设备不一致导致加载失败。
还有一个细节是检查点的写入方式。直接覆盖旧文件有风险，如果写入过程中程序崩溃，检查点就损坏了。我习惯先写到一个临时文件，写完后再原子性地重命名。这样即使写入失败，旧检查点依然完好。这个习惯在长时间训练中能救命。
3.3 分布式训练的数据分片与梯度同步
当单卡放不下模型或者训练太慢时，就需要上分布式。我一开始用DataParallel，结果发现主卡显存占用远高于其他卡，而且速度提升有限。后来换成DistributedDataParallel，情况好了很多。DDP的核心是每个进程独立加载数据，然后通过all-reduce同步梯度。这里的关键是数据分片要均匀，否则快的进程要等慢的进程，整体效率被拖累。
数据分片我一般用DistributedSampler，它会自动把数据按进程数切分。但要注意，如果数据集大小不能被进程数整除，最后一个batch可能会多出一些样本，导致不同进程的batch size不一致。解决办法是设置drop_last=True，或者手动补齐。梯度同步方面，DDP默认是每个batch同步一次，如果通信开销大，可以考虑梯度累积，每N个batch同步一次。但梯度累积会改变有效的batch size，学习率也要相应调整。
还有一个坑是随机种子。分布式训练中，每个进程的随机种子必须不同，否则数据增强会完全一样，相当于变相减小了batch size。我通常用base_seed + rank来设置每个进程的种子，保证数据增强的多样性。
4. 推理服务：把模型变成产品的最后一公里
4.1 模型序列化与加载的性能考量
训练完的模型要部署，第一步就是序列化。PyTorch提供了torch.save和torch.jit.trace两种方式。torch.save保存的是Python对象，加载时需要完整的类定义，部署环境稍微有点不一致就可能加载失败。torch.jit.trace会把模型转成TorchScript，脱离Python依赖，加载更快，但要求模型的计算图是静态的。我一般优先用TorchScript，如果模型里有动态控制流，再退回torch.save。
加载性能方面，模型文件越大，加载越慢。如果服务需要频繁重启，加载时间会直接影响可用性。我的做法是在服务启动时就把模型加载到内存，并预热几次推理，让CUDA内核完成编译和缓存。预热很重要，第一次推理往往比后续慢好几倍，如果不预热，第一个请求的延迟会非常高。预热的数据可以用随机张量，也可以用真实数据的采样，后者效果更好。
还有一个细节是模型文件的存储位置。放在网络存储上加载会慢很多，我一般会把模型文件复制到本地SSD再加载。如果模型特别大，可以考虑分片加载，但实现复杂度较高，一般场景下没必要。
4.2 批处理与动态批处理的实现逻辑
推理服务的吞吐和延迟是一对矛盾。批处理能提高吞吐，但会增加延迟，因为要等齐一个批次。静态批处理实现简单，但灵活性差。动态批处理根据请求到达情况动态组批，能在延迟和吞吐之间取得更好的平衡。我实现过一个简单的动态批处理：维护一个请求队列，当队列长度达到阈值或者等待时间超过上限时，就触发一次推理。
动态批处理的关键参数是最大批大小和最大等待时间。最大批大小受显存限制，需要根据模型大小和输入尺寸来估算。最大等待时间决定了最坏情况下的延迟。我的经验是，如果服务对延迟敏感，最大等待时间设小一点，比如10毫秒；如果追求吞吐，可以设到50毫秒甚至更高。这两个参数需要根据实际流量压测来确定，没有万能值。
还有一个容易忽略的点是批内样本的尺寸对齐。如果输入尺寸不一致，组批时需要padding到最大尺寸，这会浪费计算资源。我一般会在预处理阶段就把输入统一到固定尺寸，避免动态padding。如果业务上确实需要不同尺寸，可以考虑按尺寸分桶，同桶内组批。
4.3 健康检查与优雅退出
推理服务上线后，健康检查是必不可少的。我见过很多服务只检查进程是否存活，不检查模型是否可用。结果模型加载失败，进程还在，但所有请求都返回错误。我的做法是健康检查接口里实际跑一次轻量推理，比如用一个固定的小张量过一遍模型，确认输出正常。这样能及时发现模型损坏或显存不足的问题。
优雅退出也很重要。服务收到终止信号时，不能直接杀进程，要先把队列里的请求处理完，再释放资源。我一般会设置一个超时时间，比如30秒，超时后强制退出。退出前要把模型从显存中释放，避免影响其他进程。如果用了GPU，还要注意CUDA上下文的清理，否则可能出现显存泄漏。
还有一个实践是给服务加一个就绪探针，在模型加载完成之前，就绪探针返回失败，这样负载均衡不会把流量导进来。等模型加载完、预热完成后，就绪探针再返回成功。这个机制在滚动更新时特别有用，能保证新实例完全准备好之后才接收流量。
5. 性能调优：那些文档里不会写的参数
5.1 显存占用的构成与优化手段
显存占用是推理服务最核心的资源约束。很多人只知道模型参数占显存，其实还有几大块：模型参数、中间激活值、CUDA上下文、显存碎片。模型参数是固定的，中间激活值跟batch size和输入尺寸相关，CUDA上下文一般几百MB，显存碎片则跟分配策略有关。我一般用torch.cuda.memory_summary()来查看详细占用，定位大头在哪里。
优化显存的手段有几个：第一，用更小的数据类型，比如FP16或INT8，但要注意精度损失；第二，减少中间激活值的保存，比如用梯度检查点，但推理时一般不需要；第三，及时释放不再使用的张量，Python的垃圾回收有时候不及时，可以手动调用torch.cuda.empty_cache()，但频繁调用会拖慢速度；第四，设置PYTORCH_CUDA_ALLOC_CONF环境变量来调整分配策略，比如用expandable_segments来减少碎片。
我实测下来，最有效的还是降低batch size和用更小的数据类型。但batch size太小会影响吞吐，所以要在延迟和吞吐之间找平衡点。我一般会做一个压测，画出不同batch size下的延迟和吞吐曲线，选一个拐点作为默认值。
5.2 推理延迟的拆解与定位
推理延迟可以拆成几个部分：网络传输、预处理、模型计算、后处理。定位延迟瓶颈的第一步是打点计时。我在每个阶段前后都加了时间戳，记录耗时。如果预处理占了大部分时间，就要优化数据加载和增强；如果模型计算是大头，就要考虑模型压缩或换更快的硬件。
网络传输延迟容易被忽略。如果服务部署在远程，请求和响应的传输时间可能比计算还长。解决办法是把服务部署在离用户近的地方，或者用gRPC代替HTTP来减少协议开销。我实测过，gRPC的延迟比HTTP低不少，尤其是在小请求场景下。
模型计算延迟的优化空间很大。除了换硬件，还可以用TensorRT或ONNX Runtime来加速。TensorRT对NVIDIA GPU的优化非常到位，能自动做层融合、精度校准和内核选择。但TensorRT的转换过程比较繁琐，对模型结构有要求。ONNX Runtime则更通用，支持多种硬件后端。我一般先用ONNX Runtime跑一遍，如果还不够快，再上TensorRT。
5.3 监控指标的选择与告警阈值
监控是生产环境的眼睛。我关注的指标分几类：资源类（GPU利用率、显存占用、CPU使用率、内存占用）、性能类（QPS、P50/P95/P99延迟、错误率）、业务类（请求量、成功率、特定业务指标）。资源类指标能帮你发现瓶颈，性能类指标能反映用户体验，业务类指标能评估服务健康度。
告警阈值不能拍脑袋定。我的做法是先跑一周，收集基线数据，然后根据均值和标准差来设阈值。比如P99延迟的均值是100毫秒，标准差是20毫秒，那告警阈值可以设在160毫秒（均值加三个标准差）。这样既能及时发现异常，又不会因为正常波动频繁告警。
还有一个经验是，告警要分级。轻微异常发通知，严重异常直接打电话。我见过太多团队把所有告警都设成电话，结果大家很快就麻木了，真正严重的问题反而被忽略。分级告警能保证重要问题得到及时处理。
6. 我在从零搭建过程中踩过的几个典型坑
6.1 环境依赖的版本地狱
从零搭建最头疼的就是环境依赖。PyTorch、CUDA、cuDNN、Python、各种第三方库，版本之间互相制约。我一开始用最新版，结果发现某个库不兼容，又降级，降级后又发现另一个库不兼容。折腾了两天才跑通。后来我学乖了，用Docker把环境固化下来，每个组件都锁定版本，再也没出现过“在我机器上能跑”的问题。
Dockerfile里我一般会指定基础镜像的精确版本，比如pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime，而不是用latest。Python依赖用requirements.txt锁定，每个包都写死版本号。构建镜像的时候用--no-cache，确保每次都是干净构建。镜像构建好后推到私有仓库，部署时直接拉取，保证线上线下环境一致。
还有一个细节是CUDA版本和驱动版本的兼容性。CUDA版本不能高于驱动支持的版本，否则会报错。我一般会在文档里记录驱动版本和CUDA版本的对应关系，换机器的时候先检查驱动版本。
6.2 日志与追踪的缺失导致排查困难
刚开始的时候，我没怎么在意日志，觉得能跑就行。结果线上出问题，日志里只有一行“推理失败”，什么上下文都没有。后来我加了详细的日志，包括请求ID、输入尺寸、模型版本、各阶段耗时、错误堆栈。这样出问题的时候，能快速定位是哪个请求、哪个阶段出的错。
追踪也很重要。我用OpenTelemetry给每个请求打上trace，记录从接收到响应的完整链路。这样不仅能看单次请求的耗时分布，还能分析不同服务之间的调用关系。如果某个下游服务变慢，能很快发现。
日志的级别也要合理设置。DEBUG级别日志太多，会影响性能；ERROR级别太少，会漏掉重要信息。我一般用INFO级别记录关键事件，用WARNING记录异常但可恢复的情况，用ERROR记录需要人工介入的问题。日志要结构化，用JSON格式，方便后续检索和分析。
6.3 压测数据与真实分布的偏差
压测是上线前的必要环节，但压测数据的选择很关键。我一开始用随机生成的张量做压测，结果线上表现和压测差很多。原因是真实数据的分布和随机数据完全不同，某些输入会导致模型走不同的分支，耗时差异很大。后来我改用真实数据的采样做压测，结果就准确多了。
压测的流量模式也要模拟真实情况。真实流量往往有波峰波谷，如果只按恒定QPS压测，无法发现突发流量下的问题。我一般会设计几种流量模式：恒定流量、阶梯上升、突发尖峰。每种模式都跑一遍，观察服务的表现。
还有一个坑是压测时的资源竞争。如果压测客户端和服务部署在同一台机器上，客户端的资源消耗会影响服务性能。我一般会把压测客户端单独部署，或者用多台机器分布式压测，确保压测结果反映的是服务本身的性能。
7. 从零搭建之后，我对AI工程的理解变化
自己亲手搭过一遍之后，再看那些封装好的平台和框架，感觉完全不一样了。以前觉得某个参数无关紧要，现在知道它背后可能影响显存分配或者计算图优化。以前遇到问题只会重启，现在能根据日志和监控快速定位。这种从底层到上层的理解，是看多少文档都换不来的。
还有一个变化是对“简单”的重新认识。以前觉得代码越少越好，现在觉得代码少不代表简单，可能只是把复杂度藏起来了。从零搭建的代码量肯定比调包多，但每一行都是可控的，出了问题知道去哪里找。这种可控性在生产环境中极其重要。
如果你也想从零搭建一套AI工程体系，我的建议是从小处着手，先跑通一个最小闭环，再逐步加功能。不要一上来就追求大而全，那样很容易半途而废。每加一个模块，都要想清楚它解决了什么问题，引入了什么新的复杂度。这样一步步走下来，你对整个系统的理解会非常扎实。
最后分享一个我常用的调试技巧：当推理结果不符合预期时，先别急着改模型，用相同的输入分别在训练模式和推理模式下跑一遍，对比中间层的输出。很多时候问题出在预处理或者后处理，而不是模型本身。这个技巧帮我省下了大量排查时间。
