← 文章 / 云原生与基础设施

HuggingFace博客 2小时前 · 2026-08-30 02:38:11 · 2 阅读

同一集群，利用率高出33个百分点：变的是分配决策的顺序

上一篇文章指出，企业 AI 下一个真正的制约正在形成于利用率而非智能，并在结尾提到：一套成熟的 GPU 管理实践应该是什么样子，目前尚无可循的成规。这就是我们的答案。

我们构建了一个约束感知的 GPU 分配器，并在七个基准场景中与 FIFO 调度器对比测试。在相同硬件、相同工作负载下，GPU 利用率最高提升 33 个百分点，且每一个场景的优先级加权产出都有增长，最高达 105%。硬件没有任何变化，改变的是分配决策被作出的顺序。

在进入数字之前，先说明一下度量口径。下文每一项增益都表示为相对同一场景下 FIFO 结果的提升。利用率以百分点计；价值以优先级加权产出的百分比增幅计。

精确定义这个决策

"让 GPU 保持忙碌"并不是一个系统能执行的决策。真正的决策更窄、也更难：哪个 GPU 在哪个时间步、以什么优先级运行哪个任务。形式上，它是 GPU、任务与时间步的每个组合上的一个二元选择，输出是一张网格——覆盖整个调度周期的每一块 GPU，每个格子要么写着任务名，要么空着。

争夺这张网格的有四种工作负载：训练、实时推理、批量推理和量化。它们分裂成两种截然不同的分配形态，难点正在于此。训练、批量推理和量化属于批处理式：一旦启动，各自需要一块连续的 GPU 区块，不间断地持有到任务结束。实时推理恰恰相反：有弹性，由每个时间步都在变化的需求曲线驱动，随流量涨落而伸缩。

两种互不兼容的形态在同一时间步争夺同一批硬件，这是核心难题。第二种异质性藏在单一类型内部：同样是训练任务，时长从几小时到几天不等，规模从 1 块 GPU 到几十块不等。

争用之下 FIFO 的代价

全文的对照基线是一个基于 FIFO 的调度器：实时推理由固定预留量保障，其余任务按到达顺序放置，全然不顾优先级。

在合适的条件下，这是一种合理的策略。当集群有余量时，分配顺序对利用率毫无影响——无论顺序如何一切都放得下，FIFO 和任何更精巧的方法填满的是同样的资源比例。争用正是这种排序成本从"看不见"变成"连容量也要付出"的转折点。届时它会以两种彼此独立的方式变得昂贵，值得逐一拆解。

预留。实时推理等不起容量；流量需要的那一刻 GPU 就必须就位。按到达顺序放置任务的调度器，没有任何机制可以在低谷释放 GPU、又在下一个高峰前收回，因此保证可用性的唯一办法，就是取每个实时应用当日的最大需求，按这个数目预留一整天。代价落在每一个非高峰时段。一个中午需要 6 块 GPU、凌晨 4 点只要 2 块的应用，会把 6 块全部占满 24 小时，那 4 块闲置的 GPU 全天对任何批处理任务都不可用。它们没被使用，但也并不免费。这就是为什么在预留占主导的两个场景中，基线利用率趴在集群一半附近：混合对照组为 51.6%，训练偏重场景为 53.6%。约一半的资源池，其中闲置的那部分大多是被预留占住，而非真的空闲。无论集群是否争用，这笔成本都在支付——争用只是让它显形。

排序。在真正的争用之下，哪些任务放得下取决于放置的顺序，而不仅仅取决于容量有多少。顺序不是在容量问题解决之后再启用的平局决胜规则，顺序本身就是容量决策。FIFO 来一个放一个，既不权衡这个任务值多少，也不检查整个周期内还有什么必须塞进来，于是高优先级工作排在先到者身后，容量则在后续任务无法利用的放置中被锁定。

两者还会叠加。为当日实时需求峰值预留的区块，对队列中的每一个批处理任务、在每一个小时都不可触及，而剩下的容量又按请求恰好到达的顺序分发出去。

这就好比一家航空公司把飞机分配给最先来电的包机客户，然后发现真正赚钱的航线已无机可派。而为持续几小时的峰值预留一整天的 GPU，正是上一篇文章中"停场飞机"最字面意义上的翻版：随时待命，分文不赚，谁也用不上。

[图：并排的分配网格——上为分配器，下为 FIFO，同一场景]

在为制造真实争用而设计的五个基准场景中，分配器同时改善了两个维度。利用率从 52–85% 区间提升到 72–88% 区间。优先级加权价值提升幅度在 24.6% 到 105.1% 之间，平均 52%。每个场景、两项指标，没有任何需要辩解的权衡。

最强的单例是 8 GPU 上的训练偏重型负载：利用率从 53.6% 升至 87.0%，价值翻了一倍还多，提升 105%。三十三个百分点——来自一项固定且已在折旧的资产——靠收回预留的待命容量、再按优先级顺序放置其余任务而重新赢得。（该数字反映的是单一基线排序。）

