大语言模型推理优化技术综述（The Art of LLM Inference）

2025-05-28
重庆
本文字数：7847 字
阅读完需：约 26 分钟

编者按： 如何将 LLM 的推理过程从“烧钱的无底洞”转变为“高性能的生产力引擎”？本文深入剖析了提升 LLM 推理效率的五大核心技术：巧妙的 KV 缓存管理、Query-sparsity attention（QUEST）、推测解码（使用 draft model 加速生成过程）、权重调度（通过 Flexgen 实现跨设备资源分配）以及系统级优化（FastServe 解决队头阻塞问题）。此外，作者还简要介绍了多种常见优化方向，包括量化技术（AWQ、INT8、FP8 等）、Early Exit Inference（LITE）、注意力机制优化（FlashAttention、ROFormer）以及使用非自回归 LLM 等。

作者 | Trung Thanh Tran

编译 | 岳扬

如果您正在开发 AI 解决方案，并托管基于大语言模型（LLMs）的基础模型，那么您就应该关注模型服务的成本。然而，资金并非唯一的考量因素。请相信，如果无法解决模型性能的难题，即便预算充足，LLMs serving 的实际效果仍会大打折扣。本文将探讨如何将 LLM 的推理过程从「烧钱的无底洞」转变为「高性能的生产力引擎」。

01 LLMs serving 面临的一些挑战

LLMs 非常强大，但它们的特性使其难以高效服务。LLM 的推理过程包含两个阶段：

1) 预填充阶段：当你输入提示词（上下文、对话历史、问题等）时，模型会一次性处理所有 token。

2) 解码阶段：在初始的提示词后，模型逐 token 生成内容，每个新 token 依赖于之前生成的 token。

举一个易懂的类比：预填充阶段如同下棋时摆棋盘（耗时较长），而解码阶段则像摆好棋后逐步下棋（每一步都很快）。

然而，LLMs serving（译者注：将训练好的大语言模型部署到实际应用中，以低延迟、高吞吐、资源高效的方式处理用户请求的技术过程。）并非轻而易举，必须考虑以下问题：

Sparsity

在神经网络（尤其是 FFN 模块）中，大量神经元的激活值为零。跳过这些零激活值的神经元、仅计算非零元素可以大大节省运算时间。

LLM 中大量神经元的激活值为零，导致矩阵运算中存在大量零值。图片来源[1]

内存带宽限制与内存瓶颈

在 GPU 上传输数据往往超过数据计算的耗时。此外，大型模型（例如传闻参数量达万亿的 ChatGPT）无法单卡装载。

将当前最先进 LLM 的内存需求，与 GPU 的显存容量进行对比。图片来源：ChatGPT

低效调度——先到先得

LLM 通常需要同时处理多个请求。这会导致短请求（例如询问天气、时间或简短的回答）被迫等待长请求完成。那么，平均响应时间几乎完全由等待时间主导，而非实际计算时间。

你更快，但必须等待之前的请求先处理完。图片来源：ChatGPT

Sequential Decoding（按顺序进行解码）

生成 token 时无法轻松实现并行处理。每次前向传播只能产生一个 token（或一个小 batch）。当我们向 ChatGPT 请求长回复时，输出内容往往是逐词生成的。这就是为什么“流式输出”（streaming output）的用户体验并不比等待完整答案一次性输出更差。

逐步进行解码。图片来源：ChatGPT

KV Cache 增长

注意力机制需对整个序列的所有文本进行计算，这是 LLM 的推理过程中最核心且最耗时的操作。有趣的是，每当序列中生成新 token 时，系统会对过去的 token 重复大量相同的计算。键值缓存（KV Cache）技术通过存储前几步的关键信息来加速此过程（使用 KV Cache 可使 T4 GPU 上的 GPT2 推理速度提升 5 倍）。下图展示了使用缓存与不使用的区别，但使用缓存也会额外占用内存。

解码序列 [token 1, token 2, token 3, token 4] 时的 KV Cache 操作步骤。图片来源[2]

实验表明，KV（Key-Value）缓存的使用率在 20.4% 到 38.2% 之间。我用 Qwen-VL 2.0 模型对约 1 万张图片生成简短描述（要求回答少于 20 字），发现速度比未使用 KV 缓存的版本快 20%。

