GPU 利用率从 15% 走向 90%：先修数据流水线，再谈模型优化

📌 One-Sentence Summary

一位多模态训练工程师把 GPU 利用率低的问题追溯到串行取数，并展示并发、预取、Ray 对象引用和分散调度如何在训练扩容过程中不断转移瓶颈。

📝 Summary

演讲分析了一条类似 Qwen3-VL 的多模态监督微调流水线：图像获取与 CPU 预处理让昂贵的 GPU 长时间空闲。串行基线获取一个批次需超过 100 秒，模型计算约需 15 至 20 秒，GPU 利用率因此约为 15%。异步取图与 Ray actor 处理首先缩短等待，后台生产队列又在训练器请求前预取数据。但这暴露出另一项成本：大幅图像数组在多个进程之间反复拷贝。团队改用 Ray 对象引用，让数据并行进程直接取得数组，而无需绕经协调节点。演讲称，等待时间占比由约 85% 降至 20%。扩容后，集中在同一节点的 worker 又挤满网卡；分散调度与零拷贝检索配合，报告额外带来约 50% 的吞吐提升，尽管两项设置在小规模实验中都不明显。这是一段有具体时间与瓶颈演变的一手性能排查。标题中的 90% 利用率在开头被提到，但详细复盘主要支持等待比例变化，最终利用率的测量口径并不完整。

💡 Main Points

优化模型内核前，先剖析完整训练流水线。

基线中，一个批次的取数和准备超过 100 秒，模型工作只有约 15 至 20 秒，GPU 因而长期等待。

并发和预取分别对应不同瓶颈。

异步 IO 获取图像，Ray actor 处理 CPU 密集型变换，后台生产者提前填充队列，避免训练器请求时才开始准备。

对象引用可减少大型多模态张量的反复传输。

样本无须在 worker、协调器与训练器之间一再序列化；数据并行进程可以通过 Ray 对象存储直接取得数组。

规模变化会改变调度决策的优劣。

大规模数据并行时，worker 集中部署会挤满网卡；分散调度配合零拷贝才显现收益，而小规模测试未必看得出来。

💬 Key Quotes

关键是让解决办法对应真正的瓶颈。

每次选择并行或并发方案，都要考虑随之增加的通信成本。

我们的基线等待比例从 85% 降到了 20%。

剖析基线，才能找到真正推动性能的地方。

📊 Article Meta

AI Screening： 90

Featured： Yes

Source： AI Engineer

Author： AI Engineer

Category： 软件编程

Language： 英文

Read Time： 12 min

Word Count： 2772

Tags：

编程与工程 , 分布式系统 , 数据工程 , AI 硬件与芯片 , AI 工作流

Play Full Video