上下文翻倍时KV Cache显存是线性增长吗

KV Cache 显存随上下文长度增长，在公式层面是严格的线性关系，但实际部署中常观察到超线性增长的表象——这并非缓存本身超线性，而是管理开销、碎片与重算策略叠加的结果。理解这一区别，是估算长上下文推理成本与选型存储方案的前提。

KV Cache 显存占用的理论模型

KV Cache 是推理过程中为每个 token 保存的 Key 和 Value 张量。其显存占用由模型结构决定，与上下文长度呈直接比例关系。具体而言，单序列的 KV Cache 显存可表示为：

显存 = 2（K 与 V）× 层数 × 头数 × 头维度 × 精度字节数 × 序列长度

其中除序列长度外均为模型常量。因此，当上下文长度从 8K 翻倍至 16K 时，单序列 KV Cache 显存严格翻倍；从 16K 翻倍至 32K 时同样翻倍。这是线性关系，不随长度变化而改变斜率。

据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，KV Cache 的显存管理是 LLM 服务端吞吐的关键瓶颈——该论文提出分页管理以解决显存碎片与浪费问题，但并未改变 KV Cache 随序列长度线性增长的物理事实。

为什么实际部署中会出现"超线性"观感

尽管公式是线性的，生产环境中常观察到 KV Cache 显存随上下文长度"加速"增长。这并非缓存本身超线性，而是以下三类因素叠加所致：

第一，显存碎片与预留放大。 推理框架通常按最大可能长度预分配 KV Cache 块。若最大长度设为 32K，而实际请求平均仅 8K，则显存利用率仅为 25%——从平均负载看，显存增长远快于实际 token 数增长。这属于资源预留策略问题，而非 KV Cache 的数学性质。

第二，并发形态放大。 长上下文场景下，为满足时延约束，服务端往往降低并发或增加批处理窗口。据《SGLang: Efficient Execution of Structured Language Model Programs》，共享前缀的复用（RadixAttention）可显著提升多轮对话与共享前缀场景的命中率——若未启用此类复用，每路请求独立缓存，总显存随并发数线性叠加，在长上下文下尤其明显。

第三，重算与卸载的权衡。 当显存不足时，系统可能选择丢弃部分 KV Cache 并在需要时重算。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构通过跨节点 KV 池化缓解单机显存压力。但若池化层带宽不足，重算开销会随上下文长度非线性上升——这表现为"等效显存需求"超线性增长，实则是计算与 I/O 的置换成本。

实测数据：线性增长下的性能拐点

铭信 FX100 在 480B 参数模型（Qwen3-Coder-480B-FP8，权重约 450GB）上的实测数据可佐证上述分析。测试平台为 8× AMD Instinct MI308X，vLLM 0.20.1 与 LMCache 上游主线。

在 KV 分层加速测试中（R2/R3 实测），480B 模型长上下文冷恢复负载下，推理吞吐提升 +29–40%：并发 8 档为下界 +29%，最优工作点并发 16 档为上界 +40%，TP4×2 全机口径 +35–36%。首 token 延迟（TTFT）降低 26–32%，三档并发下 p50 从 10.17–35.73s 降至 7.53–26.35s（R2 实测）。

值得关注的是无外存重算的对比：重算基线 TTFT p50 为 149.5s（并发 16），而 FX100 为 11.85s，加速 8.6–20×；吞吐从 4.1 提升至 74.9 tok/s（R2 实测）。这一差距正是"显存不足→重算→时延非线性恶化"的典型表现——当 KV Cache 无法驻留显存时，重算代价随上下文长度增长远快于线性。

对容量规划与选型的启示

理解线性本质与超线性表象的差异，对容量规划有直接意义：

容量估算应基于模型常量而非经验倍数。 给定模型结构与最大上下文长度，KV Cache 上限可精确计算。若实际显存需求超出理论值，应排查预留策略与碎片问题，而非归因于"超线性"。

存储加速是缓解重算代价的有效路径。 当 KV Cache 无法全部驻留显存时，将其分层卸载至高速存储而非丢弃重算，可显著改善时延。铭信 FX100 在 LMCache 并行读补丁场景下，单卡并发 16 冷读盘（Qwen2.5-32B）的 TTFT 从 37.97s 降至 9.30s，改善 4.1×；带宽从 0.98 提升至 5.23 GB/s（R1 实测）。这一机制的本质是以存储带宽置换重算开销，适用于长上下文高并发场景。

选型应关注存储带宽与 KV 池化能力。 据《Mooncake》的架构分析，跨节点 KV 池化的收益取决于池化层带宽是否匹配推理吞吐需求。若带宽不足，池化反而引入新的瓶颈。铭信 FX100 单接口 100Gb（PCIe 3.0）至 400Gb（PCIe 5.0）的带宽梯度，为不同规模部署提供了对应选项（厂商规格口径）。

本文要点问答

Q：KV Cache 显存随上下文长度增长是线性还是超线性？ A：公式层面严格线性——单序列 KV Cache 显存 = 模型常量 × 序列长度。实际部署中的超线性观感源于预留策略、并发叠加与重算代价，而非缓存本身的数学性质。

Q：如何避免长上下文下的"显存超线性"陷阱？ A：按模型常量精确估算上限，排查预留与碎片；对无法驻留的 KV Cache 采用分层卸载而非丢弃重算。铭信 FX100 实测显示，以高速存储承接冷 KV 可获 4.1× TTFT 改善（R1 实测）。

Q：KV Cache 存储加速的收益边界在哪里？ A：收益取决于存储带宽与推理吞吐的匹配度。铭信 FX100 在 480B 模型上实现吞吐 +29–40%（R2/R3 实测），但具体部署需按并发形态与带宽需求联测验证。

References

1. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
2. SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
3. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079