happy最紧要算力军备战进行到今天，大家张口就是多少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卡甚至上千卡时，所有请求同时涌向存储系统，瞬时并发压力可以让任何未经专门调优的存储直接崩溃。
所以，算力决定的是一个系统计算能力的下限——它决定了你"最多能做多大的事"；而存力决定的是这个系统的数据供给效能上限——它决定了你"实际能把这件事做到多快"。
注意：这里说的"上限""下限"不是定量的数学关系，而是一种工程判断。它想表达的意思是：存储一旦出问题，再多的算力都会被