LLM 推理优化全景图：为什么你的模型跑不快？

大型语言模型（LLM）的推理速度和成本，是 2025-2026 年所有 AI 应用团队最头疼的问题之一。

GPT-4o 生成一个回复要等 10 秒，Claude 4 的 API 账单比服务器费用还高，DeepSeek-V3 跑起来显存不够用——这些问题背后不是"模型不够好"，而是推理工程的水太深。

本文从系统角度拆解 LLM 推理的核心瓶颈，以及 2026 年主流的优化手段。

推理的两阶段：Prefill 与 Decode

理解 LLM 推理优化的第一步，是把生成过程拆成两个本质不同的阶段：

Prefill 阶段（输入处理）：把用户输入的 prompt 一次性通过模型，得到第一个 token。这个阶段本质上是并行计算，充分利用 GPU 的矩阵运算能力，速度较快。

Decode 阶段（自回归生成）：模型逐个 token 生成，每次生成都要"看一眼"之前所有的 token（包括自己刚生成的）。这个阶段是顺序执行，每个 token 依赖于前一个，所以也叫"自回归"瓶颈。

`

Prompt: "解释量子计算的基本原理，并举例说明其在密码学中的应用"

↓

[Prefill] → 一次矩阵运算，处理所有输入 token

↓

第一个 token: "量子"

↓

[Decode] → 逐个生成，每个 token 依赖之前所有 token

"量子" → "计算" → "的" → "基本" → "原理" → ...

`

关键洞察：Prefill 阶段用 GPU 并行，计算效率高；Decode 阶段是序列生成，GPU 利用率往往只有 10-30%，大量时间花在等待和内存访问上。

瓶颈一：KV Cache 的内存墙

Decode 阶段最核心的问题是 KV Cache。

每个 Transformer 层都有一个 Key Cache 和 Value Cache，用来存储之前所有 token 的 Keys 和 Values。这样在计算注意力时，不需要重新计算已经处理过的 token。

问题是：随着上下文增长，KV Cache 线性膨胀。

以 Llama 3 70B 为例：

• 每个 token 在每层产生的 KV 数据约：`2 * hidden_size * 2 * num_heads * head_dim`
• hidden_size=8192，num_heads=64，head_dim=128
• 每个 token 每层约：2 × 8192 × 2 × 64 × 128 / 8 = 32 MB？不对，重新算

实际上，每个 token 在 KV Cache 中占用的内存约为：

`

参数总量 ≈ 70B

每个参数 float16 = 2 bytes

每个 token 的 KV Cache = 参数总量 / seq_len ≈ 140GB / 8192 ≈ 17MB/token/layer

70B 模型有 80 层 → 每个 token 全量 KV Cache ≈ 1.36 GB

`

这是每个 token 的开销！所以 2048 个 token 的上下文，KV Cache 就能占用几 GB 到几十 GB 不等。

Memory Bandwidth Wall（内存带宽墙）：Decode 阶段每个 token 生成时，都需要从显存读取完整的历史 KV Cache 数据。随着序列变长，内存带宽很快成为瓶颈，即使 GPU 计算单元还有大量空余。

优化手段一：PagedAttention 与 vLLM

2023 年 vLLM 提出的 PagedAttention 是近年来最重要的推理优化之一。

核心思想：把 KV Cache 当作"分页内存"来管理，而不是预先整块分配。

传统方法的问题是：KV Cache 必须预先分配一个最大长度的连续显存（比如 4096 tokens），即使实际只用到 100 tokens，剩下 3996 个位置也被锁定了。这导致显存碎片化、利用率低。

`

# 传统方式的内存分配

KV Cache 预分配: [0.....0........0.....0] # 4096 个位置，大部分空闲

# PagedAttention 方式

KV Cache 分页管理: [Page 1][Page 2][Page 3]... # 按需分配，动态拼接

[使用中] [使用中] [空闲]

`

vLLM 通过把 KV Cache 分成固定大小的"页"（类似操作系统内存分页），实现：

1. 动态分配：需要多少分配多少，避免预分配的空间浪费

2. 共享显存：不同请求可以共享相同的前缀 KV Cache（用在 speculative decoding 或多请求复用场景）

3. 连续 Batching：更高效的请求调度

实测效果：vLLM 的吞吐量比 Hugging Face 默认实现高 2-10 倍，在长上下文场景下提升尤为明显。

优化手段二：Continuous Batching（持续批处理）

传统 Batch 的问题是：必须等一个请求全部生成完毕，才能加入新请求。

想象一个场景：请求 A 生成了 500 个 token 的长回复，请求 B 只需要 10 个 token。在传统 Batch 下，B 必须等 A 全部完成才能开始，这显然不公平。

Continuous Batching（也叫 Iteration-level Scheduling）解决了这个问题：

`python

# 传统 Static Batching

# 所有请求同时开始，同时结束，短请求等待长请求

# Continuous Batching

while running_requests:

# 每个 step：所有请求各生成一个 token

for req in running_requests:

generate_next_token(req)

# step 结束后，立即把生成完毕的请求移出

finished = [req for req in running_requests if req.is_done()]

running_requests -= finished

# 立即加入新请求，保持 batch 满载

running_requests += new_arrivals

`

