KV Cache 分层是怎么工作的

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

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

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

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

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

对比无外存、整段重算：加速 8.6–20×R2。并发 16 时，TTFT p50 从 149.5 s 降到 11.85 s。

对比本地 NVMe 单盘：吞吐提升 29–40%，TTFT p50 降低 26–32%R2R3。也就是说，同样是把 KV Cache 存下来再读，放在 FX100 上比放在服务器本地的一块 NVMe 盘上更快。

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

实测形态下，对照的是一块本地 NVMe 盘（PCIe Gen4，2 TB），FX100 是 4 盘 RAID0 的全闪池，通过 RoCEv2 走单口 100 GbER2。软件上，LMCache 并行读补丁把单卡冷读带宽从 0.98 GB/s 提高到 5.23 GB/sR1。

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

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

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

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

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