Agent 存储范式重估：FMS 2026 之后，推演变成了产品

2024 年 8 月，圣克拉拉。SK 海力士在讲 12 层 HBM3E 的量产时间表。2025 年 8 月，铠侠捧着 245.76TB SSD 拿走了"展会最佳"奖。2026 年 8 月，铠侠 GP1 拿走 Best of Show——不是因为容量，而是因为 1000 万 IOPS 和 512 字节访问粒度。

三年，同一个峰会，三个完全不同的故事。

一个月前我们在《当存储变成 Agent 的工作记忆》中推演了 AI 存储的四阶段框架：权重管道期 → 显存内管理期 → 跨层级状态管理期 → Agent 工作记忆期。当时 FMS 2026 还没召开，分析基于预览议程。

现在 FMS 2026 开完了。NVIDIA 开源 cuFile 并发布 SCADA 架构，ICMSP 把 SSD 定义为 KV Cache 的正式内存节点，铠侠 GP1 证明 SSD 可以以内存粒度工作，OCP 发布了 HBF 标准，Samsung 展出了 zHBM 概念模型。推演正在变成产品。

但不是一个产品，而是多条独立路线在回答同一个问题。NVIDIA 的 ICMSP 依赖 BlueField-4 DPU 做语义转换，月之暗面的 Mooncake 用纯软件层做分布式缓存调度，DeepSeek 的 DualPath 在 660B 生产模型上实现了 98.7% 的 KV Cache 命中率，OCP 的 HBF 走开放标准路线让 NAND 直接连进处理器封装。

这篇文章用 FMS 2026 的实际产品形态，重新审视一个月前的每一个推演。核心修正：四阶段不是串行，阶段三（跨层级状态管理）和阶段四（Agent 工作记忆）在同时发生——因为它们用的是同一套硬件基础设施。 同时用三个维度（总线/介质/协议）审视 Agent 部署的具体变化。

一、推演回顾：一个月前的框架说了什么

简要复述核心判断链条。

阶段一（权重管道期，2023H2—2024） 和 阶段二（显存内管理期，2024H2—2025H1） 仍然成立。存储的角色是存训练数据、加载权重、写 checkpoint。KV Cache 完全在 GPU 显存内管理。上下文窗口膨胀后，FP8 量化和 CPU offload 是临时方案，存储行业仍在场外。

以 Llama 2 70B 为例（80 层、8 KV heads、head_dim=128、FP16），单 token 的 KV Cache 约 320 KB；128K 上下文单请求约 40 GB，1M 上下文则超过 300 GB。并发几个请求就把 HBM 挤爆了。KV Cache 溢出只是时间问题。

转折点在 2025H2。 Prefix Cache 是催化剂。当系统发现多个请求共享相同的前缀（system prompt、长文档、少样本示例），KV Cache 变成可跨请求复用的资产。这立刻引出三个存储系统级别的问题：

1. 命名：怎么标识一段 prefix KV Cache？
2. 寻址：它在 HBM、DRAM 还是 SSD 上？怎么搬运？
3. 生命周期：什么时候驱逐？按 LRU 还是按频率？

KV Cache 在这一刻从数据结构变成了存储对象。存储行业终于被拉进了推理的关键路径。

原框架预测接下来进入阶段四：Agent 工作负载对存储系统提出三个新冲击——状态持久化、IO 模式翻转、内存语义延伸。FMS 2026 表明：阶段三和阶段四在同时发生。原因很简单：Agent 推理本身就是 KV Cache 的最大消费者。ICMSP 既是 KV Cache 的跨介质调度方案，也是 Agent 状态持久化的硬件基础。用同一套 DPU + SSD 基础设施同时解决了两个阶段的问题。

二、总线维度：Agent 数据访问路径的根本变化

这是影响最深的维度。不是"存储变快了"，而是Agent 的数据访问路径从"CPU 主导"变成了"GPU + DPU 主导"。这个变化重塑了 Agent 部署的架构约束。

