LLM 推理如何运作：大型语言模型的服务与优化实用指南

大型语言模型（LLM）的推理正在成为一门独立的技术艺术。

各家公司正越来越多地寻找能更快服务模型、使用更少硬件、并降低推理成本的 LLM 推理与 MLOps 工程师。

无论您是在本地运行模型、部署推理服务器，还是在尝试开源 LLM，理解推理的工作原理都能带来巨大差异。

高效的 LLM 推理背后是一整套技术栈，包括量化、KV 缓存优化、连续批处理、优化的注意力内核、投机解码以及面向硬件的调优等。

许多现代推理框架会自动启用其中部分技术，这意味着即使您未完全理解底层机制，也可能已经在受益。

在本指南中，我将探讨 LLM 推理的基础、最重要的性能指标、常见的服务框架，以及让模型更快、更省内存、运行成本更低的实用技术。

什么是 LLM 推理？

我们从基础开始：什么是推理、推理如何工作、如何衡量性能，以及为何模型架构很重要。

每当您向语言模型发送提示并等待响应时，发生的就是 LLM 推理。模型会将输入逐层处理，然后逐个 token 生成输出。

这与训练不同。训练阶段，模型从数据中学习并更新权重。推理阶段，这些权重保持不变，已训练的模型仅用于生成预测。

在生产中，绝大多数 LLM 的计算成本发生在推理阶段。

一个模型可能只训练一次，却要处理数百万次请求。这使推理效率成为当前应用型 AI 中最重要的工程问题之一。

理解推理的技术细节很重要，因为瓶颈并不直观。

更快的硬件并不总是意味着更快的响应。更大的模型也不一定更慢。模型架构、输入长度、批大小以及服务基础设施之间会相互影响，因此在开始优化之前值得先理解这些因素。

LLM 推理如何工作？

对于大多数基于解码器的 LLM，推理包含两个主要阶段：预填充（prefill）和解码（decode）。

• 在预填充阶段，模型处理输入提示中的所有 token，并创建初始的键-值（KV）缓存。由于许多输入 token 可并行处理，此阶段通常计算密集。
• 当模型开始产生输出时，解码阶段开始。LLM 通常是自回归的，意味着每个新 token 依赖之前生成的 token。模型会反复执行前向传播来生成下一个 token。

在较小批量时，解码往往更受内存带宽限制，而非原始 GPU 计算力，因为需要不断从内存中读取模型权重和缓存的注意力状态。

这一区别很重要，因为提升预填充性能的优化，不一定会提升解码性能。

我们如何衡量 LLM 推理？

没有单一指标能告诉我们推理服务器是否快速、高效或具性价比。这些指标有助于定位瓶颈、比较服务方案，并判断某项优化是否真正提升了性能。

一些最重要的指标包括：

• 首个 Token 时间（TTFT）： 首个 token 出现前所需的时间。
• Token 间延迟（ITL）： 已生成 token 之间的间隔延迟。
• 单 Token 输出时间（TPOT）： 生成每个输出 token 所需的平均时间。
• 每秒 Token 数： token 处理或生成的速度。
• 吞吐量： 在一段时间内处理的 token 或请求总数。
• 并发度： 服务器可高效同时处理的请求数量。
• P50/P95/P99 延迟： 展示典型性能及较慢的边缘情况。
• 有效吞吐（Goodput）： 在满足延迟目标的前提下，真正有用的吞吐量。
• GPU 利用率： 可用硬件的使用效率。
• 缓存命中率： 输入 token 或前缀可复用先前计算的 KV 缓存而无需重新处理的比例。
• 输入成本： 处理提示与上下文 token 的成本。
• 输出成本： 生成新 token 的成本，通常更为耗算力。
• 每请求/每 token 成本： 服务该工作负载的总体成本。

缓存命中率在生产环境中特别重要。智能体系统常常会复用大型系统提示、工具定义、对话前缀或文档。

如果 95% 或更多的输入可由缓存提供服务，就能大幅减少重复的预填充计算，改善延迟并降低这些请求的有效服务成本。

这些指标彼此紧密相关。

更大的批量与更高的并发可提升吞吐与 GPU 利用率，但可能会增加单个用户的延迟。

同样地，降低数值精度可以减少内存使用和硬件需求，但如果硬件缺乏针对该格式的优化内核，未必能提升生成速度。

