随着大模型进入”推理为王”时代，万卡级推理集群的存储架构正经历根本性变革。传统以分布式文件系统为中心的存储范式（如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 四级存储层次

层级	介质	延迟量级	核心用途
G1	GPU HBM	纳秒级 (~10-100ns)	活跃token生成，直接参与注意力计算
G2	Host DRAM	百纳秒级 (~100ns)	预加载缓冲区，近期复用上下文
G3	本地 NVMe SSD	微秒级 (~10-100μs)	传统本地卸载，单节点容量扩展
G3.5	CMX/STX 闪存池	十微秒级 (~10-50μs)	Pod级共享上下文内存，KV Cache 专用
G4	网络共享存储	毫秒级 (~1-10ms)	持久化日志、冷数据、企业级归档

关键洞察：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 最低时延要求与性能断崖

指标	英伟达CMX目标	文件系统方案典型值	差距
端到端读取延迟	< 100μs（P99）	1-10ms（P99）	10-100×
端到端写入延迟	< 50μs（异步卸载）	2-20ms（同步 fsync）	40-400×
元数据操作延迟	硬件加速，< 1μs	~1-10ms（分布式元数据服务）	1000-10000×
GPU stall 时间	趋近于零（预加载隐藏延迟）	显著（文件系统 I/O 阻塞 CUDA 流）	致命

时延要求的推导逻辑：

• 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延迟使窗口失效。

性能断崖临界点：

延迟层级	GPU 利用率	性能影响
<100μs（G3.5 目标）	> 95%	吞吐量接近理论上限
100μs-1ms	70-90%	开始出现流水线气泡
1ms-10ms	30-60%	频繁stall，吞吐量腰斩
>10ms（文件系统典型值）	< 30%	不如直接重新计算KV Cache

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

2.1 技术定位

分布式文件系统：

- 完全POSIX兼容API

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

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

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

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

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

维度	CMX存储平台（裸设备直通）	件系统（POSIX 层）
数据路径	GPU→RDMA→DPU→NVMe（3 跳）	GPU→CUDA Driver→内核→网络文件系统客户端→内核网络栈→存储服务器→文件系统→块设备（8-12 跳）
延迟来源	网络传输+闪存访问（~10-50μs）	系统调用+VFS解析+ 数据查询+权限检查+ 网络协议栈+文件锁+块映射（~1-10ms）
CPU 参与	零CPU干预	深度CPU参与
内存拷贝	零拷贝（RDMA 直接写入 GPU HBM）	多次拷贝
元数据开销	硬件加速的 KV 块索引（微秒级）	分布式元数据服务（毫秒级）
一致性模型	弱一致性，允许KV Cache重建	强一致性，需保证 POSIX 语义
访问粒度	细粒度KV Block（4KB-128KB）	文件级或块级（预分配、对齐开销）

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 小文件聚合技术

分布式文件系统	KV Cache场景的真实劣势
合并小文件存储与传输	反向优化：KV Cache需要细粒度独立块访问，合并存储会导致读放大——读取一个token的KV需解压整个聚合块；
针对 checkpoint、模型权重片段	场景错配：checkpoint是顺序写入、全量读取的粗粒度文件，KV Cache是随机增量写入、稀疏读取的细粒度数据；
解决高并发小文件 IOPS	IOPS 定义不同：文件系统的IOPS是文件创建/打开/关闭操作，KV Cache的IOPS是KV Block读写操作。NEST优化前者，恶化后者。

根本矛盾：小文件聚合假设”小文件会一起被访问”，但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

维度	文件系统	CMX存储平台	劣势
协议层	NVMe-oF（块级协议）	NIXL+ 自定义 KV传输协议（语义级协议）	NVMe-oF无KV Cache语义感知，每次访问需额外的块地址映射层
DPU 角色	NVMe 虚拟化控制器（I/O 卸载）	KV Cache编排器（预加载、块管理、一致性）	PU只是网卡+RAID 卡，英伟达的DPU是推理协同处理器
GPU 协同	无原生协同，GPU 通过标准 CUDA API 访问	Dynamo KV Block Manager 直接调度 G3.5 层	GPU仍需主动发起I/O请求，英伟达GPU被被动预加载
预加载机制	无（或需自行开发）	硬件级预加载，隐藏延迟于计算流水线	无预加载=每次 KV 访问都是同步阻塞 I/O

3.5 纠删码与高可靠性机制

分布式存储	KV Cache 场景劣势
全局纠删码（N+M）与多副本	过度可靠性：KV Cache是ephemeral数据，丢失后可重新计算。纠删码的计算开销和网络带宽消耗对推理是纯粹负担
数据写入95%性能无损	容量优化对推理无意义：KV Cache需要低延迟，而非高容量利用率。95%容量利用率意味着更激进的垃圾回收、碎片整理、写放大
99.999%可用性	可用性定义错配：文件系统的可用性是”数据可访问”，KV Cache 的可用性是”GPU不stall”
闪电修复快速重建	修复对推理无价值：KV Cache无需修复，直接重新计算即可。修复机制占用网络带宽，干扰正常推理流量

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