从空闲GPU到有效算力：大规模AI集群调度的演进
随着大模型训练和推理业务快速增长，GPU集群规模从千卡、万卡逐渐走向十万卡规模。表面上看，GPU资源越来越丰富，但生产环境中一个新的矛盾逐渐显现：
物理GPU增长并没有等比例转化为业务有效算力。
在早期GPU调度系统中，资源管理问题通常比较简单：
当一个任务需要GPU时，只要找到满足资源request的节点即可。
但在今天的大规模AI集群中，这个模型已经失效。一张GPU即使处于空闲状态，也可能因为以下原因无法被业务使用：
- 剩余GPU数量无法满足大规模任务；
- CPU、Memory等配套资源不足；
- 网络拓扑不满足训练通信要求；
- 优先级策略不允许被低优任务使用；
- 业务并行执行方式无法利用当前GPU数量。
因此，大规模AI集群调度正在转向如何让物理GPU在满足业务约束的情况下，持续转化为可被训练和推理任务消费的有效算力。
Alibaba在OSDI 2026发表的论文《Heterogeneity at Hyperscale: Characterization and Scheduling of Large Production AI Clusters at Alibaba》，通过对超大规模生产GPU集群的分析，给出了一个非常直接的结论：
高GPU需求并不自动带来高有效利用率。（High GPU demand does not imply high effective utilization.）
而快手在WAIC Academic 2026发表的《TIDAL: Tidal Intelligent Dynamic Allocation and Scheduling for Large-scale Federated GPU Clusters》，关注的是另一个维度的问题：
GPU资源不是静态存在的，而是在业务潮汐变化中不断流动。
通过横向对比两篇工作的技术思路，可以看到大规模GPU调度正在面临相似的问题。
一、Alibaba：从GPU资源碎片到有效资源供给
在Alibaba的生产GPU集群中，资源浪费并不只是简单的GPU空闲，而是大量GPU处于“不可交付”状态。
论文通过生产Trace分析发现，现代AI集群中的主要碎片来源已经发生变化。
过去GPU调度关注较多的Fractional GPU Fragmentation问题正在减少，例如通过GPU虚拟化将一张卡切分为多份资源导致的碎片。
但在大规模训练和推理场景中，更主要的问题来自：
- Stranded GPU：多卡节点中剩余零散GPU，无法满足大规格任务；
- CPU/GPU资源不匹配：GPU存在空闲，但CPU或Memory不足；
- Network Topology约束：GPU数量满足，但无法组成满足通信要求的拓扑结构。
1. IPC：GPU碎片整理
IPC（Iterative Partitioned Consolidation）解决的是存量资源碎片问题。
与一次调度不同，IPC不是决定新任务放在哪里，而是针对已经运行中的任务，通过迁移重新整理资源。
例如一个8卡节点已经分配：
- Task A：2 GPU；
- Task B：2 GPU。
虽然节点仍然有4张空闲GPU，但无法承载新的8卡任务。
IPC通过迁移已有任务，将多个节点上的零散资源重新归并，释放完整节点。其核心机制有三个。
分区搜索（Partitioned Search）
由于十万卡规模下无法进行全局最优搜索，IPC将集群划分为多个独立分组，在局部范围内并行寻找迁移方案。
连续迁移（Ejection Chain）
当目标节点无法直接接收任务时，通过连续迁移释放空间。
例如Job-1要迁移到Node-1，但Node-1空间不足，需要先将Job-3进行迁移，最终达到Node-0整机腾空。
先启后停（Make-before-break）
迁移过程中先创建目标实例，再删除原实例，避免业务中断。
IPC的核心价值不在于寻找理论最优方案，而是在生产环境约束下，以分钟级完成大规模资源整理。
2. 机间拓扑感知策略（Topology-aware Allocation）
除了治理已有碎片，Alibaba也关注如何减少新的碎片产生。
对于大规模训练任务，仅满足GPU数量是不够的。因此，Alibaba引入Topology-aware Allocation，在任务调度阶段尽量将大规模任务集中到更少的网络交换域中，减少由于网络拓扑造成的资源不可用。
3. SpotGPU：释放高优业务长期预留的闲置资源
除了碎片问题，Alibaba还发现了另一类资源浪费场景。
在线业务通常会为了应对流量峰值和故障切换，提前预留GPU。但是在低峰期，这些GPU并没有实际计算任务。
如果直接采用GPU Sharing，又会遇到下列问题：
- MPS/MIG隔离能力有限；
- GenAI模型显存占用较高；
- 多任务共享难以保证稳定性。
因此，Alibaba提出SpotGPU，将问题从GPU粒度提升到任务粒度。SpotGPU是一种抢占式资源机制，将集群闲置资源分配给可回收任务使用。
为了确保高优任务快速启动，高优任务可以进入Standby状态：
- 停止业务流量；
- 保留Container进程；
- 释放CPU、GPU计算资源。
当高优任务需要恢复时，系统可以驱逐低优任务，恢复高优任务。
这种方式本质上建立了一种高优资源可临时借用、能够快速回收的资源抢占机制。
4. Heterogeneity at Hyperscale的整体价值
Heterogeneity at Hyperscale的价值不只在于提出IPC、Topology-aware Allocation和SpotGPU三个机制，更重要的是通过15万卡级生产Trace重新定义了大规模AI集群里的“资源利用效率”问题。
论文通过生产数据说明，过去重点关注的Fractional GPU Fragmentation（GPU虚拟化产生）已经不再是主要矛盾，Stranded GPU、CPU/GPU配比失衡和Network Topology逐渐成为资源不可交付的主要原因；同时，在线高优业务为峰值和容灾预留的大量空闲资源，又形成了另一类资源浪费。
因此，这篇论文最值得借鉴的并不是某一个单点算法，而是它治理GPU资源的方法：
不仅要看集群还有多少GPU，更要看这些GPU能否以业务真正需要的形态被调度和使用。
二、快手：面向潮汐资源的动态GPU调度
在训练和推理混部场景中，GPU资源具有明显的潮汐特征。TIDAL关注的是GPU释放以后为什么没有被及时利用。
传统调度系统通常只能在任务启动时完成一次资源分配，但无法很好处理运行过程中的资源变化。
在大规模AI集群中，训练、推理、数据刷新等不同类型任务通常共享GPU资源池。其中：
- Online Inference需要严格满足延迟和SLO要求；
- Training需要大规模GPU并行计算；
- Offline Data Refresh更加关注吞吐，可以容忍一定延迟。
这些任务虽然都使用GPU资源，但在优先级、弹性、拓扑要求和重启成本上存在明显差异。
因此，GPU资源需求并不是固定不变的，而是随着在线业务流量呈现明显的潮汐变化：
- 白天在线推理流量增长，大量GPU被服务业务占用，离线训练和数据刷新可用资源减少；
- 夜间在线流量下降，GPU资源重新释放回集群。
TIDAL将这种现象称为Tidal Pattern。论文指出，调度系统需要同时解决两个问题：
- 高峰期如何安全回收资源，保障高优任务；
- 低峰期如何快速获取空闲资源，减少GPU闲置。
1. 潮汐资源变化带来的三个调度问题
TIDAL认为，动态资源变化带来了三个新的调度缺口。
Rising Tide阶段：高优任务无法及时获得资源
传统调度通常按照任务进入顺序分配资源。低优任务因为更早获得资源，反而阻塞了更重要的任务。
Ebbing Tide阶段：释放资源无法持续利用
资源释放发生在运行过程中，但任务规模通常在启动时已经决定。夜间持续释放的资源会继续保持空闲。
Pipeline Parallel场景：分配的GPU资源无法转化为有效算力
对于Pipeline Parallel训练，GPU扩展不是任意数量增长，分配的GPU资源不一定能够转化为有效算力。
2. TIDAL架构：联邦调度层负责决策，子集群负责执行
TIDAL在自研的统一调度联邦架构上，扩展任务负载的调度能力。
整体分为两层。
Federation Layer负责全局资源视角下的调度决策
- 判断哪个Sub-cluster可以满足任务需求；
- 依据任务优先级，综合考虑空闲资源和可回收资源的分配；
- 生成Placement决策。
Sub-cluster Layer负责具体执行
- Node级资源过滤；
- Pod放置；
- Pod抢占；
- Elastic Scale-out。
3. TIDAL的三个机制
针对潮汐资源变化带来的三个调度缺口，TIDAL分别从资源回收、弹性调度和执行语义三个方向进行优化。
整体思路可以概括为：
- Reclaim：高峰期回收低优资源，保障高优任务；
- Absorb：低峰期持续吸收释放的资源，提高资源利用率；
- Align：感知业务执行粒度，避免分配资源无法转化为有效算力。
三个机制共同解决一个问题：如何让GPU资源在业务变化过程中持续转化为有效计算能力。
Reclaim：高峰期回收资源，保障高优任务
在AI训练推理集群中，潮汐资源供给离线刷库、训练任务使用。单从调度队列中依据优先级分配空闲资源，依然无法解决时序上的低优任务占用高优任务资源的问题。
因此，TIDAL引入Collaborative Priority-based Preemption，将资源可回收性纳入Federation层调度判断。如果这些资源可以被安全回收，那么高优任务实际上仍然具备调度可能。
Fed-scheduler在进行余量探测时，不仅考虑当前空闲资源，还考虑优先级更低任务的可回收资源。
进而依据“如果允许抢占低优任务，该Cluster是否能够满足高优任务需求？”进行判断。如果满足，则认为该Placement可以下发。
Sub-cluster内的调度器（unified-scheduler）执行具体抢占：
- 选择Victim Pod：除了考虑优先级以外，还会判断Victim的运行时间、占用资源成本；
- 执行Eviction；
- 等待资源释放；
- 重新触发高优任务调度。
这种设计将“是否能够通过抢占满足需求”和“具体抢占”两个问题拆开，避免Federation Scheduler直接管理底层Pod细节。
Absorb：低峰期持续吸收释放资源
如果说Reclaim解决的是GPU不够时如何快速获得资源，那么Absorb解决的是GPU释放后如何避免重新闲置。
在传统调度系统中，资源分配通常发生在Job启动阶段，通过min-max协议分配min与max之间的资源量，即完成调度。
而离线刷库（consumer类型）任务可以接受持续提供GPU来加速任务完成。针对这种场景，TIDAL引入Continuous Elastic Scale-out机制，将运行中的Elastic Job也作为持续调度对象。
当空闲资源释放后，调度器判断距离max还可以补充多少资源。
因此，资源释放不再只是一次性的空闲事件，而成为下一轮任务调度可使用的有效算力。
Align：让Allocated GPU真正转化为Usable GPU
前两个机制解决的是GPU什么时候可以使用，但还有一个问题：分配出去的GPU是否真的能够被业务使用。
对于多机训练任务，尤其是Pipeline Parallel场景，GPU数量不是任意增长的。
例如某作业运行需要10卡，假设集群内没有buffer资源并出现单台机器故障，仅有9卡可用。此时作业重启会出现资源不足，并且9卡资源会完全闲置，直至人工运维将作业需要的资源数由10调整为9，作业才能正常启动。
如果直接配置min < max的gang调度协议，可以支持在少数节点异常时弹性使用资源。但在min-max调度模式下，由于大模型使用流水线并行技术进行加速，只有batchSize整数倍实例才可以完成组网并被有效使用，其他运行实例会产生任务内部的空闲资源浪费。
比如，单作业需要200台机器（单实例8卡），batchSize是8实例。当单台物理机故障时，剩余199台物理机，实际只能有效使用192台机器，会浪费7台。
TIDAL引入Step-aware Scheduling，将业务执行粒度引入调度。通过batchSize参数表示每次合法扩展步长。调度时：
Allocation = floor(Available GPU / batchSize) × batchSize
这样可以最大化Usable GPU。
4. TIDAL的整体价值
在实际生产环境中，TIDAL部署下的集群GPU算力活跃度显著提升，同时GPU Memory使用保持稳定。
核心指标变化如下：
| 指标 | 上线前 | 上线后 | 变化 |
|---|---|---|---|
| 平均GPU利用率（GPU Utilization） | 31.82% | 43.38% | 提升11.56个百分点 |
| GPU计算活跃度（SM Activity） | 20.41% | 29.77% | 提升9.36个百分点 |
| GPU Memory使用 | - | - | 下降约1.70个百分点 |
这里的显存占用保持集中和稳定是合理的，说明没有通过增加显存压力来换取利用率提升：
- 离线任务中有一个特征：刷库任务占用GPU显存的比例较少；
- 前后对比期间，在线推理的弹性没有缩容动机，即释放资源没有收益；
- 所以潮汐调度后，离线占用显存与在线并不是1:1置换。
三、从论文到实践：AI异构集群资源调度的演进
Alibaba和TIDAL虽然分别从不同角度出发研究GPU调度问题，但二者实际上揭示了大规模AI集群中的共同挑战：
GPU资源的有效利用，不仅取决于资源数量，还取决于资源是否满足空间、时间和业务执行约束。
在传统调度模型中，Scheduler关注的是：
找到一个满足资源request的节点。
但在大规模AI集群中，调度目标正在发生变化：
如何持续将物理GPU转化为业务真正可消费的有效算力。
从这个角度看，Alibaba和TIDAL分别解决了两个维度的问题。
Alibaba的研究主要从空间维度分析大规模GPU集群中的资源不可用问题：
- GPU节点内部碎片；
- 多GPU任务无法满足整机需求；
- CPU/GPU配比不匹配；
- Network Topology约束导致资源不可用。
对应解决方案：
- IPC进行存量碎片整理；
- Topology-aware Allocation减少新的拓扑碎片；
- SpotGPU回收Reserved-but-idle Capacity。
TIDAL则从时间维度分析训练、推理一体场景下GPU资源动态变化带来的调度挑战：
- 高峰期如何回收低优资源；
- 低峰期如何吸收释放资源；
- 如何保证分配GPU真正符合业务执行粒度。
对应解决方案：
- Priority-aware Preemption：高峰期回收资源，保障高优任务；
- Continuous Elastic Scale-out：低峰期持续吸收释放资源；
- Step-aware Scheduling：让Allocated GPU真正转化为Usable GPU。
1. 快手GPU调度实践：空间与时间维度的统一治理
论文更多关注调度模型和核心机制，而在实际生产环境中，GPU资源浪费往往同时来自空间和时间两个维度。
快手GPU调度体系也围绕两个方向持续建设：
- 空间维度：通过碎片整理和拓扑感知，提高GPU资源可交付能力；
- 时间维度：通过弹性调度和潮汐资源利用，提高GPU资源动态利用效率。
因为篇幅取舍，TIDAL论文并没有涉及碎片整理和拓扑感知亲和调度。而在实际生产环境中，快手也落地了相应的调度能力。
2. 定向迁移碎片整理能力
通过定向迁移能力，对高碎片节点进行识别和批量整理，将可迁移实例重新放置，使分散的空闲GPU重新聚合为整机、半机等可交付资源。
为了确保迁移结果可控，调度系统定义了一个Reservation对象，作为调度系统的first class。资源调度约束定义与Pod定义兼容。
执行重调度迁移前，先将指定Reservation调度到目标节点，锁定空闲资源。这样可以避免迁移过程中资源被其他任务争抢，并确保新实例可以调度到机器的这部分预留对象上。
3. 机间拓扑感知调度
目前快手的RDMA网络基础设施已经采用双平面设计：参数平面采用多轨设计，数据平面采用AZ级RDMA设计。一台机器会依据网卡所属网络拓扑，归属于不同的RDMA-POD。
因此，容器调度具备RDMA网络平面拓扑感知能力，以满足不同业务对指定RDMA平面的精准调度需求。
对于潮汐训练任务，例如需要近千卡规模的集中资源，碎片整理和在线推理缩容过程中都会感知RDMA-POD维度资源视图，通过贪心策略优先释放和聚合更大的RDMA空闲资源。
四、总结
随着AI模型规模持续增长，GPU调度正在经历一次范式变化。
Scheduler需要解决的问题，是如何让整个集群中的GPU算力持续、高效、稳定地流向最需要它的业务。这要求Scheduler不仅感知资源状态，还需要理解业务语义：
- 不同工作负载（Training、Inference、Data Processing）的资源使用模式和效率差异；
- 任务依赖的GPU型号、模型类型和执行方式；
- 业务对弹性、拓扑、优先级和稳定性的不同要求。
只有具备对资源和业务的综合感知能力，调度系统才能从简单的资源分配，演进为面向AI算力的动态管理。
最终目标不是让更多GPU处于运行状态，而是让每一份GPU算力在业务变化、硬件异构和执行约束下持续成为有效算力。