这些特性看似棘手，但通过巧妙的工程化手段，反而能转化为优势。

02 主题 1：巧妙的 KV 缓存管理

Page attention

KV 缓存会占用大量内存。上下文越长，KV 缓存占用的内存越大。 例如，若某 LLM 的输入长度为 2048 个 token，则需预留 2048 个词槽（slots）。下图说明了我提到的情况。

在图中，2048 个词槽被一个包含 7 个单词的提示词（“four, score, and, seven, years, ago, our”）占用了，后续生成的 4 个单词（“fathers, brought, forth, ”）占用了第 8-11 个词槽。这意味着仍有 2038 个词槽被保留，但从未被使用过，这就产生了内存的内部碎片（internal fragmentation）。

每个推理步骤都会生成键值对（KV pairs），在使用注意力机制时必须缓存这些数据。KV 缓存通常以连续的块（chunks）或页（pages）的形式分配在内存中。当序列生成完成并释放内存页后，已释放的页可能不再连续。后续序列所需的内存大小可能无法恰好匹配现有空闲块，导致内存中散布小型的空闲块——即外部碎片（external fragmentation）。

受操作系统的内存管理启发，Page Attention 机制也将数据组织为逻辑内存块（logical memory block），并通过页表（page table）进行监控，再将合适的页（page）映射到物理内存中。具体实现如下：

1) Fixed-size Blocks（固定大小的内存块） ：PagedAttention 分配固定大小且相对较小的内存块（称为“页（pages）”）来存储 KV 缓存。

2) Shared Blocks（共享内存块） ：这些固定大小的内存块可在不同请求间共享。

3) On-demand Allocation（按需进行分配） ：随着生成过程逐步分配内存块，无需根据最大序列长度的估算预先分配。

LLM 中的分页机制示意图。Image by the author

支持多请求间共享内存块的 LLM 分页机制示意图。Image by the author

Raddix tree KV cache

在计算机科学中，基数树（radix tree，亦称 radix trie、compact prefix tree 或 compressed trie）是一种优化了空间效率的字典树（前缀树），其将每个唯一的子节点与其父节点合并。

Raddix tree KV cache 是一种支持跨不同推理请求高效复用键值（KV）缓存的技术，尤其适用于多个请求共享共同前缀的场景。 通过将 KV 缓存组织为 Raddix 树结构，可高效检索缓存数据并在请求间共享。在下面的例子中，三个请求共享相同的前缀 "ABC"（存储于父节点中），每个请求中的最后一个单词则分别存储在三个叶子节点。需注意：树结构的运行时间复杂度为 O(nlogn)，远低于注意力计算的 O(n²)。

Raddix tree KV cache 示例

Compressed attention

多头注意力机制（Multi-head Attention）[3]是 Transformer 模型（LLMs 的基石）的核心机制。每个注意力头从不同视角分析文本：其中一个注意力头关注主谓关系，另一个注意力头解析词汇特征，第三个注意力头分析句子结构。这种多头机制虽增强了模型的理解能力，但也导致每个注意力头需要独立的 KV 对。在实时文本处理或长序列场景中，这些独立的 Key 和 Value 会占用大量内存。

分组查询注意力机制（Group Query Attention, GQA）允许多个查询（queries）共享同一组 Key 和 Value，从而减少所需 KV 对数量。多查询注意力机制（Multi Query Attention, MQA）则更为激进，仅用一组 KV 对服务所有查询（queries）。

多头注意力、多查询注意力、分组查询注意力对比图

中国 AI 初创公司深度求索（DeepSeek）今年初发布了其 chatbot。该产品以高效、开源著称，人们传言他们的成功源于对 ChatGPT 生成数据的分析工作。然而，阅读了他们的技术报告后，我发现其技术突破不仅仅局限于数据提取操作。DeepSeek 提出的 Flash Multi Latent Attention（Flash MLA）通过低秩压缩将 Key 和 Value 向下投影到更小维度的 latent vector 中，大幅减小了缓存体积。计算注意力时再将 latent vector 向上投影，且上投影矩阵权重与查询矩阵权重"折叠"融合，进一步加速了注意力的计算。