传统路径：CPU 是所有数据的中介

Agent runtime 跑在 CPU 上。Agent 的每一步循环：

1. 观察环境 → CPU 从 SSD 读 RAG 向量索引（经过完整 IO 栈：应用 → 系统调用 → VFS → 文件系统 → NVMe 驱动 → SSD）
2. 组装 prompt → CPU 从 DRAM 拼 token 序列
3. 调用模型 → CPU 通过 PCIe 把 prompt 拷贝到 GPU HBM
4. GPU 推理 → 生成输出 → 通过 PCIe 拷贝回 CPU
5. 更新状态 → CPU 写到 SSD 或 DRAM

每一步 CPU 都在路径上。一次 Agent 循环涉及 4-5 次 CPU 介入，每次 IO 延迟 10-50μs 加上 PCIe 拷贝开销。100 步任务累积数秒的纯搬运开销。

关键约束：

• Agent 状态存在 CPU 侧 DRAM（Agent framework 的 Python 进程内存），GPU 只在推理时通过 PCIe 收到数据
• KV Cache 存在 GPU HBM 内，溢出时由 CPU 搬到主机 DRAM（CPU 管理的 offload）
• 多 Agent 通信通过进程间通信（IPC）或网络消息传递
• 多租户隔离靠操作系统进程权限

FMS 2026 之后：三条新路径同时打开

路径 A：GPU → DPU → SSD（SCADA + ICMSP）

NVIDIA 的 SCADA 架构让 GPU 通过 cuFile API 发起存储 I/O 请求，BlueField-4 DPU 负责实际的 NVMe 队列管理。GPU 发请求，BF4 执行，CPU 全程不参与数据搬运。

ICMSP 在这条路径上加了语义层。BF4 上运行专用 FTL（Flash Translation Layer），把 KV Cache 的键值寻址映射到 SSD 的物理块。对 GPU 暴露的是"读取 attention head 0 layer 15 的 KV 数据"这样的内存式接口，对下仍然发标准 NVMe 命令。SSD 硬件本身不需要定制。

实测数据（注意：这是 FMS 现场概念验证 demo，使用 H100 GPU，与下文 Vera Rubin / BF4 量产架构不同）：3 颗 H100 GPU 驱动 44 块 PCIe Gen6 SSD，实现 2.3 亿次随机读 IOPS，单台服务器存储吞吐 118 GB/s。SCADA 速度是 CPU 触发模式的 5.3 倍。[^1]

一个 Vera Rubin SuperPod 的 BF4 机架有 64 个 BlueField-4 + 9600TB NVMe SSD。ICMSP 把这些 SSD 组织成 pod 级的 KV Cache 池，通过 Spectrum-X 以太网和 NVMe-oF 做 RDMA 数据传输。

对 Agent 部署的影响：Agent 的 KV Cache 可以放在 ICMSP 管理的 SSD 上（9600TB per SuperPod），GPU 按需读取。Agent 状态不再受 CPU 侧 DRAM 容量限制。9600TB 意味着可以同时维护数十万个长上下文会话的 KV Cache。代价是延迟在 μs 级（比 HBM 慢一个数量级），适合温/冷 KV Cache 和持久化状态。

但要注意：SCADA + ICMSP 目前需要 NVIDIA 的全套基础设施（BlueField-4 DPU + Spectrum-X 网络 + Vera Rubin 平台）。这是一个平台绑定方案，不是开放标准。开放替代方案是否存在？Mooncake 用纯软件实现了类似的分布式 KV Cache 管理（DRAM + SSD 多级缓存，不需要专用 DPU），但性能和 ICMSP 的差距没有公开 benchmark。

路径 B：GPU → CXL 内存池

CXL（Compute Express Link）的 CXL.mem 协议允许 CPU 通过 load/store 指令直接访问 CXL 设备上的内存，延迟端到端约 200-300ns（基于 Intel Sapphire Rapids CXL 1.1 平台实测，CXL 3.2 预期更低），介于本地 DRAM（~100ns）和 NVMe SSD（10-100μs）之间。

