同一集群利用率提升 33 个百分点，只改了调度顺序
来自 Hugging Face · 期号 2026-08-18
摘要
上一篇文章说，企业 AI 的下一个瓶颈不是智能，而是利用率。这篇是他们的解法。 核心问题很简单：训练、批量推理、量化需要连续占用 GPU，实时推理却要弹性伸缩。两种不兼容的形状抢同一块硬件，FIFO 调度器只能给实时推理预留一整天的最大容量，非峰值时段的 GPU 就空转。 他们做了一个约束感知分配器，把问题形式化为「每块 GPU、每个时间片、跑哪个任务」，然后直接求解。在七个基准场景上，同一集群、同一负载，利用率最高提升了 33 个百分点，优先级加权产出最高提升了 105%。 硬件没变，变的只是分配决策的顺序。 原文给出了完整的调度模型和基准方法，附了开源代码。
深读
导读 企业 AI 集群的 GPU 利用率长期偏低，根源往往不是硬件不够，而是调度策略不当。本文来自 Dharma AI 团队，他们构建了一个约束感知的 GPU 分配器，在七个基准场景中，同一集群、同一负载下，利用率最高提升 33 个百分点，优先级加权产出最高提升 105%。读完你会理解：为什么 FIFO 调度在竞争环境下代价高昂，以及如何通过将调度问题形式化为一个全局优化模型来释放闲置容量。 关键信息 - 分配器在 8 块 GPU、16 个任务的训练密集型场景中，将利用率从 53.6% 提升至 87.0%，优先级加权产出提升 105.1%。 - 在 64 块 GPU、30 个任务的规模测试中，分配器与 FIFO 的利用率同为 44.9%，但优先级加权产出高出 15.9%。 - 所有任务优先级相同时，分配器仍将利用率从 76.8% 提升至 87.5%，产出提升 23.1%，证明收益并非仅来自按优先级排序，全局规划本身也有贡献。 - 分配器在五个竞争场景中的运行时间为 1 到 2 毫秒，64 块 GPU 和 30 个任务时为 15 毫秒。 - 实时推理的弹性处理依赖一个关键设计：未满足实时需求的惩罚权重是批处理任务分配权重的 5 到 10 倍。 逐节讲解 问题：两种不兼容的分配形状争夺同一硬件 训练、批量推理和量化是批处理型任务：一旦启动，需要连续占用一组 GPU 直到完成。实时推理则相反，其需求曲线随时间变化，需要弹性伸缩。这两种不兼容的形状在同一时间片竞争同一块硬件，是核心问题。FIFO 调度器只能为实时推理预留一整天的最大容量，非峰值时段的 GPU 因此空转，且无法被任何批处理任务使用。在混合控制和训练密集型两个场景中，FIFO 的利用率分别仅为 51.6% 和 53.6%，其中大量闲置容量来自预留而非空闲。 解法：将调度问题写成一个全局优化模型 分配器将问题形式化为：每块 GPU、每个时间片、跑哪个任务。五个约束定义了一个合法分配：一块 GPU 每时间片最多服务一个任务；批处理任务占用连续且大小为 2 的幂的 GPU 块；实时任务在连续时间片之间可交换的 GPU 数量有硬上限；已启动的任务不可中断。目标函数有两项：分配 GPU 给批处理任务获得优先级乘以时间衰减权重的奖励；未满足实时需求则产生与缺口大小成正比的惩罚。实时惩罚权重是分配权重的 5 到 10 倍，这使得延迟保障被内化到同一个优化中，而非由独立的自动缩放器与调度器竞争 GPU。 实现：启发式算法与形式模型的分层架构 由于这是一个 NP 难的组合分配问题，且调度器在每次任务到达时重新运行，决策必须在两次 API 请求的间隙内返回。架构因此采用分层设计：一个启发式算法位于热路径上，其规则直接来自形式模型的约束，因此它产生的每个分配网格都是合法分配。该算法在放置任何任务之前就能看到所有排队任务，可以…