A Guide to AI Inference Engineering

TL;DR · AI 摘要
推理工程已成为AI生产环境优化的核心领域,涉及GPU代码、模型服务框架和云基础设施。
核心要点
- 推理工程优化目标包括延迟、吞吐量、成本和质量。
- 自托管开放模型可针对特定产品的工作负载模式调整延迟。
- 2024年后,开源模型数量增长25倍,推动推理工程成为主流实践。
结构提纲
按章节快速跳转。
- §引言
介绍推理工程在AI生产环境中的重要性。
开源模型的普及推动了推理工程从前沿AI实验室向主流实践的转变。
自托管开放模型在延迟、可用性和成本控制方面具有显著优势。
GPU计算和内存带宽限制是推理工程优化的关键瓶颈。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 推理工程
- 核心挑战
- GPU计算瓶颈
- 内存带宽限制
- 优势
- 延迟优化
- 可用性提升
- 成本控制
金句 / Highlights
值得收藏与分享的关键句。
自托管开放模型可针对特定产品的工作负载模式调整延迟。
开源模型数量在五年内增长25倍,推动推理工程成为主流实践。
推理工程优化目标包括延迟、吞吐量、成本和质量。
AI 推理工程指南 - ByteByteGo 电子报
AI 推理工程指南
ByteByteGo
2026年6月15日
FeatureOps Summit 2026 - AI 时代的功能管理(赞助)
没有控制的速度是一种虚假的经济。随着AI代码生成加速软件交付,2026年的FeatureOps Summit应运而生,确保我们在交付更多内容的同时,减少出错的几率。这场顶级的虚拟活动汇聚了来自Wayfair、Visa、Mintlify、Lloyds等公司的工程师、架构师和产品领导者,共同探索无畏交付的基础设施。
主要主题:
AI 安全网:为自动化代码的洪流设置防护措施。边缘韧性:在大规模下实现亚毫秒级评估。持续流动:超越“固定发布”的思维模式。今天注册,掌握构建安全无误发布环境所需工具和模式。
立即注册
每次大型语言模型(LLM)生成响应时,两个操作会按顺序在同一个GPU上运行。第一个处理输入提示并生成一个标记。第二个则依次生成之后的每一个标记。
从外部看,它们像是一个过程的不同阶段。然而在硬件内部,它们的瓶颈却截然相反。一个受限于原始计算能力,另一个受限于数据在内存中移动的速度。大多数让生产AI系统变得快速的工程工作都源于这种分裂,而用于处理这种分裂的技术正是推理工程的核心所在。
推理工程是一门在生产环境中高效运行训练好的AI模型的学科。这项工作涵盖了低级GPU代码、模型服务框架以及将它们连接在一起的云基础设施。该领域的工程师优化的目标是延迟、吞吐量、成本和质量的某种组合,具体组合取决于他们支持的产品。几年前,这项工作几乎完全发生在前沿AI实验室内部。如今,它已成为任何进行严肃AI工作负载的公司都会投入的广泛专业领域。
在本文中,我们将逐步介绍推理是如何工作的,以及该领域的优化技术为何存在。
免责声明:本文基于来自多个来源的公开信息。如果您发现任何不准确之处,请在评论中指出。
推理工程的兴起
三年前,推理工程几乎完全是在前沿AI实验室内部进行的专门领域。这项工作涉及一小群工程师,他们构建封闭模型,其余行业则通过API消费这些模型。自2024年以来,这一图景发生了巨大变化。
开源模型推动了这一变化。目前,作为AI模型公共注册库的Hugging Face现在托管了超过两百万个开源模型,大约是五年前的25倍。像DeepSeek V3这样的开源发布已经弥合了与封闭模型在能力上的差距,使公司能够在支付封闭API费用和自行运行开源模型之间做出真正的选择。
与封闭API相比,自托管开源模型带来了三个运营优势:
- 延迟配置可以针对特定产品的负载模式进行调整,而公共API则优化了跨多个客户的总体吞吐量。
- 通过专用部署,正常运行时间可以达到四个九或更高,与公共API通常的两个九相比具有明显优势。
- 一旦工程投资得到体积的合理证明,成本通常会下降约80%。
结果是,许多不同领域的公司现在都在构建严肃的推理堆栈,包括原生人工智能初创公司、将人工智能整合到现有工作流程中的成熟产品,甚至是一直以来持谨慎态度的行业,如医疗保健。
Cursor 提供了一个具有代表性的例子。该团队基于一个开源模型构建了 Composer 2.0,通过大量的推理工程应用,实现了比封闭式 API 更低的自动补全延迟。
大语言模型推理的两个阶段
理解为什么推理工程看起来是这个样子,首先要理解当提示到达大语言模型时实际上发生了什么。这个过程分为两个阶段,对 GPU 的物理需求截然不同。
一个 token 是大语言模型处理的基本单位。大致来说,它是一个词或词的一部分。“inference”可能是一个 token,而“engineering”可能会被拆分为两个 token。提到每秒 token 数的延迟指标就是以这个单位来计算的。
第一个阶段称为预填充(prefill)。
模型会将整个输入提示同时通过模型中每一层权重进行处理。这个突发处理会输出两个结果,即响应的第一个 token 和 KV 缓存,KV 缓存是一种存储注意力机制中间值的结构,以便在生成更多 token 时可以引用这些值。
预填充是计算密集型的。GPU 的数学单元是限制因素,因为每个输入 token 都会同时通过模型的每一层进行处理,增加原始计算能力可以加快这个阶段。衡量预填充性能的指标是第一个 token 的时间(Time to First Token,TTFT)。在向 ChatGPT 发送提示和看到第一个 token 出现之间的那个短暂暂停,就是预填充在起作用。
第二个阶段是解码阶段(decode phase)。
模型逐个生成后续的每个 token,对每个 token 都需要通过模型中每一层权重进行一次完整的前向传递。每个新生成的 token 都依赖于之前的所有 token,这使得该过程本质上是顺序的,GPU 会为长响应执行数千次这样的操作。
解码阶段是内存带宽受限的。在 GPU 为每次前向传递从内存中读取模型权重时,数学吞吐量大部分处于空闲状态,瓶颈存在于数据移动而非算术运算上。衡量解码性能的指标是每秒 token 数(Tokens Per Second,TPS)。长响应的流式速度就是解码阶段在起作用。
由于预填充和解码阶段的瓶颈相反,加速其中一个阶段的技术通常对另一个阶段影响很小。这就是为什么基准测试会将 TTFT 和 TPS 报告为两个独立的数字,每个阶段的性能都是独立测量的。
这种划分也是推理工程其余部分的结构性洞察。一旦将预填充和解码视为两个不同的操作,该领域的技术就会被分为三类:加速预填充的技术、加速解码的技术,以及在两者之间重新平衡的技术。
上面的图示有些简化。实际的推理引擎会运行批处理、调度和其他复杂性,这些复杂性叠加在上面,而预填充和解码的划分在所有这些复杂性之下依然成立,这也是为什么它成为本文其余部分的基础。
优化技术
考虑到预填充-解码的拆分,推理工程中的主要技术变得更容易组织。每种技术都加速特定阶段,出于不同原因对两个阶段进行优化,或者围绕拆分本身重构系统。
让我们详细地介绍这六种技术。
批处理
批处理是扩展单个 GPU 输出的最基本方式。推理引擎将多个请求逐个 token 地交织在一起,这样单个 GPU 可以同时为许多用户提供服务。吞吐量显著提高,因为 GPU 的计算能力得到了充分利用,而不是在请求之间处于空闲状态。
代价体现在每个用户的延迟上。
在一个未进行批处理的系统中,单个用户可以获得最低的响应时间,而在一个高度批处理的系统中,同一个用户需要等待更长时间,因为 GPU 同时还在处理其他请求。这种权衡是其他所有技术所围绕的主要张力,不同的产品在这一光谱上处于不同的位置,消费级聊天工具倾向于较低的延迟,而批处理流水线则倾向于较高的吞吐量。
前缀缓存
前缀缓存通过在请求之间重用 KV 缓存值来加速预填充。当两个提示共享一个开头段,比如一个在数千个请求中都相同的长系统提示时,引擎只需计算一次该前缀,之后就可以从缓存中读取。这就是为什么 API 提供商对缓存的输入 token 收取较少费用。
需要注意的是,缓存的帮助从序列的开始一直持续到第一个不匹配的 token。如果两个提示的第一个 token 就不同,即使其余部分完全相同,前缀缓存也无法带来任何节省。因此,提示结构直接影响成本和延迟,将可变的用户输入放在提示的较后部分,而将共享内容放在前面,可以为缓存提供可操作的内容。
量化
量化对推理的两个阶段都有帮助,尽管原因不同。
基本做法是将模型权重存储在更低精度的数字格式中。大多数现代模型使用 16 位浮点数进行训练,量化将这些值压缩为 8 位或 4 位表示,这意味着权重更小,占用更少的内存,并且需要更少的数据移动。
预填充速度加快,因为现代 GPU 中的专用数学单元可以更快地执行低精度的数学运算。解码速度加快,因为内存带宽压力减少,每次前向传播时权重从内存中加载得更快。通常,精度的降低可以带来大约 30 到 50% 的性能提升,具体提升幅度取决于模型和所应用的技术。
代价是潜在的质量下降,模型的不同部分对量化容忍度也不同。
线性权重处理得较好,激活值则稍微敏感一些,KV 缓存更加敏感,而注意力层是最敏感的。原因在于,注意力层中的小精度误差会在 token 序列中累积,每个 token 的计算都建立在前一个的基础上,因此即使小的误差也会在长时间响应中累积成显著的质量损失。
出于这个原因,大多数生产环境将注意力层保持在完整精度。量化中的大部分工程工作都集中在确定哪些部分可以压缩以及压缩的强度。
推测性解码通过利用一种不对称性来加速解码过程。从头生成一个标记代价高昂,而验证一个候选标记是否与主模型生成的标记匹配则要便宜得多。数独的类比在这里适用,解决谜题需要付出努力,而检查一个完成的谜题则非常迅速。
在推测性解码中,一个较小的草稿模型预测接下来的几个标记,而主模型在一个前向传递中验证所有这些标记,接受与自身预测匹配的标记,拒绝其余的。结果是,每次通过主模型的前向传递可以生成多个标记,而通常只生成一个。
推测性解码在不改变首次令牌延迟(TTFT)的情况下提高了每秒请求数(TPS),因为预填充仍然正常运行。该技术在较小的批量大小下表现最佳,此时GPU有额外的计算能力可用于验证。在较大的批量大小下,当同时处理大量请求时,GPU已经饱和,推测性解码会动态禁用,因为每个周期都用于主任务。
并行性
并行性技术允许在单个GPU不足以处理时,让大型模型跨多个GPU运行,这可能是因为模型太大无法放入内存,或者单个GPU的延迟太高。在开源模型领域,两种主要方法占据主导地位:张量并行和专家并行。
张量并行将模型的每一层拆分到多个GPU上。每个GPU持有每一层的一个片段,GPU在每次前向传递中分担工作。这需要GPU之间有高带宽互连,如NVIDIA的NVLink,因为每层之后需要合并结果。张量并行是为非常大的密集模型服务的默认选择,因为高带宽通信的开销被每层工作共享带来的加速所抵消。
专家并行专门适用于专家混合模型,其中每个标记只激活模型参数的一个子集。不同的专家分布在不同的GPU上,标记被路由到它们所需的专家。与张量并行相比,专家并行的通信开销较低,因为专家独立运行,这使得专家并行非常适合带宽受限的多节点部署。大多数生产部署结合使用这两种方法,在节点内使用张量并行,在节点间使用专家并行。
分离
分离字面意义上地执行了预填充和解码的分离。其理念是在一组GPU上运行预填充,在另一组GPU上运行解码,通过网络在它们之间传输KV缓存。每组使用针对其特定瓶颈优化的硬件,并根据各自的流量模式独立扩展。
流程变为一个三步过程:
- 预填充引擎接收输入序列,并生成第一个标记和KV缓存。
- 缓存通过高速互连发送到解码引擎,解码引擎处理所有后续的标记。
- 在条件分离中,短或已缓存的请求完全跳过交接过程,仅在解码引擎上运行,这在包含长提示和短提示混合的真实世界流量中表现更好。
解耦是这里所涵盖技术中最具架构性的一种。它将预填充和解码视为具有各自运营关注点的独立服务,使操作者能够独立地对两者进行扩展。在运行大规模推理的公司中,一旦对其工作负载组合有了充分的理解,通常会将这一步视为几乎是必经的。
何时投资于推理工程
将这些技术投入生产是一项严肃的任务,而将它们结合起来会进一步增加复杂性。每个工程团队必须回答的问题是:是否要承担这项工作,还是继续选择现成的 API。答案取决于产品的阶段。
在构建 AI 产品初期,几乎总是选择来自成熟供应商的现成 API。有意义的优化需要真实的约束条件作为基础,而早期阶段的产品往往对流量模式、延迟要求和单位经济效益有模糊的假设。在这一阶段,工程努力最好用于交付产品,因为运行自定义推理堆栈的复杂性会减慢迭代速度,而迭代速度是真正重要的因素。
通常有三个信号表明情况已经发生了变化:
- API 成本已经增长为一项重要的支出。
- 延迟要求已经超过了封闭式 API 能够提供的水平。
- 可靠性需求开始超过供应商 SLA 提供的范围。
Cursor 在应对这一转变方面做得很好。亚秒级的自动补全延迟本身就是产品本身,而封闭式 API 的目标是为众多客户提供通用的吞吐量,而代码补全模型则需要特定形式的速度。通过自托管一个开源模型,并在整个堆栈中应用推理工程,使得延迟目标变得可实现,而这项投资也得到了回报,因为约束是真实的,且工作负载已经得到了充分的理解。
结论
大语言模型的推理包含两个具有相反物理约束的操作。
预填充是计算密集型的,每个请求只运行一次。解码是内存带宽密集型的,每个 token 只运行一次。推理工程中的大多数技术都源于这种分裂,理解这一点会使整个领域更容易掌握。
上述每种技术都适用于预填充-解码框架:
- 批处理以每个用户的延迟换取总吞吐量。
- 前缀缓存通过共享开头部分的提示来减少预填充工作。
- 量化通过压缩模型权重来帮助两个阶段。
- 推测解码通过利用空闲计算来从解码中提取更多 token。
- 并行性将模型扩展到多个 GPU 上。
- 解耦将预填充和解码完全运行在不同的硬件上。
在所有这些之上,还有一个构建与购买的问题。对于大多数产品在早期阶段,现成的 API 仍然是正确的选择,而当 API 成本增长为真正的支出线、延迟要求超出封闭式 API 能够提供的范围,或者可靠性需求超过供应商 SLA 时,自托管开始变得有意义。
参考资料:
- Hugging Face Hub 文档
- DeepSeek-V3 技术报告
- Cursor — Composer: 使用强化学习构建快速前沿模型
- Cursor — 介绍 Composer 2
- DistServe: 为吞吐量优化的大语言模型服务解耦预填充和解码
- 使用 PagedAttention 进行大语言模型服务的高效内存管理
- Anthropic — 提示缓存文档
- NVIDIA TensorRT 文档
- 通过推测解码实现 Transformer 的快速推理
- Megatron-LM:使用模型并行训练数十亿参数的语言模型
- NVIDIA Megatron-Core 开发者指南 —— 张量并行
- 非常大的神经网络:稀疏门控的专家混合层
- NVIDIA NVLink 和 NVLink 交换机
- Anthropic Claude API 文档