vLLM V1 功能表里，FP8 KV Cache 已经标为可用。它解决的是推理服务最头疼的问题：长上下文把 KV cache 撑爆 HBM，能同时服务的并发数被迫砍半。
FP8 KV 到底能省下多少显存？
KV cache 的大小约等于「层数 × 序列长度 × KV 头数 × 头维度 × 字节数」。BF16 下每个元素占 2 字节，压到 FP8 的 E4M3 格式后变成 1 字节，同等 HBM 能装下约两倍长的上下文或两倍并发。在 GB300 NVL72 这类靠 HBM 容量决定吞吐的机器上，这直接转化为每百万 token 的成本下降。
省显存的代价藏在哪里？
权重量化大家已经很熟，KV 量化的特殊之处在于：KV cache 里存的是历史注意力信息，一旦量化误差在长序列里逐步累积，模型对遥远位置的注意力会漂移，出现「长上下文末尾忘事」。所以 FP8 KV 不是免费午餐——短上下文几乎无感，超长上下文要专门评测召回质量。
什么场景该开 FP8 KV、什么场景不该？
上下文在 32K 以内、并发吃紧，大胆开 FP8 KV；上下文逼近 1M、且任务强依赖远距离检索，先拿你的真实请求集测一遍准确率，再决定是否回退 BF16。vLLM 里通过相关开关开启，灰度切流即可。
FP8 KV 在推理部署里排什么位置？
FP8 KV Cache 会和 prefix caching、PD 分离一起，成为 2026 年推理部署的标准三件套。容量换精度，是这笔账的本质。
怎么安全地灰度开启 FP8 KV？
不要一上来全量切 FP8 KV。正确做法是先开一小部分流量做对照：同样的请求，一半走 BF16 KV，一半走 FP8 KV，对比两类业务指标——生成文本的相关性，以及长文档问答里对遥远段落的召回。如果短文档任务几乎无差、长文档任务召回下降在可接受范围，再逐步放量。还要注意，FP8 KV 与 prefix caching、PD 分离叠用时，量化块的对齐方式会影响命中率，需要按官方文档确认参数组合。容量是省出来了，但别让看不见的精度漂移，悄悄吃掉你产品的体验。
另外，FP8 KV 与权重量化最好一起评估：如果权重已经压到 FP8 或 NVFP4，KV 再压到 FP8 是顺水推舟；如果权重仍用 BF16，单独压 KV 的收益要单独测算，避免两套精度混用带来意外波动。
去论坛讨论
这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：FP8-KV-Cache