因此目标不是最大化某个单一指标，而是为您的工作负载在延迟、吞吐、利用率与成本之间找到合适平衡。

模型架构如何影响推理

推理性能在很大程度上受模型自身架构影响。

一个致密 Transformer基本上会在每个 token 上使用其全部参数。相比之下，专家混合（MoE）模型包含许多专家，但对每个 token 仅激活其中一小部分。

这可以降低每个 token 的计算量，但也带来专家路由、负载均衡、GPU 通信与专家放置等挑战。

此外，注意力架构也会显著影响内存使用与推理速度。

传统的多头注意力（MHA）为每个注意力头分别存储键和值表示，这会使 KV 缓存变大。

多查询注意力（MQA）通过让多个查询头共享同一组键和值，降低了内存需求。

分组查询注意力（GQA）介于两者之间，让一组查询头共享键值表示。更新的架构还可能使用诸如多头潜在注意力（MLA）等技术，进一步压缩这些表示。

这也是为何两种参数规模相近的模型在推理时可能表现截然不同。

它们的架构会显著影响计算需求、KV 缓存大小、内存使用与生成速度。

LLM 服务框架

接下来，我们将了解从本地部署到大规模生产系统中运行 LLM 的主流框架。

vLLM

vLLM 是应用最广泛的通用推理引擎之一。它支持连续批处理、PagedAttention、分块预填充、前缀缓存、量化、投机解码、优化的注意力内核以及分布式推理。

SGLang

SGLang 专注于高性能生成与高效请求调度。它对智能体、推理模型、重复上下文、结构化输出以及其他复杂生成工作负载特别有用。

TensorRT-LLM

TensorRT-LLM 是 NVIDIA 的优化推理栈。它充分利用 NVIDIA GPU 特性、专用 CUDA 内核、低精度格式、分布式执行、KV 缓存与高级批处理。

llama.cpp

llama.cpp 对本地与资源受限的推理尤其有用。它支持 GGUF 量化、CPU-GPU 混合推理与内存映射模型文件，使得权重可以分布在 GPU 显存、系统内存，必要时甚至是磁盘映射内存中。

这使得在可用显存远小于模型大小的情况下也能运行更大的模型，但对磁盘的重度依赖会显著降低性能。

MLX

MLX 是为 Apple Silicon 设计的推理与机器学习框架。它充分利用 Mac 的统一内存架构，是在 M 系列设备上本地运行与试验 LLM 的实用选择。

核心 LLM 推理优化

从量化到投机解码，本部分涵盖让推理更快、更省钱、更省内存的技术。

量化

最常见的推理优化之一是量化。

模型通常使用 BF16 或 FP16 精度进行训练。

量化使用更小的数值格式表示权重、激活或缓存。

常见格式与方法包括：

• FP8
• FP4
• INT8
• INT4
• AWQ
• GPTQ
• GGUF 量化

降低精度会减少内存占用，并可降低内存带宽需求。

然而，更小并不代表自动更快。性能高度取决于目标硬件是否为该精度提供高效内核。

此外，KV 缓存也可以量化，对于长上下文与高并发服务，这一点愈发重要。

注意力与内核优化

注意力是 Transformer 中最重要的运算之一。它让模型在生成下一个 token 时判断上下文中哪些 token 最相关。

然而，随着上下文窗口增大，注意力会变得计算开销高昂。

这时，优化的内核就很重要了。内核是针对 GPU 等硬件执行特定数学运算的高度优化代码。优化内核不改变模型工作方式，而是让相同计算运行更快、内存使用更高效。

一个很好的例子是FlashAttention。传统注意力会在 GPU 内存与计算单元之间搬运大量中间结果，耗时严重。

FlashAttention 通过以更小块处理注意力并将更多计算留在 GPU 侧，降低了这部分开销。

现代推理引擎会采用多种类似优化，包括：

• FlashAttention
• FlashInfer
• FlashMLA
• Triton 内核
• 融合算子
• 优化的 GEMM 内核
• CUDA 图
• 专用 MoE 内核

关键在于这些技术通常不改变模型或其输出质量。它们优化的是计算的执行方式，帮助推理引擎更快生成 token，并更高效地利用可用硬件。

KV 缓存优化

在生成过程中，Transformer 会将先前 token 的键和值存储在KV 缓存中。

没有该缓存，模型在每次生成新 token 时都需要重新计算先前的 token。

