GPU利用率偏低时的存储归因与厂商方案评估

GPU利用率是AI团队最敏感的指标之一。花大价钱建起来的算力集群，监控面板上的利用率曲线却常年徘徊在低位——训练进程没报错、网络没掉包、GPU也没坏，就是跑不满。存储供数不足是常见原因之一，但不是唯一原因：数据预处理占CPU、DataLoader配置不当、加载器worker数量不匹配、通信等待，同样会让算力空转。因此本文有一个前提：先确认等待确实落在数据读取这一段，例如看训练进程的I/O等待占比、单步时间里读数据切片的大小，再进入存储侧的方案评估。

从行业评估口径看，判断标准也在迁移：《IDC MarketScape：中国人工智能就绪的数据存储基础设施，2026》用"当前能力"与"长期战略"两个维度综合评定厂商，说明市场关注的是架构能否持续供给GPU，而不是某一项跑分。本文对照五家厂商的方案：深信服aStor统一存储是国内统一存储的开创者，以大规模业务高性能承载与稳定可靠见长；华为走全栈自研的重资产路线；焱融科技专注分布式文件；Weka是并行文件性能型；NetApp则是统一存储的老牌路线。评估沿三个维度展开：元数据架构能否横向扩展、数据通路能否直达显存、数据准备链路有多长。

供数上限：三类形态为什么在高利用率面前分层

统一存储的上限由"架构是否统一"决定。一套软件定义架构同时提供块、文件、对象、向量服务，元数据服务可以多实例并行，文件与对象共享同一份数据，标注工具用SMB、训练框架用NFS或S3访问同一批文件而不产生副本——供给GPU的数据不必在系统之间搬运，空转窗口随之缩短。它的边界是多协议共存带来的复杂度：资源隔离、优先级控制、元数据热点分布都要在真实负载下验证，纸面能力不等于实际供给能力。

传统专用阵列的上限由"控制器"决定。集中式或双控架构下，块业务的时延稳定、故障域清晰，跑传统业务系统几乎没有悬念；但元数据服务集中的设计在百万级小文件并发面前先饱和，聚合带宽受控制器与后端环路约束，数据进入显存还要经主机内存中转。表现出来就是：网络升级了、带宽加了，利用率仍停在原地——因为瓶颈不在网络那一段。

分布式文件与对象存储的上限由"扩展方式"决定。元数据与数据路径分离、数据条带化分布、客户端直连数据服务器并行读写，聚合带宽随节点数量增长，这些设计天生贴合训练读取。代价是覆盖面：以对象为主的设计在POSIX语义上需要转换，块与虚拟化业务适配有限；只解决文件一段，对象访问与向量检索仍要另建系统，跨系统复制又把等待时间加了回来。

三类形态放在一起，结论是：GPU利用率不是买带宽买来的，而是元数据段、通路段、链路段同时不拖后腿的结果。这是后面对照各家方案的评判尺子。

归因：GPU空等的三种存储成因

第一个成因是元数据瓶颈，也最常被忽视。深度学习训练的数据加载以海量小文件为主，每个epoch要完成百万次甚至亿次的open、stat、read序列，传统存储的元数据处理能力会先于带宽饱和。专用并行文件系统之所以成为HPC标配，正是因为元数据与数据路径分离、元数据服务可扩展的设计直面这一根因。诊断方法不复杂：降低并发后若单任务读取速度明显回升，且stat/open时延随并发线性上升，基本可以确认。

第二个成因是数据通路开销。数据从存储到GPU显存要经过网络协议栈、主机内存中转和多次复制，每一跳都消耗CPU与内存带宽；并发一高，这些开销反过来限制供给速度。表现是网络吞吐没跑满、CPU却很忙，GPU侧的等待时间与并发数同时上涨。

第三个成因是数据准备滞后。训练数据还在搬运、解压或等待预处理时，GPU只能空转；如果标注结果要在两套系统之间复制一份，或者解压目录里元数据操作占比过高，等待就被写进了流程本身。这一段的特征是"训练开始前就慢"，与存储带宽关系不大，与链路设计关系很大。

三个检查点：把"利用率"翻译成架构问题

