万卡推理集群存储选型分析：从核心架构到应用视角

（原标题：万卡推理集群存储选型分析：从核心架构到应用视角）

随着大模型进入”推理为王”时代，万卡级推理集群的存储架构正经历根本性变革。传统以分布式文件系统为中心的存储范式（如IBM GPFS、Lustre、Ceph 等）在训练场景表现优异，但面对推理时代 KV Cache（键值缓存）爆炸性增长、长上下文扩展、多Agent共享等新需求，已捉襟见肘。

英伟达在2026年GTC大会上提出CMX G3.5存储层（Context Memory Storage） 概念，通过STX架构重新定义了AI推理的存储层次。与此同时，国内厂商绿算技术同步推出了符合英伟达STX架构的CMX存储平台GP-7000。

本分析从核心架构原理出发，逐层穿透至具体业务场景，对比两种方案在延迟模型、数据路径、GPU协同等维度的本质差异，为英伟达万卡集群（的存储选型提供决策依据。

第一章：英伟达原生分级 KV Cache 卸载架构

1.1四级存储层次

关键洞察：G3.5不是传统存储的”更快版本”，而是一个全新的数据类别——Context Memory Storage（上下文内存存储）。它本质上是一个分布式缓存层，而非持久化存储层。

1.2核心设计原则

1、裸设备直通（Bare-metal Direct Access）

CMX平台通过BlueField DPU直接管理NVMe SSD，完全绕过传统文件系统：

BlueField运行KV I/O 平面，直接终止NVMe-oF和object/RDMA 协议；

GPU通过NIXL（NVIDIA Inference Transfer Library）与CMX通信，数据路径为：GPU HBM → Spectrum-X RDMA → BlueField → NVMe SSD；

全程零 CPU 干预、零内存拷贝、零内核上下文切换。

2、KV Cache感知的数据编排

Dynamo推理框架的 KV Block Manager与NIXL协同工作：

- 预加载（Pre-staging）：在 Decode 阶段前，将KV块从G3.5预加载到 G2/G1，避免GPU等待 ；

- 拓扑感知调度：Grove编排器根据KV局部性跨机架调度负载，即使节点迁移也能复用上下文 ；

- 硬件加速元数据管理：BlueField 的Vera CPU直接处理KV Cache的块分配、回收、一致性，消除传统存储的元数据开销。

3、Pod级共享

CMX提供PB级共享容量，整个GPU Pod内的多个AI Agent可同时访问不断演进的对话上下文，避免每个节点独立重建KV Cache。

1.3最低时延要求与性能断崖

时延要求的推导逻辑：

TTFT预算：128K上下文需在1-5秒内完成，KV Cache加载占5-15%。若延迟10ms（文件系统典型值），总加载时间320ms，TTFT恶化10%；

TPOT预算：每个token生成周期10-50ms，KV增量写入必须在周期内完成。文件系统的 >2ms延迟直接打断流水线，GPU利用率暴跌；

预加载窗口：Dynamo需在1-2ms内完成下一token的KV块预加载。文件系统的> 1ms延迟使窗口失效。

性能断崖临界点：

第二章：分布式文件系统架构的本质局限

2.1技术定位

分布式文件系统：

- 完全POSIX兼容API

- 支持Ceph、Gluster、BeeGFS等多种后端

- 基于Hadoop大数据引擎，可替代HDFS

- 强调全局统一命名空间、数据镜像保护、分级存储

核心矛盾：设计目标是通用企业级数据存储，而非AI推理的瞬时上下文内存。

2.2分布式文件系统vs长上下文存储：架构代差

2.3分布式文件系统在KV Cache场景下的具体劣势

（1）POSIX 语义是性能杀手

KV Cache数据特征与POSIX文件语义完全错配：

- Ephemeral（临时性）：90% 生命周期 < 5分钟，丢失后可重新计算，无需持久化

- 可重建性：是注意力机制的中间结果，重建成本远低于存储开销

- 无跨用户共享需求：文件系统的全局命名空间和权限管理是冗余负担

文件系统强制要求的原子写、fsync、日志、权限检查、时间戳更新等操作，在 KV Cache 场景下全部是无效开销。

（2）VFS 层的延迟放大效应

即使使用 NVMe-oF 或 RDMA 挂载文件系统，数据仍需经过：

GPU→CUDA API→内核NVMe/RDMA驱动→VFS层→客户端→网络传输→服务端→本地文件系统→块I/O调度器→NVMe驱动→ SSD

每一层都会引入微秒到毫秒级的延迟累积。

（3）元数据服务瓶颈

分布式元数据架构在处理KV Cache的高并发细粒度块分配时会出现瓶颈：

- 每个KV Block的分配/回收都需要元数据操作

- 文件系统的inode表、目录树、扩展属性对KV Cache毫无意义

- 分布式锁和一致性协议（Paxos/Raft）在Pod级共享场景下成为延迟抖动源

（4）缓存策略错配

文件系统的缓存策略基于时间局部性和空间局部性假设：

- 预读（Read-ahead）：对顺序访问有效，但KV Cache访问是随机的注意力局部性；

- 写回（Write-back）：为保证数据完整性会延迟写盘，但KV Cache需要即时卸载；

- 页缓存（Page Cache）：对文件系统必要，但对KV Cache是双重拷贝（已在GPU HBM中）。

第三章：逐项劣势拆解

3.1定位

核心矛盾：用训练时代的分布式文件系统思维解决推理时代的内存扩展问题。

3.2性能指标：带宽与延迟陷阱

单节点150GB/s读/90GB/s写（假设）

-大概率基于大文件顺序访问测试，与 KV Cache 的随机小粒度块访问错配 ；

150GB/s是聚合带宽，KV Cache预加载需要低延迟单流，而非高聚合带宽 - 数据需经过DPU→网络→文件系统服务端→再返回，有效带宽利用率 < 30%。

万卡集群1.47TB/s 聚合带宽

万卡聚合带宽是营销数字，对单GPU的KV Cache卸载毫无意义-RoCE/IB 网络在万卡规模下的拥塞控制、PFC 风暴、ECN 降级会显著放大延迟抖动；

延迟”压缩至约2μs”

2μs是DPU本地NVMe访问延迟，非端到端延迟-端到端延迟需包含：GPU发起请求→CUDA驱动→RDMA发送→网络传输→DPU处理→NVMe访问→返回，实际应为50-200μs ；

CMX的< 100μs是真正的端到端（从GPU HBM到G3.5闪存再返回GPU HBM）；

延迟数字是局部优化，CMX的是全局协同。

3.3小文件聚合技术

根本矛盾：小文件聚合假设”小文件会一起被访问”，但Transformer注意力机制是随机稀疏访问——每个新token只与历史特定位置的KV交互。

3.4 GPU-DPU存算一体方案

架构路径对比：

分布式文件系统：GPU→PCIe直连→BlueField DPU→NVMe-oF(RoCE/IB)→NVMe-oF扩展盘柜

CMX平台：GPU→NIXL→Spectrum-X RDMA→BlueField→NVMe SSD

3.5纠删码与高可靠性机制

根本矛盾：将企业级存储的可靠性范式强加于AI推理的瞬时数据。纠删码、副本、修复机制在训练场景有价值，在推理场景是负优化。