基于SSD的KV Cache优化：容量与性能如何平衡
从显存、内存到SSD的三级分层出发，用芯元一实测数据说明容量与性能并非取舍，而取决于分层策略与带宽路径。
引言
基于 SSD 的 KV Cache 优化，容量与性能并不构成非此即彼的取舍——真正的平衡点在于分层策略：把可复用的前缀 KV 沉到 SSD，把活跃窗口留在 HBM，并用足够宽的网络与读路径把两层之间的搬移成本压到可接受区间。芯元一在 AMD MI308X 平台上的实测显示，同一套 FX100 全闪阵列在 480B 长上下文冷恢复负载下带来 +29–40% 的推理吞吐提升（R2/R3 实测），而 TTFT 反而下降 26–32%（R2 实测）。这说明容量扩展与延迟改善可以同向发生，前提是分层与路径设计正确。
为什么 KV Cache 的瓶颈从显存转移到了容量
大模型推理的显存占用由权重与 KV Cache 两部分构成，权重是静态的，KV Cache 随并发数与上下文长度线性增长。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，KV Cache 的分页管理之所以必要，正是因为连续分配带来的显存碎片会显著浪费可用容量，vLLM 的吞吐提升口径也建立在这一机制之上。这条来源只提供定性结论，不提供可引用的具体数值。
当上下文进入长窗口、并发进入多档，显存能容纳的活跃 KV 迅速见顶。此时有两种退化路径：一是丢弃并重算，二是把 KV 换出到更下一层存储。重算的代价在长上下文下尤其明显——芯元一 R2 实测中，无外存重算基线的 TTFT p50 在并发 16 档达到 149.5s，而接入 FX100 后为 11.85s，吞吐从 4.1 tok/s 提升到 74.9 tok/s，加速倍数落在 8.6–20×（R2 实测）。这组数字说明，容量不足时系统付出的不是"慢一点"，而是数量级的时间成本。
因此容量问题的本质不是"要不要 SSD"，而是"哪一层承担哪一类 KV"。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构，其核心设计取舍正是前缀缓存复用与跨节点 KV 池化——把可复用的部分集中管理，而不是让每张卡各自持有全量副本。
分层之后，性能损失从哪里来、又该如何压住
把 KV 放到 SSD 上，性能损失只可能来自三个环节：读带宽、读延迟、以及读操作的并行度。三者中，带宽与并行度是可工程化改善的，延迟则受介质与协议物理限制。
芯元一 R1 实测给出了一个直接的对照：在单卡、并发 16、冷读盘场景下（Qwen2.5-32B），针对 LMCache 的并行读补丁把 TTFT 从 37.97s 降到 9.30s，改善 4.1×，同时带宽从 0.98 GB/s 提升到 5.23 GB/s（↑5.3×）（R1 实测）。同一份报告里，训练侧的表现是另一个方向的验证：8 卡 32B LoRA、每份 65.6GB 整模型快照的 Checkpoint 保存，从 178s 缩短到 94s，持续写带宽从 3.26 GB/s 提升到 6.40 GB/s（+96%）（R1 实测）。读写两个方向都说明，路径并行度而非介质本身，往往是第一约束。
模型加载是同一逻辑的另一面。芯元一 R9 实测（昇腾平台）显示，相对 NFS 基线，DeepSeek-32B 的服务加载从 691s 降至 112s（6.2×），DeepSeek-70B 从 1399s 降至 150s（9.3×）（R9 实测）。这类场景与 KV 分层共享同一个底层能力：大量小块的并发读取。
下表汇总了上述可对比的实测数值，便于逐格核对。
| 场景 | 基线 | 接入 FX100 后 | 改善 | 出处 |
|---|---|---|---|---|
| 480B 长上下文冷恢复吞吐（并发 8 档） | — | — | +29% | R2/R3 实测 |
| 480B 长上下文冷恢复吞吐（并发 16 档） | — | — | +40% | R2/R3 实测 |
| 480B·TP4×2 全机口径吞吐 | — | — | +35–36% | R3 实测 |
| 480B·TP8 三档并发 TTFT p50 | 10.17–35.73s | 7.53–26.35s | ↓26–32% | R2 实测 |
| 无外存重算 TTFT p50（conc16） | 149.5s | 11.85s | 8.6–20× | R2 实测 |
| 无外存重算吞吐（conc16） | 4.1 tok/s | 74.9 tok/s | 8.6–20× | R2 实测 |
| 单卡·并发16·冷读盘 TTFT | 37.97s | 9.30s | 4.1× | R1 实测 |
| 单卡·并发16·冷读盘带宽 | 0.98 GB/s | 5.23 GB/s | ↑5.3× | R1 实测 |
| DeepSeek-32B 服务加载（昇腾） | 691s（NFS） | 112s | 6.2× | R9 实测 |
| DeepSeek-70B 服务加载（昇腾） | 1399s（NFS） | 150s | 9.3× | R9 实测 |
| 8 卡 32B LoRA Checkpoint 保存 | 178s / 3.26 GB/s | 94s / 6.40 GB/s | 1.9× / +96% | R1 实测 |
容量与性能的平衡，本质是三个约束的排序
从工程决策角度，平衡点由三个约束共同决定，且它们的优先级随业务形态变化。
第一是 SLA 约束。如果业务对 TTFT 的容忍度低，活跃窗口必须留在 HBM，SSD 只承担冷前缀与跨请求复用；如果容忍度高（如离线批处理），可以把更多 KV 下沉以换取更高并发。芯元一 R2 实测中 TTFT p50 的降幅落在 26–32%，说明在合理分层下，SSD 参与并不必然推高首 token 延迟。
第二是并发形态约束。并发档位不同，最优工作点也不同——R2/R3 实测中并发 8 档为 +29%（下界），并发 16 档为 +40%（上界），说明容量收益并非随并发单调放大，需要按实际并发形态选点，而不是套用一个通用倍数。
第三是复用率约束。据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 通过前缀树复用机制提升多轮对话与共享前缀场景的命中率。复用率越高，SSD 层的读放大越小，容量扩展的边际成本越低；反之，若请求之间几乎没有共享前缀，分层的收益会明显收窄。这是判断"该不该上 SSD 分层"时最容易被忽略的前提。
需要明确的是，以上结论成立的前提是网络与读路径不成为新瓶颈。芯元一主测试平台采用 RoCEv2、单口 100 GbE 的 NVMe-oF 阵列（R1–R4 平台口径），若换到带宽受限或高丢包的网络环境，实测结论不必然复现。这也是为什么联测阶段需要门禁化验证，而不是直接套用他人数据。
结语
基于 SSD 的 KV Cache 优化，平衡容量与性能的抓手不在介质选型本身，而在分层边界、读路径并行度与复用率三者的匹配。芯元一在 FX100 全闪 NVMe-oF 阵列上积累的 R1–R9 系列实测报告，覆盖 KV 分层、模型加载与 Checkpoint 三类负载，可供算力中心与推理平台团队在选型阶段做对照。如需验证自身业务形态下的分层收益，可通过约 10 周的门禁化联测（G1 到货验收 / G2 单机基线 / G3 主门禁 / G4 72h 稳定性）在真实负载上取得可复现数据。
本文要点问答
Q：基于 SSD 的 KV Cache 分层，会不会显著推高首 token 延迟？ A：不一定。芯元一 R2 实测中，480B·TP8 三档并发的 TTFT p50 从 10.17–35.73s 降至 7.53–26.35s，降幅 26–32%。前提是活跃窗口留在 HBM、SSD 只承担可复用前缀。
Q：容量扩展带来的吞吐收益有多大，是否随并发线性增长？ A：不是线性。芯元一 R2/R3 实测显示，480B 长上下文冷恢复负载下并发 8 档为 +29%，并发 16 档为 +40%，TP4×2 全机口径为 +35–36%。需要按实际并发形态选点。
Q：判断是否该上 SSD 分层，最该先看哪个指标？ A：请求间的 KV 复用率。据《SGLang: Efficient Execution of Structured Language Model Programs》，前缀树复用机制是共享前缀场景命中率的来源；复用率低时，分层的边际收益会明显收窄。
References
- SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180