算力决定下限，存力决定上限：AI存储暗战与架构实践

算力军备战进行到今天，大家张口就是多少PFLOPS、多少张卡，但真正跑过大模型训练的人都会意识到一个反常识的事实：很多时候，训练作业停摆不是因为GPU不够，而是因为数据喂不进去。我见过太多次集群利用率在某个凌晨突然崩塌的场景，排查到最后，问题都指向存储——数据集加载超时、检查点写入卡死、小文件读取排队。这时候你才会真正理解一句话：算力决定下限，存力决定上限。而Gartner魔力象限每一年都在画新的分界线，那分界线背后，其实是各大存储厂商在AI领域的暗战。这篇内容我想把这条暗线彻底拆开，讲清楚为什么存储会在AI时代从配角变成主角，以及我们在实际项目中该怎么应对。

1. 算力和存力争的不是同一个"快"：先理清两个底层概念

1.1 算力的衡量标准为何自带"迷惑性"

算力这个词在过去几年被用得太滥了。从手机发布会上讲的"TOPS"，到GPU规格表上的"TFLOPS"，再到超算榜单上的"PFLOPS"，数字越来越夸张，但很多人对它的理解其实停留在"算得快不快"这个层面。

严格来讲，算力指的是单位时间内系统能完成多少次浮点运算或整数运算。以NVIDIA H100为例，其FP16算力接近1000 TFLOPS，这在理论上意味着每秒可以进行约一千万亿次半精度浮点运算。但注意一个关键前提——这是芯片的峰值算力，是理论上的极限值。实际训练中，GPU算力利用率能够做到50%到60%已经算是非常优秀的调度水平，大部分分布式训练任务长期徘徊在30%左右。

这就是我所说的"迷惑性"：厂商和市场讨论算力时，默认把峰值当作实际值。大量算力指标被用来做军备竞赛的攀比，却很少有人追问：当GPU真正开始计算时，它的数据从哪里来？数据能不能及时送进计算单元？如果送不进来，再高的TFLOPS也只是空转的数字游戏。

1.2 存力是一条容易被低估的"数据管道"

存力这个词不是我的创造，它最早从数据中心基础设施的语境里蔓延出来，指的是整个系统存储、管理、流动数据的能力。它不只是"硬盘容量大"，而是包含三个维度：容量、吞吐、延迟。

容量好理解，就是能装多少数据。但吞吐和延迟才是AI场景里最致命的两个指标。吞吐决定了某个时间窗口内能从存储系统中读出多少数据，延迟则决定了单次数据请求要等待多久才能返回。大模型训练的数据集动辄几个TB甚至几十个TB，如果存储系统只能提供几百MB/s的读取带宽，那GPU再强，也只能饿着肚子等数据。

用一个生活化的类比：算力像一个顶级厨师的技术，存力则是厨房的食材供应链和备菜速度。厨师刀工再好、火候掌握再精准，如果食材一直在路上堵着，出餐速度依然上不去。现实中，多数团队把预算和精力都砸在"请顶级厨师"上，对备菜系统和供应链的关注度远远不够，这是AI项目后期问题频发的根源。

1.3 算力与存力之间，存在一条"等式不等式"

如果只看单机单卡，算力与存力的矛盾还不明显。但AI训练几乎必然是分布式的，这就把问题指数级放大。

一个典型的计算链路是这样：GPU发起数据请求 → 经过CPU内存/页面缓存 → 通过网络到达存储节点 → 存储节点从磁盘或闪存介质读取数据 → 走网络返回 → 最终送进显存。这条链路上的每个环节都是瓶颈候选者。GPU的处理时间是毫秒或微秒级的，而网络往返、磁盘寻址、文件系统锁竞争的时间是毫秒甚至秒级的。当并行规模从单机8卡变成128卡甚至上千卡时，所有请求同时涌向存储系统，瞬时并发压力可以让任何未经专门调优的存储直接崩溃。