代价是内存消耗。长上下文与大量并发用户会让 KV 缓存占据大量 GPU 内存。

多种技术可缓解此问题。

PagedAttention 将 KV 缓存内存划分为可管理的小块，而不是要求大型连续分配。

前缀缓存允许具有相同前缀的请求复用先前计算的 KV 状态。对于共享系统提示、智能体和重复的文档上下文尤其有用。

其他方法包括：

• KV 缓存量化
• 缓存淘汰
• 缓存压缩
• KV 缓存卸载
• 跨请求缓存共享

对于大规模推理系统，KV 缓存管理的重要性不亚于模型权重优化。

连续批处理与请求调度

当推理服务器同时接收大量请求时，会尝试将它们放在一起处理，以保持 GPU 繁忙。这称为批处理。

问题在于 LLM 请求很少同时结束。

一个用户可能生成 50 个 token，而另一个则生成 2000 个。

在传统批处理中，较短的请求可能不得不等待批中最长的请求完成。

连续批处理通过移除已完成的请求并立即替换为新的请求来解决这一问题。这样可使 GPU 持续工作，而非让算力空置。

另一项实用技术是分块预填充。服务器不再一次性处理一个超大的提示，而是将其拆分为更小的块，从而不会阻塞其他正在生成 token 的请求。

随着流量增长，推理成为一个调度问题。服务器需要决定处理哪些请求、如何分组，以及如何在 GPU 内存、序列长度、吞吐与延迟之间做权衡。

投机解码

传统自回归解码一次生成一个 token，这使得生成本质上是串行的。

投机解码尝试通过便宜地生成若干候选 token，然后让完整的目标模型并行验证它们，来打破这一瓶颈。

如果多个候选被接受，生成就可以一次前进多个 token，而不改变目标模型的输出分布。

有多种方法遵循这一思路：

• 草稿模型投机： 使用更小更快的模型提出 token 供更大模型验证。
• Medusa： 为目标模型增添轻量的预测头，用于提出多个未来 token。
• EAGLE-3： 使用基于目标模型多层特征的轻量草稿器生成更高质量的草稿 token。
• MTP（多 token 预测）： 使用内置于兼容模型的预测头来预测多个未来 token。
• DFlash 与 DFlash2： 迈向并行起草，在单次前向传播中生成整块候选 token，而不是按序逐个起草。
• DSpark： 在并行起草基础上建模草稿 token 之间的依赖，估计候选块中哪些部分更可能被接受。

基本思路很简单：

用低成本生成若干可能的未来 token，再由更大模型高效验证。

当下一个 token 相对可预测、接受率较高时，投机解码效果最佳。

这使其对编码等顺序性任务特别有用，较小的模型也常能预测接下来会出现什么。

对于复杂推理或高度不可预测的生成，被接受的草稿 token 可能更少，从而降低性能收益。

内存与扩展

随着模型与工作负载增长，内存会成为主要限制。在这里，我们将探讨卸载、多 GPU 推理、解耦式服务与长上下文优化。

卸载与内存层级

有时目标不是极致速度，而是让模型在现有硬件上跑起来。

推理系统可以使用不同层级的内存：

GPU HBM → CPU RAM → NVMe 存储

GPU 内存最快，但容量最有限。

CPU 内存容量更大但速度更低，而 NVMe 存储提供更大的空间但要慢得多。

如果模型或其 KV 缓存无法完全装入显存，推理引擎可以通过以下技术将部分工作负载移动到其他位置：

• 权重卸载
• CPU-GPU 混合推理
• KV 缓存卸载
• CPU 内存
• NVMe 或 SSD 存储

这会增加可用内存总量，但通常会带来性能损失，因为数据需要在更慢的内存层级之间移动，且常经过 PCIe。

基本权衡很简单：数据离 GPU 内存越远，容量增长越多，但推理通常越慢。

多 GPU 与分布式推理

非常大的模型通常需要多个加速器。

常见策略包括：

1. 张量并行： 将单个模型计算拆分到多个 GPU 上，共同处理同一层。
2. 流水线并行： 将模型层划分到不同 GPU，每个 GPU 处理模型的不同部分。
3. 数据并行： 在多个 GPU 上运行模型副本，以同时处理更多请求。
4. 专家并行： 将 MoE 模型的专家分布到不同 GPU 上。
5. 上下文并行： 将长输入序列拆分到多个 GPU，以减少每台设备的内存与计算压力。

