同一个集群多出 33 个点的利用率：变的只是分配顺序

先把决定说清楚

「让 GPU 忙起来」不是一个系统能执行的决定。真正的决定窄得多也难得多：哪块 GPU、在哪个时间片、跑哪个任务、按什么优先级。

形式化之后，它是每个「GPU × 任务 × 时间片」组合上的一个二元选择，输出是一张网格——每块卡在整个调度窗口里的每一格，要么写着一个任务名，要么空着。

四类负载争抢这张网格：训练、实时推理、批量推理、量化。它们分成两种互不相容的形状：

• 块状（训练、批量推理、量化）：一旦开始，就要占住一整块连续的 GPU，中途不能被打断，直到跑完。
• 弹性（实时推理）：跟着每个时间片都在变的需求曲线增减。

两种形状在同一个时间片争同一批硬件，才是这个问题真正难的地方。而同一类里还有第二层异质性：同一个基础模型，训练任务可以从几小时到好几天，从一块卡到几十块。

FIFO 在争抢下要付两笔钱

对照组是一个 FIFO 调度器：实时推理由固定预留供给，其余任务按到达顺序摆放，不看优先级。集群有余量时这是合理策略——怎么排都放得下，顺序不花钱。争抢是让顺序成本从隐形变成实打实容量损失的那个条件。

第一笔是预留。 实时推理等不了，流量来的时候卡必须在。按到达顺序摆放的调度器没有「低谷时释放、峰值前收回」的机制，于是保证可用性的唯一办法，就是取每个实时应用当天的最大需求，把那么多卡包上一整天。代价落在所有非峰值的小时里：一个中午要 6 块、凌晨 4 点只要 2 块的应用，会把 6 块占满 24 小时，那 4 块闲卡对任何批处理任务都不可用——它们既没有在被使用，也不是空闲的。 这也是为什么两个由预留主导的场景里，基线只有 51.6%（混合对照）和 53.6%（训练密集）：大约半个池子，而闲着的那一半多数是被预留掉的。这笔钱不管争不争抢都要付，争抢只是让它显形。

第二笔是顺序。 真正争抢时，哪些任务放得下取决于你按什么次序放，而不只是取决于还剩多少容量。原文这句值得抄下来：顺序不是容量问题定了之后用来打破平局的东西，顺序本身就是一个容量决定。FIFO 按到达先后摆放，既不衡量任务值多少，也不检查窗口里还有什么必须放进来，于是高优先级的工作排在先来的后面，容量被提交给了后来者用不上的摆法。

两笔钱会叠加：为当天峰值包下的那一块，对队列里每一个批处理任务、在每一个小时都是不可用的；剩下的部分再按请求碰巧到达的顺序发出去。

结果

在五个为真实争抢构造的基准场景里，分配器两个指标同时改善：

1. 利用率从 52%–85% 的区间移到 72%–88%。
2. 优先级加权价值上升 24.6% 到 105.1%，平均 52%。
3. 每个场景、两个指标都改善，没有需要解释的取舍。

最强的单个案例是 8 块卡上的训练密集负载：利用率 53.6% → 87.0%，价值涨了 105%。三十三个百分点，从一笔已经在折旧的固定资产上取回来——靠的是把预留的待机容量收回，再把其余部分按优先级摆放。

这条信号的边界

• 全部增益都是相对同一场景下的 FIFO 结果表述的：利用率用百分点，价值用优先级加权产出的百分比增幅。换一个对照基线，数字就不是这个。
• 原文自己标注：最强那个案例的图反映的是单一基线排序。
• 原文有一节标题就叫「需求数字错了的话，这些全都不成立」——这个方法的输入是预测，而预测会错。
• 场景是为争抢构造的。集群有余量时，作者明确说 FIFO 与更复杂的策略填充同样的比例，这套东西在你的集群上值多少，取决于你是否真的在争抢。