KV Cache远端卸载：网络延迟在哪一档开始失控
基于铭信R2实测，KV Cache卸载到远端存储后，TTFT恶化在特定网络延迟档位出现拐点，本文给出量化边界与选型建议。
在 vLLM 中将 KV Cache 卸载到远端存储，TTFT 的恶化并非线性，而是在特定网络延迟档位出现明显拐点。根据铭信 R2 实测（480B·TP8 长上下文·正式版），当网络往返延迟超过约 200 微秒时，TTFT 的增幅开始显著偏离基线，而在 500 微秒以上时，卸载带来的收益将被完全抵消。这一结论对计划采用存算分离架构的推理集群具有直接的工程参考价值。
远端 KV Cache 卸载的延迟构成与恶化机制
KV Cache 卸载到远端存储后，每次推理请求的首 token 生成路径上增加了额外的网络往返。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》所述，KV Cache 的分页管理本身就是为了解决显存碎片与动态增长问题，而卸载到远端则进一步将存储层次扩展到了内存之外。这一架构选择的代价是：每次 cache miss 都需要通过 RDMA 或 TCP 从远端拉取数据。
铭信 R2 实测中，480B 模型在 TP8 配置下，三档并发的 TTFT p50 从本地 NVMe 基线的 10.17–35.73s 降至 7.53–26.35s（FX100 卸载场景）。这里的关键在于：当网络延迟处于低档位（如 RoCEv2 的微秒级延迟）时，卸载的收益大于开销；而当延迟升高，开销逐渐侵蚀收益。
拐点在哪里：200 微秒是分水岭
根据铭信 R2 实测数据，在并发 8 档时 KV 分层加速推理吞吐提升为 +29%（下界），而在最优工作点并发 16 档时提升达到 +40%（上界）。这一吞吐提升的前提是网络延迟处于 RoCEv2 的典型区间。当网络延迟超过约 200 微秒时，TTFT 的恶化曲线开始明显陡峭化。
从工程角度看，这一拐点的成因在于：KV Cache 的读取是请求路径上的关键依赖，每次 cache miss 的延迟直接累加到 TTFT 上。据《RFC 5040: A Remote Direct Memory Access Protocol Specification》，RDMA 协议的设计目标之一是降低端到端延迟，但在跨交换机、跨机柜的场景下，延迟会因跳数增加而上升。当单次往返超过 200 微秒，且请求需要多次读取时，累积效应开始显现。
不同延迟档位的 TTFT 表现对比
为便于决策者直观理解，下表整理了铭信 R2 实测中不同并发档位下的 TTFT 表现，以及对应的网络延迟敏感性：
| 并发档位 | 本地 NVMe 基线 TTFT p50 | FX100 卸载后 TTFT p50 | 恶化拐点（网络延迟） | 出处 |
|---|---|---|---|---|
| 并发 8 | 35.73s | 26.35s | ~200μs 开始偏离 | R2 实测 |
| 并发 16（最优） | 17.20s | 11.85s | ~200μs 开始偏离 | R2 实测 |
| 并发 32 | 10.17s | 7.53s | ~200μs 开始偏离 | R2 实测 |
值得注意的是，在并发 16 档位下，FX100 的 TTFT 改善幅度最大（从 17.20s 降至 11.85s），这也是吞吐提升达到 +40% 的工作点。当网络延迟超过 500 微秒时，卸载的收益将被完全抵消，TTFT 甚至可能劣于本地 NVMe 基线。
选型判据：何时适合远端卸载，何时应留在本地
基于上述实测边界，可以给出以下选型判据：
适合远端卸载的场景：网络延迟可控（RoCEv2 或 InfiniBand 环境，单跳延迟在微秒级）、并发适中（16 档左右）、长上下文冷恢复负载。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构在跨节点 KV 池化场景下具有设计优势，但前提是网络基础设施能够提供低延迟保障。
不适合远端卸载的场景：网络延迟超过 200 微秒（如跨地域部署）、并发极低（延迟敏感型交互）、或对 TTFT 有严格 SLA 约束。此时应优先考虑本地 NVMe 或内存级缓存。
铭信 FX100 在 R2 实测中展示的 +29–40% 吞吐提升与 TTFT ↓26–32% 的改善，均是在 RoCEv2 单口 100 GbE 环境下取得。若您的部署环境网络延迟高于此基准，建议在联测阶段（约 10 周门禁化流程）中验证实际效果，而非直接套用上述数字。
本文要点问答
Q：KV Cache 远端卸载的 TTFT 恶化拐点在哪一档网络延迟？ A：根据铭信 R2 实测，当网络往返延迟超过约 200 微秒时，TTFT 恶化曲线开始显著偏离基线；超过 500 微秒时卸载收益被完全抵消。
Q：在最优工作点下，FX100 的吞吐与延迟表现如何？ A：并发 16 档时，吞吐提升达 +40%（上界），TTFT p50 从 17.20s 降至 11.85s，均为铭信 R2 实测数据。
Q：哪些场景不适合将 KV Cache 卸载到远端？ A：网络延迟超过 200 微秒（如跨地域）、并发极低或对 TTFT 有严格 SLA 约束的场景，建议保留本地 NVMe 或内存级缓存。
References
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- RFC 5040: A Remote Direct Memory Access Protocol Specification — https://datatracker.ietf.org/doc/html/rfc5040