AI SSD：大模型推理的存储范式转移

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> AI SSD：大模型推理的存储范式转移 思邈 2026-08-07 10:56:46 来源： 量子位 允中 发自 凹非寺 量子位 | 公众号 QbitAI 过去两年，AI基础设施的竞争主要围绕GPU数量、芯片算力、HBM带宽和高速网络展开。 但随着大模型进入长上下文、复杂推理和多智能体阶段，决定一套系统能够产出多少有效Token的因素正在变得更加复杂。 GPU依然是算力底座，其实际利用率却越来越取决于 模型权重、KV Cache和MoE专家能否在正确的时间到达正确的计算节点 。 如果KV Cache无法及时复用，系统就需要重新执行Prefill； 如果MoE专家权重没有在路由发生前进入内存，GPU便可能停下来等待数据； 如果大量推理状态长期占据HBM，又会压缩并发请求和有效批处理的空间。 AI Infra由此正在从“堆叠计算资源”进入“ 协同计算、网络、内存与存储数据路径 ”的新阶段。 月之暗面的Mooncake与NVIDIA推出的CMX，构成了这一变化的两个代表性信号。 月之暗面从大规模推理软件架构出发，把分散在集群中的CPU、DRAM、SSD和NIC组织为可调度的KV Cache资源； NVIDIA进一步在Vera Rubin基础设施中建立专门的Pod级Flash上下文层。 二者尺度和实现方式不同，却共同指向一个趋势： 推理状态正在成为AI基础设施中的一级资源，存储也开始进入Token生成的实时主链路。 Mooncake：把KV Cache变成独立的基础设施资源 Mooncake最重要的产业意义，并不只是为Kimi构建了一套新的推理服务系统，更是 改变了大模型基础设施对“数据”的组织方式 。 传统推理节点往往把GPU、CPU、DRAM和本地SSD视为一台服务器内部的固定资源，KV Cache主要跟随请求和GPU实例存在；一旦缓存被驱逐或请求迁移，已经完成的Prefill计算便可能失去复用价值。 上下文越长，重复计算和昂贵GPU资源的浪费就越明显。 Moonshot AI与清华大学发表于USENIX FAST ’25的Mooncake采用以KV Cache为中心的分离式架构，将Prefill与Decode部署在不同资源池中，并把GPU集群中未被充分利用的CPU、DRAM、SSD和NIC组织成分布式KV Cache池。 位于中心的Conductor不再只根据GPU负载分发请求，而是结合KV Cache分布、缓存命中、节点负载以及TTFT、TBT等服务目标，决定缓存复用、Prefill执行和Decode调度[1]。 Mooncake的请求流进一步说明了这种变化：可复用的Prefix KV Cache先被送至合适的Prefill实例，新增KV Cache随模型各层计算持续生成，再与Prefill计算重叠，异步流送到目标Decode节点；缓存到齐后，请求才进入连续批处理。 Mooncake Store负责KV块的放置、复制、淘汰和生命周期管理，Transfer Engine则通过RDMA、多NIC带宽聚合与拓扑感知路径选择连接不同计算和存储层[1][2]。 推理系统由此从“给GPU喂数据”转向“围绕Tensor生命周期编排整条数据路径”。 △Mooncake以KV Cache为中心的分离式推理架构：Prefill与Decode资源池通过Mooncake Store、RDMA传输引擎和全局调度器协同工作。 Mooncake论文把这一思路概括为“ 用更多存储换取更少计算 ”。 根据论文披露，在真实请求轨迹和不同TBT约束下，Mooncake相对于所比较的基线系统提高了59%至498%的有效请求承载能力；论文发表时，其生产系统已运行于数千个节点，每日处理超过1000亿Token[1]。 需要强调的是，这些数据反映的是缓存、调度、网络与计算协同后的端到端架构收益，并非某一块SSD的单盘收益。 更值得AI SSD产业关注的是，Mooncake当前官方文档已经把DRAM与SSD/NVMe明确纳入多级缓存，并给出从内存向本地SSD卸载的路径，即将从内存淘汰的对象可在后台进入SSD，内存未命中时再从SSD回读；数据经过预注册缓冲区后，由Transfer Engine送往目标DRAM或VRAM[2][3]。 上层系统解决“何时迁移、迁到哪里”，设备侧仍要解决尾延迟、并行搬运、持续负载、耐久和与推理生命周期协同的问题。 SSD因此不再只是模型启动前的文件来源，而成为TTFT、吞吐与服务SLO共同约束的推理数据层。 CMX：NVIDIA在HBM与共享存储之间增加G3.5层 Agent时代进一步改变了AI基础设施的优化对象。 一次复杂请求不再只是一次模型前向，还可能展开为模型调用、工具执行、记忆检索、数据访问和多轮推理组成的长链路。 KV Cache也由GPU内部的临时状态，转变为需要跨节点移动、共享和复用的基础设施数据。 GPU能否持续获得正确的上下文，开始变得与 GPU本身能算多快 同样重要。 在NVIDIA给出的分层体系中： G1是GPU HBM，用于保存参与当前Token生成的热KV Cache； G2是系统内存，承担交换和暂存； G3是本地SSD，用于承接短期可能复用的温数据； G4则是面向持久化数据的共享文件或对象存储。 随着智能体上下文延伸至多轮对话、工具调用和跨任务状态，G1至G3的容量很快受到限制，而G4的访问时延和通用数据服务开销又不适合频繁进入Decode路径[4]。 NVIDIA CMX Context Memory Storage Platform由此在二者之间增加了一个被称为“G3.5”的层级：通过以太网连接、以Flash为介质、面向KV Cache优化的Pod级上下文内存。 它主要承载短暂、派生、可重新计算但延迟敏感的推理上下文，而不是取代用于长期知识、日志和业务记录的G4持久化存储[4]。 △BlueField-4横跨Rubin GPU计算、Vera CPU服务与BlueField-4 STX共享KV Cache存储节点，构成统一的AI Factory数据路径。 CMX的意义并不只是给GPU Pod外挂一组大容量SSD。 Dynamo的KV block manager与NIXL负责KV块跨层编排和搬移； DOCA Memos提供面向上下文缓存的通信、元数据、放置与共享能力； BlueField-4把KV I/O、队列、预取、完整性与加密等操作下沉到靠近网络和NVMe Flash的位置； Spectrum-X Ethernet则提供RDMA数据通道[4][5]。 当Decode即将使用某组KV块时，系统可以提前将其从CMX预置到系统内存或GPU HBM，以减少GPU等待和历史上下文重算。 据NVIDIA披露，CMX可在单个GPU Pod内提供PB级共享上下文容量，面向长上下文和智能体负载的持续Token吞吐与功耗效率最高可达到传统存储方案的5倍[4]。 这一数据