FMS 2026 上 CXL 产业链看起来接近可部署——Samsung CMM-D MD310（CXL 3.2 / PCIe 6.0 / 256GB / 72 GB/s）量产，Marvell Structera 提供亚微秒级延迟的共享内存池，澜起科技 MXC CXL 3.2 控制器进入试产。但从"产业链准备好"到"Agent 场景的大规模生产部署"之间还有结构性阻力：CPU 厂商对 CXL 内存池化半心半意（它削弱了 CPU 的平台锁定），操作系统对 CXL 内存池的 hot-plug 和 page migration 支持还在早期，NVIDIA 也不推 CXL（它推的是 GPU 直接管存储的 ICMSP/SCADA 路线）。CXL 的主场可能不在 AI 推理，而在传统数据库和虚拟化场景。

对 Agent 部署的影响：Agent 的热状态（当前会话的 working memory）可以放在 CXL 内存池。多个 Agent 实例可以共享同一池：一个 Agent 写入的工具结果，另一个 Agent 可以立即读到（通过 CXL 一致性域）。这解决了多 Agent 协作的状态共享难题，不再需要通过消息传递（IPC/网络）交换状态，而是通过共享内存直接读取。

当前架构限制：CXL 目前仍需经过 CPU 的 root complex——GPU 不能直接发起 CXL 请求。GPU 使用 CXL 内存的路径是 GPU→PCIe→CPU root complex→CXL 设备→CPU 内存→GPU，多了一轮 PCIe 往返。这意味着路径 B 仍然有 CPU 介入（虽然不搬运数据，只做协议转换）。未来的 CXL 扩展可能支持 GPU 直接发起 CXL 请求（通过 GPU 的 root complex 或 UCIe 桥接），但目前的硬件还不支持。

路径 C：GPU ↔ 封装内介质（HBF / zHBM）

HBF（High Bandwidth Flash）用 UCIe 接口直接挂在 GPU 封装内。GPU 的内存控制器可以直接寻址 HBF 上的数据。NAND 延迟比 DRAM 高一个数量级，但 HBF 的带宽优势来自极致的并行度——大量 NAND 通道通过 TSV 同时工作，以吞吐换延迟。适合 KV Cache 温数据层。

Samsung 的 zHBM 走更激进的路线：通过晶圆键合把 HBM 垂直堆叠在 AI 加速器正上方，性能预计达 HBM5 的 8 倍，但 2029 年才量产。

对 Agent 部署的影响：Agent 的高频温数据（如 prefix cache）可以放在 HBF 上：比 SSD 快两个数量级，比 HBM 便宜 5-10 倍。这填补了此前"HBM 太贵但 SSD 太慢"的中间空白。但 HBF 产品要到 2027H2 才出 Grade 1。

三条路径合在一起：Agent 状态的分层存储

三条路径不是互斥的。一个完整的 Agent 存储架构可能同时使用三种：

这个分层和传统的"CPU DRAM + SSD"两层结构完全不同。Agent 部署从"把状态塞进 Python 进程内存"变成"在五种介质节点上做数据分层调度"。

Agent 框架的架构变化

当前 Agent 框架（LangGraph、CrewAI、AutoGen）的设计假设是 CPU 主导：状态存在 Python 进程内存里，调用 LLM 是远程 API 请求，工具调用结果序列化到文件或数据库。

当 GPU 可以直接寻址 SSD（SCADA/ICMSP）、CXL 内存池（共享状态）、HBF（封装内温数据），Agent 框架的设计约束变了：

状态不需要序列化。 Agent 状态可以存在 DPU 管理的存储层上，GPU 直接寻址，不需要 CPU 做 serialize/deserialize。当前的 Agent 框架每一步都要把状态编码成 JSON 或 pickle，这在 100 步任务里产生大量 CPU 开销和内存拷贝。当状态通过 cuFile 直接可寻址，这层开销消失了。

