一、项目背景

某算法团队攒了几十张卡的集群，白天主要跑推理服务，深夜才让训练任务上来吃空闲算力。听起来是错峰利用，实际一塌糊涂。训练任务一多就排长队，大任务卡在队首半天起不来，小任务又碎片化占着卡不释放，整体利用率忽高忽低，加卡也填不满坑。

我们进场盘点时，集群平均利用率只有四成出头，但排队里的大任务平均等两三个小时。最离谱的一次，一张卡上挂了三个占用极小显存的小任务，大任务因为凑不齐整卡只能干等。大家都在喊加卡，我们判断问题不在卡少，在调度把碎片撒了一地没收。

二、落地场景

我们做的第一件事是给任务分级，推理服务最高优先级，训练按业务紧急度排，闲时批处理最低。任务分级排队是第一段，高优任务来了能抢占低优的空档。GPU 碎片整理是第二段，把零散占用的小任务 compaction 到少数卡上，腾出整卡给大任务。抢占与优雅回收放第三段，低优任务被抢占时先存检查点再释放，不白干。空闲回收兜底，长时间不活跃的资源自动收回池子，不让它占着不用。

案例片段（已脱敏）： 任务优先级与碎片整理调度配置片段（示意）：priority: [infer=0, train_biz=1, batch=2] defrag:  enable: true  compact_small: true preemption:  checkpoint_first: true  grace_sec: 30 reclaim:  idle_min: 10上线后集群平均利用率从约 42% 提到约 68%，大任务平均等待从约 2.5 小时压到约 40 分钟，碎片率从约 30% 降到约 8%，同样一批卡多扛了约三成任务。

三、关键技术挑战与解决思路

第一个坑是优先级建模。什么算紧急容易拍脑袋，结果高优被滥用，所有任务都标最高。我们做法是优先级和业务 KPI 挂钩，且高优任务有配额上限，不能无限占。这一步比加队列重要，因为优先级失了信，排队就变摆设。

第二个难点是碎片整理本身有成本。compaction 要迁移任务、重建上下文，动得勤了反而拖慢整体。我们设了触发阈值，碎片率超线才整理，且只在低峰做，避免和高优推理抢资源。这里有个权衡，整理太勤浪费算力，太懒碎片又堆积，调到碎片率八成线附近最划算。

第三个点是抢占无感。低优训练被抢占，如果直接杀，几小时的进度没了，用户会骂。我们强制先 checkpoint 再释放，grace 期三十秒让任务自己存盘，用户几乎无感。代价是多花一点存储和秒级延迟，但信任留住了。

四、效果数据

集群平均利用率约 68%，大任务平均等待约 40 分钟，碎片率约 8%，同样一批卡多扛约三成任务。最直观的是排队长队消失了，训练同学不再半夜蹲点抢卡。我们复盘时发现，利用率上来后，原本打算新购的十几张卡可以暂缓，光这一项就省了一大笔预算。（数据均为脱敏示意值）

运维侧把调度数据接进了容量规划。哪类任务在什么时段吃多少卡，一眼看清，扩缩容不再靠猜。我们还加了碎片率预警，快到阈值就提醒运维手动干预极端情况。优先级配额也反过来驱动了业务方的习惯，大家不再无脑标高优，因为知道会被限，资源反而更公平。

五、可复用经验总结

利用率上不去，十有八九不是卡不够，是调度没把碎片收拢，加一层碎片整理和抢占回收，同样卡多扛三成任务，比加硬件划算。优先级要和业务 KPI 挂钩且设上限，失了信排队就变摆设。碎片整理别太勤，低峰触发最省。我后来觉得，GPU 集群的坑不在买不起卡，在管不好卡，调度的活儿看着不性感，省下的可是真金白银。

结语

我们后来把这套调度接进了成本中心，每张卡的产出直接挂钩业务线的算力账单，哪个团队占了多少、浪费了多少一目了然，资源争夺从扯皮变成了看数。还有个意外收获，碎片整理跑顺后，我们敢接一些原本不敢接的大训练任务，因为知道随时能腾出整卡，业务的想象力被调度能力放大了。说实话，GPU 这东西贵，但更贵的是让它空转，我们算过一笔账，利用率每提十个点，相当于白捡几张卡，这比任何采购谈判都实在。往后我们准备把优先级和业务的商业价值更紧地绑，不只是紧急度，而是这任务晚一小时到底值多少钱，调度按这个排，资源才真正流到值钱的地方。我们也踩过过度优化的坑，有一阵为了碎片率疯狂整理，结果整理本身吃掉算力，后来加了成本门禁才平衡。调度的艺术大概就是，永远在收碎片和别为收碎片而收碎片之间找平衡，这事儿没标准答案，只能靠数据慢慢调。

我们也把调度的可视化做给了业务方看，谁占了多少卡、为什么排队，一眼透明，扯皮少了信任多了。资源这件事，透明本身就是生产力，看得见才服众，这是我们从这套系统里学到的另一课。后来业务方自己会根据看板调整任务节奏，反而比我们催更有效。这比任何制度都管用，因为动力来自他自己。