KV Cache 分层加速方案

KV Cache 分层加速，是把推理时算出的 KV 缓存从显存扩展到外部全闪存储，用户回到旧会话时直接读回而不是重算。实测吞吐提升 29% 到 40%（R2/R3）。

更新于 2026-11-12 · 芯元一（天津）半导体设备有限公司

它解决的是什么问题？

它解决长上下文会话的冷恢复：显存放不下的 KV 缓存被淘汰后，同一个会话再来请求，模型要把整段历史重算一遍，用户看到的是首字迟迟不出来。

R2 测了三种做法。并发 16 档，现场重算的首 token 延迟中位数是 149.48 秒、吞吐 4.1 tok/s；缓存放本地 NVMe 单盘是 17.31 秒、53.6 tok/s；放 FX100 是 11.85 秒、74.9 tok/s。

出处：R2。并发 16 档另测了不用外存现场重算：首 token p50 为 149.48 秒，吞吐 4.1 tok/s。吞吐提升一列按表内读数换算。
并发	FX100 首 token p50	本地盘首 token p50	FX100 吞吐	本地盘吞吐	吞吐提升
8	7.53 秒	10.17 秒	56.6 tok/s	43.9 tok/s	+29%
16	11.85 秒	17.31 秒	74.9 tok/s	53.6 tok/s	+40%
32	26.35 秒	35.73 秒	71.6 tok/s	53.9 tok/s	+33%

■ FX100　■ 本地 NVMe 单盘　· 首 token 延迟中位数（越短越好）（秒）· 出处 R2

方案有三部分：FX 系列全闪 NVMe-oF 阵列做缓存的外部存储层，vLLM 加 LMCache 做推理和缓存管理，再加芯元一为 LMCache 写的并行读补丁，把读回速度提上去。

并行读补丁单独测过：单卡、并发 16、冷读盘的场景下，首 token 延迟从 37.97 秒降到 9.30 秒，读盘带宽从 0.98 GB/s 提到 5.23 GB/s（R1）。补丁以 git patch 的形式随 R8 复现包提供。

多实例部署时，各实例通过 fs:// 共享池读写同一份缓存，一个实例算过的前缀，另一个实例可以直接用。R3 在四卡双实例上验证了这一点，整机吞吐提升 35% 到 36%。

上下文长、会话会中断再回来的业务收益明显：代码助手、Agent、长文档问答、多轮客服。同一前缀的第二次请求，首字延迟从 29.15 秒降到 0.37 秒（R2/R3）。

短上下文、一问一答、几乎没有重复前缀的业务，从这个方案里得到的收益有限。是否适用，联测的第一步就能看出来。

标准做法是约 10 周的四道门禁联测。第 7 周的主门禁要求首 token 延迟降幅不低于 25%，不达标即停止。存储投入约占 GPU 投入的一成以内（联测口径）。

「一成以内」是联测口径，不是报价承诺。FX100 满配整机参考价 ¥371,200，按每台服务 8 个 GPU 节点配比。流程细节见四道门禁的联测流程。

想用自己的模型和负载验证这些数字？从一次联测开始，不达标就停。

可以，R2 的对照基线就是本地 NVMe 单盘。但本地盘只归一台机器用，容量小，其他节点读不到。同一负载下 FX100 比它吞吐高 29% 到 40%，首 token 延迟低 26% 到 32%。

一般不需要改模型和业务代码。改动在推理服务这一层：用带 LMCache 的 vLLM 部署，把缓存后端指向 FX 存储。并行读补丁以 git patch 提供，改了什么都能逐行看到。

不是。主要实测在 8 卡 MI308X 上完成，另外在华为昇腾 910B 上测过模型加载（R9），在沐曦 N260 上做过显存效益论证（R5）。不同平台的数字不能混着引用。