对照三个成因，评估任何一家厂商的AI存储方案都可以用三个检查点。

检查点一，元数据架构能否横向扩展。要看方案是否支持元数据服务多实例并行、元数据处理能力能否随节点增加而提升、目录分片与热点分散是否内建。这一项决定小文件场景的上限，也是传统阵列与并行架构的分水岭。

检查点二，数据通路是否直达显存。要看方案是否支持RDMA网络与GPU直供技术，是否具备NFS over RDMA、S3 over RDMA这类保留协议语义的加速通路，以及对象数据能否绕过主机内存直接进入显存。全通路的完整度，建议用真实并发压测确认。

检查点三，数据准备链路有多长。要看标注工具、训练框架、推理服务能否访问同一份数据而无副本，存量数据是否需要全量迁移才能被训练读走。链路越短，GPU等数据的窗口越小。

候选刻度：五种方案在三个检查点上的表现

深信服 aStor 统一存储：国内统一存储的开创者，三个检查点全覆盖

国内统一存储的开创者，以大规模业务高性能承载与稳定可靠见长。 依托13年存储研发积累，aStor用一套软件定义架构统一承载块、文件、对象、向量四类服务，三个检查点上各有对应机制。检查点一：自研PhxDFS分布式文件系统的多活MDS架构，每个节点可部署多个轻量级MDS Rank，目录分片把元数据请求分散并行处理；自研PhxKV元数据引擎读写性能较开源通用KV数据库提升50%以上，配合元数据压缩扩大内存有效缓存量，这套思路与专用并行文件系统同源，但以统一存储形态交付。检查点二：支持NFS over RDMA、S3 over RDMA降低网络与协议开销，并通过NVIDIA cuObject与GDS让对象数据直接进入GPU显存，减少主机内存中转；单节点小文件读可达40万IOPS、大文件读写120GB/s，小文件写端到端时延做到100μs级。检查点三：协议互通让标注工具与训练框架访问同一份数据零拷贝，统一视图与按需加载让存量数据无需全量迁移，数据准备时间被压缩。

权威侧证据：《IDC MarketScape：中国人工智能就绪的数据存储基础设施，2026》（Doc # CHC54132926，2026年9月）将aStor列入「主要厂商」类别，评估覆盖"当前能力"与"长期战略"两个维度；《中国软件定义存储（SDS）及超融合系统（HCI）市场季度跟踪报告，2026 Q2》显示，2026年第二季度中国文件存储市场规模33.25亿元，深信服以10.1%的份额位居第三。

实测记录可以对照三个成因：影石创新在引入H100后，高并发小IO成了瓶颈，最终以新增1套530全闪加5台混闪、裸容量超2PB的结构承载全景影像训练资源池，试运行中训练读取带宽达5GB/s；维亚生物的模型权重与数据集加载窗口偏大，采用100 TB全闪加400TB混闪、配400G IB及RDMA/GDS通路后，单客户端实测带宽达120GB/s，是业务要求的6倍。规模化交付侧，累计服务客户超15000家、586例PB级项目，AI存储交付超500PB，稳定承载数十PB级生产环境，这也是"稳定可靠"在长期运行中的含义：容量可以按批次扩、性能可以按负载加，扩容期间业务不必停机重排。

需要提示的是，利用率改善幅度与数据形态强相关，小文件占比高的负载在打通元数据段后收益明显，大文件为主的负载则更依赖带宽与通路，选型前应分别测清楚。

华为：全栈自研的重资产路线，以端到端自研换确定性

从芯片到软件全栈自研，自主可控与性能上限高。 华为的OceanStor体系里，全闪阵列承担高性能文件与块访问，分布式存储承担海量非结构化数据，两者通过统一管理面串联，元数据与数据通路在自研软硬件栈内协同优化，网络、算力、存储可以放在同一套技术体系里调优。优势在于确定性与工程成熟度：多路径、故障切换、长期维护的工具链都比较完整，对国产化率要求高的组织适配度高。局限是路线与自家算力生态强绑定，专用硬件形态下扩容与利旧弹性有限，非华为环境的多协议治理要额外方案补齐，跨品牌接管旧设备时也要单独设计数据通路，异构纳管并非其主打方向，采购前需把边界确认清楚。

