KV Cache 网络架构：超大规模数据中心设计要点
超大规模数据中心 KV Cache 网络架构设计，需权衡吞吐、时延与成本。铭信 FX100 实测显示推理吞吐提升 29–40%。
超大规模数据中心中，KV Cache 的存储与访问正成为推理性能的关键瓶颈。网络架构设计需在吞吐、时延与成本之间取得平衡。铭信 FX100 在 480B 生产部署形态下，KV 分层加速推理吞吐提升 29–40%（R2/R3 实测），这为网络架构选择提供了量化参考。本文从网络平面划分、传输协议选型与存储部署三个维度展开。
为什么 KV Cache 需要专用网络平面？
KV Cache 的访问模式与训练数据流有本质区别。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）的分析，KV Cache 具有显存碎片化与动态增长的特征，这决定了它对网络的诉求是低时延随机读而非高带宽顺序写。在超大规模数据中心中，将 KV Cache 流量与训练流量混跑会互相干扰，因此设计上应划分独立网络平面。
铭信 R2 实测数据显示，在 480B·TP8 三档并发下，TTFT p50 从 10.17–35.73s 降至 7.53–26.35s，降幅 26–32%。这一结果的前提正是 KV Cache 访问路径上无网络拥塞竞争。若与训练流量共用网络，时延抖动会直接传导至推理 SLA。
网络平面的划分粒度需与扩展单元对齐。据《NVIDIA DGX SuperPOD - NVIDIA Docs》描述的参考架构，大规模 GPU 集群按计算/存储/网络分层组织，并以扩展单元为基本扩容单位。KV Cache 网络可参照这一分层思路，但具体平面数量与带宽配比需依据实际负载模型测算，DGX SuperPOD 文档并未定义 KV Cache 网络的特定设计。
传输协议：RDMA 还是 TCP？
KV Cache 网络的核心矛盾是：既要低时延（微秒级），又要高吞吐（数百 Gbps）。据《RFC 5040: A Remote Direct Memory Access Protocol Specification》，RDMA 协议定义了内核旁路与零拷贝语义，适合低时延场景。而据《RFC 9293: Transmission Control Protocol (TCP)》，TCP 提供可靠字节流但协议栈开销较大。
| 维度 | RDMA（RoCEv2） | TCP | 出处 |
|---|---|---|---|
| 时延特征 | 内核旁路，微秒级 | 协议栈处理，毫秒级 | RFC 5040 / RFC 9293 |
| 部署成本 | 需无损网络配置 | 标准以太网即可 | InfiniBand TA |
| 适用场景 | KV Cache 读路径 | 控制面与备份路径 | 铭信 R1 实测 |
铭信 R1 实测中，LMCache 并行读补丁在单卡·并发16·冷读盘（Qwen2.5-32B）下，TTFT 从 37.97s 降至 9.30s（4.1×），带宽从 0.98 提升至 5.23 GB/s（↑5.3×）。该测试基于 RoCEv2 网络，单口 100 GbE。这说明 RDMA 路径在冷读场景下的优势显著。
需要厘清的是，RoCEv2 并非由 InfiniBand 规范定义——据《InfiniBand Specification Frequently Asked Questions》，IBTA 负责 InfiniBand 规范，而 RoCE 的封装格式由 IBTA 与 IEEE 协作推进，两者标准归属不同。设计选型时应分别核对协议版本与交换机支持矩阵。
存储层如何与网络协同？
KV Cache 的存储介质选择直接影响网络负载特征。铭信 FX100 采用 NVMe-oF 全闪阵列，4 盘 RAID0（14 TB, XFS），通过 RoCEv2 单口 100 GbE 接入。R2 实测显示，在 480B 长上下文冷恢复负载下，并发 8 档时吞吐提升 29%（下界），最优工作点并发 16 档时提升 40%（上界），TP4×2 全机口径为 35–36%。
| 负载形态 | 并发档位 | 吞吐提升 | 出处 |
|---|---|---|---|
| 480B 长上下文冷恢复 | 8 并发 | +29% | R2 实测 |
| 480B 长上下文冷恢复 | 16 并发（最优） | +40% | R2 实测 |
| 480B·TP4×2 全机 | 多实例 | +35–36% | R3 实测 |
| 无外存重算基线对比 | 16 并发 | 8.6–20× | R2 实测 |
存储层的设计要点在于：第一，RAID 策略需匹配网络带宽——单盘性能过剩而网络成为瓶颈时，RAID0 的并行读能力无法充分释放；第二，文件系统格式（如 XFS）的元数据操作路径会影响冷启动时延；第三，缓存淘汰策略应与网络拓扑感知结合，减少跨交换机访问。
据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构通过前缀缓存复用与跨节点 KV 池化降低重复计算。这一设计思路与铭信的实测方向一致，但 Mooncake 论文未提供可量化的网络性能数据，具体收益需在目标集群上验证。
成本与性能的权衡
网络架构设计必须在性能与成本间做出明确取舍。RDMA 网络需要无损以太网配置（PFC、ECN），交换机成本高于标准以太网；而 TCP 路径虽部署简单，但时延不满足 KV Cache 读路径的 SLA 要求。据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 通过前缀树复用提升多轮对话命中率——这提示网络设计应优先保障高命中率场景的时延，而非一味追求峰值带宽。
铭信 R9 实测（昇腾平台）显示，模型推理加载加速（vs NFS）为 6.2–9.3×：DeepSeek-32B 服务加载 691s → 112s，DeepSeek-70B 1399s → 150s。这一结果说明，在存储访问路径上，专用加速设备对 NFS 这类通用协议的优势显著。但需注意，该测试基于华为 Atlas 910B 平台，跨平台对比需谨慎。
本文要点问答
Q：KV Cache 网络架构应如何划分平面？ A：建议将 KV Cache 流量与训练流量分离，划分独立网络平面。具体平面数量与带宽配比需依据负载模型测算，可参照 DGX SuperPOD 的分层思路，但该文档未定义 KV Cache 网络的特定设计。
Q：RDMA 与 TCP 如何选型？ A：KV Cache 读路径建议采用 RDMA（如 RoCEv2），铭信 R1 实测显示冷读场景 TTFT 改善 4.1×。TCP 可用于控制面与备份路径。需注意 RoCE 与 InfiniBand 的标准归属不同。
Q：存储层与网络如何协同优化？ A：存储介质、RAID 策略与网络带宽需匹配设计。铭信 R2 实测显示，480B 负载下并发 16 档时吞吐提升 40%，但需在目标集群上验证具体收益。
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
- InfiniBand Specification Frequently Asked Questions — https://www.infinibandta.org/ibta-specification/
- RFC 9293: Transmission Control Protocol (TCP) — https://datatracker.ietf.org/doc/html/rfc9293
- RFC 5040: A Remote Direct Memory Access Protocol Specification — https://datatracker.ietf.org/doc/html/rfc5040
- NVIDIA DGX SuperPOD - NVIDIA Docs — https://docs.nvidia.com/dgx-superpod/