多 Agent 协作不需要消息传递。 多个 Agent 跑在同一 CXL 一致性域内，共享内存里的状态，不需要 IPC 或网络。一个 Agent 写入的工具结果，另一个 Agent 在下一个时钟周期就能读到。这把多 Agent 系统从"分布式系统问题"变成"共享内存并发问题"，编程模型完全不同。

Agent 不需要绑死在一台机器上。 ICMSP 的 KV Cache 通过 Spectrum-X RDMA 可以跨节点共享（BF4 的 ConnectX-9 提供 RDMA 连接）。Agent 的状态跟着推理任务走，不跟着机器走。这意味着 Agent 迁移从"序列化状态 → 网络传输 → 反序列化"变成"切换 RDMA 指针"。

这些变化意味着 Agent 框架会从"CPU 进程 + 远程 LLM API"模型，进化到"GPU 进程 + 本地推理 + DPU 管理的分布式状态"模型。这个转变才刚开始，目前的 Agent 框架还没有任何一个为此设计。

三、介质维度：Agent 工作负载需要什么

IO 模式翻转：从顺序带宽到随机 IOPS

这是三个冲击维度中被低估最深的变化，也是 FMS 2026 验证最彻底的一个。

Agent 的每一步执行——观察环境（RAG 检索产生随机读）、调用工具（产生小文件写）、更新状态（随机读写状态对象）、保存快照（周期性中等写入）——都在产生细粒度随机 IO。

NVIDIA 的 Storage-Next 倡议联合 40 多家厂商专门优化 512 字节读写——传统 SSD 的最小管理单元（物理页）已达 8-16KB，而 KV Cache 和 Agent 状态的单次访问可能只有 512 字节。一次有效的 512 字节读取要搬动 16-32KB 物理数据，实际读取放大可能超过 30 倍。

铠侠 GP1 拿到 Best of Show 不是因为容量——245.76TB 的 QLC 盘在 FMS 上已经不稀奇——而是因为它证明了 SSD 可以以内存的访问粒度工作：512 字节访问粒度、1000 万 IOPS、50 DWPD。

NAND 物理特性推演链

为什么 Agent 的随机小粒度 IO 对 SSD 是一个严重问题？需要从 NAND 的物理特性出发推演。

NAND 闪存的最小写入单位是一个 page（典型 4-16KB），最小擦除单位是一个 block（包含数十到数百个 page，典型 1-4MB）。不能覆盖写。要修改一个 page 里的数据，必须先把整个 block 擦除再重写。这就是写放大（WAF）的根源。

传统 AI 工作负载下，写入是大块顺序的（checkpoint 几 GB 一次），FTL 可以高效地批量写入空 page，后台 GC 批量回收无效 block，WAF 接近 1。延迟可预测。

Agent 工作负载打破了这个平衡。1000 个 Agent 并发，每个每隔几百毫秒更新一个 512 字节的状态片段：

1. Page 浪费：每次 512B 写入需要占用一个完整的 4-16KB page，其余空间被浪费
2. GC 频繁触发：分散的随机写很快填满空 page，迫使 GC 更频繁触发
3. 延迟尖峰：GC 需要读出有效数据、搬运到新 block、擦除旧 block——一次 50ms 的 GC 暂停对要求 p99 < 10ms 的 Agent 交互来说就是超时
4. WAF 恶化：有效数据散落在大量 block 中（因为是随机写），GC 搬运的有效数据比例高，WAF 可能从 1.1 恶化到 3-5（推演值，无公开 Agent 工作负载 benchmark 验证）
5. 寿命消耗：WAF 恶化意味着实际写入量是逻辑写入量的 3-5 倍，SSD 寿命加速消耗

连锁影响逐层展开：

