GPU还有空位，训练任务却开不了工

先看一个假设：集群有8张可用GPU，甲、乙两个训练任务各需要6个工作进程，每个进程占1张卡，而且必须凑齐6个才能推进。如果两个任务交替申请，各自先拿到3张，剩余2张空着，看板会显示已有6张被分配，两个任务却都在等伙伴。

即使把剩余2张全部交给甲，甲也只有5张。继续按单个进程争取资源，解决不了这个局面。若一开始完整接纳甲的6个进程，再让乙等待，至少有一个任务具备推进条件。这里先忽略通信、存储和其他资源限制，只看成组资源被拆散后的结果。

图1｜假设共有8张GPU，甲乙各先占3张、剩余2张。每项任务最低需要6张，即使拿走全部剩余资源，任一任务也仅有5张。条形按同一零起点刻度绘制，非实际利用率。

这正是近期Kubernetes调度演进值得架构师关注的地方。2026年8月26日发布的1.37版本将Gang scheduling推进到Beta。它改变的关键是调度决策所面对的对象：从逐个Pod争取位置，走向考虑一组Pod能否满足共同运行的最低条件。

能凑成一组，和能真正跑起来，还隔着几件事

Gang scheduling通常译为成组调度。Kubernetes用PodGroup描述组，最低成员数由minCount表达。初次放置时，如果无法满足这个最低数量，组内Pod不会先被零散绑定到节点。它要减少的是开头那种“资源占了一部分，业务却无法前进”的情况。

最低数量必须来自应用。刚性的同步训练需要全部参与者到齐，就不能为了让调度看起来更顺畅，把门槛随意调低。能够弹性改变工作进程数的任务，可以考虑较小门槛，但也要确认训练框架确实支持人数变化、状态恢复和对应的计算语义。minCount是调度约束，不是给应用自动增加弹性能力的开关。

数量满足后，还要找到符合要求的位置。GPU型号、显存、设备健康状态、CPU和内存都可能限制候选节点。需要频繁同步的任务，还应评估网络连接与拓扑。如果6张卡分布在不满足通信要求的位置，“总共有6张”依然不等于有一组可用资源。

Kubernetes的DRA，也就是动态资源分配，帮助系统表达和分配设备能力；它与成组调度关注的问题并不相同。设备能被识别、单个Pod能拿到设备，并不能代替整个任务的准入判断。拓扑约束也需要实际设备信息、标签、驱动和调度实现共同支持，不能只在架构图里画一条高速连线。

还有一条容易被略过的边界：成组调度保证的不是所有进程同时启动，更不是它们运行期间永远齐员。 节点绑定完成后，镜像拉取、设备准备、数据加载和训练进程的相互发现仍可能失败。官方文档也说明，运行中的Pod被删除或驱逐后，组内数量可能降到minCount以下。

因此，任务控制器和训练程序仍要处理缺员：其他进程是继续、等待，还是从检查点恢复？失败成员重新加入时，所有成员使用的训练状态是否一致？这部分属于运行恢复，不能让调度器替它承担全部保证。

图2｜准入和运行分别检查。左类条件决定能否放置，右类条件决定放置后能否持续推进；此图不表示时序或自动恢复保证。

部署时也要核对成熟度。当前1.37官方概念文档将该能力标为Beta且默认关闭，需要启用相关功能门控。控制器集成、拓扑与设备能力分别演进，不能把“升级到1.37”写成整套训练调度已经自动就位。

让整组等待，也是在分配代价

成组准入避免了无效的部分占用，却可能增加整组等待的时间。大任务需要的资源越集中，可同时满足条件的机会就可能越少；为了它长期预留资源，又会影响能够立即开展的小任务。

回到8张卡的假设。让甲先获得6张后，剩余2张如果不能帮助乙达到最低规模，可以交给确实能独立推进的小任务。但这些任务何时结束、是否允许抢占，又会影响乙下一次凑齐资源的时机。调度策略需要考虑队列、公平性和优先级，而不是看到空位就无条件塞满。

抢占也有成本。被打断的任务可能丢失未保存进度，需要重新载入数据和检查点。如果频繁腾挪，却始终没有为高优先级任务凑出有效运行条件，只是把空等换成了反复重做。观察抢占次数不足以判断策略有效，还要看被接纳的工作是否真正向完成推进。

并非所有工作都值得绑定成组。彼此独立的批处理分片、可以独立服务的在线副本，常常能先运行一部分就产生价值。对这类负载强加不必要的整组门槛，可能白白增加等待。判断依据是成员之间的协作要求，不是任务名字里有没有“AI”。

试点时，把刚性训练和独立任务放在同一组测试中，观察从提交到有效完成的时间、长时间等不到资源的任务，以及设备已分配却没有训练进展的时段。再故意让一个成员启动失败或运行中退出，核对整项任务怎样恢复。

如果瓶颈主要是部分占用造成的相互等待，成组准入值得优先验证；若组已经齐了却仍在等数据或跨节点通信，下一步应处理相应的数据路径和拓扑。把“GPU分出去了”改成“任务在推进”，调度改造才有可靠的验收对象。