多头潜在注意力机制（MLA）示意图。Image by the author

03 主题 2：Query-sparsity attention

QUEST: Query-Aware Sparsity for Efficient Long-Context LLM Inference

从 MIT 研究人员撰写的论文《QUEST: Query-Aware Sparsity for Efficient Long-Context LLM Inference》[4]中，我们得知 Transformer 模型在推理过程中（尤其是注意力计算环节）常存在高稀疏性「译者注：high sparsity，大部分神经元或注意力权重在计算过程中未被激活（值为零或接近零）」。这意味着大模型中并非全部的神经节点被激活。通过将高稀疏性（high sparsity）的特性应用于剪枝机制（pruning mechanism），我们能够发现一种高效运行大模型的方法。下图展示了 Transformer 模型各层的稀疏性统计数据。遗憾的是，第 3 层之后的模型层通常非常稀疏。极端情况下，某些模型层（如第 10 层）甚至达到了 100% 稀疏，这种现象等同于在运行大语言模型时多次乘以 0，从而产生零值输出。

出现这种现象的原因很简单：并非每个单词都对当前上下文有贡献。

例如，给定提示词："A is B. C is D. A is"，模型应生成 "B"。这意味着只需要最关键的 token，而这很大程度上取决于查询（queries）。因此该技术被命名为查询感知的稀疏性算法（query-aware sparsity）。

Transformer 模型推理中的稀疏性估算。图片来源[5]

了解这一特性后，QUEST 的核心策略就是定位对注意力计算最关键的数据块。QUEST 将找出前 K 个数据块。其算法流程直观清晰（见下图）：

QUEST 获取 top K 个关键数据块进行注意力计算的流程

首先，对于每个数据块，QUEST 会找出最小和最大键值（minimum and maximum keys）及其通道尺度上的数值（channel-wise values）。接着，query 会逐个元素地生成最大和最小键值。这种方法能够大大减少所需的计算量 —— 即使 query 的符号（sign）变化，后续的乘积运算通常仍能得到最大值：当 query 符号为负时，乘以最小值必然得到最大输出值，反之亦然。在获取每个数据块的最大值后，QUEST 仅筛选出与 query 最相关的 K 个关键 KV 块。通过这一流程，计算量得以大幅降低。

最后一个关键问题是选择恰当的 K 值，以避免模型性能下降。K 是一个需要通过实验才能确定的超参数（hyperparameter）。在论文中，作者建议选择 K=4096，可使模型性能保持在接近 100% 的水平。

以下是 K=4096 时的数据：

PG19（一种教科书数据集）上的准确率 ≈ 完全达到了全局注意力（Full Attention）的基准准确率
passkey retrieval 数据集上准确率 ≈ 100%
LongBench 任务上的准确率 ≈ 在多数数据集上等效于全缓存（full cache）

04 主题 3：推测解码

推测解码（speculative decoding）对于大语言模型（LLM）推理的加速非常重要，该技术由 Andrej Karpathy[6] 提出，并由 Google 在 2022 年首次引入[7]。

该技术的核心思想非常简单：

与其仅用庞大、缓慢但精确的模型（称为 target model）逐词生成，不如先用小型、快速但不太准确的模型（通常称为 draft model）快速"推测"后续的多个 token。然后用大型模型验证这些猜测的 token。若大型模型认同小型模型的预测，则一次性接受所有结果（减少计算量）。如若不一致，就从分歧点开始回退（重新执行）。示意图如下文所示。

draft model 可以是 Ngrams、1B 参数级别的模型，最高可达 3B 参数级别的模型。target model 则可以是数十亿甚至数万亿参数规模的模型。

虽然使用两个模型会消耗较多内存，且重复生成过程也比较耗时，但该技术的核心价值在于其卓越的实用性 —— 连 Gemini 这样的顶级模型都已采用该技术（如下图所示）。实际情况是，draft model 生成的 token 通常正确率很高，以至于 target model 无需修正结果。这是因为在现实语境中常见词汇如"yes, this, is, and so on"出现频率极高，即使小型语言模型也能轻松预测。通过并行验证 draft model 生成的所有 token，而非逐词进行自回归解码，这样可以节省大量时间。