一旦推理跨越多个 GPU，通信就会成为重要瓶颈。

因此 NVLink、NVSwitch 与高速网络等技术会对性能产生显著影响。

预填充与解码的解耦

预填充与解码在推理期间表现截然不同。预填充通常计算密集，因为会并行处理大量提示 token；而解码往往受内存带宽限制，需要逐个生成 token。

与其让两个阶段争夺相同 GPU，大型服务系统可以将它们分离：

Prompt → 预填充工作器 → KV 缓存传输 → 解码工作器 → 响应

预填充工作器处理提示并构建KV 缓存，随后将其传递给专门的解码工作器以生成响应。这样每个阶段可以采用不同的硬件、批处理与并行策略。

主要优势在于可以分别优化与扩展预填充和解码，有助于控制首个 token 时间（TTFT）与 token 间延迟（ITL），尤其适用于长提示与高流量负载。

长上下文推理

长上下文窗口带来一组不同的推理挑战。随着输入增长，预填充计算量增大，而KV 缓存变得更大，占用 GPU 内存并让解码更昂贵。

多种技术可以提供帮助：

• 前缀缓存： 当请求共享相同提示或上下文时复用 KV 缓存，避免重复预填充计算。
• KV 缓存量化与压缩： 降低存储先前 token 所需的内存。
• 滑动窗口或稀疏注意力： 在模型架构支持的情况下限制模型的上下文关注范围。
• 上下文并行： 将长序列或其 KV 缓存拆分到多个 GPU，帮助长上下文的预填充与解码。
• KV 缓存传输与卸载： 当 GPU 内存受限时，在 GPU、CPU 内存或存储之间移动缓存状态。

重要的是，支持一百万 token 的上下文窗口并不意味着服务一百万 token 就快速、廉价或切实可行。

更长的上下文会增加内存使用、首个 token 时间与整体推理成本。

特定推理工作负载

并非所有模型在推理时的表现都相同，因此我们将考察 MoE 模型、结构化生成与推理工作负载的独特挑战。

专家混合（MoE）推理

专家混合（MoE）模型的行为不同于致密模型。它并非对每个 token 使用所有参数，而是由路由器仅选择少量专家来处理每个 token。

这减少了计算量，但全部专家仍需要存放在服务硬件的某处。

因此，高效的 MoE 推理取决于：

• 专家路由： 选择哪些专家处理每个 token。
• 专家放置： 决定专家在各 GPU 上的存放位置。
• 专家并行： 将不同专家分布到多个 GPU。
• 负载均衡： 防止热门专家压垮特定 GPU。
• 全互连通信： 高效地将 token 发送至所选专家并返回结果。
• 优化的 MoE 内核： 加速专家计算与通信。

在规模化场景中，通信可能成为主要瓶颈，因此诸如DeepEP等技术提供了在专家间移动 token 的高吞吐、低延迟专用内核。

关键区别在于，总参数决定了需要存储多少模型容量，而活跃参数更能反映每个 token 实际执行了多少计算。

结构化与受限解码

现代 LLM 应用常常需要比无约束文本更可预测的输出。例如，智能体可能需要生成符合预定义模式的JSON、工具参数、SQL，或遵循既定架构的响应。

受限解码会在每一步限制模型允许生成的 token，从而确保最终输出遵循所需结构。vLLM 等现代推理引擎支持多种约束，包括：

• JSON Schema
• 正则表达式
• 语法（Grammars）
• 工具与函数模式

这通常比生成无约束文本再事后修复更可靠。但需注意，受限解码保证的是结构，并不必然保证其中信息的正确性。

推理模型的推理（Reasoning）

推理模型会形成非常不同的推理工作负载，因为它们可能在给出最终答案前生成数千个中间推理 token。

不同于长上下文工作负载（其大部分成本可能来自处理庞大输入），推理工作负载在整个生成过程中可能都保持昂贵，因为解码阶段本身变得非常长。

冗长的推理轨迹会影响：

• 解码延迟
• KV 缓存内存
• 请求调度
• 批处理效率
• 吞吐量
• 成本

另一个挑战是推理长度往往难以预测。

有的请求会很快结束，而另一些会持续生成数千个 token。这使得在服务大量用户时，批处理、调度与 KV 缓存分配更加困难。