分配器消除了上述两种行为。实时需求被当作曲线而非天花板，逐时间步按需求分配，批处理式工作填入低谷，并受限于实时任务在相邻时间步之间可调换的 GPU 数量上限。批处理式任务则按优先级在整个周期上统一放置，而非按到达顺序。本文余下部分讲的就是怎么做。

利用率是必要条件，优先级才把它变成价值

利用率度量的是占用：可用 GPU 时间中有多少被分配给了某种任务。它完全不携带"这种任务价值几何"的信息。有一个场景把两者彻底拉开，而且差距的方向很容易被忽视。

在规模测试中——64 块 GPU 上跑 30 个任务——FIFO 和分配器产出了完全相同的利用率（均为 44.9%）和完全相同的吞吐（30 个任务完成 27 个）。但分配器多交付了 15.9% 的优先级加权价值。每块仪表盘读数都一样，集群的实际产出却截然不同。

一个不为优先级定价的目标函数，可以把集群填到完全相同的水平、完成数量相同的任务，交付的价值却更少。上一篇文章指出，占用率并不足以判断一个集群是否在赚钱；这就是那个论点的实测版本。

把问题写下来

出路并不是罗列更多启发式规则。有些约束只有全局看才有意义，任何局部规则都表达不了：连续区块、整个周期可接受的 GPU 变动预算、运行中的工作绝不被抢占的保证。要满足这些，就必须把问题当作一个整体写下来。

五条约束定义了一次合法分配：

每块 GPU 在每个时间步至多服务一个任务。
每个任务都遵守自身需求区间，已在运行的部分被继承并保持。
批处理式任务占据连续的 GPU 区块，规模为 2 的幂。
实时任务在相邻时间步之间可调换的 GPU 数量有硬性上限。
已启动的任务不可中断。

目标函数有两项。把一块 GPU 分给批处理式任务，可获得等于其优先级乘以时间衰减权重的奖励。未能满足实时需求，则按缺口大小成比例地受罚。

这两个权重的相对大小就是全部服务水平策略，浓缩成一个数字。实时惩罚权重是分配权重的 5 到 10 倍。也就是说，一个单位的未满足实时需求，其代价等于 5 到 10 个 GPU 时间步的同等优先级批处理工作。这种不对称是刻意的：它意味着延迟义务在与批处理放置同一个优化内部被执行，而不是由一个与调度器争夺同一批 GPU 的独立自动扩缩器来执行。

这也是实时需求的弹性处理得以安全的原因。分配器之所以敢在低谷把 GPU 交给批处理工作，是因为日后亏欠实时需求的代价被定得远高于那些批处理工作的任何收益——保护可用性的是惩罚，而非静态预留。

时间权重沿周期衰减，原因只有在在线系统中才说得通：到下一次调度运行时，新任务已经到来。现在就使用的容量，比日后许诺的容量更值钱。

天然知晓约束的分配器

形式化模型定义了"合法且高分"的分配长什么样。响应新到的请求是另一项工作，属于另一个组件。这是 NP-hard 的组合分配问题，而调度器在每次任务到达时都要被重新调用，因此决策必须在两个 API 请求之间的间隙内返回。这个延迟预算是整个架构设计所围绕的固定约束，这也是为什么热路径上放的是启发式算法，而形式化模型退居其后，作为启发式构建时就要满足的规格说明。

这个启发式并非普通的贪心分配器。它的规则就是形式化模型的结构约束，因此它产出的每一张网格在构造上就是一次合法分配。不是"通常有效"，而是"设计使然的有效"。

正是这种覆盖整个周期、而非逐个到达放置的设计，带来了利用率增益。分配器在放置任何任务之前先看到队列中的全部任务，可以把空闲资源池维持成剩余工作真正能占据的形状，需要特定尺寸连续区块的批处理任务轮到它时仍有容身之处。优先级决定谁对这块空间有第一索取权。FIFO 两种视野都没有：它把容量承诺给最先请求的任务，后到且需要特定形状的任务可能发现已无适配空间，于是无法被调度，它本应消耗的 GPU 时也无人认领。

它在五个争用场景上 1 至 2 毫秒内运行完毕，在 64 GPU、30 任务的规模下为 15 毫秒——快到足以对每一个新到请求运行。

系统提供两种模式。快速模式只运行分配器并返回其网格，这是热路径。完整模式把该网格作为形式化模型的起点，由后者尝试进一步改进——适合周期性复核，而非逐请求决策。

结果

场景	利用率	价值	价值增益	延迟
混合对照（8 GPU，10 任务）	51.6% → 72.4%	7,093 → 10,980	+54.8%	1 ms
实时争用（8 GPU，8 任务）	75.0% → 80.2%	3,233 → 4,029	+24.6%	1 ms
训练偏重（8 GPU，16 任务）	53.6% → 87.0%	8,553 → 17,545	+105.1%	2 ms
大规模混合（14 GPU，16 任务）	76.8% → 82.7%	13,977 → 20,101	+43.8%	2 ms
超订（8 GPU，9 任务）	85.4% → 87.5%	4,311 → 5,760	+33.6%	1 ms
规模测试（64 GPU，30 任务）	44.9% → 44.9%	44,233 → 51,248	+15.9%	15 ms
统一优先级（14 GPU，16 任务）	76.8% → 87.5%	25,219 → 31,052	+23.1%	2 ms