05 主题 4：权重调度

调度（Scheduling）的核心在于将模型权重平衡分配到物理机器的资源（包括 GPU、CPU 和硬盘）中。这种策略不仅能通过并行计算加快推理速度，还能让 100B 参数级别的超大型模型在仅配备有 T4 GPU 的低配置 PC 上运行。

实现这一目标的关键在于两个核心要素：

在 GPU、CPU 和硬盘间智能地加载/卸载模型权重
高效处理计算单元间的 I/O 数据传输

Flexgen

由 Stanford、UC Berkeley 和 CMU 联合提出的 Flexgen[8]，正是解决这两个关键问题最具创新性的方案之一。

推理过程通常如下图所示。需要处理的每个数据块被定义为加载到模型层的一批数据，其中列方向按批次处理的，行方向则按照模型层维度处理。

我们定义有效路径为满足以下约束条件的遍历（即计算）所有方格的路径：

从左向右执行
所有数据必须位于同一设备
当前方块的激活值（Activation）需要等待其右侧相邻方块完成计算后，才能被释放或复用
KV Cache 需存储至最右侧数据计算完成时释放
任意时刻设备上存储的张量总大小不得超过该设备内存容量

如果我们有 n 个 token，每个 token 的数据将按顺序加载和计算。每一层的权重仅在需要计算时加载，并在计算结束后立即卸载。由于 GPU 的计算速度极快（如闪电），而内存传输速度极慢（如蜗牛），频繁的加载/卸载会带来巨大时间开销。

图中每个方块表示 GPU 对一个模型层（layer）的批处理计算（batch computation），同色方块共享同一层的权重参数

Flexgen 通过将行扫描改为列扫描或之字形块调度（zig-zag block schedule）进行优化：在无 I/O 开销的情况下保留模型层权重，并为下一列保存激活值。在计算块执行期间，Flexgen 实现三大操作的并行执行：加载下一层权重、存储前一数据批次的激活值/KV 缓存、执行当前数据批次的计算，从而有效解决内存传输问题。

Flexgen 的另一个核心创新在于模型权重的硬件分布策略。

Flexgen 采用线性规划策略搜索法（Linear Programming Policy Search）来寻找最优加载配置，使模型整体推理时间最小化。

其中：

n：每个序列输出 token 的数量
𝑙：transformer 层数
block size：每个计算块处理的样本量（数据批次大小 × 数据批次数量）

下图展示了 Flexgen 在搭载了 T4 GPU 的机器上运行 OPT-30B 模型的配置示例。

论文对比了 HuggingFace 的 DeepSpeed 库和 Accelerate 库的性能：Flexgen 声称能达到 7.32 tokens/秒，而 DeepSpeed 为 1.57 tokens/秒，Accelerate 仅 0.62 tokens/秒。

06 主题 5：系统级优化

现有 LLM serving 系统（如 vLLM、Orca）通常采用先到先服务（FCFS，First-Come-First-Serve）机制和执行到完成为止（run-to-completion）的运行方式，这会导致队头出现阻塞（HOL） —— 简单来说：长任务会延迟短任务的处理。这就造成了较高的排队延迟，在实际工作负载中可达总延迟的 90%。 请看论文 FastServe[9] 中的统计数据：

注意：当我们提及长请求/短请求时，并非指提示词（prompt）的长度，而是指生成首个 token 所需的时间。

time by execuation vs queuing. Image source[9]

该问题的解决方案是：允许中断长请求，将已完成的部分存入缓存，保留未完成的部分稍后处理，然后切换至短请求。待短请求完成后，继续运行长请求的剩余部分。此方案需实现具有多个不同优先级的队列（multi-queue）。

但这一想法仍然存在一个问题：若高优先级队列中存在多个长请求位于短请求之前，可能导致长请求被多次中断才切换到短请求。这不仅增加长请求的处理时间，还会对缓存造成额外压力。

FastServe 通过引入跳转式多级反馈队列（Skip-Join MLFQ）来解决这个问题：当系统收到请求时，会预估生成首个 token 所需的时间，据此将请求路由至合适优先级的队列，避免干扰更短请求。此外，通过 KV 缓存管理，可在 GPU 处理先前的队列时主动在队列间迁移数据，进一步降低延迟。

