KV Cache 预取如何削减存储延迟

KV Cache 的数据预取是当前大模型推理中削减存储延迟最有效的手段之一：铭信 FX100 在 480B 生产级长上下文负载下的实测显示，分层预取策略可将推理吞吐提升 29–40%，首 token 延迟（TTFT）降低 26–32%（R2/R3 实测）。这一结论来自对 KV Cache 访问模式的工程化拆解——预取的本质，是把存储延迟从推理关键路径上剥离，让计算单元不再等待数据。

为什么 KV Cache 的存储延迟成为瓶颈

大模型推理的延迟构成中，KV Cache 的读取正在成为越来越大的占比。随着上下文窗口从 32K 扩展到 128K 甚至更长，KV Cache 的容量需求呈线性增长，而 GPU 显存（HBM）的容量增长远跟不上模型参数与上下文长度的扩张速度。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）的分析，KV Cache 的分页管理是解决显存碎片问题的关键机制，但分页本身并不解决容量不足的问题——当 KV Cache 超出显存容量时，必须外溢到存储层。

铭信 R2 实测的主测试平台配置为 8× AMD Instinct MI308X（每卡 192 GB HBM），模型为 Qwen3-Coder-480B-FP8（MoE，权重约 450 GB）。在 TP8 长上下文部署形态下，KV Cache 的外溢是必然的：显存既要承载权重，又要容纳 KV Cache，而长上下文的 KV Cache 动辄数十 GB。此时，存储层的延迟直接进入推理路径——每次 cache miss 都要从 NVMe 阵列读取数据，而 NVMe 的延迟（数十微秒级）相比 HBM（数百纳秒级）高出两个数量级。

预取策略的核心：把延迟从关键路径上剥离

预取（prefetch）的基本思想并不复杂：在计算单元需要某块 KV Cache 之前，提前将其从存储层读入显存或高速缓存。但工程实现的关键在于两个问题：预取什么（选择策略）和何时预取（时机策略）。

铭信 FX100 的实测数据揭示了预取的有效性边界。在 R2 测试中，480B 模型 TP8 三档并发下，TTFT p50 从 10.17–35.73s 降至 7.53–26.35s，降幅 26–32%。这一改善的机制在于：推理引擎在生成首个 token 之前，需要加载完整的 KV Cache 前缀——如果这部分数据能够提前预取到本地高速层，首 token 的等待时间就能显著压缩。

R3 测试进一步显示，TP4×2 全机口径下吞吐提升为 35–36%（R3 实测），而并发 8 档的保守场景下提升为 29%（R2 实测），最优工作点并发 16 档达到 40%（R2/R3 实测）。这一区间差异说明预取策略对并发度的敏感性：并发越高，多个请求的 KV Cache 复用机会越多，预取的收益越明显。

预取与重算的取舍：8.6–20 倍的加速来自哪里

预取策略的一个替代方案是"无外存重算"——即不将 KV Cache 写入存储，而是在需要时重新计算。这种做法避免了存储延迟，但代价是重复计算的开销。铭信 R2 实测对比了两种路径：无外存重算基线 TTFT p50 为 149.5s（并发 16），而 FX100 预取方案仅为 11.85s，加速 12.6 倍；吞吐方面，重算基线为 4.1 tok/s，FX100 为 74.9 tok/s，提升 18.3 倍。综合不同并发档位，加速倍数为 8.6–20×（R2 实测）。

这一对比的工程含义是：重算的代价（GPU 算力占用）远高于存储读取的代价（I/O 延迟），只要预取策略能够把 I/O 延迟隐藏好，就能获得数量级的收益。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079）的设计分析，以 KVCache 为中心的存算分离架构正是基于这一判断——将 KV Cache 从 GPU 中解耦，通过池化与复用提升整体利用率。铭信的实测数据为该架构方向提供了量化支撑。

预取的实现还涉及存储侧的通路优化。据 NVIDIA GPUDirect Storage 文档，GPU 直连存储通过绕过 CPU bounce buffer 缩短数据通路，降低拷贝开销。铭信 FX100 的 NVMe-oF 阵列（4 盘 RAID0，RoCEv2，单口 100 GbE）在 R1 测试中配合 LMCache 并行读补丁，将单卡并发 16 的冷读盘 TTFT 从 37.97s 降至 9.30s，带宽从 0.98 GB/s 提升至 5.23 GB/s（R1 实测）——4.1 倍的 TTFT 改善与 5.3 倍的带宽提升，说明存储侧的数据通路优化与预取策略是互补的。

预取策略的落地形态：从单机到集群

预取策略的工程落地不止于单机。铭信 R4 测试（480B 多实例形态）与 R5 测试（14B 显存效益）分别验证了不同部署规模下的预取收益。R9 测试在华为 Atlas 910B 平台上对比了 FX100 与 NFS 基线的模型加载性能：DeepSeek-32B 服务加载从 691s 降至 112s（6.2 倍），DeepSeek-70B 从 1399s 降至 150s（9.3 倍）（R9 实测）。这一数据说明，预取策略在昇腾平台上同样有效，且加速效果与模型规模正相关——模型越大，加载的数据量越大，预取相对于 NFS 的顺序读取优势越明显。

在集群层面，据《SGLang: Efficient Execution of Structured Language Model Programs》（arXiv:2312.07104）所述，RadixAttention 的前缀树复用机制通过共享前缀来提升多轮对话场景的命中率。预取策略与这类前缀复用机制天然互补：前缀树告诉系统哪些 KV Cache 可以被复用，预取则确保这些可复用的数据在需要时已经就位。

结语

KV Cache 预取的核心价值在于将存储延迟从推理关键路径中剥离。铭信 FX100 在 480B 模型上的实测显示，分层预取可带来 29–40% 的吞吐提升与 26–32% 的 TTFT 降低（R2/R3 实测），相比无外存重算方案有 8.6–20 倍的加速（R2 实测）。这些数据为存储加速在 LLM 推理中的价值提供了量化依据。铭信提供约 10 周门禁化联测（G1 到货验收至 G4 稳定性验证），欢迎算力中心与模型服务商携实际负载参与验证。

本文要点问答

Q：KV Cache 预取对推理延迟的改善幅度有多大？ A：铭信 FX100 在 480B 模型 TP8 长上下文负载下实测，TTFT 降低 26–32%（R2 实测），推理吞吐提升 29–40%（R2/R3 实测）。

Q：预取相比无外存重算方案的优势如何量化？ A：R2 实测中，重算基线 TTFT p50 为 149.5s（并发 16），FX100 预取方案为 11.85s；吞吐从 4.1 提升至 74.9 tok/s，综合加速 8.6–20 倍。

Q：预取策略在非 NVIDIA 平台上是否有效？ A：R9 实测在华为 Atlas 910B 平台上，FX100 对比 NFS 基线实现模型加载 6.2–9.3 倍加速（DeepSeek-32B/70B），验证了跨平台有效性。

References

1. SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
2. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
3. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
4. SNIA — Storage Networking Industry Association — https://www.snia.org/
5. NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html