所以，算力决定的是一个系统计算能力的下限——它决定了你"最多能做多大的事"；而存力决定的是这个系统的数据供给效能上限——它决定了你"实际能把这件事做到多快"。

注意：这里说的"上限""下限"不是定量的数学关系，而是一种工程判断。它想表达的意思是：存储一旦出问题，再多的算力都会被打折。

2. Gartner魔力象限画出的赛道，为什么存储厂商开始占C位

2.1 魔力象限的核心逻辑和它的局限

Gartner魔力象限（Magic Quadrant）是Gartner公司每年针对特定技术市场发布的评估报告，把厂商按照"前瞻性"和"执行力"两个维度划分到领导者、挑战者、有远见者和特定领域者四个象限。它的影响力在于：大量企业的技术选型会参考这份报告，把象限位置当作采购决策的重要依据。

但魔力象限有一个不得不说的局限：它评估的是市场层面的厂商综合能力，而不是某个单一技术指标的横向对比。这意味着，入选象限的厂商不一定是性能最强的那家，但一定是最懂市场需求、最会做产品包装和生态建设的那家。这个逻辑放在AI存储的语境里尤其值得玩味——过去几年，魔力象限上最引人注目的变化，就是一批传统存储厂商旁边，挤进来了一堆AI原生的新面孔。

2.2 Gartner关注的存储市场，正在从SAN/NAS转向"AI数据平台"

复盘Gartner历年发布的存储类魔力象限，能明显感受到赛道重心的迁移。

五年前，主存储魔力象限的主角还是传统SAN阵列和NAS设备，大家比拼的是控制器双活、快照效率、数据精简这些企业级特性。但在AI工作负载爆发之后，Gartner在存储方向上增加了很多与AI直接相关的类别——比如分布式文件系统、高性能存储、数据管理平台等——在这些新类别里，入选逻辑完全变了：不再只看控制器冗余和高可用，而是看是否具备横向扩展能力、是否支持海量小文件和高并发随机读、是否能与GPU直通架构协同。

这个转变背后，是整个数据中心的访问模型正在改变。传统虚拟化环境里，IO模型以小块随机读写为主，低延迟和高可用是最核心诉求。而AI训练的数据访问模型完全相反：GPU需要的是大块顺序读，高吞吐远比低延迟更重要（当然，推理场景对延迟的敏感度会更高），同时还要能容忍极高并发的元数据操作。这两套逻辑几乎是互斥的，老一代为虚机时代设计的存储架构，天然就不是为GPU喂数据准备的。

2.3 新旧势力的换位：谁在往上走，谁在掉队

基于公开市场信息和Gartner各期报告的反馈来看，目前这个市场大致分成了三个梯队：

第一梯队是传统企业级存储巨头，比如Dell、NetApp、HPE等。它们手里有大把企业客户资源，但在AI存储的创新速度上显得相对稳健而保守。它们的策略通常是把既有产品线加一个"AI增强"卖点，比如增加NVMe支持、优化小文件性能、提供GPU集成方案。这套打法稳妥，但在面对纯AI负载时，往往缺少那种"为GPU而生"的利落感。

第二梯队是AI原生玩家，代表就是WEKA、VAST Data这类公司。它们从第一天起就不是为传统数据库或虚拟机做的存储，而是围绕GPU集群的数据流特点重新设计了整套系统。典型的特征包括：全NVMe或全闪存架构、并行文件系统、无POSIX兼容负担、深度集成GPU驱动的数据缓存机制。这类厂商在魔力象限里的位置不断爬升，事实上已经在倒逼传统巨头加快迭代。

第三梯队是云存储服务商，比如AWS、Azure、Google Cloud各自的托管存储方案。云厂商的优势在于弹性——算力可以分钟级扩容，存储同理。但在超大规模AI训练场景里，云存储的网络距离往往成为绕不开的瓶颈，很多团队最终会选择混合架构：计算在云上，数据在自建存储里，或者反过来。

