# KV Cache 分层的工作原理：显存、内存与外置全闪

> KV Cache 被挤出显存后，是整段重算还是从外置全闪读回？按一次请求的路径说明 KV Cache 分层为什么能降低 TTFT，以及它在哪些场景没用。

网页地址: https://vuke.top/tech · 更新于 2026 年 11 月 12 日

一句话：把溢出显存的 KV Cache 存下来，下次直接读，不再重算。下面沿着一次请求的路径，说明它为什么有效、在哪里有效、在哪里没用。

## 问题：显存装不下所有会话

大模型每处理一个 token，都会在各注意力层留下一份 Key / Value 张量，这就是 KV Cache。有了它，生成下一个 token 时不必重新计算前面的上下文。上下文越长，这份缓存越大。

显存是有限的。本站测试平台的每张 AMD MI308X 有 192 GB HBM，除了放模型权重，还要放所有活跃会话的 KV Cache。会话一多，较早的缓存就被逐出。

被逐出的会话再发来请求时，模型只能把整段上下文重新预填充一遍。在 480B 模型、并发 16 的实测里，这样一次整段重算的首 token 延迟 p50 是 149.5 s [R2](https://vuke.top/evidence/R2)。

## 三层存放：显存、主机内存、外置全闪

KV Cache 分层按访问热度把缓存放在三种介质上。前两层由推理框架管理，第三层需要单独的存储设备，FX 系列做的就是这一层。

- 第一层，显存：放当前活跃的会话，三层里访问延迟最低，容量也最小。
- 第二层，主机内存：放近期用过的会话，由 LMCache 管理。
- 第三层，外置全闪：放全部历史会话，并让多个推理实例共享同一份缓存。

## 一次请求怎么走

命中一次外置缓存，就省掉一次完整的预填充。这是首 token 延迟下降的全部原因。

- 请求到达，LMCache 按输入 token 的前缀查找已有的 KV Cache。
- 显存里有，直接使用。
- 显存里没有，依次查主机内存和外置全闪；命中后把 KV Cache 读回显存，跳过这部分预填充。
- 各层都没有，才由 GPU 计算，并把新生成的 KV Cache 写入各层，供以后使用。

## 实测：读回比重算快多少

测试对象是 Qwen3-Coder-480B-FP8，以八卡单实例（TP=8）的生产形态部署在 8 × AMD MI308X 上，负载是长上下文冷恢复。有两个对照基线，分母不同，不能混在一句话里说。

对比无外存、整段重算：加速 8.6–20× [R2](https://vuke.top/evidence/R2)。并发 16 时，TTFT p50 从 149.5 s 降到 11.85 s。

对比本地 NVMe 单盘：吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。也就是说，同样是把 KV Cache 存下来再读，放在 FX100 上比放在服务器本地的一块 NVMe 盘上更快。

## 为什么网络上的阵列比本地盘还快

直觉上，本地盘离 GPU 更近，应该更快。但决定首 token 延迟的不是协议多出来的那一点时延，而是并发回读时能不能把数据足够快地送回显存。

实测形态下，对照的是一块本地 NVMe 盘（PCIe Gen4，2 TB），FX100 是 4 盘 RAID0 的全闪池，通过 RoCEv2 走单口 100 GbE [R2](https://vuke.top/evidence/R2)。软件上，LMCache 并行读补丁把单卡冷读带宽从 0.98 GB/s 提高到 5.23 GB/s [R1](https://vuke.top/evidence/R1)。

外置池还有一件本地盘做不到的事：多个推理实例共享同一份缓存。fs:// 共享池的跨实例热共享已经验证通过 [R3](https://vuke.top/evidence/R3)。

## 边界：什么时候没用

收益来自缓存命中。短对话、低并发的场景里，会话很少被逐出，也很少回来，命中率低，这层存储的收益就有限。

长上下文、多轮对话、Agent 和代码助手这类负载，会话恢复频繁，收益最明显。你的负载属于哪一种，要用自己的会话长度分布和并发量测过才知道。这也是我们坚持先联测、后采购的原因。

## 软件栈与复现材料

接入不需要重写推理引擎，用的是开源的 vLLM + LMCache 组合。实测使用的版本是 ROCm 7.2、vLLM 0.20.1+rocm721，LMCache 由上游主线 2026-06-29 的源码编译 [R2](https://vuke.top/evidence/R2)。

我们写的 LMCache 并行读补丁，连同负载客户端、编排脚本、探针取证脚本和原始数据，一起打包为 R8，第三方可以在自己的集群上重跑 [R8](https://vuke.top/evidence/R8)。

## 原始读数

| 并发 | FX100 TTFT p50 (s) | 本地 NVMe 单盘 TTFT p50 (s) | 整段重算 TTFT p50 (s) | FX100 tok/s | 本地 NVMe 单盘 tok/s | 整段重算 tok/s |
| --- | --- | --- | --- | --- | --- | --- |
| 8 | 7.53 | 10.17 | — | 56.6 | 43.9 | — |
| 16 | 11.85 | 17.31 | 149.48 | 74.9 | 53.6 | 4.1 |
| 32 | 26.35 | 35.73 | — | 71.6 | 53.9 | — |

Qwen3-Coder-480B-FP8 · TP=8 · 8 × MI308X · 长上下文冷恢复负载。TTFT 为 p50，单位秒；吞吐单位 tok/s；整段重算只测了并发 16 一档。 出处: [R2](https://vuke.top/evidence/R2)

## 外部参考资料

- [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机
- [Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving](https://arxiv.org/abs/2407.00079) · arXiv. 以 KV Cache 为中心的存算分离架构，以及跨节点复用 KV Cache 的设计取舍
- [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明
- [vLLM Documentation](https://docs.vllm.ai/) · vLLM Project. vLLM 的部署方式、前缀缓存与张量并行等配置的官方说明
- [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. NVMe 与 NVMe over Fabrics 的官方规范
- [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. RDMA 协议的规范定义