随着大模型进入"推理为王"时代，万卡级推理集群的存储架构正经历根本性变革。传统以分布式文件系统为中心的存储范式（如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推理的瞬时数据 。纠删码、副本、修复机制在训练场景有价值，在推理场景是负优化。