在这种格局下，所谓"暗战"其实已经不是未来时，而是进行时。传统厂商靠存量客户护城河防守，AI原生厂商靠技术代差进攻，云厂商靠边界溢出渗透，三方在Gartner魔力象限上交错站位，谁也不想被画进"被淘汰"的那一侧。

3. 存储暗战的核心技术战场：NVMe、并行文件系统与DPU

3.1 NVMe和NVMe-oF：AI存储的第一块地基

过去的存储系统多采用SATA或SAS接口协议，专为机械硬盘时代的顺序读写优化。SSD普及后，SATA接口的速度上限反而成了瓶颈。NVMe协议的出现解决的就是这个问题——它直接挂载在PCIe总线上，绕开了传统控制器的协议转换。单块NVMe SSD的PCIe 4.0峰值读取速度可以超过7GB/s，PCIe 5.0时代这个数字能进一步提升到14GB/s甚至更高。

但单机上的NVMe只是第一步，AI训练是分布式系统，必须让每个计算节点都能像访问本地盘一样高速访问远端存储。这就是NVMe-oF（NVMe over Fabric）的用武之地。它允许通过光纤通道或以太网远程访问NVMe设备，把单机的低延迟特性扩展到整个存储集群。另一个技术分支NVMe/TCP则更倾向于用传统以太网设施承载NVMe命令，部署成本更低、兼容性更好，代价是延迟比基于RDMA的infiniBand/ROCE方案稍高。

3.2 并行文件系统：AI存储从中枢向边缘渗透

文件系统层面，AI存储的争夺更激烈。传统的NAS系统用的是通用网络文件系统，它适合小规模文件共享，但面对千卡集群的高并发访问时，单点元数据服务器会成为噩梦。并行文件系统（如Lustre、IBM Storage Scale/GFS、WEKA、VAST Data自研系统等）最核心的改进，就是把元数据服务和数据存储都横向拆开，多个节点各自承担一部分，文件被条带化存到多个存储节点上。客户端并发读取时，不同GPU会访问不同的文件分片，带宽呈近线性扩展。

这一设计的价值在真实训练任务中体现得非常直观。以千卡规模的LLM训练为例，检查点文件常常在几十GB到几百GB规模，如果写到传统NAS上，光保存一个检查点可能就要几分钟甚至十几分钟，训练过程只能阻塞等待；并行文件系统可以通过条带化将这个写入时间压缩到几秒到几十秒，训练中断的时间成本大幅缩小。

3.3 DPU与存储加速：把CPU从数据搬运中解放

存储是数据流动的骨架，但数据真正从网卡进到内存、再从内存进到存储介质，这个过程消耗了大量CPU资源。一个高速网卡处理数据包时，CPU中断占比可能高达30%以上。这等于GPU任务正在和数据搬运任务抢同一批CPU核心。

DPU（数据处理单元）的核心使命就是把网络、存储、安全这些事情从CPU上卸载下来。以NVIDIA BlueField系列为代表的DPU，可以在网卡层面完成NVMe-oF卸载、加密操作、RDMA协议处理乃至部分存储虚拟化功能。配置DPU的存储节点，即使在高IO压力下，CPU占用率也能保持在低位，把全部算力留给计算任务或存储服务本身的逻辑处理。

提示：这部分是"暗战"最容易被忽略的地方——表面上各家存储厂商在拼读写性能，但实际上比拼的是整个数据链路的协同优化能力。从NVMe-oF到并行文件系统再到DPU卸载，每一步都决定了数据的最终流速。

4. 从第一性原理出发：AI存储选型和架构设计的实践路径

4.1 先分清场景：训练、微调、推理、数据准备，存储诉求完全不同

做AI存储选型的第一件事，不是看参数，而是拆分你的业务场景。不同场景的IO模型差异极大，甚至互相矛盾。