• FTL：需要从"大块顺序分配"转向"小粒度随机写的 WAF 控制"，更细粒度的 page 映射、写合并（write coalesing）
• GC：后台批量 GC 的延迟尖峰在 Agent 场景不可接受。需要转向前台低延迟 GC——更频繁但每次回收更少 block，降低峰值
• OP（预留空间）：典型企业级 SSD OP 是 7%，Agent 场景可能需要 15-25% 才能保持稳定延迟
• DRAM Buffer：从大块预读转向小文件热点缓存——识别哪些 Agent 状态片段是热的

FMS 2026 的状态：GP1 的 50 DWPD 和 512 字节粒度说明控制器层面已经在为这个工作负载做准备。但没有任何厂商展示过 Agent 工作负载下的实际 WAF benchmark。推演链在逻辑上成立，实测验证缺失。

介质光谱

把 Agent 相关的所有介质放在一起看：

*HBF 价格为行业推测值，尚未量产。

延迟从纳秒到百微秒连续分布。Agent 不同类型的数据落在光谱的不同位置——不是所有状态都需要 HBM 的延迟，也不是所有状态都能容忍 QLC 的百微秒。调度器的作用是根据每种数据的延迟预算选择最合适的介质节点。

四、协议维度：谁控制 Agent 的数据调度

物理连接和介质节点都有了。但谁来决定一段数据放在哪个介质上？这是协议层的竞争。

cuFile + SCADA：GPU 接管存储访问

NVIDIA 开源 cuFile API 并发布 SCADA 架构。传统存储协议栈是：应用 → 系统调用 → VFS → 文件系统 → 块设备层 → NVMe 驱动 → SSD。SCADA 截短为：GPU → cuFile → BF4 DPU → NVMe 队列 → SSD。CPU 不在路径上。

这不只是性能优化，是架构权力的转移。当 GPU 直接（通过 DPU）管理 NVMe 队列，传统文件系统语义（open/read/write/close）不再是唯一的数据访问方式。这对 KV Cache 这种"不需要文件名、只需要键值寻址"的场景来说，去掉了一层不必要的抽象。

ICMSP FTL：存储理解数据语义

ICMSP 的专用 FTL 把 KV Cache 的语义引入存储层。传统 SSD 的 FTL 不知道块里装的是什么。ICMSP 的 FTL 知道：

• 哪些数据属于同一个 attention head
• 哪些数据属于同一个 prefix cache 命名空间
• 哪些数据可以被安全驱逐

目前 ICMSP 理解的是 KV Cache 的语义。但这个架构的推理指向更远的方向：如果 DPU 上的 FTL 能理解 KV Cache 的语义，它也能理解 Agent 状态的语义。

Agent 状态比 KV Cache 更复杂。工具调用结果之间有因果依赖（第 47 步的决策依赖第 23 步的输出），执行轨迹需要版本化（回溯到第 23 步重新执行），多 Agent 消息传递需要命名空间隔离。当前的 ICMSP FTL 不处理这些——它只懂 attention head 和 prefix cache。

但推演很直接：当 DPU FTL 从"KV-aware"进化到"Agent-aware"，存储系统就从"推理专用内存节点"进一步变成"Agent 工作记忆节点"。这一步还没发生，但架构基础已经铺好了。

FDP：行业标准的数据放置

NVMe 工作组推的 FDP（Flexible Data Placement）让 host 显式标记数据放置位置——checkpoint 写 SLC 层做 burst buffer，热数据写 TLC，冷数据下沉 QLC。

FDP 和 cuFile 不在同一层——cuFile 定义 GPU 怎么发起访问，FDP 定义 SSD 怎么安排放置。两者互补。真正的竞争在于：NVIDIA 想让 cuFile 成为 GPU 访问存储的事实标准（像 CUDA 之于计算），而标准组织希望存储接口保持厂商中立。

Mooncake / DualPath：软件层路线

不是所有方案都依赖专用 DPU。月之暗面的 Mooncake 用分离式架构把 KV Cache 组织成分布式缓存资源——DRAM 做热层，SSD/NVMe 做冷层，纯软件层管理。Mooncake Store 支持多级缓存，使冷数据能在容量更大、成本更低的闪存层长期保留。