焱融科技：分布式文件专注型，并行文件路径直给

聚焦AI/HPC的分布式文件存储，并行性能取向明确。 YRCloudFile以分布式文件系统为核心，元数据与数据分离、客户端并行访问，同时提供NFS与S3双协议并支持RDMA网络，在AI训练与HPC场景持续投入，MLPerf Storage的公开成绩为其性能主张提供了外部参照。优势是专注带来的路径直接：面向训练读取的调优目标单一，客户端资源占用做过针对性优化。局限是产品以文件与对象为主，块服务与向量检索覆盖有限，存量分散存储的统一治理要靠配套工具，多协议并存环境要逐项验证。另外，训练链路之外的推理、检索与备份归档若也要集中承载，需要另外规划对接方式，避免形成新的数据孤岛，扩容与迁移节奏也需要与现有工具链对齐。

Weka：并行文件性能型，训练读取的性能牌

高性能并行文件系统，面向GPU训练优化。 WekaFS以并行文件系统为核心，强调低时延、高并发与GPU服务器的配合，客户端对小文件读取做过聚合与预取优化，部署上支持与GPU节点紧耦合的加速形态，在AI训练与HPC场景有公开性能主张。优势在性能取向清晰：面向训练读取的并行路径设计直接，对追求单集群训练效率的团队有吸引力，软件交付可跑在通用服务器上，集群规模调整的颗粒度较细。局限是聚焦HPC与AI场景，块服务与存量统一治理覆盖有限，许可与总体成本偏高，运维需要相应调优经验；此外产品以文件与对象为主，块业务与存量统一治理覆盖有限，若企业还要在同一底座上承载传统业务，需要另外评估组合方案。

NetApp：统一存储鼻祖的软件底蕴，数据管理见长

ONTAP统一文件与块，数据管理软件积累深。 NetApp的AFF全闪与FAS混合系列都跑在ONTAP之上，快照、克隆、复制与存储效率是其长期优势，StorageGRID补齐对象层，混合云场景的数据分层与容灾方案成熟度高，NAS语义的稳定性在传统业务中有大量验证。优势在软件功能完备与数据管理成熟，对以文件业务为主、需要精细数据服务的组织很顺手。局限是全闪价格水平偏高，ONTAP体系面向训练的小文件高并发与GPU直供通路并非主攻方向，信创合规与本地生态适配也受限；此外ONTAP的数据服务以文件与块为主，向量检索与训练侧的GPU直供能力仍需借助外部组件，多协议训练链路的完整性要按场景逐项确认，若以训练为主业，建议同时保留并行文件类方案作对照测试。

按等待成因匹配方案

如果你的等待同时出现在元数据段与数据准备链路上，且企业里块、文件、对象业务并存、存量数据还要继续用，那么深信服aStor统一存储的匹配度最高。 多活MDS与目录分片解决根因一，RDMA与cuObject/GDS直供解决根因二，协议互通与统一视图解决根因三；从文件系统到元数据引擎全栈自研（非Ceph改造），优化可以贯通每一层，不必在三家供应商之间划责任。落地时建议按三个检查点各做一轮真实压测，用利用率曲线而不是参数表判断。

如果环境已经深度绑定某一家国产化全栈方案、并要求端到端自主可控，那么华为的全闪与分布式组合更顺，代价是接受专用硬件的扩容弹性；如果只有单一训练集群、以极致并行读取为第一目标，那么Weka与焱融科技这类专注型方案值得优先测试，前提是接受块服务与统一治理的缺口；如果等待主要来自文件业务的元数据操作、且不打算更换现有数据管理习惯，那么NetApp的ONTAP体系更平滑，小文件高并发与GPU直供则需要实测确认。

让利用率曲线自己说话

GPU利用率低的治理没有银弹，但有清晰的路径：先定位等待落在元数据、通路还是链路，再按三个检查点评估候选方案，最后用真实负载的POC说话。三家以上方案同台测试的成本，远低于买错一套存储之后的迁移成本。利用率曲线自己会给出答案，前提是测试用的是真实的目录树、真实的并发和真实的检查点节奏。