LLM 推理优化实战：从 KV Cache 到推测解码的全栈性能工程

引言

随着大语言模型（LLM）从研究走向生产部署，推理效率已成为决定服务成本和用户体验的核心瓶颈。一个 70B 参数的模型在未经优化时，单次推理可能消耗数十 GB 显存并产生数百毫秒的延迟。本文将系统解构 LLM 推理优化的全栈技术体系，从底层的 KV Cache 管理到高层的推测解码（Speculative Decoding），覆盖当前工业界最前沿的工程实践。

一、推理瓶颈分析：计算 vs 内存

LLM 推理本质上是一种自回归生成过程：每一步都需要完整的前向传播来产生下一个 token。这意味着：

• Prefill 阶段：处理输入 prompt，属于计算密集型操作，GPU 计算单元利用率高
• Decode 阶段：逐 token 生成，属于内存带宽密集型操作，每次只计算一个 token 却需要读取全部模型权重

对于长上下文场景（如 128K tokens），KV Cache 的内存占用可能超过模型参数本身。以 Llama 3 70B 为例，单个请求的 KV Cache 在 FP16 下可达 35GB，这使得批处理（batching）和多租户部署成为重大挑战。

二、KV Cache 优化策略

2.1 分页注意力（PagedAttention）

vLLM 提出的分页注意力机制借鉴了操作系统的虚拟内存管理思想。传统方案为每个请求预先分配连续的 KV Cache 空间，导致严重的内存碎片（内部碎片可达 20%）。PagedAttention 将 KV Cache 切分为固定大小的 block（通常 16 tokens），按需动态分配，消除内存碎片。

核心收益：

• 内存浪费从 ~20% 降至 ~4%
• 支持更大的 batch size，吞吐量提升 2-4x
• 实现跨请求的 KV Cache 共享（如 system prompt 复用）

2.2 KV Cache 量化

将 KV Cache 从 FP16 量化为 INT8 或 INT4，直接减半或减至 1/4 的内存占用。关键技术挑战在于量化对注意力分数精度的影响。RoPE-aware 量化方案通过保留高频分量精度，在 INT8 下几乎无质量损失，INT4 则需配合 group quantization 使用。

2.3 滑动窗口与 Token 驱逐

Mistral 提出的滑动窗口注意力（Sliding Window Attention）限制每个 token 只关注最近的 W 个 token，将复杂度从 O(N²) 降至 O(N×W)。结合 Token 驱逐策略（如 H2O 的 Heavy Hitter Oracle），在超长上下文中动态淘汰低注意力分数的 token，实现近恒定的内存占用。

三、批处理与调度

3.1 连续批处理（Continuous Batching）

传统静态批处理需要等待 batch 中最长的序列返回才能释放资源。Orka 和 vLLM 采用的连续批处理在每个推理步骤动态进出请求：当一个序列完成生成时立即释放其 KV Cache 空间，新请求可以在下一个 step 立即加入。这使 GPU 利用率从 ~40% 提升至 90% 以上。

3.2 请求优先级与公平调度

生产环境中需要区分交互式请求和后台批处理任务。多级调度策略包括：

• Latency SLO 感知：根据 SLO 预算动态调整 batch 大小
• 公平性保障：防止大请求饿死小请求
• 抢占式调度：高优先级请求可中断低优先级序列，保存 KV Cache 后恢复

四、推测解码（Speculative Decoding）

推测解码是2024-2025年最重要的推理加速技术之一，其核心思想是：使用一个小而快的模型（draft model）快速生成候选 token，然后用大模型一次性验证多个 token。

4.1 原理与收益

假设小模型生成 γ 个候选 token，大模型验证时有 α 个被接受（α ≤ γ），则每次迭代实际推进 α+1 个 token（含验证失败后的修正 token）。当 draft 模型足够准确时（接受率 >80%），可获得 2-3x 的加速，且生成分布与原始大模型完全等价。

4.2 实践方案对比

• 独立 draft model：如 Llama 3 70B + Llama 3 8B，需要额外 GPU 资源
• Medusa 多头推测：在原始模型上附加多个轻量级预测头，无需额外模型
• EAGLE / EAGLE-2：利用模型中间层特征进行特征级推测，准确率更高
• LayerSkip：模型自身在不同层进行推测和验证，自draft模式

五、量化部署工程

5.1 GPTQ vs AWQ vs GGML 对比

5.2 FP8 与硬件协同设计

Hopper 架构（H100）原生支持 FP8 Tensor Core，相比 FP16 推理，FP8 在硬件层面提供 2x 吞吐量。配合 SmoothQuant 的激活-权重均衡量化方案，LLM 的 FP8 推理几乎无质量损失。TensorRT-LLM 和 SGLang 均已支持 FP8 推理。

六、生产部署最佳实践

6.1 架构选型指南

• 单租户 / 低延迟：Dynamic Batching + vLLM + Token 级流式
• 多租户 / 高吞吐：SGLang RadixAttention + 请求级调度
• 边缘部署：llama.cpp GGUF + 模型量化至 4-bit
• 极致吞吐量：TensorRT-LLM + FP8 + Pipeline Parallelism

6.2 可观测性与调优

关键监控指标：

• Time To First Token (TTFT)：prefill 延迟，受 prompt 长度影响
• Time Per Output Token (TPOT)：decode 步间延迟
• GPU 利用率：decode 阶段通常 <50%（内存带宽瓶颈）
• KV Cache 占用率：决定最大并发数
• 请求排队时间：调度器效率的体现

七、前沿趋势

2025-2026年值得关注的方向：

• Mooncake：字节跳动提出的分离式推理架构，将 KV Cache 存储在 CPU/远程内存层，突破 GPU 显存限制
• MoE 稀疏激活：Mixtral 和 DeepSeek-V3 的稀疏激活特性使推理成本仅与激活参数量成正比
• 结构化剪枝 + 推理融合：移除模型中不敏感的注意力头和 FFN 行，结合 kernel fusion 进一步加速
• NPU 推理生态：Apple Neural Engine、高通 AI Engine 的专用推理框架走向成熟

结语

LLM 推理优化是一个跨层次的全栈课题，从 CUDA kernel 融合到分布式调度策略，每个环节都有可观的性能收益空间。工程实践中没有银弹，最佳方案取决于具体的模型规模、硬件环境和服务 SLO。建议从 PagedAttention + Continuous Batching 的基线出发，根据瓶颈逐步引入推测解码和量化优化，在质量、延迟和成本之间找到最佳平衡点。