DeepSeek 的 DualPath 在 660B 生产模型上实现了 98.7% 的 KV Cache 命中率，吞吐提升 1.87×/1.96×。这是不需要任何专用硬件（DPU/CXL）的纯软件方案。

关键判断：ICMSP 和 Mooncake 代表两条路线的竞争。ICMSP 把智能放在 DPU 层（需要 NVIDIA 基础设施），Mooncake 把智能放在软件层（可跑在通用硬件上）。谁会成为主流取决于 TCO——ICMSP 的硬件成本更高但延迟更低，Mooncake 的硬件成本更低但延迟受限于通用 IO 栈。目前没有公开的 head-to-head benchmark。

核心判断

协议层的竞争指向一个判断：Agent 存储架构的价值重心正在从介质层转向调度层。 介质是可替换的——HBM、HBF、CXL DRAM、GP1 SSD，谁更便宜用谁。但调度接口——GPU 怎么发起访问、SSD 怎么理解数据、数据放在哪个介质——决定了谁的话语权最大。

NVIDIA 清楚这一点。cuFile + ICMSP + Storage-Next 三条线合在一起，它在试图成为 Agent 存储调度层的事实标准。和 CUDA 之于计算层的策略完全一致。

五、Agent 需要的不是传统文件系统

这个判断一个月前就做了，FMS 2026 不仅没有推翻它，反而加强了。

Agent 的每一步执行都会产生状态变更——工具调用结果、推理中间产物、环境观察快照。一个运行 100 步的 Agent，可能产生 500+ 个状态片段，每个几百字节到几 KB。传统文件系统的设计假设和 Agent 需求之间的裂痕：

ICMSP 的 FTL 已经在 KV Cache 层面证明了"让存储理解数据语义"的价值——从通用块设备变成 attention-head-aware 的内存节点。下一步就是在 Agent 状态层面做同样的事：从 KV-aware FTL 进化到 Agent-aware FTL。

当前 Agent 框架（LangGraph 的 checkpointer、MemGPT 的记忆管理、Letta 的持久化层）各自在软件层做状态管理，和存储层没有语义接口。当 Agent 状态的因果依赖、版本化、命名空间隔离能被 DPU 上的 FTL 直接管理时，Agent 框架就不需要自己在 Python 进程里维护这些了。

六、三个未解问题

FMS 2026 解决了硬件层的问题，但三个问题仍然开放。

问题一：Agent 工作负载下的 WAF benchmark 缺失

GP1 有 512 字节粒度和 50 DWPD，但没有厂商展示过 Agent 工作负载下的实际 WAF。推演链（512B 写 → page 浪费 → GC 频繁 → WAF 3-5）在逻辑上成立，但缺乏实测验证。

这个 gap 的影响：企业在采购 Agent 部署用的 SSD 时，无法准确估算寿命和成本。如果 WAF 真的是 3-5，意味着 SSD 的实际写入量是预期的 3-5 倍——这对 TCO 计算的影响是决定性的。需要等第一个大规模 Agent 部署的实测数据出来。

问题二：DPU FTL 从 KV-aware 到 Agent-aware

ICMSP 理解的是 KV Cache 语义（attention head / prefix cache）。Agent 状态更复杂——工具调用结果的因果依赖、执行轨迹的版本化、多 Agent 命名空间隔离。这些目前由 Agent 框架在软件层做，和存储层没有语义接口。

当 DPU FTL 能理解"第 47 步的决策依赖第 23 步的工具输出"这种因果依赖时，存储系统就能主动参与 Agent 的状态管理——比如预取第 48 步需要的状态、自动清理不再引用的历史版本。但这一步还没发生。

问题三：Agent 存储的"CUDA 时刻"还没到

硬件有了——五种介质节点、三条访问路径、HBF 封装内互联。ICMSP/SCADA 定义了 GPU→存储的接口。但"哪段数据放在哪个介质上"这个调度决策，目前还是推理引擎各自实现（vLLM 管 HBM 内的，Mooncake 管 DRAM+SSD 的，ICMSP 管 BF4+SSD 的），没有统一抽象层。