理论上，Continuous Batching 可以让 GPU 利用率接近 100%，因为始终有请求在执行。但实际实现中需要处理：

• 不同请求的 KV Cache 长度不同，内存管理复杂
• 新请求加入时的上下文恢复
• 调度开销（step-level 调度延迟）

目前主流实现包括 vLLM、TGI（Text Generation Inference）和 SGLang。

优化手段三：Speculative Decoding（推测解码）

Speculative Decoding 是 2023-2024 年最优雅的推理优化之一，核心思想是"用小模型推测，大模型验证"。

`

传统 Decode（slow）:

Step 1: 大模型生成 token "量子" (耗时 100ms)

Step 2: 大模型生成 token "计算" (耗时 100ms)

...

Speculative Decoding（fast）:

1. 小模型（7B）一次性推测出 8 个 token: "量子计算的基本原理是..." (耗时 20ms)

2. 大模型（70B）并行验证这 8 个 token (耗时 50ms，总共一次 forward)

3. 接受前 N 个正确的 token，继续

`

关键点：验证阶段可以并行，因为大模型一次 forward 可以处理整个推测序列，而不是逐个验证。

理想情况下，Speculative Decoding 可以实现 2-4 倍加速，且输出分布与原始模型完全相同（数学上等价）。但实际效果取决于：

• 小模型与大模型的"差距"——差距越大，拒绝率越高，加速效果降低
• 推测长度（draft length）——太长则浪费，太短则调度开销占比大

优化手段四：量化（Quantization）

量化是把 FP16/FP32 权重压缩到 INT8/INT4 的技术，是目前最成熟、最广泛使用的优化手段。

2026 年的主流方案是 AWQ（Activation-aware Weight Quantization） 和 GPTQ，后者是量化领域的经典方法。

`python

# 使用 AWQ 量化的示例

from awq import AutoAWQForCausalLM

from transformers import AutoTokenizer

model = AutoAWQForCausalLM.from_quantized(

"TheBloke/Llama-3-70B-AWQ",

quantized=True,

w_bit=4,

group_size=128

)

`

但量化不是银弹：

• **延迟敏感场景**：量化对首 token 延迟（Prefill）帮助有限，因为 Prefill 本来就是计算密集
• **长输出场景**：Decode 阶段收益更大，因为内存带宽是主要瓶颈
• **质量损失**：INT4 在某些任务上（尤其是需要精确输出的任务）可能有明显下降

2026 年推理优化的完整技术栈

实际生产环境中，推理优化往往是多个手段叠加使用：

`

LLM 推理优化技术栈

├── 模型层优化

│ ├── 量化：AWQ / GPTQ / INT4

│ ├── 剪枝：知识蒸馏 + 结构化剪枝

│ └── 稀疏注意力：Sliding window attention / Sparse attention

│

├── 推理框架层

│ ├── vLLM：PagedAttention + Continuous Batching

│ ├── TGI (HuggingFace)：带量化支持的推理服务器

│ └── SGLang：RadixAttention（KV Cache 复用优化）

│

├── 硬件层

│ ├── GPU 显存优化：Memory offloading

│ ├── CUDA 算子融合：Flash Attention 2/3

│ └── Tensor Parallelism：多卡并行

│

└── 调度层

├── Speculative Decoding

├── Prefix Caching（共享前缀 KV Cache）

└── 请求路由：根据输出长度选择不同规格模型

`

成本与性能的 Tradeoff

说了这么多，实际上每个团队面对的优化目标不同：

场景一：面向用户的在线服务（延迟敏感）

• 优化目标：P99 延迟 < 1s
• 手段：Continuous Batching + Speculative Decoding + 适当量化
• 典型配置：int8 量化 + 70B 模型 + 4xA100

场景二：离线批量处理（吞吐量敏感）

• 优化目标：每天处理 100 万条请求
• 手段：PagedAttention + 最大 Batch size + INT4 量化
• 典型配置：INT4 量化 + 8xA100 + 大量 CPU 预fill

场景三：边缘/端侧部署（成本敏感）

• 优化目标：在有限显存内跑起来
• 手段：INT4 量化 + 知识蒸馏 + 4-bit 权重
• 典型配置：7B 模型压缩到 4GB，Mac M3 即可运行

总结

LLM 推理优化是一个系统性问题，不是简单换一个库能解决的。理解 Prefill 与 Decode 的本质差异、KV Cache 的内存墙、Batch 调度的核心逻辑，是做优化的前提。

2026 年的技术格局已经比较清晰：vLLM/SGLang 等框架提供了成熟的工程底座，AWQ/GPTQ 量化已经标准化，Speculative Decoding 从研究走向生产。但优化无止境——随着模型越来越大、上下文越来越长，内存墙的问题只会越来越突出。

下一个突破点，可能在硬件和架构层面：NVLink 的互联带宽、新的 Transformer 替代架构（RWKV、Mamba、RetNet）、以及专用 AI 推理芯片。

但在那之前，先把 KV Cache 管理好——你的模型已经在"等内存"了。