• 大模型预训练：数据集大但相对固定，核心诉求为高顺序读吞吐、高带宽，同时需要支撑大规模并行访问和频繁的检查点写入。这类场景对应的存储策略是大文件、条带化、并行文件系统。
• 微调和RLHF（基于人类反馈的强化学习）：需要频繁读取多份小样本数据集、保存多个中间模型版本，元数据操作压力大，小文件随机读性能至关重要。
• 推理服务：追求低延迟、高并发小请求。缓存命中率、热点数据的加速能力是关键。此时本地NVMe缓存比远端大容量存储更重要。
• 数据准备/清洗/预处理：读写比较零散，可能有大量并发小文件，对带宽要求不高但对IOPS有要求。一个效率不高的存储方案会让数据工程师每天多等好几个小时。

4.2 一套可供参考的中型AI存储架构

以一个128卡GPU集群、大约需要支撑千亿参数模型训练的假设为例，我给出一个常见的参考架构设计：

这套设计里，最重要的一条经验是不要为了省钱混合部署机械盘。混构架构在省钱的同时，会让性能基线直接掉到机械盘的延迟水平，你之前为NVMe和并行文件系统花的钱等于白扔了。存储系统的性能取决于最慢的那块介质，而不是最快的那块。

4.3 必须盯住的几个关键指标

选型时不要被厂商的花哨宣传带偏，回归这四个指标：

• 顺序读吞吐（GB/s）：对应大文件读取，决定训练数据加载速率。
• 随机读IOPS：对应小文件与元数据操作，决定数据准备和微调效率。
• 满分段延迟（µs）：单次IO的端到端等待时间，推理型负载尤其看重。
• 扩缩容能力：是否能在不停机的情况下平滑扩展容量和带宽，决定系统能否跟上模型规模的增长。

此外，要在真实负载下做验证，而不是在厂商的benchmark环境里看演示。最简单有效的测试就是把你的训练脚本直接跑在目标存储上，观察训练整个epoch的平均耗时、GPU利用率曲线，以及检查点保存的耗时。这些数据无法做假，也是选型决策最可靠的依据。

4.4 成本账：单看每TB价格是伪命题

存储采购里最常见的误区是拿"每TB单价"做ROI计算。AI存储的真实成本应该看每GB/s带宽的成本和每百万IOPS的成本，因为瓶颈永远是性能而不只是容量。

不妨算一笔账：假设模型训练每小时占用128卡GPU，按每卡一小时几十元的租赁成本估算，一小时的GPU成本就非常可观。如果一套存储方案能让训练每个epoch的时间缩短10%，并且让GPU平均利用率从40%提升到60%，这带来的节省远超存储硬件本身的差价。所以，在AI项目里，存储不该是省钱的起点，反而是最值得投入的杠杆点。

5. 踩坑实录：三个真实教训，告诉你AI存储有多容易翻车

5.1 坑一：把检查点保存放在计算网络上，结果全网拥堵

曾经有一个项目，团队规划时把计算网络和存储网络共用了同一套40Gbps以太网。同步梯度的流量和检查点写入流量挤在同一条链路上，训练进行到每10分钟保存一次检查点时，网络直接被写满，梯度同步延迟暴增，GPU利用率从55%掉到15%左右。

排查过程其实不难：先看网络流量曲线，发现每个检查点时间点前后都有一个巨大的流量尖峰，顺着这个就去查了检查点写入路径，最后确认是网络拥塞。修复方案是增加一条独立的存储专用网络，用RDMA承载存储流量。改动之后，GPU利用率立刻回升到50%附近，检查点保存也不再影响训练。

这个坑给所有人的教训是：AI存储的带宽规划必须和计算网络物理隔离，至少在逻辑上独立规划，不能共用一个千兆级交换机。

5.2 坑二：海量小文件的元数据风暴，把存储系统拖垮

另一个项目做多模态数据训练，数据集里有大量图片和短视频片段，单文件体量只有几百KB到几MB，但数量达到几千万个。刚开始用的是通用NAS，结果每次打开数据集目录，光列目录就要等十几秒；训练进程并行读取时，文件系统元数据服务直接过载，部分进程报超时错误。

