Hugging Face 提出约束感知 GPU 分配器，相同集群利用率最高提升 33 个百分点

Hugging Face 在官方博客发表了一篇工程实践长文，详细介绍其自研的约束感知 GPU 分配器（constraint-aware GPU allocator），并以 FIFO 调度器为基准进行了七组场景的对比测试。结果显示，在硬件和工作负载完全相同的前提下，新分配器最多可将 GPU 利用率提升 33 个百分点，优先级加权产出（priority-weighted output）在所有场景中均有提升，最高幅度达到 105%。文章强调，改变的不是硬件，而是分配决策的执行顺序。

问题定义：两种互斥的分配形态

文章首先把问题精确化：在每一个「GPU × 作业 × 时间步」的组合上，分配器要做一次二元决策，最终产出一张覆盖整个调度时间跨度的网格。竞争这张网格的作业分为四类——训练、实时推理、批量推理、量化——而它们又归并为两种截然不同的分配形态：

• 类批处理（训练 / 批量推理 / 量化）：一旦启动，需要占用一整块连续 GPU，中途不能被打断，直到作业完成。
• 实时推理：弹性伸缩，需求曲线随流量逐时刻变化，容量可增可减。

同一时刻、同一个硬件池里，这两种形态互相不兼容，正是 GPU 调度难度的核心。同一类作业内部也存在异构性——同样是训练，时长从几小时到数天不等，占用 GPU 数从 1 张到几十张不等。

FIFO 在争抢场景下的代价

文章以 FIFO 调度器为对照：实时推理按固定预留量保障，其余作业按到达顺序入队，不考虑优先级。在集群空闲时，这种策略与更复杂的分配器差别不大；一旦进入争抢阶段，排序成本会以两种方式显化。

一是预留代价。实时推理不能等待，调度器又没有机制在低谷期释放、峰值前回收 GPU，因此必须按全天最大需求预留资源。一个白天需要 6 张 GPU、凌晨 4 点只需 2 张的应用，会把 6 张卡全部预留一整天，中间闲置的 4 张卡任何批处理作业都无法使用。正因如此，FIFO 在两个以预留为主的基准场景中基线利用率分别只有 51.6% 和 53.6%——将近一半的算力「闲置但不可用」。

二是排序代价。在真正争抢资源时，哪些作业能塞进调度窗口，取决于放置顺序，而不仅仅是总容量。FIFO 按到达顺序放置，不评估每个作业的优先级，也不预判后续作业是否还能塞入时间窗口，导致高优先级工作排在先到请求之后，容量被不可逆地消耗。文章形象地比喻：这就好像航空公司把飞机先派给先打电话的包机客户，等到真正赚钱的航线要飞时，已经无飞机可派。

七组基准：利用率与价值双双提升

文章给出了在五组专门设计的争抢场景下的对比结果：

• GPU 利用率从 52%–85% 区间提升至 72%–88% 区间。
• 优先级加权产出提升幅度在 24.6% 到 105.1% 之间，平均约 52%。
• 每一组场景两项指标同时改善，不存在以一项换另一项的取舍。

最显著的一组是 8 卡集群上的训练密集型工作负载：利用率从 53.6% 跃升至 87.0%，价值提升超过 105%。换言之，仅靠回收整天预留的闲置容量、并把剩余作业按优先级重排，就从一块已折旧完毕的固定资产中多挤出 33 个百分点的利用率。

分配器的核心做法

针对上述两类损失，新分配器做了两处对应的修改：

• 把实时需求当作曲线而非上限：逐时刻按实际需求分配，类批处理作业填入低谷时段，但限制实时作业在相邻时间步之间可交换的 GPU 数量上限。
• 类批处理作业按优先级跨整个调度窗口放置：不再按到达顺序排队，而是从全局视角决定先后。

文章最后预告将展开这套分配器的具体实现细节。整体而言，这是一份面向工程实践的深度博客，核心信息是：在 AI 算力紧缺、集群规模不断扩大的当下，分配顺序本身就是一个容量决策，调度策略升级能带来可观的、零硬件成本的回报。