这和 GPU 计算早期类似——硬件有了，CUDA 还没出来。Agent 存储的统一调度层（如果出现的话）会定义"数据类型 → 介质选择 → 访问路径"的标准抽象，让 Agent 框架不需要关心数据物理上存在哪里。这个抽象层目前不存在。

七、清醒判断

FMS 2026 的产品信号让我们可以把 Agent 存储状态重新分层：

已经发生的（产品级验证）：

• KV Cache 跨介质管理：ICMSP / Mooncake / DualPath 三条独立路线，不同技术路径验证了同一个方向
• GPU 接管存储调度：SCADA + cuFile 开源，Storage-Next 倡议 40+ 厂商加入
• SSD 以内存粒度工作：GP1（512B / 1000 万 IOPS / 50 DWPD）Best of Show
• 新介质填补空白：HBF 标准（$2-8/GB 区间），CXL 3.2 内存池量产前夜
• Agent 状态容量不再受 CPU DRAM 限制：ICMSP 9600TB per SuperPod

正在被讲述的（有产品但缺独立验证）：

• ICMSP 的 82.7% TTFT 缩短和 67% 内存节省是厂商数据，待独立 benchmark
• CXL 内存池在 Agent 场景的大规模部署。产业链有产品但缺结构性驱动力——CPU 厂商半心半意、软件栈不成熟、NVIDIA 推的是 GPU 直接管存储而非 CXL。CXL 的主场可能不在 AI 推理
• Agent 框架从"CPU 进程 + 远程 API"到"GPU 进程 + 本地推理 + DPU 状态管理"的转变

尚未发生的：

• DPU FTL 从 KV-aware 到 Agent-aware
• Agent 工作负载下的 WAF 实测 benchmark
• Agent 存储的统一调度层（"CUDA 时刻"）
• 计算型存储与 Agent 的交叉

这个方向已经不可逆。当 Agent 从概念走向生产部署，存储系统正在适配一种全新的工作模式。FMS 2026 给出了第一批产品级答案：让 SSD 理解 KV Cache 的语义（ICMSP FTL），让 GPU 绕过 CPU 直接访问存储（SCADA），让 NAND 以内存粒度工作（GP1），让 NAND 直接连进封装（HBF）。

2024 年的 FMS 讲的是"怎么把数据喂进 GPU"。2026 年讲的是"怎么让 Agent 记住它正在做什么"。ICMSP 是 NVIDIA 给出的答案，Mooncake 是月之暗面给出的答案，HBF 是 OCP 联盟给出的答案。谁会成为事实标准还没定——但问题本身已经被行业认领了。

---

主要信息来源（按重要性）：

• FMS 2026 官方议程与主题演讲材料
• NVIDIA FMS 2026 keynote：cuFile 开源、SCADA 架构、ICMSP G3.5 层、Storage-Next 倡议
• Kioxia GP1 产品页面与 Best of Show 新闻稿
• OCP HBF 规范文档（SK Hynix + Sandisk 联合发布，2026-08）
• Samsung FMS 2026 路线图：zHBM / zNAND-O / V10 BV-NAND / HBM4E
• 月之暗面 Mooncake 技术博客 / Mooncake Store 文档
• DeepSeek DualPath 论文（2026-02），660B 生产模型实测数据
• 前篇：《当存储变成 Agent 的工作记忆：FMS 三年风向迁移》（2026-07-18）
• 相关：《FMS 2026：存储层级正在被网络化》

不构成投资建议。数据截至 2026 年 8 月 9 日。

[^1]: NVIDIA/Solidigm/AIC 联合发布数据，属厂商公布结果，待独立 benchmark 验证。ICMSP 架构细节及 82.7%/67% 数据来源于 FMS 2026 技术演讲 PPT；SCADA 性能数据来源于 NVIDIA FMS 2026 keynote。截至撰稿时未见独立 benchmark。