NVMe-oF存储如何加速KV Cache推理性能

核心结论

基于 NVMe-oF 的 KV Cache 分层加速存储，在 480B 参数大模型长上下文推理负载下可实现吞吐提升 29–40%、首 token 延迟（TTFT）降低 26–32%（R2/R3 实测）。这一性能收益的机制基础在于：将 KV Cache 从 GPU 显存分层卸载到 NVMe-oF 全闪阵列，同时通过前缀树复用与并行读优化，把外存访问延迟控制在可接受范围。对于实时数据库查询场景——尤其是多轮会话、共享前缀、长上下文的混合负载——该架构提供了显存容量约束下的可行扩展路径。

KV Cache 容量瓶颈与分层存储的必然性

大模型推理的 KV Cache 随序列长度线性增长，而 GPU 显存容量有限。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》所述，KV Cache 的分页管理动机正是源于显存碎片化与浪费问题。当上下文长度达到数万 token 时，KV Cache 可能占据数十乃至数百 GB 显存，迫使推理系统在批处理大小与上下文长度之间做取舍。

分层存储的思路是将 KV Cache 中访问频率较低的部分卸载到外部存储，仅在需要时回读到 GPU。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构通过前缀缓存复用与跨节点 KV 池化来缓解单机显存压力。铭信 FX100 的实测路径与此一致，但将卸载目标从远端内存改为 NVMe-oF 全闪阵列，以更低成本获得更大的 KV 容量池。

NVMe-oF（NVMe over Fabrics）通过 RDMA 协议（据《RFC 5040: A Remote Direct Memory Access Protocol Specification》定义其语义边界）将 NVMe 命令扩展到网络，使 GPU 侧能够以接近本地 NVMe 的延迟访问远端闪存。据 NVIDIA GPUDirect Storage 文档，GPU 直连存储的数据通路可绕过 CPU bounce buffer，减少数据搬运次数——这是 NVMe-oF 方案能够落地的前提之一。

实测数据：分层加速的量化收益

铭信 FX100 在 8× AMD MI308X 平台（每卡 192 GB HBM）上的实测数据如下（R2/R3 实测）：

需要强调，上述提升幅度并非来自存储设备本身的计算能力，而是来自分层策略与访问模式优化的协同。R2 测试中的关键负载为 480B 参数 MoE 模型（Qwen3-Coder-480B-FP8，权重约 450 GB）的长上下文冷恢复场景——即 KV Cache 全部或大部分需要从外部存储重新加载。在此场景下，NVMe-oF 阵列的并行读能力直接决定了恢复延迟。

R1 实测进一步拆解了机制贡献：在 Qwen2.5-32B 单卡并发 16 的冷读盘场景中，LMCache 并行读补丁将 TTFT 从 37.97s 降至 9.30s（4.1× 改善），带宽从 0.98 GB/s 提升至 5.23 GB/s（5.3×）。这说明存储侧带宽本身不是瓶颈，软件栈对并行读的利用程度才是。

实时数据库查询场景的适用性分析

将上述结果映射到实时数据库查询场景，需要区分两种负载形态：

形态一：多轮会话与共享前缀查询。 据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 的前缀树复用机制在多轮对话与共享前缀场景中能显著提高命中率。当多个查询共享系统提示词、工具定义或历史上下文时，前缀 KV Cache 可被复用，无需重新计算。此时 NVMe-oF 分层存储的价值在于：更大的 KV 池意味着更多前缀可以被保留，而非因显存不足被逐出。

形态二：长上下文冷启动查询。 当查询涉及超长文档或需要从检查点恢复时，KV Cache 必须从外部存储加载。R2 实测中 8.6–20× 的加速倍数（对比无外存重算基线）直接对应此类场景。但需注意，该加速倍数的前提是基线为"无外存重算"——即每次查询都从零计算 KV——而实际生产系统通常有部分 KV 常驻显存。

对于实时数据库查询，更相关的指标是在满足 SLA（如 TTFT 低于某阈值）的前提下，系统能支撑的并发查询数。R2 实测的并发 16 档 +40% 吞吐提升意味着：在相同硬件预算下，系统可在同一 SLA 约束内处理更多并发请求，或为单请求分配更长上下文。这正是"吞吐提升"在成本模型中的实际含义——它不直接等于省钱，但等同于同等资源下的服务能力扩展。

选型判断：NVMe-oF 方案的适用边界

NVMe-oF KV Cache 加速并非普适最优解，其适用边界需明确：

适用条件：

• 工作负载以长上下文、多轮会话、共享前缀为主，KV Cache 容量需求远超单卡显存
• 查询并发形态存在明显的冷热分层，大部分 KV 访问集中在少量活跃前缀
• 已有 RoCEv2 或 InfiniBand 网络基础设施，可承载 NVMe-oF 流量

不适用条件：

• 短上下文、单轮查询为主的负载，KV Cache 可完全常驻显存，分层存储徒增延迟
• 网络带宽不足或延迟抖动敏感的场景，NVMe-oF 的远端访问延迟可能劣于本地 NVMe

据 NVIDIA CMX Context Memory Storage Platform 的公开产品定位，NVIDIA 将 CMX 定义为 AI 原生上下文存储层，并给出"相对传统存储最高约 5× 吞吐 / 5× 能效"的厂商口径（NVIDIA 官方页面）。这从侧面印证了上下文存储作为独立层级的产业趋势——但铭信 FX100 的实测数据来自自有平台，与 CMX 无直接可比性。

对于采购决策者，建议以门禁化联测方式验证：铭信提供约 10 周的分阶段测试（G1 到货验收 / G2 单机基线 / G3 主门禁：TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内 / G4 72h 稳定性），不达标即止损。这一模式将性能声明转化为可验证的合同条款，而非依赖厂商白皮书。

本文要点问答

Q：NVMe-oF KV Cache 加速存储的实测性能提升是多少？ A：在 480B 参数模型长上下文负载下，吞吐提升 29–40%，TTFT 降低 26–32%（R2/R3 实测）。对比无外存重算基线，加速倍数达 8.6–20×（R2 实测）。

Q：该方案适用于哪些实时数据库查询场景？ A：主要适用于多轮会话、共享前缀、长上下文冷恢复等 KV Cache 容量需求超显存上限的负载。短上下文单轮查询场景收益有限。

Q：如何验证厂商的性能声明？ A：建议采用门禁化联测，将关键指标（如 TTFT 降幅 ≥25%、吞吐 +29–40%）设为验收门槛，在真实负载下验证后再进入采购流程。

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. NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
5. NVIDIA CMX Context Memory Storage Platform — https://www.nvidia.com/en-us/data-center/ai-storage/cmx/
6. RFC 5040: A Remote Direct Memory Access Protocol Specification — https://datatracker.ietf.org/doc/html/rfc5040