一个参数让128K上下文塞进4090：FP8 KV缓存量化实战

为什么KV缓存才是长上下文的真正瓶颈

很多人以为7B模型能在24GB显卡上跑起来就万事大吉，直到打开128K上下文窗口才发现显存直接爆掉。据开发者社区的计算，Llama 3.1 8B在FP16权重下约16GB，加上2GB运行时开销，32K上下文时KV缓存占4GB、总计约22GB还算宽裕；但到了64K，缓存翻倍到8GB、总计26GB已经越过4090的24GB红线；128K时缓存高达16GB、总计约34GB，彻底无缘单卡。

问题的本质在于：权重是固定的，KV缓存却随上下文线性增长。所以与其折腾权重精度，不如直接对缓存下手——这也是成本最低的一步。

rss source: Your 128K Context Fits on a 4090 — If You Quantize the KV Cache

KV缓存是Transformer自回归推理时保存历史token的Key和Value张量的机制。生成每个新token时，模型需要关注之前所有token的Key和Value，缓存它们避免重复计算，从而将推理复杂度从O(n²)降至O(n)。但缓存大小与上下文长度、层数、注意力头数、头维度成正比：对于Llama 3.1 8B（32层、32头、头维度128），每个token的KV缓存约占0.5MB（FP16），32K上下文即约16GB？实际计算：2（K和V）×32层×32头×128维×2字节=512KB/token，32K约16GB，与文中4GB不符，说明文中可能按GQA（分组查询注意力）计算，Llama 3.1 8B使用GQA，KV头数为8，则每token缓存为2×32×8×128×2=128KB，32K约4GB，吻合。

一个命令行参数，缓存直接减半

在vLLM里，只需要加上--kv-cache-dtype fp8，权重保持FP16/BF16不动，KV缓存从每个值2字节压缩到1字节。据vLLM官方文档，fp8对应E4M3格式，并提供三种校准方式：不校准（缩放因子默认1.0）、随机token预热、以及通过llm-compressor做数据集校准（追求最高精度时推荐）。

效果立竿见影：64K上下文下，FP16缓存的8GB降到4GB，总显存约22GB，刚好塞进4090。原本需要80GB显卡、每小时1.5美元以上的7B/64K工作负载，现在一张24GB的4090、每小时约0.35美元就能跑，成本降到约四分之一——代价只是一个CLI参数。

FP8为什么特别适合KV缓存

权重量化抢走了大部分注意力，但KV值其实是更容易处理的目标：在单个注意力头内部，数值分布集中在一个狭窄、行为良好的区间里。E4M3的窄动态范围加3位尾数恰好匹配这种分布；而E5M2虽然动态范围更宽，但对KV缓存来说大部分范围根本用不上，2位尾数反而会明显劣化注意力分数，并且这种误差会随层数累积放大。

换句话说，格式选择本身就是个技术决策：默认应该用fp8（即E4M3），而不是fp8_e5m2。这是一个容易被忽略但影响深远的细节。

数学不会说谎：128K仍然不够

需要诚实地说：单靠FP8缓存，Llama 3.1 8B在24GB卡上依然跑不了128K。8GB缓存加上16GB权重和2GB开销，总计约26GB，还是超。

出路有两条：一是叠加FP8权重，8+8+2约18GB，轻松装下；二是换用GQA更激进的架构，比如Qwen2.5 7B在128K下FP16缓存只要约7GB，FP8后约3.5GB，总计约19GB。这个参数很强，但不是魔法，算术规则依然统治一切。

上下文	FP16缓存总显存	FP8缓存总显存
32K	4GB → 约22GB ✅	2GB → 约20GB ✅
64K	8GB → 约26GB ❌	4GB → 约22GB ✅ 适配4090
128K	16GB → 约34GB ❌	8GB → 约26GB ❌ 仍超

上线前的三个注意事项

硬件支持差异：最大的收益出现在原生支持FP8的Hopper架构GPU上。老卡上内存节省是真实的，但需要确认所用vLLM版本的kernel支持情况，计算路径未必同样优化。

精度校准不能省：默认缩放因子1.0适合起步，但生产环境建议走llm-compressor的数据集校准。如果要做比per-tensor更细的per-head量化，还需要FlashAttention后端配合校准流程。

评测检索能力而非困惑度：标准基准上的精度下降通常很小，但精确召回类长上下文任务（如大海捞针式的文档问答）会最先暴露问题。上线前后务必跑自己的评测集对比。

实践中的取舍逻辑

这套方案的真正价值在于把人留在便宜卡上。量化缓存不是孤立技巧，而是与模型架构选择、权重精度形成组合拳：64K以内单靠FP8缓存就够了；128K需要FP8缓存加FP8权重，或者直接换GQA架构更友好的模型。

作者还做了一个免费的GPU Advisor工具，输入模型大小、上下文长度和量化容忍度就能推荐最便宜的可运行配置。不过对大多数团队来说，先在自己的负载上验证FP8 KV缓存的精度表现，可能比任何推荐工具都更有说服力。

背景补充

FP8 E4M3是一种8位浮点格式，包含1位符号、4位指数和3位尾数，动态范围约±448，精度约2位十进制有效数字。相比FP16（5位指数、10位尾数），E4M3牺牲了动态范围和精度，但更适合数值分布集中的场景。在KV缓存中，每个注意力头内的Key和Value值通常在一个较窄的范围内波动，E4M3的窄动态范围恰好覆盖，而3位尾数能保留足够精度。E5M2则具有5位指数和2位尾数，动态范围更宽（可表示极大极小值），但尾数精度更低，导致注意力分数计算误差更大，且误差会随层数累积。因此vLLM默认推荐fp8（E4M3）而非fp8_e5m2。

llm-compressor是vLLM生态中的模型量化工具库，支持对权重和激活进行FP8、INT8等量化，并提供基于数据集的校准流程。校准过程通过输入代表性数据（如领域文本），统计张量的动态范围，计算最优缩放因子（scale），以最小化量化误差。对于KV缓存，校准可以针对Key和Value分别进行，甚至细化到每个注意力头（per-head），但需要FlashAttention后端支持相应的量化kernel。不校准（缩放因子1.0）在多数情况下可行，但若数据分布偏移较大，可能导致溢出或精度损失。