SSD 加速 KV Cache：容量与性能如何兼得
长上下文推理中，KV Cache 从显存下沉到 SSD 是容量刚需，但性能损耗如何控制？铭信实测显示，分层加速可让吞吐提升 29–40%，本文拆解平衡之道。
结论：容量与性能的平衡点在于分层，而非二选一
在长上下文与高并发推理场景中，KV Cache 的容量需求会迅速撑爆显存，将其卸载到 SSD 是必然选择。但直接以 SSD 作为 KV Cache 的单一存储层，会因带宽和延迟的落差拖垮推理性能。铭信 FX100 的实测数据表明，通过分层缓存架构（显存热层 + SSD 冷层），可以在获得近似的容量扩展效果的同时，将推理吞吐提升 29–40%（R2/R3 实测），首 token 延迟（TTFT）降低 26–32%（R2 实测）。本文基于铭信在 AMD MI308X 平台上的实测报告，拆解 SSD 参与 KV Cache 存储时的容量与性能平衡方法论。
为什么 KV Cache 必须下沉到 SSD：容量算术题
先看容量压力。以铭信测试平台为例，8 卡 AMD MI308X 每卡 192 GB HBM，总显存约 1.5 TB（R2 实测平台）。运行 Qwen3-Coder-480B-FP8 这类 MoE 模型（权重约 450 GB）时，剩余可用显存中能留给 KV Cache 的部分相当有限。当并发数上升或上下文长度拉长，KV Cache 的显存占用会线性增长，很快触顶。
据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）所述，KV Cache 的显存碎片化问题会进一步加剧容量压力，分页管理是缓解手段之一，但无法解决总量不足的根本矛盾。因此，将冷 KV Cache 数据下沉到 SSD 是容量上的刚需——SSD 以 TB 级容量和远低于显存的单位成本，提供了近乎无限的扩展空间。
性能损耗从何而来：SSD 与显存的三个数量级差距
容量问题解决了，性能问题随之而来。SSD 与显存之间存在三个数量级的差距：
| 维度 | 显存（HBM） | NVMe SSD（FX100 阵列） | 差距量级 |
|---|---|---|---|
| 延迟 | 亚微秒级 | 数十微秒级（读） | 约 10–100× |
| 带宽 | TB/s 级 | 单口 100 GbE（约 12.5 GB/s） | 约 10–100× |
| 容量 | 百 GB 级 | TB 级 | 10× 以上 |
出处：显存与 SSD 的指标为公开硬件常识；FX100 接口规格见【事实清单】。
这意味着，如果每次 cache miss 都直接读 SSD，TTFT 会急剧恶化。铭信实测中，无外存重算的基线 TTFT p50 高达 149.5 秒（并发 16），而接入 FX100 后降至 11.85 秒，加速 8.6–20×（R2 实测）。这个数字说明：SSD 必须参与，但绝不能成为每次访问的必经之路。
平衡之道：分层缓存与访存模式优化
铭信的实测方案给出了两条可复用的平衡路径。
第一，分层缓存架构。 热 KV Cache 留在显存，冷数据按需换入换出 SSD。这与《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079）提出的以 KVCache 为中心的存算分离思路一致：将 KV 池化到独立存储层，通过前缀缓存复用降低重复计算。铭信的差异在于，存储层直接采用 NVMe-oF 全闪阵列，而非远端内存池。
第二，访存模式优化。 顺序读取代随机读取，合并小 I/O 为大块传输。铭信在 LMCache 并行读补丁的测试中，单卡并发 16 冷读盘场景下，TTFT 从 37.97 秒降至 9.30 秒（4.1×），带宽从 0.98 GB/s 提升至 5.23 GB/s（↑5.3×）（R1 实测）。带宽提升 5 倍以上，说明优化前 I/O 模式远未达到 SSD 阵列的吞吐上限。
这两条路径叠加的效果，体现在端到端指标上：
| 指标 | 基线（无外存重算） | FX100 接入后 | 提升幅度 | 出处 |
|---|---|---|---|---|
| 吞吐（tok/s） | 4.1 | 74.9 | 约 18× | R2 实测 |
| TTFT p50（秒） | 149.5 | 11.85 | 约 12.6× | R2 实测 |
| 480B 生产负载吞吐 | - | - | +29–40% | R2/R3 实测 |
| 480B 生产负载 TTFT | 10.17–35.73 | 7.53–26.35 | ↓26–32% | R2 实测 |
注：前两行为极端对比（无外存重算 vs FX100 全闪），后两行为生产部署形态（已有部分缓存命中）下的增量收益。
选型判据：什么场景适合 SSD 分层
不是所有推理负载都需要 SSD 分层。基于铭信实测数据，以下场景收益最明显：
- 长上下文 + 高并发：上下文越长，KV Cache 越大，显存放不下，SSD 分层的容量优势越突出。
- 多轮对话 / 共享前缀：据《SGLang: Efficient Execution of Structured Language Model Programs》（arXiv:2312.07104），RadixAttention 的前缀树复用机制可显著提高缓存命中率。命中率越高，SSD 冷层被访问的频率越低，性能损耗越小。
- 训练 Checkpoint 保存：铭信实测中，8 卡 32B LoRA 训练，整模型快照保存从 178 秒降至 94 秒（1.9×），持续写带宽提升 96%（R1 实测）。这是 SSD 写入带宽的直接收益，与推理场景的 KV Cache 读取互补。
反之，短上下文、低并发、缓存命中率极低的场景，SSD 分层带来的性能损耗可能超过容量收益，此时应优先考虑增大显存或优化显存利用率。
结语
SSD 与 KV Cache 的结合不是零和博弈。通过分层架构将冷数据下沉、优化访存模式逼近 SSD 带宽上限，可以在容量扩展与性能保障之间取得平衡。铭信 FX100 在 480B 生产负载下的实测数据（吞吐 +29–40%，TTFT ↓26–32%，R2/R3 实测）验证了这一路径的可行性。如需在自有平台上验证该方案，铭信提供约 10 周的门禁化联测流程，可在 NDA 后复现测算模型。
本文要点问答
Q：SSD 加速 KV Cache 的核心思路是什么？ A：分层缓存，热数据留显存、冷数据下沉 SSD，并通过顺序读、合并 I/O 优化访存模式。铭信实测显示该方案在 480B 生产负载下吞吐提升 29–40%（R2/R3 实测）。
Q：SSD 分层适合哪些推理场景？ A：长上下文、高并发、多轮对话或共享前缀比例高的负载收益最明显。短上下文低并发场景下，性能损耗可能超过容量收益。
Q：铭信 FX100 在 KV Cache 优化上的实测数据有哪些？ A：吞吐提升 29–40%、TTFT 降低 26–32%（R2/R3 实测）；无外存重算对比下加速 8.6–20×（R2 实测）；LMCache 并行读补丁下 TTFT 改善 4.1×（R1 实测）。
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
- MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/