vLLM 吞吐量优化实战：10个KV-Cache调优方法让tokens/sec翻倍

十个经过实战检验的 vLLM KV-cache 优化方法 —— 量化、分块预填充、前缀重用、滑动窗口、ROPE 缩放、后端选择等等 —— 提升 tokens/sec。

GPU 性能没问题，模型也训练得不错，但 token 吞吐量就是上不去？问题多半出在 KV-cache 上。本文整理了 10 个实际可用的优化方向，都是能直接上生产环境的那种。

1、给 cache 足够的内存空间

vLLM 启动时会预分配一大块 VRAM 给 KV-cache 用。如果分配得太保守，批处理规模会急剧下降，吞吐量也跟着崩。两个关键参数：

--gpu-memory-utilization 控制预分配的激进程度

--max-num-seqs 限制并发序列数，避免内存碎片和频繁抢占

把 utilization 往上调，直到不再频繁出现 preemption；然后再调 max-num-seqs，让批次保持密集但别超出承载能力。vLLM 官方优化文档里专门提到过这点。

python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3-8b-instruct \
--gpu-memory-utilization 0.92 \
--max-num-seqs 256

2、FP8 量化 KV-cache（需要硬件得支持）

注意这里量化的是KV-cache本身，不是模型权重。降到 FP8 之后，同样的显存能塞下更大的上下文，批次规模也能跟着扩大，吞吐自然就上去了。

--kv-cache-dtype fp8 (或者 fp8_e4m3、fp8_e5m2)

但这里有几个坑：FP8 支持强依赖硬件和后端实现。Hopper/Ada 架构（H100、4090）和 AMD MI300 系列可以跑，Ampere（比如 3090）就不行。而且部分 attention 后端压根不支持 FP8 模式，开了反而会更慢。

有人做过详细对比测试，FP8 确实能扩大批次，但在 vLLM 上的加速效果取决于后端支持情况；TensorRT-LLM 表现更稳定一些。所以需要针对自己的配置实测。

3、 分块预填充让解码和 prefill 并行

长 prompt 在 prefill 阶段会把 GPU 算力全占了，decode 只能干等着。Chunked prefill把大段的 prefill 切成小块，这样就可以和 decode token 交错执行，GPU 利用率也可以保持在高位。并且在混合长度请求的场景下，端到端吞吐提升相当明显，vLLM 文档和社区反馈都验证过这个效果。

新版本默认开启了 chunked prefill，但还是要留意调度策略，别让 decode 被饿死。

4、前缀缓存的命中条件比较苛刻

vLLM 的 prompt 缓存基于 PagedAttention，粒度是block级别的。哪怕一个 block 里只有一个 token 不一样，整个 block 就没法复用。所以想提高命中率得把 prompt 做标准化处理，让前面的 token 尽可能对齐到 block 边界——比如固定的 system prompt、统一的前导模板之类的。社区里对这个 block-level 约束讨论得挺透彻。

5、 滑动窗口注意力配合混合管理器

SW-attention（也叫 local attention）只保留最近窗口内的 KV，长序列下的缓存增长能控制得很死。新版 vLLM 的混合 KV-cache 管理器能协调 SW 层和全注意力层，让缓存命中逻辑在不同层之间保持一致。结果就是 KV 工作集更小、访问更热，长对话场景下的持续吞吐会稳定很多。

6、ROPE 缩放要算清楚成本

ROPE scaling（线性或动态缩放）能把上下文窗口拉长，但每个被 attend 的 token 还是要占 KV-cache 空间的。这招虽然适合用在检索密集型任务或者评测里但它并不省 VRAM。vLLM 支持不同的缩放类型（dynamic 等），会针对每种缩放方式缓存对应的 cos/sin 查找表。用之前需要证下 factor 和 type 设置。

--rope-scaling '{"type":"dynamic","factor":4.0}' --max-model-len 64_000

7、推测解码降低 memory-bound 延迟

当瓶颈卡在内存带宽上时，speculative decoding能帮上忙。让一个轻量级 draft model 先猜几个 token，大模型只负责快速验证接受或拒绝。实测下来，根据请求类型和上下文长度，加速比能到 2.5 倍左右。vLLM 现在把这个做成了一等公民特性，配置好就能看到 inter-token latency 明显下降。

8、跨会话持久化 KV 状态

如果经常重启 pod 或者激进地做 autoscale，每次都会把热的 KV 状态扔掉。外部 KV 持久化方案（比如基于快速共享存储的 LMCache）可以让服务重新加载或者共享 KV 片段，避免冷启动的卡顿。对于那种有大量重复 header/prompt 的检索流水线特别管用。这个可以看看 vLLM 和文件存储 KV 命名空间的集成案例。

9、多模态 token 也会占 KV 槽位

跑 VLM 的话还要注意图像（和其他模态）会像文本 token 一样在 KV 里占位置，这会悄悄压缩并发序列的空间。规划 --max-num-seqs 和内存利用率时要把多模态 token 算进去，不然加了视觉功能后会发现批次莫名其妙变小了。

10、后端选择要和 KV dtype 匹配

后端实现直接决定了 KV dtype 能不能跑得快：

FlashAttention-2：默认的高性能选项，但有些版本/后端不支持 FP8 KV

XFormers / FlashInfer：FP8 场景下可能得用这些，牺牲一点绝对速度换兼容性

如果开了 --kv-cache-dtype fp8* 但吞吐反而掉了，多半是掉到慢速路径上了。换个后端重新测一下，这个性能差异是有实际 benchmark 数据支撑的。

简单的入门配置

• 从 --gpu-memory-utilization 0.90+ 和合理的 --max-num-seqs 起步
• Hopper/Ada/MI300 架构上试试 --kv-cache-dtype fp8_e5m2，确认后端走的是快速 kernel
• 确保chunked prefill开启，观察负载下的 decode 延迟表现
• 标准化 prompt 结构，提升前缀复用的 block 对齐命中率
• 长会话场景优先考虑 SW-attention 模型，用上混合KV 管理器
• memory-bound 的工作流加上speculative decoding，配个小 draft model

OpenAI 兼容服务器 + FP8 KV + 调优后的内存利用率（需硬件支持）：

python -m vllm.entrypoints.openai.api_server \
--model mistralai/Mistral-7B-Instruct-v0.3 \
--kv-cache-dtype fp8_e5m2 \
--gpu-memory-utilization 0.94 \
--max-num-seqs 192

(如果吞吐量暴跌，切换后端或恢复 dtype 重新测试)

推测解码配置（draft model + target model）：

python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3-8b-instruct \
--speculative-model microsoft/phi-3-mini-4k-instruct

(跑个快速 A/B 测试后调整接受阈值)

总结

现在大部分 LLM 服务栈的瓶颈不在算力，而是KV-bound。好在 vLLM 提供了不少现成的调优手段：扩大缓存空间、优化批处理策略、真正能命中的复用机制、匹配 dtype 的后端选择，以及 memory stall 时的 draft model 加持。

如果只改两个配置，建议试试 FP8 KV（硬件支持的话）和 chunked prefill。测一下数据然后再叠加 prefix 标准化和 speculative decoding。tokens/sec 和延迟曲线会直接告诉你效果。

https://avoid.overfit.cn/post/321dd7c3c76444b59e97137c23ff6965

作者：Nexumo