因此，服务一个生成几百个 token 的聊天机器人，与服务一个可能生成 10,000 个 token 的推理模型，所需的推理、内存与调度策略可能截然不同。

面向硬件的 LLM 推理

软件优化只是 LLM 推理的一部分。其下层硬件对速度、内存容量、可扩展性与成本的影响同样显著。

重要的硬件特性包括：

• GPU 计算性能： 决定数学运算的执行速度。
• 内存带宽： 决定模型权重与 KV 缓存数据在 GPU 内存与计算单元之间移动的速度。
• HBM 容量： 决定模型、KV 缓存与活跃请求有多少可以直接驻留在 GPU 上。
• CPU 内存： 当需要卸载模型或缓存时提供额外容量。
• PCIe 带宽： 影响数据在 CPU 与 GPU 之间移动的速度。
• GPU 间互连： 例如 NVLink，允许 GPU 在多 GPU 推理中快速交换数据。
• 网络带宽： 当推理分布在多台服务器上时变得重要。

理解硬件性能的一个有用概念是算术强度，即相对于需要移动的数据量，完成了多少计算。算术强度高的工作负载往往是算力受限，而算术强度低的工作负载通常受内存带宽限制。

在预填充阶段，可以并行处理许多提示 token，使硬件更好地发挥算力资源。在解码阶段，则是串行逐个生成 token，系统需要反复访问模型权重与 KV 缓存数据。因此内存带宽对生成速度尤为关键。

这也是为什么内存容量与内存带宽是两回事。例如，NVIDIA DGX Spark 与Apple M4 Max 系统都可提供最高 128 GB 的统一内存。但 DGX Spark 的内存带宽为273 GB/s，而 M4 Max 可达546 GB/s。因此即便两套系统都能让同一大模型“装得下”，推理性能可能截然不同。

同理，在比较 GPU 与本地 AI 机器时也适用：装得下模型解决的是容量问题，不一定是速度问题。

对于 LLM 推理，需要综合考虑算力性能、内存容量、内存带宽与互连速度。

选择合适的 LLM 推理优化

面对众多推理技术，关键是先识别究竟是什么在限制您的系统。

装不进显存的模型与一个因高延迟或低吞吐而挣扎的服务器，需要完全不同的优化方案。

重要的是，没有单一的最佳优化。

先测量 TTFT、token 生成速度、吞吐、GPU 利用率与内存使用等指标。然后针对真正的瓶颈应用相应技术，并再次基准测试。

例如，内存受限时可以使用量化；连续批处理可提升吞吐；前缀缓存能减少重复预填充；当未来 token 可预测时，投机解码可提升生成速度。

目标不只是最大化每秒 token 数，而是要在延迟、吞吐、内存使用、模型质量、硬件与成本之间找到最佳平衡。

结语

在本地运行 LLM 并用 llama.cpp 得到一个响应是很好的起点，但这并不意味着您就构建了一个高效的推理系统。

对于个人项目、试验与小规模工作负载，简单的本地方案可能已足够。

但一旦您开始服务大量用户、处理长上下文，或构建复杂的编码与智能体系统，需求便会迅速变化。

您需要一套推理栈，既能同时处理大量请求，又能保持良好的生成速度、高效管理内存，并在负载更重时仍保持响应性。

这时，连续批处理、前缀缓存、KV 缓存管理、量化、投机解码、优化内核、并行与请求调度等概念就开始变得重要。

您还需要理解诸如TTFT、吞吐、延迟、并发、GPU 利用率与每 token 成本等指标，而不是仅凭每秒 token 数来评判性能。

同样，没有一种通用配置适用于每个模型或工作负载。对编码有效的技术，未必能在推理任务上带来同样收益。

提升吞吐的优化可能会增加延迟。量化能显著降低内存需求，但更激进的量化也可能降低模型质量。

归根结底，优秀的 LLM 推理工程在于平衡。目标是在现有硬件上尽可能发挥效能，同时平衡速度、内存、吞吐、延迟、模型质量与成本。

这就是学习推理的重要性。与其完全依赖默认设置或一味增加 GPU，您可以理解瓶颈所在，选择合适的优化，并构建真正契合自身工作负载的服务系统。

要进一步了解 LLM 推理，推荐查看我们的“理解 LLM 推理”的网络研讨会。