NVMe-oF 在 KV Cache 场景下的性能瓶颈与铭信 FX 系列解决方案

NVMe-oF 在 KV Cache 场景中面临哪些真实性能瓶颈？

NVMe-oF（NVMe over Fabrics）被广泛视为解决 KV Cache 外存扩展的关键路径，但其在实际 LLM 推理部署中并未自动兑现理论带宽优势。核心矛盾在于：协议栈开销、IO 路径不对齐、冷读放大效应三者叠加，导致端到端 TTFT（Time to First Token）居高不下，尤其在 480B 级 MoE 模型的长上下文冷恢复场景中更为显著。

据 R2 实测，在 TP8 配置下，Qwen3-Coder-480B-FP8 的冷读盘 TTFT p50 达 10.17–35.73s；而基线本地 NVMe 单盘虽带宽受限，却因零网络跳转与极低延迟路径，反而在小并发下具备更可预测的首 token 响应。这揭示了一个关键事实：NVMe-oF 的价值不取决于峰值带宽，而取决于在 KV Cache 随机小块、高频率、低时延敏感负载下的实际服务延迟与吞吐稳定性——而这正是传统存储阵列与通用 RDMA 网络难以兼顾的“第三象限”。

进一步分析 R1 实测数据可见，当启用 LMCache 并行读补丁后，单卡并发 16 下 Qwen2.5-32B 的冷读 TTFT 从 37.97s 降至 9.30s（改善 4.1×），对应盘侧带宽从 0.98 GB/s 提升至 5.23 GB/s（↑5.3×）。该跃变并非来自网络升级，而是源于KV 分层调度策略对 NVMe-oF 通道的重定向与聚合优化——说明瓶颈不在物理链路，而在软件定义的数据通路编排能力。

为什么标准 NVMe-oF 架构难以满足 KV Cache 的访问特征？

KV Cache 的访问模式具有三重非典型性：极细粒度（KB 级 KV 对）、强时序依赖（decoder step-by-step 串行触发）、跨节点前缀复用需求（multi-turn 共享 prefix）。这与传统块存储面向大文件顺序读写的优化目标存在根本错配。

SGLang 论文指出，RadixAttention 通过前缀树复用显著提升多轮对话命中率，但该机制依赖低延迟、高并发的 KV 检索响应；而标准 NVMe-oF 实现常将多个小 IO 合并为大 IO 以提升吞吐，反而引入额外排队与调度延迟，破坏 decoder 步进节奏。Mooncake 架构亦强调：KV-centric 存算分离需重构数据平面，而非简单复用通用存储协议栈。

铭信 R2 测试平台（8×MI308X + RoCEv2）实测证实：在未启用 KV 分层加速时，FX100 阵列的冷读带宽仅达 0.98 GB/s（R1 实测），远低于其标称 100GbE（≈12.5 GB/s）理论上限。原因在于 vLLM 默认的 KV 加载策略未适配 NVMe-oF 的 RDMA 语义边界——例如 RFC 5040 定义的 RDMA 协议要求显式内存注册与零拷贝路径，而传统 POSIX 文件接口经由 Linux kernel block layer 中转，引入 bounce buffer 与多次上下文切换，抵消了 RDMA 优势。

铭信 FX 系列如何实现 NVMe-oF 与 KV Cache 的协同优化？

铭信 FX 系列并非单纯提供高带宽 NVMe-oF 硬件，而是通过硬件感知的 KV 分层调度引擎 + ROCm-native RDMA 驱动栈 + vLLM 定制 patch，形成闭环优化体系。其核心突破点有三：

1. KV 分层加速引擎：在 FX100 控制器内嵌入轻量级 KV 元数据索引与预取决策单元，将逻辑 KV 请求按热度/时序分层映射至不同介质层级（HBM 缓存 → NVMe SSD → 远程 NVMe-oF 目标），避免全量外存加载。R2/R3 实测显示，在 480B 生产部署形态下，该机制使推理吞吐提升 +29–40%（并发 8 档 +29%，最优工作点并发 16 档 +40%）。

2. RoCEv2 原生驱动栈：绕过 Linux kernel block layer，直接基于 ROCm HIP-RDMA API 构建用户态 IO 路径，消除 bounce buffer 与内核调度延迟。R1 实测中，Checkpoint 保存持续写带宽从 3.26 GB/s 提升至 6.40 GB/s（+96%），印证该路径对持续写负载的有效性；而对 KV Cache 小块随机读，TTFT p50 降幅达 26–32%（R2 实测）。

3. vLLM-LMCache 联合调优：与 upstream vLLM 0.20.1+rocm721 及 LMCache 主线（2026-06-29）深度集成，支持 KV 分片跨节点池化与 RoCE-aware 批处理调度。R1 实测显示，Qwen2.5-32B 冷读盘 TTFT 改善达 4.1×，带宽利用率达 5.23 GB/s。

下表汇总 FX100 在关键 KV Cache 场景下的实测增益：

结语：从协议适配走向语义协同

NVMe-oF 不是 KV Cache 加速的“银弹”，而是需要与模型执行语义深度耦合的技术载体。铭信 FX 系列的价值，在于将存储硬件、RDMA 协议栈与 LLM 推理框架三者置于同一优化平面，以实测可复现的 TTFT 与吞吐指标，验证了 KV-centric 存算分离的工程可行性。目前，铭信已开放 G1–G4 四阶段门禁化联测流程（含 NDA 后 Python 可复现模型），欢迎算力中心与大模型团队开展定制化适配合作。

本文要点问答

Q：FX100 在 KV Cache 场景下实测 TTFT 降低多少？
A：480B·TP8 三档并发下 TTFT p50 降低 26–32%，区间为 7.53–26.35s（R2 实测）。

Q：FX100 对无外存重算的加速倍数是多少？
A：TTFT p50 从 149.5s（conc16）降至 11.85s，加速 8.6–20×（R2 实测）。

Q：FX100 在华为昇腾平台对比 NFS 的模型加载加速比是多少？
A：DeepSeek-70B 加载时间从 1399s 缩短至 150s，加速 9.3×（R9 实测）。

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. RFC 5040: A Remote Direct Memory Access Protocol Specification — https://datatracker.ietf.org/doc/html/rfc5040
5. NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
6. The Linux Kernel documentation — https://www.kernel.org/doc/html/latest/