1. 从零手搓AI工程为什么“调包”救不了你很多人对AI工程的理解还停留在“装个环境、跑个demo、调个API”的阶段。我刚开始接触这个领域时也这么想直到有一次线上推理服务在高峰期直接雪崩日志里全是显存溢出和请求超时我才意识到会调包和会做AI工程中间隔着一整套系统工程能力。“ai-engineering-from-scratch”这个标题核心不在“AI”而在“from scratch”。它指向的是一类非常具体的需求不依赖高度封装的框架黑盒从底层把推理、训练、数据处理、服务部署这条链路自己搭一遍。这样做的好处不是“重复造轮子”而是当轮子出问题时你知道该拧哪颗螺丝。这篇文章适合三类人一是刚转行做AI应用、只会调库但不懂原理的开发者二是被线上推理性能问题折磨过、想搞清楚底层机制的后端工程师三是想系统补齐AI工程能力、不满足于“跑通就行”的技术人。我会围绕从零构建AI工程链路的关键环节展开包括推理引擎的最小实现、显存与算力的估算方法、数据管道的设计取舍、服务化部署的坑以及我实际踩过的几个典型问题。需要先说明一点这里的“from scratch”不是让你从晶体管开始造芯片而是指不把核心逻辑交给黑盒。你可以用现成的数学库做矩阵运算但推理调度、内存管理、批处理策略这些决定系统行为的部分得自己心里有数。2. 推理引擎的最小可用实现从一次矩阵乘法说起2.1 为什么先手写一遍推理循环大部分框架把推理封装成一行model.generate()方便是真方便但一旦遇到性能瓶颈你连从哪里下手都不知道。我建议每个做AI工程的人都至少手写一次最朴素的推理循环哪怕只是跑一个两层的小网络。核心逻辑其实不复杂输入数据经过线性变换、激活函数、再线性变换输出结果。用Python和NumPy就能实现。关键不在于结果多准而在于你会被迫面对几个问题权重怎么加载、中间结果怎么缓存、批处理维度怎么对齐、数值精度怎么控制。这些问题在框架里被隐藏了但在真实系统里一个都跑不掉。我当初手写第一版时最直接的收获是理解了推理的本质是一系列张量运算的调度。框架帮你做的是算子融合、内存复用、并行计算但前提是你得知道这些优化的对象是什么。2.2 一个可运行的最小推理实现下面这段代码展示了一个极简的全连接网络推理过程不依赖任何深度学习框架只用NumPyimport numpy as np def linear(x, w, b): return np.dot(x, w) b def relu(x): return np.maximum(0, x) def softmax(x): exp_x np.exp(x - np.max(x, axis-1, keepdimsTrue)) return exp_x / np.sum(exp_x, axis-1, keepdimsTrue) def inference(x, weights): h relu(linear(x, weights[w1], weights[b1])) h relu(linear(h, weights[w2], weights[b2])) out softmax(linear(h, weights[w3], weights[b3])) return out weights { w1: np.random.randn(128, 256).astype(np.float32) * 0.01, b1: np.zeros(256, dtypenp.float32), w2: np.random.randn(256, 128).astype(np.float32) * 0.01, b2: np.zeros(128, dtypenp.float32), w3: np.random.randn(128, 10).astype(np.float32) * 0.01, b3: np.zeros(10, dtypenp.float32), } x np.random.randn(1, 128).astype(np.float32) result inference(x, weights) print(result.shape, result.sum())这段代码跑起来毫无难度但它暴露了几个真实工程里必须处理的问题。第一np.dot在大矩阵上效率远不如专门的BLAS库实际部署时得换底层实现。第二每次推理都重新分配中间张量高频调用时内存分配开销会累积。第三没有批处理一次只处理一条数据吞吐量上不去。2.3 从最小实现到工程化的三个跳跃第一个跳跃是算子替换。把NumPy换成针对硬件优化的计算库比如用OpenBLAS或oneDNN做矩阵乘法性能可能有数倍差距。这一步的取舍在于优化库的接口更复杂但换来的是实打实的吞吐提升。第二个跳跃是内存池化。推理过程中反复申请释放张量内存会导致碎片化和分配延迟。工程上的做法是预分配一块大内存自己管理张量的生命周期。我见过一个案例仅仅是把中间张量的分配改成复用P99延迟就降了将近四成。第三个跳跃是批处理调度。单条推理的算力利用率往往很低因为矩阵乘法的规模太小硬件并行度吃不满。把多条请求攒成一批一起算能显著提升吞吐。但批处理会引入等待延迟需要在吞吐和延迟之间找平衡点。常见的策略是设置一个最大等待窗口窗口内到达的请求合并成一批。3. 显存与算力估算上线前必须算清楚的两笔账3.1 模型显存占用的构成拆解很多人上线前只关心模型文件多大结果一跑就爆显存。模型显存占用远不止权重本身还包括激活值、梯度训练时、优化器状态、以及推理框架自身的开销。以推理场景为例显存占用大致分三块权重占用、激活值占用、临时缓冲区。权重占用好算参数量乘以每个参数的字节数。比如一个1亿参数、FP16精度的模型权重大约占200MB。激活值占用跟批大小和序列长度强相关这部分往往才是大头。临时缓冲区取决于具体算子的实现框架不同差异很大。我一般会用一个粗略公式做初筛总显存 ≈ 权重 × 1.2 批大小 × 单条激活值 × 层数系数。层数系数是个经验值Transformer类模型通常在2到4之间。这个公式不精确但能快速判断配置是否离谱。3.2 算力需求的估算逻辑算力估算的核心是搞清楚一次推理需要多少次浮点运算。对于全连接层计算量约等于2 × 输入维度 × 输出维度。对于注意力机制计算量跟序列长度的平方成正比这也是长序列推理特别吃算力的原因。把各层的计算量加起来再乘以请求频率就得到所需的算力总量。然后对照硬件的峰值算力考虑实际利用率通常30%到60%就能估算需要多少计算资源。这里有个容易忽略的点算力利用率和批大小强相关。批太小硬件跑不满批太大延迟又上去了。下面这张表是我在实际项目中总结的估算参考针对不同规模模型的推理场景模型规模权重显存(FP16)单条激活值(约)建议最小批典型算力利用率1亿参数200MB10MB835%10亿参数2GB50MB445%70亿参数14GB200MB255%130亿参数26GB350MB160%注意这张表是经验值实际数字会因模型结构、序列长度、框架实现差异很大。它的价值在于帮你快速判断“这个配置大概靠不靠谱”而不是精确计算。3.3 一个真实的估算失误案例我之前负责过一个文本分类服务模型只有几千万参数按权重算显存占用很小我直接按单卡部署。结果上线后并发一上来就OOM。排查后发现问题出在动态批处理没有设上限高峰期一批攒了几百条请求激活值直接把显存吃光了。后来改成设置最大批大小并且根据当前显存水位动态调整问题才解决。这个教训让我明白显存估算不能只看静态的权重动态部分的峰值才是决定性的。上线前一定要做压力测试观察显存水位随并发的变化曲线。4. 数据管道设计被低估的工程重灾区4.1 数据管道的三个核心阶段AI工程里数据管道的重要性经常被低估。模型再强喂进去的数据有问题结果就是垃圾进垃圾出。一个完整的数据管道通常包含三个阶段采集与清洗、预处理与特征化、批处理与投递。采集阶段要处理的是数据来源的多样性可能是数据库、消息队列、文件系统。清洗阶段要处理缺失值、异常值、格式不一致。预处理阶段把原始数据转成模型能吃的张量格式。投递阶段负责把处理好的数据按需送给推理或训练进程。每个阶段都有坑。采集阶段的坑在于数据源不稳定清洗阶段的坑在于规则太死导致误杀预处理阶段的坑在于CPU和GPU之间的数据搬运成为瓶颈投递阶段的坑在于背压处理不当导致内存堆积。4.2 预处理为什么容易成为瓶颈很多人把注意力放在模型推理上结果发现GPU利用率上不去排查半天发现是预处理拖了后腿。预处理通常在CPU上做包括分词、归一化、padding这些操作。如果预处理速度跟不上推理速度GPU就会经常空转。我实测过一个场景单条文本的分词加padding耗时约2毫秒而模型推理只要1毫秒。也就是说预处理成了整个链路的瓶颈。解决办法有几个方向一是把预处理并行化用多进程或多线程二是把部分预处理逻辑下沉到更高效的实现比如用C重写热点函数三是做预处理结果的缓存对重复输入直接命中缓存。4.3 批处理策略的取舍批处理是提升吞吐的关键手段但策略设计需要权衡。常见的做法有静态批处理和动态批处理两种。静态批处理是固定批大小实现简单但灵活性差请求少时浪费算力请求多时排队。动态批处理是根据当前请求量动态组批吞吐和延迟表现更好但实现复杂度高。我在实际项目里更倾向动态批处理但会加两个约束设置最大批大小防止显存溢出设置最大等待时间防止延迟失控。这两个参数的调优需要结合业务对延迟的容忍度。如果业务能接受200毫秒的延迟那等待窗口可以设大一点换取更高的吞吐。还有一个容易被忽略的点是批内数据的长度对齐。如果一批里有的序列长、有的短padding到统一长度会浪费大量算力。更好的做法是按长度分桶把长度相近的请求放在一批里。这个优化在长序列场景下效果特别明显。5. 服务化部署从能跑到扛得住的鸿沟5.1 推理服务的接口设计要点把模型跑起来只是第一步做成服务对外提供能力是另一回事。接口设计要考虑几个问题请求格式怎么定、响应怎么返回、错误怎么处理、版本怎么管理。请求格式我一般推荐用JSON可读性好、调试方便。但如果对性能要求极高可以考虑用Protobuf或MessagePack做序列化减少传输开销。响应里除了结果本身建议带上耗时信息方便排查问题。错误处理是个重点。模型推理可能因为各种原因失败输入格式不对、显存不足、超时。每种错误应该返回明确的错误码和描述而不是笼统的500。我见过有的服务所有错误都返回同一个码排查问题时简直抓瞎。5.2 并发模型的选择推理服务的并发模型直接影响吞吐和延迟。常见的选择有同步阻塞、多线程、异步IO、多进程几种。同步阻塞实现最简单但并发能力差。多线程受限于GIL对CPU密集型任务提升有限。异步IO适合IO密集型场景但推理本身是计算密集型收益不明显。多进程能绕开GIL但进程间通信有开销。我的经验是如果推理框架本身支持批处理和异步优先用框架的能力。如果框架不支持可以用一个请求队列加多个工作进程的模式。请求先入队工作进程从队列取批数据做推理结果再回传。这样既能批处理又能控制并发度。5.3 健康检查与优雅退出这两个点看起来不起眼但在生产环境里至关重要。健康检查让负载均衡器知道实例是否可用优雅退出保证服务重启时不丢请求。健康检查不能只检查进程是否存活还要检查模型是否加载完成、显存是否正常、依赖服务是否可达。我一般会实现两个接口一个轻量的存活检查一个完整的就绪检查。负载均衡器用存活检查判断是否摘除实例用就绪检查判断是否开始转发流量。优雅退出的逻辑是收到退出信号后停止接受新请求等待正在处理的请求完成然后释放资源退出。这里的关键是设置一个合理的等待超时避免无限期等待。超时后强制退出但要记录日志方便排查。6. 踩坑实录那些让我熬夜的典型问题6.1 显存碎片导致的间歇性OOM这个问题困扰了我很久。服务跑得好好的突然就OOM重启后又正常过一段时间又复现。排查后发现是显存碎片化频繁申请释放不同大小的张量导致显存里全是小空洞虽然总空闲显存够但没有一块连续的大空间满足新请求。解决办法是引入显存池预分配大块显存自己管理避免频繁向系统申请。PyTorch有内置的缓存分配器但配置不当也会碎片化。关键参数是设置合理的缓存块大小让分配器尽量复用已有的块。6.2 批处理导致的延迟毛刺动态批处理提升了平均吞吐但引入了延迟毛刺。表现是大部分请求很快返回但偶尔有请求延迟特别高。原因是这些请求恰好赶上了批处理窗口的边界等待了完整的窗口时间。缓解办法是让等待窗口自适应请求少时窗口短请求多时窗口长。还可以设置优先级对延迟敏感的请求单独处理不走批处理。这个取舍没有完美解只能根据业务特点找平衡。6.3 数值精度引发的诡异结果有一次模型输出结果偶尔出现NaN排查了很久。最后定位到是某些输入经过多层计算后数值溢出FP16精度不够导致。改成FP32后问题消失但性能下降明显。折中方案是用混合精度大部分计算用FP16关键层用FP32。或者引入数值稳定技巧比如在softmax前减去最大值、在归一化时加一个极小值防止除零。这些技巧在框架里通常有默认实现但自己手写时容易漏掉。6.4 数据管道背压缺失导致的内存爆炸数据生产速度超过消费速度时如果没有背压机制数据会在内存里越堆越多最终OOM。我遇到过一次上游数据源突然加速下游推理跟不上队列长度暴涨内存直接打满。解决办法是给队列设上限满了就阻塞生产者或丢弃数据。丢弃策略要看业务能否接受不能接受就阻塞能接受就丢弃并记录。更好的做法是监控队列长度接近上限时提前告警给扩容留出时间。7. 从零构建之后我总结的几条实战原则走完一遍从零构建的流程后我对AI工程的理解和只会调包时完全不同。这里分享几条我实际总结出来的原则不一定对所有人都适用但至少是我踩过坑之后的真实体会。第一先算账再动手。上线前把显存和算力估算清楚别等跑起来才发现资源不够。估算不用很精确但量级不能错。第二瓶颈往往不在你以为的地方。模型推理看起来是计算密集型但实际瓶颈可能是数据预处理、内存分配、甚至日志打印。做性能优化前先做profiling用数据说话。第三批处理是吞吐的杠杆但要控制好延迟。动态批处理能大幅提升吞吐但等待窗口和最大批大小需要根据业务调优没有万能参数。第四监控要覆盖全链路。从请求进入到结果返回每个环节的耗时、成功率、资源占用都要有监控。出问题时能快速定位是哪个环节拖后腿。第五优雅降级比硬扛更重要。资源不足时与其让服务崩溃不如主动拒绝部分请求或降低服务质量。设置合理的限流和熔断策略保证核心功能可用。最后再分享一个小技巧如果你也在做从零构建的练习建议每实现一个模块就写一个最小测试用例。不是为了覆盖率而是为了在改动时快速验证行为是否符合预期。我当初就是靠这个方法在重构推理循环时避免了好几次回归问题。