除一个场景恰好打平外，其余所有场景的利用率都有提升。价值则在全部七个场景中都有增长。

规模测试的意义在于优势在规模化下依然成立：64 块 GPU、30 个任务、15 毫秒、多 15.9% 的价值。

统一优先级测试的意义在于它回应了最显见的怀疑式解读。把所有任务的优先级一律覆盖为相同值，让没有任何优先级信号可资区分，分配器仍能把利用率从 76.8% 提到 87.5%、价值提升 23.1%。增益并非纯粹是按优先级排序的产物——跨周期规划放置本身就有效果。

需求数字错了，一切都白搭

以上一切的前提，是调度器知道每个任务需要多少 GPU 时、以及将有多少实时流量到来。两者都是预测而非输入，调度器的好坏完全取决于它们的好坏。

单一通用估计器行不通，因为四种工作负载的成本驱动因素在性质上不同。上一篇的专门化论证在这里重新接上了：让专用模型胜过通才模型的同一逻辑，同样适用于给调度器供数的估计器。

训练不是一种负载。它沿两条独立、可自由组合的轴变化。策略（Strategy）决定更新模型的多少（全量微调，还是 LoRA 这类参数高效方法）。技术（Technique）决定优化目标和训练循环（SFT、DPO、RLHF、RLVR、CPT）。这些差异不是边际性的：在同一基座模型上，LoRA 相比全量微调最高可把可训练参数削减 10,000 倍、显存约削减 3 倍；DPO 则同时移除了 RLHF 的奖励模型和采样循环。仅凭模型大小做估计，等于把相差几个数量级的运行一概取平均——而偏差恰好落在调度器要决策的两个量上：时长和 GPU 数量。我们的训练预测器以 22 个特征为条件，其中包括一个区分 10 种具体训练变体的类别变量。

量化是一个可调度的任务，不是后台杂务。量化一个大模型可能在其他工作排队等待的硬件上吃掉数小时的 GPU 时间。它有自己的预测，由按参数量划分的校准层级构建，对不同算法（bitsandbytes、AWQ、GPTQ）分别处理，并在向上取整为整数 GPU 时之前留出安全余量。该领域的既往工作把量化完全排除在调度范围之外。

实时推理则根本不按任务估计。它被预测为一条持续再校准的周需求曲线，由逐小时流量历史重建，并按形式化模型所执行的同一调换成本映射到 GPU 数量。于是预测器与优化器对"变动值多少代价"达成一致，而不是各执一词、互相打架。正是这条预测取代了峰值预留。逐时间步的需求曲线，是唯一能让调度器在低谷放心释放 GPU、并有把握在下一个高峰前收回的东西。

这里又绕回了排序论证。更好的需求估计，正是让优先级感知的放置成为可能的前提——不知道任务将消耗什么，就无法把它排好。

优化一天，只提交当前一小时

对这一切最直白的反驳是：预测会错。错了怎么办？

要避免的失效模式有一个值得借用的名字：世界末日效应（end-of-world effect）。看不到周期终点之外的优化器，会做出祸及周期外紧邻时间步的当下决策，因为在这个模型看来，周期终结之后什么都不存在。

架构一举回答了这两个问题。调度器优化 24 小时周期，但只提交当前时间步，并且每 30 到 60 分钟重跑一次。上午 9 点运行时，9 点的分配是真实的；上午 10 点到下午 5 点的计划之所以存在，只是为了让 9 点的决策由一个"知道未来存在"的模型做出。真正 10 点的分配来自 10 点的那次运行，用的是最新数据。

结果是预测误差被再优化吸收，而不是滚雪球。每轮运行继承实际正在运行的内容并将其钉在原地，因此相邻两次计划是在更新，而不是反复推翻。

还有一项次要收益。周期计划本身就是一种预测产品：它在实时覆盖风险和可预见的空闲窗口到来之前就把它们暴露出来，无论那些具体分配最终是否提交，这都有用。

这也是时间衰减权重存在的原因。到下一轮运行时，负载组合已经变了。

它能推广到什么

航空公司不是靠计算出一个最优时刻表来解决利用率的。它们的解法是把运营纪律编码进事情的先后顺序（过站流程、维护窗口、机组排班），并让这种纪律复利累积。

这里发生了同样的事。在最拥挤的场景中拿到三十三个百分点利用率、平均 52% 的优先级加权产出增益——相同硬件、相同负载、几毫秒内完成——靠的是把集群物理上允许什么编码进决策的先后顺序。结构战胜了精巧。

上一篇文章论证过，专门化与编排是同一问题的两半：专门化缩小每种负载所需的资源，编排决定省下来的部分去向何处。两个杠杆单独哪一个都不兑现。这就是后半部分被建造出来的样子。

GPU 早已装好、早已投用、早已在折旧。增益在于我们选择如何花费它们。

延伸阅读

---

欢迎 在 Hugging Face 上探索 Dharma AI ， 试用我们的交互式演示， 下载我们的开源模型，了解专用 AI 系统如何在真实企业应用中胜过通用模型。

原始来源： HuggingFace博客