07 其他主题

还有很多其他优化 LLM 推理的技术方向，本文不再详述（因为这些技术方向非常常见，许多工程师每天都在使用），仅列举技术方向与参考文献：

量化（Quantization）

通过降低权重和激活值的精度（如从 FP16 降至 INT4 或 FP8）压缩模型体积并提升推理速度，同时将精度损失降到最小。

AWQ

通过激活值计算每个权重/通道的重要性分数进行基于激活值感知的权重量化。支持低比特推理（如 INT3）且无需重训练。

LLM.int8()

提出通过校准过程（Calibration）实现 Post-training INT8 矩阵乘法，支持 Transformer 推理且不会降低精度。

SmoothQuant

通过跨层对齐激活值与权重的数值范围，提升 post-training 量化效果。

ZeroQuant / V2 / FP

使用校准过程（Calibration）和低秩补偿（Low-rank Compensation）的低比特量化技术（INT4, FP4）。

LLM-FP4

证明 FP4 表示法可在显著提升推理速度的同时保持模型质量。

WINT8

针对生产环境中的 MoE 模型的 INT8 量化方案。

SpQR

将模型量化与 sparsity 相结合，实现近乎无损的 LLM 压缩，适用于边缘部署。

FP8-LM

使用 FP8 格式训练 Transformer，降低训练与推理过程的内存和算力消耗。

FP8 Formats

定义 NVIDIA 的 FP8 格式及其在深度学习推理/训练中的应用。

Early Exit Inference

LITE

在神经网络的中间层添加预测能力，当置信度较高时，token 会提前退出，最高可节省 38% FLOPS。

注意力机制优化（Attention Optimization）

FlashAttention 1, 2, 3

通过内存分块实现快速、精确的注意力计算，速度与内存效率优于标准实现方式。

ROFormer

引入旋转位置编码（Rotary Position Embedding），提升模型对长程依赖关系的泛化能力。

StreamLLM

允许注意力在流式处理过程中动态适配新的输入块。

非自回归的 LLM（Non-autoregressive LLMs）

Diffusion-LM: Improving Controllable Text Generation

将扩散模型应用于文本生成的首个重要工作。

08 如何应用这些技术

vLLM[10] 是一个开源库，能够大大提升大语言模型（LLM）推理（运行模型）的速度和效率。

它由 UC Berkeley 的研究者开发，专注于实现 LLM 的高吞吐、低延迟服务。该库最初基于 PageAttention 的核心思想，但如今已整合了前文提及的绝大多数优化技术。在我看来，vLLM 已成为大模型推理优化领域生态最活跃的开源社区之一。

以下是我使用 vLLM 调用 QwenVL 2.5 7B instruct 模型对图片进行描述的示例代码：

感谢你阅读本文！这是我以 Fatima Fellowship 身份开展的研究工作，我与 Colorado School of Mines[11] 的 PhD candidate Ismet Dagl 博士合作，专注于提升边缘设备上大语言模型（LLM）、视觉语言模型（LVM）及基础模型的性能与内存优化。

About the author

Trung Thanh Tran

END

本期互动内容 🍻

❓在您的工作中，最希望出现哪种“开箱即用”的推理优化工具？欢迎在评论区分享~

文中链接

[1]https://developer.nvidia.com/blog/accelerating-inference-with-sparsity-using-ampere-and-tensorrt/

[2]https://media.licdn.com/dms/image/v2/D5622AQEd3w_266T-cg/feedshare-shrink_2048_1536/feedshare-shrink_2048_1536/0/1708872868565?e=1748476800&v=beta&t=-USDPQAiDwF6OGy-BC8y9mHf4nW_W3qr-QL3ZT08ynk

[3]https://d2l.ai/chapter_attention-mechanisms-and-transformers/multihead-attention.html

[4]https://arxiv.org/abs/2406.10774

[5]https://medium.com/r?url=https%3A%2F%2Farxiv.org%2Fabs%2F2406.10774

[6]https://x.com/karpathy/status/1697318534555336961?lang=en