推理工程正逐渐成为人工智能领域最重要的技能之一，我认为很多工程师仍然低估了它的重要性。

wryip

推理工程正逐渐成为人工智能领域最重要的技能之一，我认为很多工程师仍然低估了它的重要性。

训练过程往往备受关注，因为模型正是在这里创建的。但一旦模型需要处理实际流量，就会出现完全不同的问题。你突然需要处理排队、批处理、键值缓存压力、GPU内存、调度、路由、内核效率、尾延迟，以及一个令人不安的事实：两个请求访问同一个模型可能具有完全不同的成本特征。

首先需要理解的是，推理本身并非单一的工作负载。预填充和解码的行为截然不同。预填充处理提示符并构建键值缓存，跨提示符位置的工作可以高效地并行化。解码是自回归的，每个序列逐个推进词元，同时反复读取模型权重和累积的键值状态。这就是为什么预填充通常计算量很大，而解码在实际服务批次大小下会受到内存带宽的严重限制。

一旦你理解了这种划分，许多现代推理工作就不再像是一堆随机技巧的集合。FlashAttention 减少了注意力机制内部的内存流量。PagedAttention 改进了键值缓存的分配和管理方式。GQA 和 MQA 减少了每个 token 存储的键值状态量。连续批处理允许调度器不断混合活动序列，而不是等待固定批次完成。分块预填充防止过长的提示信息垄断执行。前缀缓存避免了重复计算系统已经处理过的上下文。

规模的扩大使问题更加复杂。张量并行以通信为代价减少了每个设备模型的内存占用。流水线并行引入了调度复杂性和流水线气泡。MoE 服务增加了专家路由、通信和负载不均衡问题。一些系统甚至将预填充和解码分别放在不同的工作节点上，因为它们的资源配置差异很大，难以同时优化。

这也是为什么每秒 token 数是一个极其不完整的指标。生产系统必须关注 TTFT（时间-时间-流量）、令牌间延迟、吞吐量、排队延迟、键值缓存利用率、批处理组成、GPU 利用率、p95/p99 延迟以及有效吞吐量（即实际有效请求吞吐量是否满足延迟目标）。服务器可能展现出极佳的总体吞吐量，但单个用户仍然需要等待过长的时间才能收到第一个令牌。

有趣的是，推理工程处于机器学习系统、分布式系统、编译器、GPU 架构、网络、调度和性能工程的交叉领域。随着模型规模的扩大和服务量的增长，改进模型仅仅是问题的一半。如何让每个 GPU 都发挥更大的作用，本身就成为一门独立的工程学科。

模型决定下一个令牌应该是什么。推理工程决定了服务该令牌的成本、令牌到达用户的速度以及硬件能够同时支持的用户数量。

因此，我认为在未来几年，推理工程的重要性将远远超出大多数人目前的认知。