2024 年 8 月，圣克拉拉会议中心的讲台上，SK 海力士在讲 12 层 HBM3E 的量产时间表，铠侠演示了一款采用光接口的宽带 SSD。2025 年 8 月，同一个讲台，铠侠捧着 245.76TB SSD 拿走了"展会最佳"奖，分析师警告超大规模数据中心的资本支出占比已逼近 20%。2026 年 8 月（FMS 2026 即将于 8 月 4-7 日召开，以下分析基于预览议程），NVIDIA 要讲 Agent 场景的存储生态怎么构建。
三年，同一个峰会，三个完全不同的故事。
这不是简单的议题轮换。Future of Memory and Storage（FMS），前身为 Flash Memory Summit，三年的议程变迁，折射的是整个存储行业对 AI 理解的一次根本性转换。而这种转换的内核，比介质迭代更深：存储系统在 AI 产业链中的角色，正在经历四个阶段的跃迁。
四个阶段，不是一个趋势
要理解 FMS 三年的变化，需要先跳出"一年一个热点"的叙事框架。实际上，AI 存储的技术演进经历了四个相互叠加的阶段，每个阶段的核心矛盾不同：
阶段一：权重管道期（2023H2—2024）
核心矛盾：GPU 算力增长远快于数据供给能力。训练集群的 GPU 利用率受限于"喂料"速度。
存储的角色很直接：存训练数据、加载模型权重、定期写 checkpoint。数据流动是单向的、大批量的、顺序的。衡量存储性能的指标是带宽（GB/s）和容量（TB）。HBM3e 量产把带宽推过 1TB/s，QLC NAND 和 Zoned Storage 把单盘容量推向 128TB+，PCIe 5.0 单通道带宽约 4 GB/s，SSD 按 x4—x16 配置可达 16—63 GB/s。
这一阶段，推理存储根本不是一个议题。推理引擎的 KV Cache 完全在 GPU 显存内管理，vLLM 的 PagedAttention 把它当作"显存内的虚拟内存"来调度，消除碎片化、提升并发。存储行业对这一切毫不在意，因为 KV Cache 还没有溢出到存储层。
阶段二：显存内管理期（2024H2—2025H1）
核心矛盾：上下文窗口从 32K 膨胀到 128K 甚至 1M，单请求的 KV Cache 从几 GB 涨到几十 GB。一块 80-192GB 的 HBM 开始不够用了。
第一反应是软件层面：FP8 KV Cache 量化压缩，用精度换空间。第二反应是 CPU offload：把暂时不用的 KV Cache 推到 CPU 侧 DRAM。这些方案都还在"推理引擎内部"解决，存储行业仍然站在场外。
但压力在积累。以 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 溢出只是时间问题。
阶段三：跨层级状态管理期（2025H1—2025H2）
这是转折点。
当 KV Cache 不得不溢出到 SSD 时，一个根本性的认知转变发生了：KV Cache 从"推理引擎内部的数据结构"变成了"需要跨 HBM→DRAM→SSD 多级管理的系统对象"。
更关键的催化剂是 Prefix Cache。当系统发现多个请求共享相同的前缀（system prompt、长文档、少样本示例）时，KV Cache 变成了可跨请求复用的资产。这立刻引出三个存储系统级别的问题：
- 命名：怎么标识一段 prefix KV Cache，让后续请求知道它存在？
- 寻址：它在 HBM、DRAM 还是 SSD 上？怎么在 GPU 需要前搬运到正确位置？
- 生命周期：什么时候驱逐？按 LRU 还是按请求频率？跨节点怎么共享？
这三个问题本质上就是存储系统的问题。KV Cache 在这一刻从数据结构变成了存储对象。 存储行业终于被拉进了推理的关键路径。
NVIDIA 的动作印证了这个判断。2025 年 GTC 上推出 Vera Rubin GPU 的同时，大篇幅介绍了 CMX（Cache-Mix）架构，把 KV Cache 管理拉到 BlueField DPU + NVMe SSD + Spectrum-X 网络的全链路。Dynamo 推理框架内置了 KV Cache 路由功能。这不是"SSD 不够就用 SSD"的临时方案，而是系统级的架构重设计。
FMS 2025 上，KV Cache 开始作为独立议题零星出现。CXL 的讨论同步深化，从 2024 年的"怎么连接"转向"怎么管理和使用"，核心场景仍是数据库内存扩展。
阶段四：Agent 工作记忆期（2025H2—2026）
Agent 不是单轮推理。
一个 Agent 循环是这样的：观察环境 → 推理决策 → 调用工具 → 获取结果 → 更新状态 → 再推理决策 → ……可能持续几十轮，跨多个会话。
这个工作模式对存储系统产生了三种全新的压力，而 FMS 2026 的 28 场 AI&ML 主题演讲（基于预览议程，最终可能有变化），其中 Agent 相关 5 场、KV Cache 相关 7 场，正是这三种压力的集中暴露。
三个冲击维度
维度一：状态持久化，从被动容器到主动状态管理
传统推理是无状态的：请求进来，模型生成响应，结束。Agent 是有状态的：它的每一次决策、每一个工具调用的结果、每一步规划的中间产物，都需要被持久化，以便跨会话恢复、支持回溯、实现多 Agent 协作。
存储系统因此从"被动容器"（你给我什么我存什么）变成"主动状态管理器"。Agent 的状态不是传统意义上的"文件"，它更接近一种持续流动的状态流，包含环境观察、工具输出、执行进度、规划路径。
这里演化出一个更深的议题：Agent 需要的不是传统文件系统。
推演过程是这样的：Agent 的每一步执行都会产生状态变更——工具调用结果、推理中间产物、环境观察快照。一个运行 100 步的 Agent，可能产生 500+ 个状态片段，每个几百字节到几 KB。这些片段之间有因果依赖（第 47 步的决策依赖第 23 步的工具输出），需要版本化（回溯到第 23 步重新执行），需要隔离（不同 Agent 实例不能互相污染）。
传统文件系统的设计假设和这些需求之间的裂痕，逐一展开：
寻址：Agent 不在乎文件叫什么名字或放在哪个目录。它需要的是"找到第 23 步调用 search 工具返回的结果"。用路径寻址意味着 Agent 必须先维护一个"路径 → 含义"的映射，这是额外负担。内容寻址（hash-based）天然适合：状态片段的 hash 既是唯一标识也是完整性校验。
一致性：POSIX 强一致性要求所有客户端同一时刻看到同一个文件系统的完整状态。但 Agent 场景下，100 个并发 Agent 各自更新自己的状态，相互之间不直接依赖，只需要因果一致性（如果 Agent B 读取了 Agent A 的输出，B 必须看到 A 的最新版本；但如果 B 和 A 完全独立，不需要同步）。强一致性在此场景引入不必要的协调开销。
版本管理：Agent 的每一次状态更新相当于一次 commit。手动版本控制在 100 步任务里意味着 100 次显式 save，不现实。需要自动版本化——每次写入自动创建新版本，支持任意版本回滚。
隔离：传统文件系统的隔离靠用户权限（UID/GID），粒度是用户级。多租户 Agent 需要的是实例级隔离——每个 Agent 有完全独立的命名空间，不能意外覆盖另一个 Agent 的状态。
访问粒度：传统文件以 KB-MB 为单位读写。Agent 状态片段典型大小是几百字节，远小于一个文件系统块。
| 需求 | 传统文件系统 | Agent 状态管理层 |
|---|---|---|
| 寻址方式 | 路径名（/home/user/doc.txt） | 内容寻址（hash-based，类似 git） |
| 一致性 | POSIX 强一致性 | 因果一致性（causal consistency） |
| 版本管理 | 手动版本控制 | 每个 step 是一个 commit，自动版本化 |
| 隔离 | 用户权限控制 | 沙箱级隔离（每个 Agent 独立命名空间） |
| 恢复 | 从备份恢复 | 快速快照和回滚（copy-on-write） |
| 访问粒度 | 文件级（KB-MB） | 状态片段级（bytes-KB） |
所以更准确的说法不是"Agent 文件系统"，而是**"Agent 状态管理层"**。这个层可能建在传统文件系统之上（作为软件抽象，存储系统厂商的机会），也可能绕过文件系统直接管理块设备（SSD 控制器和固件层的机会）。两条路径的产业含义完全不同。
维度二：IO 模式翻转，从顺序带宽到随机 IOPS
这是三个维度中被低估最深的变化。
过去几年，AI 存储的性能叙事一直围绕顺序带宽展开。训练数据读取、模型权重加载、checkpoint 写入，都是大块顺序 IO。存储厂商竞相展示的是 GB/s 级别的吞吐数字。
Agent 的工作负载打破了这个假设。Agent 的每一步执行——观察环境（RAG 检索产生随机读）、调用工具（产生小文件写）、更新状态（随机读写状态对象）、保存快照（周期性中等写入）——都在产生细粒度随机 IO。当多个 Agent 并发执行时，这些操作叠加成大量的随机 IOPS 压力。
| 操作 | IO 特征 | 大小 |
|---|---|---|
| RAG 向量检索 | 随机读 | KB-MB |
| 工具调用结果写入 | 小文件顺序写 | KB-MB |
| 状态片段读写 | 随机读写 | bytes-KB |
| 执行快照 | 顺序写 | MB |
| 多 Agent 消息传递 | 并发小消息读写 | KB |
传统推理对 SSD 的需求几乎只有"启动时加载权重"，带宽重要，IOPS 不重要。Agent 场景把 SSD 推到了"Agent 工作空间持久层"的位置，IOPS 和 p99 尾延迟成为核心指标。
这对 SSD 控制器意味着什么？需要从 NAND 闪存的物理特性出发推演。
NAND 闪存的最小写入单位是一个 page（典型 4-16KB），但最小擦除单位是一个 block（包含数十到数百个 page，典型 1-4MB）。不能覆盖写——要修改一个 page 里的数据，必须先把整个 block 擦除再重写。这就是写放大（WAF）的根源。
传统 AI 工作负载下，写入是大块顺序的（checkpoint 几 GB 一次），FTL 可以高效地批量写入空 page，后台 GC 批量回收无效 block，WAF 接近 1。延迟可预测，因为 GC 可以在后台安静地做。
Agent 工作负载打破了这个平衡。1000 个 Agent 并发，每个每隔几百毫秒更新一个 512 字节的状态片段。FTL 面临的局面是：
- 每次 512B 写入需要占用一个完整的 4KB page（因为 page 是最小写入单位），其余 3.5KB 被浪费
- 这些分散的随机写很快填满空 page，迫使 GC 更频繁地触发
- GC 需要读出有效数据、搬运到新 block、擦除旧 block——这个过程占用带宽并产生延迟尖峰
- 有效数据散落在大量 block 中（因为是随机写），GC 搬运的有效数据比例高，WAF 可能从 1.1 恶化到 3-5
- WAF 恶化意味着实际写入量是逻辑写入量的 3-5 倍，SSD 寿命加速消耗
连锁影响逐层展开：
- FTL：需要从"大块顺序分配"转向"小粒度随机写的 WAF 控制"——比如更细粒度的 page 映射、写合并（write coalescing）、以及感知 Agent 状态生命周期的智能回收策略
- GC：后台批量 GC 的延迟尖峰在 Agent 场景不可接受。一次 50ms 的 GC 暂停，对于要求 p99 < 10ms 的 Agent 交互来说就是超时。需要转向前台低延迟 GC——更频繁但每次回收更少 block，用控制论的语言说是"降低峰值换更高频率"
- OP（预留空间）：更大的 OP 给 FTL 更多回旋空间，降低 GC 频率。典型企业级 SSD OP 是 7%（1.92TB 容量对应 ~28% 物理空间），Agent 场景可能需要 15-25% 才能保持稳定延迟
- DRAM Buffer：从大块预取（对训练数据加载有效）转向小文件热点缓存——识别哪些 Agent 状态片段是热的（频繁读写），保持在 DRAM 中减少对 NAND 的访问
维度三：内存语义延伸，CXL 的 Agent 时刻？
要理解这个问题，需要先说清楚两种根本不同的访问模式。
内存语义（Memory Semantics）：CPU 直接通过 load/store 指令按字节寻址访问数据，硬件维护缓存一致性，延迟在纳秒级。CPU 执行 load rax, [0x7ffe] 一条指令就完成读取，不需要系统调用、不需要驱动、不需要中断。原子操作（CAS、fetch-add）直接由 CPU 缓存一致性协议（如 MESIF）保证。
存储语义（Storage Semantics）：数据按块（block，通常 4KB）组织，访问需要经过完整的 I/O 栈——应用调用 read()/write() → 系统调用 → VFS → 文件系统 → 块设备层 → NVMe 驱动 → SSD 控制器。一次 4KB 读的最优延迟也在 10-50μs，比内存访问慢 100-500 倍。写入还需要考虑 fsync() 的持久化保证。
Agent 的问题在哪？
Agent 运行时的状态访问模式是：高频（每步循环多次）、小粒度（几十字节到几 KB 的状态片段）、随机（不同 Agent 实例访问不同状态）、低延迟敏感（p99 尾延迟直接影响响应时间）。这本质上是内存语义的需求。
但 Agent 状态又必须持久化——进程崩溃后需要恢复、多 Agent 需要共享状态、审计需要历史回溯。持久化层（SSD）提供的是存储语义。于是出现了一道断层：
- 读一个 256 字节的状态片段 → SSD 需要读整个 4KB 块 → 99% 的数据搬运是浪费
- 更新一个字段 → read-modify-write 整个块 → 写放大
- 1000 个 Agent 并发各更新自己的状态 → 1000 次 4KB I/O → 实际有效数据不到 1MB，但 I/O 请求占满队列
现在的临时方案：分层的软件翻译
当前实践是靠软件层做翻译：Agent runtime 把热状态放在 DRAM 里，定期 checkpoint 到 SSD。这相当于人工维护一个缓存层级。问题在于：
- DRAM 容量有限（典型服务器 256-512GB），高并发 Agent 工作集可以轻松超过 1TB
- Checkpoint 间隔太长 → 崩溃丢失数据多；间隔太短 → checkpoint 本身变成性能瓶颈
- 每个 Agent 框架自己实现状态管理层，没有统一抽象，重复造轮子
CXL 为什么是结构性解法？
CXL（Compute Express Link）的 CXL.mem 协议允许 CPU 通过内存语义（load/store）直接访问 CXL 设备上的内存，延迟端到端约 170-250ns（含 root complex 开销），介于本地 DRAM（~100ns）和 NVMe SSD（10-100μs）之间。
这意味着 Agent 状态可以放在 CXL-attached DRAM 上，CPU 用普通指针直接读写，不需要任何 I/O 栈。同时，CXL 设备可以自行管理持久化策略（比如后台刷盘），对 CPU 透明。
但这里有一个更深的问题：存储设备需要直接支持内存语义吗？
两种路线正在竞争：
- 路线 A：CXL DRAM 作为前置层。CXL-attached DRAM 做热状态层，SSD 做冷存储层，由软件管理层级置换。CXL 只管内存，SSD 只管存储，各司其职。优点是架构清晰，缺点是置换策略软件实现，延迟开销不可忽略。
- 路线 B：存储设备直接暴露内存语义接口。SSD 通过 CXL.mem 协议向 CPU 暴露字节寻址接口，CPU 可以 load/store 直接访问 SSD 上的数据。Intel Optane Persistent Memory（已停产）和铠侠 XL-FLASH 都尝试过这条路。技术验证了可行性，但介质成本和耐久性问题导致产品失败。
目前看，路线 A 更接近生产落地，因为不需要新的存储介质——用现有 DRAM + 现有 SSD，靠 CXL 做桥接。路线 B 需要存储级内存（SCM）介质，而 Optane 的退出说明这类介质在经济性上还没有突破。
如果要支持内存语义，哪些操作最关键？
从 Agent 工作负载看，最值得优先支持的不是全部 POSIX 语义，而是一个很窄的指令集：
- 字节级 load/store：按字节/字读写，不是按块——解决 4KB 块读取 99% 浪费的问题
- 原子操作（atomic CAS / fetch-add）：多 Agent 并发更新共享状态时的无锁同步
- 持久化屏障（persistence fence，x86 的
clwb+sfence）：明确告诉硬件"这批写入必须刷到持久介质"，区分易失缓存和持久数据 - 零拷贝传输：在 CXL 内存和 GPU 之间直接搬数据，不经过 CPU 中转（CXL一致性域覆盖 GPU 时可行）
这四个操作覆盖了 Agent 状态管理的 90% 需求。相比之下，完整的 POSIX 文件语义（目录、权限、链接、truncate）对 Agent 场景几乎无用——Agent 不需要 chmod。
CXL 在 Agent 场景的三个前提条件：
- CPU 端成熟：CXL 2.0 的完整支持需要 Intel Diamond Rapids 级别或更新的平台，root complex 的协议转换开销需要足够低
- CXL 内存设备经济性：CXL Type 3 设备（纯内存扩展卡）的供应商和产能需要形成规模，价格降到可接受区间
- Agent 框架的 CXL-aware：Agent 运行时需要知道哪些状态应该放在 CXL 内存上、哪些可以溢出到 SSD，这层"数据放置策略"目前还不存在
过去几年，CXL 的有限实践集中在核心数据库内存扩展。Agent 场景在技术逻辑上是 CXL 的理想应用，但距离生产部署可能还有 1-2 年。FMS 上如果出现 CXL + Agent 的实际 benchmark 数据，比任何概念 PPT 都值得跟踪。
计算存储融合的两条暗线
以上三个维度是 FMS 议程直接暴露的。还有两条暗线尚未在峰会议程中与 Agent 明确交叉，但值得关注。
暗线一：计算型存储（Computational Storage）。
Agent 运行时有一类高频操作：向量检索（RAG 中的相似度搜索）、数据过滤（从大量工具输出中筛选相关片段）、状态聚合（合并多个 Agent 的输出）。这些操作的计算量不大，但数据搬运量大——传统架构要把 SSD 上的数据搬到 CPU 内存，CPU 做完计算再搬回去。
这个搬运的代价是多少？一次 NVMe 读的最优延迟是 10-50μs，而一次向量点积计算只需要纳秒级。如果数据集是 1GB 的向量索引（中等规模），全量搬到 CPU 做检索，光搬运就消耗 10-50ms（受 SSD 带宽限制），而实际计算可能不到 1ms。搬运时间是计算时间的 10-50 倍。
计算型存储（SSD 内嵌 ARM/RISC-V 或 FPGA）的逻辑是：既然数据已经在了盘上，为什么不直接在盘内做这些简单计算，只返回结果？一个 100 维向量的相似度比对，结果只有几个字节，不需要搬 1GB 数据。
目前计算型存储标准（NVMe CS）还在早期，与 Agent 场景的交叉几乎为零。但上述数学很直接：如果 Agent 的"计算/数据比"足够低（计算简单但数据量大），计算型存储的收益就是量级的。
暗线二：DPU/NIC 存储卸载。
先说清楚 DPU 在存储链路中要解决什么问题。
Agent 多租户部署意味着：一台服务器上跑几十到几百个 Agent 实例，分属不同用户或不同业务线。这些 Agent 共享同一组 SSD，但要求：
- 带宽隔离：Agent A 的大量 checkpoint 写入不能挤占 Agent B 的实时状态读写带宽
- 加密隔离：Agent A 不能读取 Agent B 的状态数据
- 访问控制：Agent 只能访问被授权的存储区域
用 CPU 软件做这些事情的开销：带宽隔离需要 per-tenant IO 队列调度（CPU 周期）；加密需要 AES-256 加解密（CPU 的 AES-NI 指令吞吐约 3-5 GB/s/核，多个 Agent 并发加解密很快占满 CPU 核）；访问控制需要每次 IO 做 policy check（微秒级，但累积可观）。典型 8 通道 NVMe SSD 满载时，仅加解密就可能消耗 2-4 个 CPU 核。
DPU（如 NVIDIA BlueField）自带 ARM 核、加密引擎和网络接口。把 IO 调度、加解密、访问控制卸载到 DPU：CPU 发出一个普通 read 请求，DPU 在数据从 SSD 返回的路径上做权限校验、解密、带宽限速，CPU 收到的已经是干净可用的数据。CPU 核被释放出来做推理和 Agent 逻辑。
当 Agent 从单机走向分布式，DPU 的角色进一步扩展：跨节点 KV Cache 共享需要 RDMA + 一致性协议，DPU 天然有网络接口和可编程能力来做这件事。NVIDIA 的 CMX 架构把 BlueField 放在 KV Cache 管理的关键路径上，正是这个逻辑的产品化。
谁在推什么
FMS 2026 的 28 场 AI&ML 主题演讲、24 家参与厂商，每类玩家的动机不同：
| 厂商类型 | 核心动机 | 代表 | 真实部署 vs 概念 |
|---|---|---|---|
| 存储系统巨头 | 从"训练时代的盒子"升级为"Agent工作流平台" | Dell, Pure Storage, NetApp | 数据治理一体化方案已交付，但 Agent 场景偏早期 |
| SSD/主控厂商 | Agent 随机 IO = IOPS 新卖点 | Samsung, SK Hynix, Kioxia | SSD 硬件能力已有，控制器优化待跟进 |
| GPU 厂商 | 存储生态主导权，把存储拉进自己的推理全栈 | NVIDIA | CMX/Dynamo 已有产品级方案 |
| 内存/CXL 厂商 | Agent 内存扩容 = CXL 的杀手应用 | Samsung, Micron | 概念阶段，benchmark 缺失 |
议程热度不完全等于部署热度。NVIDIA 的 CMX 架构和 KV Cache 管理链路已经有产品级验证，属于"正在发生的"。Agent-native 状态管理层和 CXL Agent 内存池，更多是"正在被讲述的"。
清醒判断
FMS 三年的迁移揭示了一个真实的趋势：存储在 AI 产业链中的角色正在从被动基础设施变成主动状态管理系统。Agent 工作流确实在重塑存储架构，状态持久化、IO 模式翻转、内存语义延伸，这三个维度不是厂商编出来的故事。
但需要分层看：
已经发生的：KV Cache 从引擎内数据结构变成跨层级存储对象。Prefix Cache 的出现是分水岭，它把 KV Cache 变成了需要命名、寻址、生命周期管理的存储资产。NVIDIA 从 GTC 到 FMS 的持续投入说明这个方向通过了产品级验证。FMS 2026 用 7 场主题演讲讨论 KV Cache，不是空谈。
正在被讲述的：Agent-native 状态管理层。Agent 工作负载确实产生随机 IO，但"需要新的存储架构"和"市场上已经有方案"之间还有距离。FMS 28 场演讲中真正有生产环境 Agent 部署数据的可能不超过少数几场。
尚未发生的：CXL 在 Agent 场景的大规模部署。技术逻辑成立，但需要 CPU 平台、设备生态、软件栈三个条件同时到位。这个判断可能要到 2027-2028 才能验证。
分析师 Jim Handy 在 2025 年 FMS 上对超大规模数据中心资本支出不可持续的警告仍然有效。如果 AI 基础设施投资在 2026 下半年进入回调期，Agent 存储叙事可能经历一轮"PPT 先行、部署滞后"的尴尬窗口。
这个方向已经不可逆。当 Agent 从概念走向生产部署，存储系统需要适配一种全新的工作模式，不是存大文件、读大块数据，而是频繁地、随机地、低延迟地读写 Agent 的运行状态。这会对 SSD 控制器、状态管理抽象、内存扩展架构产生持续影响。
2024 年的 FMS 讲的是"怎么把数据喂进 GPU"。2026 年讲的是"怎么让 Agent 记住它正在做什么"。
这不是同一个问题的升级版。这是一个新问题。
主要信息来源（按重要性）：
- FMS 2024 / 2025 / 2026 官方议程与主题演讲材料
- Jim Handy, "11 Key Changes Coming," FMS 2025
- Kioxia, "Optimizing AI Infrastructure Investments with Flash Memory," FMS 2025
- NVIDIA GTC 2026: Vera Rubin, CMX Architecture, BlueField-4, Dynamo
- Saniffer / CSDN, "FMS 2025 闪存峰会参会情况和技术趋势会后分析," 2025-08
- 半导体产业纵横, "11 个关键词，看透存储趋势," 2026-01
技术细节的深入分析，见姊妹篇《当 AI Agent 重新发明文件系统：从"一切皆文件"到"一切皆上下文"》。
不构成投资建议。数据截至 2026 年 7 月 17 日。FMS 2026 尚未召开，议程分析基于预览信息。