NVMe-oF 与 KV Cache 兼容吗？实测数据与工程方案解读
铭信 FX100 在 AMD MI308X 平台实测：通过 NVMe-oF 承载 KV Cache 分层存储，推理吞吐提升 29–40%，TTFT 降低 26–32%。本文拆解协议兼容性挑战、关键配置与验证路径。
NVMe-oF（NVMe over Fabrics）与 KV Cache 的兼容性问题，核心在于远程存储访问的延迟与带宽能否满足大模型推理对 KV Cache 读写的高实时性要求。铭信 FX100 在 AMD MI308X 平台上的实测表明，通过 NVMe-oF 协议承载 KV Cache 分层存储，配合缓存复用机制，推理吞吐可提升 29–40%，首 token 延迟（TTFT）降低 26–32%【R2/R3 实测】。这一方案在 480B 参数规模、TP8 部署形态下得到验证，为存算分离架构下的 KV Cache 落地提供了可复现的工程路径。
KV Cache 卸载到远端存储，延迟和带宽能扛住吗？
大模型推理中，KV Cache 的容量需求随上下文长度线性增长。以 480B 参数 MoE 模型为例，长上下文场景下 KV Cache 可达数百 GB，远超单卡显存容量【R2 实测】。将 KV Cache 卸载至远端存储，需要解决两个核心问题：
第一，协议语义的匹配。 NVMe-oF 基于 RDMA 协议实现远程内存直接访问，其设计目标是块级存储语义【RFC 5040】。而 KV Cache 访问具有高度随机性——不同请求的前缀不同，导致缓存命中位置分散。SGLang 提出的 RadixAttention 机制通过前缀树复用共享前缀，Mooncake 架构则强调以 KVCache 为中心的存算分离设计【SGLang arXiv:2312.07104】【Mooncake arXiv:2407.00079】。这些软件层面的优化，需要底层存储协议具备低延迟随机读能力。
第二，数据通路的效率。 传统存储路径中，数据需经 CPU 内存拷贝，形成 bounce buffer 瓶颈。NVIDIA GPUDirect Storage 通过绕过 CPU 直接建立 GPU 与存储设备的数据通路，但该机制主要针对本地 GPU 直连存储【NVIDIA GDS Documentation】。在 NVMe-oF 场景下，数据需经网络传输，路径更长，延迟控制更难。
铭信 FX100 的实测数据显示，在 480B·TP8 三档并发下，TTFT p50 从 10.17–35.73s 降至 7.53–26.35s【R2 实测】。这一结果说明，NVMe-oF 在合理配置下能够满足 KV Cache 访问的时延预算。
KV Cache 外置后，推理吞吐和 TTFT 具体能改善多少？
铭信 FX100 采用 KV Cache 分层存储方案：热数据驻留显存，温数据存放于本地 NVMe，冷数据卸载至 NVMe-oF 阵列。测试平台为 8×AMD MI308X（每卡 192GB HBM），vLLM 0.20.1+rocm721，LMCache 上游主线源码编译【R1–R4 实测】。
| 指标 | 并发8 | 并发16（最优） | 并发32 | 出处 |
|---|---|---|---|---|
| 吞吐提升 | +29% | +40% | +35–36% | R2/R3 实测 |
| TTFT 降幅 | -26% | -32% | — | R2 实测 |
| 重算基线对比 | — | 8.6–20× | — | R2 实测 |
上表显示，吞吐提升幅度随并发数变化：并发 8 档为下界 +29%，并发 16 档达到上界 +40%，TP4×2 全机口径为 +35–36%【R2/R3 实测】。与无外存重算基线（TTFT p50 149.5s）相比，FX100 将 TTFT 降至 11.85s，吞吐从 4.1 提升至 74.9 tok/s【R2 实测】。
在 LMCache 并行读补丁场景下，单卡·并发16·冷读盘（Qwen2.5-32B）的 TTFT 从 37.97s 降至 9.30s，带宽从 0.98 提升至 5.23 GB/s【R1 实测】。这表明，NVMe-oF 的兼容性问题可通过软件补丁与协议优化得到有效缓解。
部署 NVMe-oF 承载 KV Cache，关键配置有哪些？
NVMe-oF 与 KV Cache 的兼容性方案，需关注以下配置维度：
网络与协议选择。 测试采用 RoCEv2，单口 100GbE。RDMA 协议提供可靠传输与低延迟保证【RFC 5040】。对于多节点部署，Mooncake 架构的跨节点 KV 池化设计可进一步降低缓存缺失率【Mooncake arXiv:2407.00079】。
缓存策略与存储分层。 PagedAttention 的分页管理机制将 KV Cache 划分为固定大小的块，减少显存碎片【PagedAttention arXiv:2309.06180】。结合 LMCache 的并行读补丁，可显著提升冷数据读取效率。
文件系统与块层调优。 Linux 内核的块层 IO 路径与 NVMe 驱动行为直接影响性能【Linux Kernel Documentation】。测试采用 4 盘 RAID0（14TB，XFS），通过条带化提升并行读带宽【R1–R4 实测】。
国产化替代场景下，这套方案在昇腾平台表现如何？
对于国产化替代场景，华为 CANN 异构计算架构提供了与 CUDA 生态对应的软件栈【CANN-昇腾社区】。铭信在华为 Atlas 910B 平台上的实测显示，模型推理加载加速 6.2–9.3×（DeepSeek-32B：691s→112s；DeepSeek-70B：1399s→150s）【R9 实测】。这为信创环境下的 KV Cache 卸载提供了参考路径。
结论：NVMe-oF 与 KV Cache 的兼容性方案是否值得采用？
NVMe-oF 与 KV Cache 的兼容性问题并非不可逾越。通过分层存储架构、RDMA 协议优化与缓存复用机制的结合，铭信 FX100 在 480B 模型上实现了推理吞吐 29–40% 的提升与 TTFT 26–32% 的降低【R2/R3 实测】。这一方案已在 AMD MI308X 与华为 910B 双平台验证，具备工程可复制性。对于计划部署长上下文推理服务的团队，建议在联测环境中验证具体工作负载下的性能表现。
铭信提供约 10 周门禁化联测合作模式（G1 到货验收/G2 单机基线/G3 主门禁：TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内/G4 72h 稳定性），不达标即止损，测算模型 NDA 后 Python 可复现。欢迎有需求的团队联系联测验证。
本文要点问答
Q：NVMe-oF 与 KV Cache 的兼容性问题具体指什么？ A：核心是远程存储访问的延迟与带宽能否满足 KV Cache 读写的实时性要求。铭信实测显示，通过分层存储与协议优化，推理吞吐可提升 29–40%，TTFT 降低 26–32%【R2/R3 实测】。
Q：该方案在哪些平台得到验证？ A：AMD MI308X 平台（8 卡，480B 模型）与华为 Atlas 910B 平台（DeepSeek-70B 加载加速 9.3×）均有实测数据【R2/R9 实测】。测试采用 RoCEv2 网络与 NVMe-oF 阵列。
Q：部署该方案需要哪些关键配置？ A：建议采用 RDMA 协议（RoCEv2）、分页管理 KV Cache、并行读补丁，并针对块层与文件系统调优。具体配置需在联测中按工作负载验证。
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
- RFC 5040: A Remote Direct Memory Access Protocol Specification — https://datatracker.ietf.org/doc/html/rfc5040
- NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
- The Linux Kernel documentation — https://www.kernel.org/doc/html/latest/
- CANN-昇腾异构计算架构-昇腾社区 — https://www.hiascend.com/software/cann