数据存储方案 | 第15期：数据喂不饱，GPU 就得等——训练数据加载这一层怎么搭
数据存储方案 | 第15期：数据喂不饱，GPU 就得等——训练数据加载这一层怎么搭
> 摘要：GPU 利用率只有 17%，问题不在卡，在数据没跟上。实测：缓存层把数据加载时间从 82% 压到 1%，GPU 利用率回到 93%。这一期讲训练数据供给的三层：对象存储、分布式缓存、节点本地热缓存。
GPU 利用率只有 17%，问题往往不在卡。Alluxio 的一组实测摆在那儿：ResNet-50 跑三轮，数据直接从对象存储读，训练时间里 82% 花在等数据，GPU 利用率 17%；中间加一层缓存，加载时间压到 1%，利用率回到 93%。卡没变，变的是数据送到的方式。
这就是训练数据供给这一层要解决的事：数据集越堆越大，算力越贵，数据准时送到就越值钱。这一期把这层拆开算。
一、一张对照：缓存层前后，两组数一起变
先把实测条件说清楚，免得数字被当成普适结论：Alluxio 官方博客的测试，PyTorch、ResNet-50、ImageNet 子集约 3.5 万张图、对象存储单区域 S3、FUSE 挂载，基线是 S3FS-FUSE 直读。结果就是上面那两组数。1这是厂商自测，测试规模不大（子集、小图），数字要打折看，但方向和生产案例对得上。
图：走缓存层后的实测截图：数据加载时间占比降到 1%，GPU 利用率 93.29%。图片来源：Alluxio 官方博客
*图：走缓存层后的实测截图：数据加载时间占比降到 1%，GPU 利用率 93.29%。图片来源：Alluxio 官方博客*
生产侧的例子：知乎（4 亿用户的问答社区）把 Alluxio 作 LLM 训练与服务的数据访问层，训练加速 2–3 倍、GPU 利用率翻倍，模型部署从几小时、几天变成每分钟可发。1厂商客户故事，客户名是 Alluxio 自己披露的，数字是厂商口径。
另一家未具名的全球电商巨头（Alluxio 客户故事，客户名未披露）：训练数据几百 PB 放在 S3，各区域与自有机房各布缓存层，S3 API 与出方向费用降一半以上，GPU 利用率提升 20%。2同样是厂商口径，但它点出了缓存层的第二笔账：不光省时间，还省出方向的钱。
二、尺子：MLPerf Storage 2.0 怎么量「喂得饱」
厂商数字各说各话，得有一把公共尺子。MLCommons 的 MLPerf Storage 2.0 就是干这个的：模拟真实训练负载向存储系统要数据，设 GPU 利用率门槛——3D U-Net、ResNet-50 要 90%，CosmoFlow 要 70%；过了门槛，比的是在这个门槛下能撑多少张卡，归根结底比的是聚合带宽。3
Oracle 云上 Alluxio 的实测就是按这把尺子量的：6 台 DenseIO 节点、350 张 H100，GPU 利用率 90% 以上，吞吐 61.55GB/s，网卡利用率八成以上。4数字出自 Oracle 官方博客与 Alluxio 的联合测试，仍是厂商侧，但测试方法与门槛是公开的。
JuiceFS 那边的 MLPerf 调优笔记补了一句实在话：单节点 6 卡时利用率掉到 83%，带宽约 15.1GB/s，瓶颈先在内存拷贝与元数据访问，不在盘。5缓存层不是万能药，瓶颈会挪地方。
三、方案怎么搭：供给分三层
源头，对象存储。数据集的唯一真相来源，S3 协议、版本、生命周期都在这层管。不动它，也不复制它——复制一份到每个机房，账和一致性都乱。
缓存池，分布式缓存。训练节点手边的闲置 NVMe 盘、内存拼成一个池，热数据第一次从源头拉来，之后多轮 epoch 都从池里读。JuiceFS 一家 LLM 训练公司的案例：原来并行文件系统贵且利用率低，改成 JuiceFS 后把闲置资源拼成 360TB 缓存池，6 台服务器聚合带宽 600Gbps、瞬时吞吐 10GB/s，存储总成本降到原来的十分之一。6厂商案例，客户未具名。
图：Alluxio 作训练与推理的数据访问层，底层仍是对象存储与原有存储。图片来源：Alluxio 官方博客
*图：Alluxio 作训练与推理的数据访问层，底层仍是对象存储与原有存储。图片来源：Alluxio 官方博客*
节点本地，热缓存。多卡多机的第一层：每台 GPU 服务器自己的 NVMe 盘，Alluxio 的共置模式就是这个意思——不买新硬件，用卡边上现成的盘。跨云的那家 AI 搜索公司（JuiceFS 客户故事）就是这么做的：H100/H200 节点各出约 50TB 本地缓存，数据集首次从 R2 取，之后几乎全走缓存，跨云取数的延迟被盖住了。7
落到操作上，四条可抄走的：缓存命中率、GPU 利用率、首轮与稳态轮耗时差，三项进验收；缓存容量按热数据集大小定，不是按总数据量定；预热写进排班，训练开始前先把热数据灌进池，别让第一轮替所有人交学费；失效策略提前定，源头数据变了，缓存里那份什么时候算过期。
四、对照与代价：缓存不是免费的
缓存层有三笔代价要先说清：一是预热时间，第一轮总要慢；二是元数据与一致性，小文件一多（比如 ImageNet 这种几十万小图），元数据访问先成瓶颈，JuiceFS 的 Arm 调优笔记里两节点场景就是卡在这儿；三是失效与版本，缓存里的数据与源头不一致时，训练复现性算谁的，事先没规矩，事后扯不清。5
小规模也别照搬大厂：单机几卡的集群，先把 DataLoader 工人数、预取队列、本地盘缓存这三件调到位，再谈分布式缓存池。缓存池是规模上去之后才划算的投入，小集群上它是多一层运维。
还有一笔容易漏的账：缓存层本身吃 CPU 与内存——JuiceFS 的实测里，每提供 10GB/s 带宽约消耗 1 个 CPU 核，客户端每 GB/s 读约 0.8 核。6报价时这部分要算进节点开销，别只算盘。
五、九羲观察：没有缓存池，也能抄走简化版
中小集群没有 Alluxio，没有 JuiceFS 集群，照样能把这套逻辑落地成便宜版：训练节点本地 NVMe 作热缓存；一台或几台闲置服务器的盘拼成小缓存池，数据集首访回源、后续走池；对象存储作唯一源头。盘位和 NVMe 位，库存服务器集群里本来就有，不用为数据供给单独立项买新硬件。
验收只看三项：缓存命中率、GPU 利用率、首轮与稳态轮的耗时差。利用率从两位数回到九成附近，缓存层就算立住了。
还留一个没统一答案的问题：缓存该不该替训练管数据版本？源头数据更新了，缓存里旧的那份是该立刻失效，还是等这一轮跑完？行业里还没有统一做法，先把问题摆出来，比假装它不存在强。
觉然小注：GPU 利用率低的时候，先别急着加卡。卡闲着，往往不是算力不够，是数据没跟上——先问数据在哪一层，再问要不要买卡。 训练数据供给的三层，归根结底是一句话：让热数据离卡近一点，让冷数据待在便宜的地方。离得近，卡就不等。
引用与出处
[1] Alluxio. GPU Utilization: What Is It and How to Maximize It. https://www.alluxio.io/blog/maximize-gpu-utilization-for-model-training （成色：厂商官方博客实测：ResNet-50 三轮、ImageNet 子集约 3.5 万张、S3 单区域、FUSE、基线 S3FS-FUSE；知乎生产案例为厂商客户故事口径）
[2] Alluxio. Accelerate AI – An Alluxio Customer Case Study（全球电商巨头）. https://www.alluxio.io/customer-stories/global-e-commerce-giant-ai-search-recommend （厂商客户故事，客户未具名：训练数据数百 PB、S3 费用降一半以上、GPU 利用率提升 20%）
[3] JuiceFS. MLPerf Storage v2.0: JuiceFS Leads in Bandwidth Utilization and Scalability for AI Training. https://juicefs.medium.com/mlperf-storage-v2-0-juicefs-leads-in-bandwidth-utilization-and-scalability-for-ai-training-1b2b394e27f2 （厂商解读：门槛 90%/70%、比门槛下可撑卡数；基准本身为 MLCommons 公共基准）
[4] Oracle. Alluxio on Oracle Cloud Infrastructure enables Scalable Throughput with Sub-Millisecond Latency for AI Workloads. https://blogs.oracle.com/cloud-infrastructure/alluxio-on-oci-submillisecond-latency-for-ai （Oracle 官方博客：6 节点、350 张 H100、90% 以上利用率、61.55GB/s）
[5] JuiceFS. Optimizing JuiceFS on the Arm Architecture: MLPerf-Based Performance Tuning. https://juicefs.com/en/blog/engineering/arm-juicefs-performance-optimization-mlperf-tuning （厂商调优笔记：单节点 6 卡利用率 83%、带宽 15.1GB/s、元数据与跨节点同步成瓶颈）
[6] JuiceFS. How JuiceFS Transformed Idle Resources into a 70 GB/s Cache Pool. https://juicefs.com/en/blog/solutions/idle-resources-elastic-high-throughput-storage-cache-pool （厂商客户案例，客户未具名：360TB 缓存池、600Gbps 聚合带宽、瞬时 10GB/s、成本降至十分之一、CPU 开销口径）
[7] JuiceFS. 42x Faster Writes & 85% Throughput Gain: JuiceFS for Multi-Cloud AI Agents. https://juicefs.com/en/blog/user-stories/multi-cloud-storage-ai-agent （厂商客户故事：星尘征途，H100/H200 节点各约 50TB 本地缓存、R2 首访后走缓存）
---
九羲科技｜重构服务器 · 硬盘 · 私有 AI 落地解决方案
系列目录：数据存储方案
上一篇｜数据存储方案 第14期：训练中断不是事故，是日常——检查点存储怎么搭
下一篇｜数据存储方案 第16期：待定
合作 | 联系我们：jx@jiuxii.cn
脚踏实地 行知合一
互相成就 拥抱未来