AI推理工程指南（阅读时间约17分钟）

# AI 推理工程指南 来源：https://blog.bytebytego.com/p/a-guide-to-ai-inference-engineering [](https://go.bytebytego.com/Unleashed_061526) 没有控制的速度，是一种虚假的经济效益。随着 AI 代码生成加速软件交付，2026 年 FeatureOps 峰会应运而生，确保我们交付更多时，也能减少故障。这场顶级虚拟活动汇聚了来自 Wayfair、Visa、Mintlify、Lloyds 等公司的工程师、架构师和产品领导者，共同探讨无畏交付的基础设施。 **关键主题：** **AI 安全网：** 为海量自动化代码提供防护措施。**边缘韧性：** 大规模下的亚毫秒级评估。**持续流动：** 摆脱“固定发布”思维。立即注册，掌握打造无故障发布环境所需的工具与模式。 立即注册 (https://go.bytebytego.com/Unleashed_061526) 每次大语言模型生成回复时，同一块 GPU 上会依次执行两个操作。第一个处理输入提示并生成一个 token。第二个逐个生成之后的所有 token。 从外部看，它们像是同一过程的两个阶段。但在硬件内部，两者的瓶颈截然相反。一个受限于原始算力。另一个受限于数据在内存中的移动速度。大多数让生产级 AI 系统变快的工程工作，都源于这种拆分，而处理这一拆分的各种技术也正是推理工程的核心。 推理工程是一门在高效生产环境中运行已训练好 AI 模型的学科。工作内容涵盖底层 GPU 代码、模型服务框架以及将它们整合起来的云基础设施。该领域的工程师会针对延迟、吞吐量、成本和质量的不同组合进行优化，具体组合取决于所支持的产品。几年前，这项工作几乎完全发生在前沿 AI 实验室内部。如今，它已发展成一个广泛的专业领域，任何承担大规模 AI 工作负载的公司都会投入其中。 在本文中，我们将介绍推理的工作原理，以及该领域优化技术存在的原因。 *免责声明：本文基于多个来源公开分享的细节撰写。如发现任何不准确之处，请留言指出。* 三年前，推理工程还是一项几乎完全在前沿 AI 实验室内部实践的专业技能。相关工作由一小群工程师负责，他们构建封闭模型，而行业其他公司则通过 API 使用这些模型。自 2024 年以来，这种局面已发生巨大变化。 开放模型推动了这一变革。AI 模型公共注册中心 Hugging Face 现在托管着超过 200 万个开放模型，大约是五年前的 25 倍。像 DeepSeek V3 这样的开放发布已缩小了与封闭模型之间的能力差距，让公司有了真正的选择：是付费使用封闭 API，还是自行运行开放模型。 与封闭 API 相比，自行托管开放模型带来了三个运营优势： - 可针对特定产品的工作负载模式调整延迟配置，而公共 API 则针对众多客户的整体吞吐量进行优化。 - 专用部署可实现 99.99% 或更高的正常运行时间，优于公共 API 典型的 99% 水平。 - 一旦规模证明工程投入是值得的，大规模运营下的成本通常会下降约 80%。 结果是，现在许多不同类别的公司都在构建严肃的推理栈，包括 AI 原生初创公司、将 AI 集成到现有工作流程中的成熟产品，甚至包括传统上较为谨慎的医疗保健行业。 Cursor 是一个代表性例子。该团队在开放模型之上构建了 Composer 2.0，并运用了大量推理工程，以实现比封闭 API 更低的自动补全延迟。 要理解推理工程为何呈现现有的面貌，首先需要了解当提示到达大语言模型时实际发生了什么。整个过程分为两个阶段，对 GPU 的物理需求截然不同。 Token 是大语言模型处理的基本单元。大致来说，它是一个单词或单词片段。单词“inference”可能是一个 token，而“engineering”可能会拆分成两个。提到每秒 token 数的延迟指标，就是以这个为单位计算的。 第一阶段称为预填充。 模型接收整个输入提示，并行地通过每一层权重。这次爆发式计算会产生两个输出：回复的第一个 token 和 KV 缓存——一种存储注意力机制中间值的结构，以便在生成更多 token 时引用。 预填充是计算密集型的。GPU 的数学运算单元是限制因素，因为每个输入 token 都会同时通过模型的每一层进行处理，给这个阶段投入更多原始算力会使其更快。衡量预填充性能的指标是首 token 延迟（TTFT）。向 ChatGPT 发送提示后，到看到第一个 token 出现之前的那段短暂停顿，就是预填充在工作。 第二阶段是解码阶段。模型逐个生成后续每个 token，每个 token 都要通过模型每一层权重进行一次完整的前向传播。每个新 token 都依赖于它之前的所有 token，这使得该过程本质上是顺序的，对于长回复，GPU 需要重复数千次这个过程。 解码是内存带宽密集型的。数学吞吐量基本闲置，而 GPU 花费大量周期为每次前向传播从内存读取模型权重——瓶颈在于数据移动而非算术运算。衡量解码性能的指标是每秒 token 数（TPS）。长回复的流式生成速度，就是解码阶段的实际表现。 [](https://substackcdn.com/image/fetch/$s_!_p6C!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8b8d857b-1ce9-4f39-93b5-67fcb663b2d4_1970x1246.png) 由于预填充和解码的瓶颈相反，加速一个阶段的技术通常对另一个阶段影响甚微。这就是为什么基准测试会将 TTFT 和 TPS 作为两个独立数字报告，对每个阶段的性能单独衡量。 这种拆分也是理解推理工程其余部分的结构性洞见。一旦理解了预填充和解码是两个不同的操作，该领域的技术就自然分成三组：加速预填充的技术、加速解码的技术，以及在两者之间重新平衡的技术。 上图稍作简化。实际的推理引擎还会在此之上运行批处理、调度等复杂操作，而预填充-解码的拆分贯穿于所有这些操作之下，这也是它成为本文其余部分基础的原因。 有了预填充-解码拆分这一背景，推理工程中的主要技术就更容易组织了。每一种技术要么加速特定阶段，要么因不同原因同时作用于两者，要么围绕拆分本身重构系统。 下面我们逐一详细介绍这六项技术。 批处理是扩展单块 GPU 输出能力最基本的方法。推理引擎将多个请求逐一 token 交织在一起，这样一块 GPU 就能同时服务许多用户。吞吐量显著提升，因为 GPU 的算力得到了充分利用，而不是在请求间空闲等待。 代价是每个用户的延迟会增加。 在非批处理系统中，单个用户能获得最低的响应时间；而在高批处理系统中，同一用户需要等待更长时间，因为 GPU 同时还在服务其他请求。这种权衡是其他所有技术围绕的主要矛盾，不同产品在光谱上处于不同位置——消费级聊天工具倾向于更低延迟，而批处理管道倾向于更高吞吐量。 [](https://substackcdn.com/image/fetch/$s_!2TLa!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1a9cf704-cfea-4b7f-8b4c-6c3554ea184a_1856x1096.png) 前缀缓存通过跨请求复用 KV 缓存值来加速预填充。当两个提示共享一个开头部分时（例如成千上万个请求共用的长系统提示），引擎只计算一次此前缀，之后都从缓存读取。这就是为什么 API 提供商对缓存输入 token 收费较低。 但需要注意的是，缓存只从序列开始到第一个不匹配的 token 起作用。如果两个提示的第一个 token 就不同，即使后续序列完全相同，前缀缓存也不会有任何节省。因此，提示结构直接成本和延迟影响；将可变的用户输入放在提示末尾，而共享内容放在开头，能让缓存发挥更大作用。 [](https://substackcdn.com/image/fetch/$s_!SnEz!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb87de856-3775-4ada-b41b-4c99125f3a7e_2220x1096.png) 量化对推理的两个阶段都有帮助，但原因不同。 基本做法是以更低精度的数字格式存储模型权重。大多数现代模型使用 16 位浮点数训练，量化将这些值压缩到 8 位或 4 位表示，这意味着更小的权重占用更少内存，所需的数据移动也更少。 预填充加速，是因为低精度数学运算在现代 GPU 的专用数学单元上运行更快。解码加速，是因为内存带宽压力减小，每次前向传播从内存加载权重的速度更快。通常精度每降低一级，性能提升约 30% 到 50%，具体收益取决于模型和应用的技术。 代价是可能的质量下降，模型的不同部分对量化的容忍度不同。 线性权重处理得很好，激活则稍敏感一些，KV 缓存更敏感，而注意力层最为敏感。原因是注意力层中的小精度误差会随着 token 序列累积——每个 token 的计算都基于前一个——因此即使是小误差，也会在长回复中滚雪球般发展成有意义的质量损失。 因此，大多数生产环境会让注意力层保持全精度。量化的大部分工程工作都在于确定哪些部分可以压缩以及压缩的激进程度。 [](https://substackcdn.com/image/fetch/$s_!Mo_d!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ffbba455a-53ba-455f-9086-0f0d9e13346a_1970x1196.png) 推测解码通过利用一种不对称性来加速解码过程。从头生成一个 token 代价高昂，而验证一个候选 token 是否与主模型生成的 token 匹配则便宜得多。数独的类比在这里很适用：解谜题需要费力，而检查一个已经完成的谜题则很快。 在推测解码中，一个小型的草稿模型预测接下来的几个 token，主模型在一次前向传播中验证所有这些 token，接受与自己预测匹配的，拒绝不匹配的。结果是，通过主模型的一次前向传播，可以产出多个 token（原本只有一个）。 推测解码能提高 TPS，但 TTFT 保持不变，因为预填充仍正常进行。该技术在小批量大小时效果最佳，因为此时 GPU 有闲置算力用于验证。在批量较大、同时服务许多请求时，GPU 已经饱和，推测会被动态禁用，因为每个周期都需要用于主要工作负载。 [](https://substackcdn.com/image/fetch/$s_!FKnr!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7a4980d-059e-4337-a525-e3800ffe57cd_1540x1228.png) 并行化技术让大型模型能够在单块 GPU 力不从心时跨多块 GPU 运行，原因可能是模型太大无法装入内存，也可能单 GPU 延迟过高。在开放模型领域，两种主要方法占据主导：张量并行和专家并行。 张量并行将模型的每一层拆分到多块 GPU 上。每块 GPU 持有每一层的一个片段，GPU 们共同分担每次前向传播的工作。这要求 GPU 之间拥有高带宽互连（如 NVIDIA 的 NVLink），因为每层之后需要合并结果。张量并行是服务非常大型稠密模型的默认选择，尽管通信对带宽要求很高，但通过分担每层工作获得的加速可以弥补。 专家并行专门适用于混合专家模型，其中每个 token 只会激活模型参数的一个子集。不同的专家分布到不同的 GPU 上，token 会被路由到需要的专家那里。通信开销低于张量并行，因为专家独立运作，这使得专家并行非常适合带宽有限的跨节点部署。大多数生产部署会结合使用两者：节点内使用张量并行，节点间使用专家并行。 [](https://substackcdn.com/image/fetch/$s_!gjho!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6f1d8e3a-4d25-4c1a-b925-7d022891fa30_1970x1436.png) 解耦（Disaggregation）字面意义上采用了预填充-解码拆分。其理念是让一组 GPU 运行预填充，另一组 GPU 运行解码，KV 缓存通过网络在两者之间传输。每组使用针对其特定瓶颈调整的硬件，并根据自身流量模式独立扩展。 流程变为三步： - 预填充引擎接收输入序列，生成第一个 token 和 KV 缓存。 - 缓存通过快速互连发送到解码引擎，解码引擎处理后续所有 token。 - 在条件解耦中，短请求或已缓存请求会跳过交接，仅在解码引擎上运行，这更符合包含长短提示混合的真实世界流量表现。 解耦是本文所涉技术中最为架构性的。它将预填充和解码视为两个独立的服务，具有各自不同的运营关注点，让操作者拥有独立的杠杆来扩展每一个。运行大规模推理的公司通常认为，一旦工作负载模式清晰，这一步几乎是必不可少的。 [](https://substackcdn.com/image/fetch/$s_!Qsld!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5cda55a4-3e8b-4095-9b61-7382ba00c1c3_2220x1164.png) 将这些技术投入生产是一项严肃的任务，而组合它们会进一步增加复杂性。每个工程团队都必须回答一个问题：是否要承担这项工作，还是现成的 API 仍然是正确选择？答案取决于产品的阶段。 在构建 AI 产品的早期阶段，来自成熟提供商的现成 API 几乎总是正确的选择。有意义的优化需要面对真实的约束，而早期产品在流量模式、延迟要求和单位经济性方面往往假设模糊。这个阶段的工程精力最好花在交付产品上，因为运行自定义推理栈的复杂性会拖慢迭代速度——而迭代速度才是真正重要的。 通常有三个信号表明情况已经改变