大模型推理加速：KV Cache 到连续批处理的性能优化

一、为什么推理性能是落地第一道坎

模型精度达标后，生产环境最先暴露的问题通常是推理速度。70B 参数模型在 Prefill 阶段要处理全部输入 Token 的注意力计算，Decode 阶段每生成一个 Token 都要读取历史 KV Cache。这种"计算密集+访存密集"的模式带来两个直接后果：首 Token 延迟（TTFT）偏高，生成吞吐量达不到业务要求。

多用户并发时问题更明显。Batch Size 为 1 时，GPU 算力利用率可能不到 10%。增大 Batch Size 又会触发 OOM——每个请求的 KV Cache 都在占显存。核心矛盾就这一个：显存有限，怎么把 GPU 用满？

二、加速机制拆解

2.1 KV Cache 为什么是瓶颈

KV Cache 的作用是避免 Decode 阶段重复计算历史 Token 的 Key 和 Value。LLaMA-2-70B 有 80 层 Transformer，序列长度 4096 时，单个请求的 KV Cache 就要消耗约 5GB 显存，还不算模型权重本身的 140GB。

Decode 阶段每次只生成一个 Token，但要从显存读取全部历史 KV Cache。计算量小、访存量大，这就是 Memory-Bound——GPU 的 TFLOPS 根本跑不满。

2.2 PagedAttention 解决显存碎片

传统方案为每个请求预分配连续显存，序列长度未知只能按最大值分配，浪费严重。不同请求的 KV Cache 在显存中形成碎片，新请求无法复用。

vLLM 的 PagedAttention 把 KV Cache 分成固定大小的 Block（如 16 个 Token），按需分配。请求间的 Block 可以不连续，通过页表映射实现逻辑连续访问。显存利用率从 60%-70% 提升到 95% 以上。

2.3 Continuous Batching 的动态调度

Static Batching 组批后必须等所有请求完成才能处理下一批，短序列被迫等长序列，造成"尾部膨胀"。Continuous Batching 每个迭代步都可以插入新请求、移除已完成请求，实现请求级别的细粒度调度。配合 PagedAttention，GPU 利用率可以从 30% 提升到 90% 以上。

三、vLLM 部署与调优

from vllm import LLM, SamplingParams
from vllm.engine.arg_utils import AsyncEngineArgs
from vllm.entrypoints.openai.api_server import run_server
import asyncio

engine_args = AsyncEngineArgs(
    model="/data/models/llama-2-70b-chat-hf",
    tensor_parallel_size=4,
    block_size=16,
    gpu_memory_utilization=0.90,
    max_model_len=4096,
    quantization="awq",
    enable_prefix_caching=True,
    swap_space=16,
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=2048,
    n=1,
)

async def serve():
    await run_server(engine_args)

if __name__ == "__main__":
    asyncio.run(serve())

几个参数的实际经验：

• block_size=16：再小会增加页表管理开销，实测这个值在大多数场景下平衡得最好
• gpu_memory_utilization=0.90：低于 0.85 吞吐明显下降，高于 0.95 OOM 风险陡增
• quantization="awq"：4bit 量化把显存压缩到原来的 1/4，精度损失约 0.5%-1%，大多数业务可以接受
• enable_prefix_caching=True：相同 system prompt 的多请求场景，TTFT 能降 40%-60%
• swap_space=16：GPU 显存不足时把 KV Cache 换到 CPU 内存，吞吐会掉但能避免 OOM 崩溃

实测数据（4xA100-80G，LLaMA-2-70B）

配置	TTFT (ms)	吞吐 (Tokens/s)	显存占用 (GB)	GPU 利用率
默认	3200	42	280	35%
+Continuous Batching	2800	128	285	78%
+PagedAttention	2700	135	245	82%
+AWQ 4bit	2100	168	72	89%
+Prefix Caching	950	172	72	91%

Prefix Caching 对 TTFT 改善最明显——重复的 system prompt 不用重新算。AWQ 量化通过降低访存量，TTFT 和吞吐一起上来了。

四、边界条件和权衡

量化精度损失

AWQ/GPTQ 4bit 在通用对话场景下精度损失可控，但以下情况退化明显：

• 数学推理（GSM8K 准确率下降 2-3 个百分点）
• 代码生成（语法错误率上升约 15%）
• 长文本摘要（信息遗漏率增加）

业务对输出质量要求高时，6bit 量化是更稳妥的选择，显存节省约 40%，精度损失控制在 0.3% 以内。

Continuous Batching 的延迟尾部分布

连续批处理提升了吞吐量，但也引入了调度开销。并发请求的序列长度差异极大时（短文本 100 Token vs 长文本 4000 Token），短请求的 P99 延迟反而可能比 Static Batching 更高——长请求占用了大量 KV Cache Block，短请求的 Block 分配被阻塞。生产环境需要设置请求优先级，或对最大序列长度做分级限制。

PagedAttention 的间接寻址开销

分页机制带来额外的间接寻址，每次注意力计算都要查页表获取 Block 的物理地址。Decode 阶段这个开销相对于访存延迟可以忽略，但 Prefill 阶段大量 Token 并行计算时，间接寻址会成为瓶颈——实测 Prefill 速度比连续内存布局慢约 5%-8%。首 Token 延迟极度敏感的场景需要考虑这一点。

前缀缓存的适用场景

Prefix Caching 只在多个请求共享相同前缀时有效。system prompt 频繁变化，或用户请求之间没有公共前缀，缓存命中率趋近于零，反而增加缓存管理的额外开销。前缀缓存还占用额外显存空间，显存紧张时需要评估缓存容量和可用显存的平衡。

五、落地建议

推理加速没有单一银弹，每项优化都有适用边界和代价。

实际落地可以按这个顺序来：

1. 先上 vLLM + Continuous Batching + PagedAttention——投入产出比最高的基础优化
2. 根据显存预算选量化方案——4bit 适合吞吐优先，6bit 适合质量优先
3. 固定 system prompt 的业务开 Prefix Caching
4. 持续监控 P99 延迟和 GPU 利用率，根据实际负载调整 gpu_memory_utilization 和 max_model_len

优化的终点不是某个理论极限值，而是业务指标和资源成本之间的平衡。

---

改写总结

修改项	原文问题	处理方式
标题	"性能突围"有宣传感	改为"性能优化"，更中性
"核心痛点""本质"等词汇	AI 高频词	删除或替换为直接表述
"关键洞察"小标题	典型的 AI 结构标记	删除，直接陈述
"以下代码展示了"	填充短语	删除，直接放代码
"数据说明"段落	多余解释	融入表格后文直接说明
"第一步/第二步/第三步/第四步"	三段式法则过度使用	改为数字列表，更自然
"银弹""系统工程问题"	AI 词汇	保留"银弹"（技术圈常用），删除"系统工程问题"
"飙升到 90% 以上"	宣传性语言	改为"提升到 90% 以上"
代码注释	过度详细、像教程	精简为关键参数的实际经验
段落结尾	多为总结性语句	改为具体数据或开放结尾