这个问题的本质是：通用文件系统的元数据操作能力和分布式并行特性和多模态AI场景严重不匹配。目录里几千万个文件的元数据，挤在一两个元数据服务器上，IOPS打得满满的，数据读取带宽反而没用上多少。解决思路是：要么换用并行文件系统，天然支持元数据横向扩展；要么在数据准备阶段就把海量小文件打包成大文件（如TFRecord、WebDataset格式），用顺序读特性替代随机小文件访问。我们后来两者结合，效果立竿见影。

5.3 坑三：忽略GPU直通存储的特性，缓存命中率低到离谱

还有一次是在推理场景。团队用高性能并行存储做所有模型权重的加载，本身性能并不差，但总感觉每次服务启动时的加载时间过长，且GPU利用率不高。后来排查发现，不同GPU实例每次启动都会从存储节点重复加载同一批模型权重，存储层没有任何缓存命中，带宽被白白浪费了。

针对这类问题，最佳实践是引入智能缓存层或本地NVMe缓存盘：所有重复读取的模型文件在第一次加载时写入GPU节点本地盘，之后直接从本地盘加载。这个优化让服务冷启动时间缩短了80%，同时显著降低了远端存储的负载。

提示：AI存储工程里最重要的是全局视角——不要只盯着某一层参数，要把GPU、网络、存储看作一个完整的流水线，瓶颈可能在任何一环。这三个坑是我在实际项目中遇到的典型问题，希望读者能比我更早发现这些信号。

6. 我对AI存储演进方向的一些判断

6.1 存储会越来越像一个"数据操作系统"

往前看两三年，我认为AI存储正在从"硬盘的集合"变成"数据操作系统"。它既要管理数据放在哪、从哪读，也要负责数据格式转换、数据版本管理、数据预处理流水线，甚至能与任务调度器联动——训练任务启动前自动将数据预加载到靠近GPU的位置。

事实上，这种趋势已经出现了。部分存储厂商开始在文件系统层面集成数据编排能力，GPU作业调度系统可以向存储系统发送"准备数据"的指令，存储系统提前把热点数据刷到最靠近计算节点的位置，把GPU的等待时间压缩到接近于零。

6.2 PIM和CXL可能改变存储的物理边界

CXL（Compute Express Link）内存互联协议近几年热度持续上升。它的意义在于：允许CPU、GPU、内存和存储设备共享统一的内存语义。简单说，未来存储设备可以像内存一样被直接访问，而不是必须通过块设备接口。这会让"数据在哪"变得不那么重要，因为任何处理器都能通过CXL直接访问远端数据，大幅减少数据拷贝带来的延迟损耗。

PIM（Processing-In-Memory，存内计算）则是另一个方向：把计算能力下沉到存储介质附近，在数据所在的地方完成一部分预处理，只把结果传回GPU。这对涉及大范围扫描过滤的场景（比如搜数据库、向量检索）很有价值。

6.3 存储团队的岗位定位会发生变化

最后说一点和人有关的观察。过去存储工程师在AI团队里的存在感不高，很多团队干脆没有专职存储角色。但根据我的经验，这个状况已经在改变：凡是把存储当成重要工程资源的团队，训练稳定性普遍高于视存储为公用事业的公司。未来，存储工程师的职责会越来越多地和性能调优、数据编排、GPU调度交叉，深度理解AI工作负载的存储工程师，会成为比算法工程师更难招的角色。

我个人判断，未来两三年里，AI存储的竞争会从"硬件堆料"转向"软件体验"。谁能在同样的硬件成本上提供更高的有效吞吐、更低的运维复杂度、更好的数据编排能力，谁就会是Gartner魔力象限里下一次排名跃升的那一个。对一线技术人来说，与其焦虑算力被垄断，不如先把存力这块高地站住——毕竟，上限决定了系统能飞多高。