KV Cache 预取能把首 token 延迟和推理吞吐优化到什么程度？

KV Cache 预取是当前削减大模型推理存储延迟的有效工程手段。铭信 FX100 在 480B 生产级长上下文负载下的实测显示，分层预取策略可将推理吞吐提升 29–40%，首 token 延迟（TTFT）降低 26–32%（R2/R3 实测）。其核心机制是将存储延迟从推理关键路径上剥离，使计算单元无需等待数据就位。以下从瓶颈成因、预取机制、方案对比与落地形态展开说明。

为什么 KV Cache 的存储延迟会成为推理瓶颈？

随着上下文窗口从 32K 扩展至 128K 以上，KV Cache 容量需求线性增长，而 GPU 显存扩容速度远跟不上。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）分析，分页管理解决的是显存碎片问题，但 KV Cache 超出显存容量后仍需外溢至存储层。铭信 R2 实测平台为 8× AMD Instinct MI308X（每卡 192 GB HBM），模型为 Qwen3-Coder-480B-FP8（权重约 450 GB），在 TP8 长上下文形态下，显存需同时承载权重与 KV Cache，外溢不可避免。存储层延迟（NVMe 数十微秒级）相比 HBM（数百纳秒级）高出两个数量级，直接进入推理路径。

KV Cache 预取具体如何降低 TTFT 和提升吞吐？

预取的核心是在计算单元需要某块 KV Cache 之前，提前从存储层读入高速缓存，关键在于选择策略与时机策略。铭信 FX100 的实测数据量化了其收益边界：在 R2 测试中，480B 模型 TP8 三档并发下，TTFT p50 从 10.17–35.73s 降至 7.53–26.35s，降幅 26–32%（R2 实测）。机制在于推理引擎生成首个 token 前需加载完整 KV Cache 前缀，提前预取至本地高速层可显著压缩等待时间。吞吐方面，R3 测试显示 TP4×2 全机口径提升 35–36%（R3 实测），并发 8 档保守场景为 29%（R2 实测），最优工作点并发 16 档达 40%（R2/R3 实测）。这一区间差异表明预取收益对并发度敏感：并发越高，多请求的 KV Cache 复用机会越多。

预取相比“无外存重算”方案，加速倍数从何而来？

替代方案“无外存重算”避免存储延迟但引入重复计算开销。铭信 R2 实测对比显示：无外存重算基线 TTFT p50 为 149.5s（并发 16），FX100 预取方案仅 11.85s，加速 12.6 倍；吞吐从 4.1 tok/s 提升至 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 为中心的存算分离架构正是基于此判断，铭信实测为其提供了量化支撑。存储侧通路优化同样关键，据 NVIDIA GPUDirect Storage 文档，GPU 直连存储可绕过 CPU bounce buffer 缩短数据通路。R1 测试中，FX100 的 NVMe-oF 阵列配合 LMCache 并行读补丁，将单卡并发 16 冷读盘 TTFT 从 37.97s 降至 9.30s，带宽从 0.98 GB/s 提升至 5.23 GB/s（R1 实测），4.1 倍 TTFT 改善与 5.3 倍带宽提升表明通路优化与预取策略互补。

预取策略在集群与跨平台场景下如何落地？

预取落地不止于单机。R9 测试在华为 Atlas 910B 平台对比 FX100 与 NFS 基线的模型加载性能：DeepSeek-32B 服务加载从 691s 降至 112s（6.2 倍），DeepSeek-70B 从 1399s 降至 150s（9.3 倍）（R9 实测），说明预取在昇腾平台同样有效，且加速效果与模型规模正相关。集群层面，据《SGLang: Efficient Execution of Structured Language Model Programs》（arXiv:2312.07104），RadixAttention 的前缀树复用机制通过共享前缀提升多轮对话命中率，与预取策略天然互补：前缀树识别可复用的 KV Cache，预取确保这些数据在需要时就位。

本文要点问答

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