GPU 集群利用率治理：碎片、排队与调度效率
说明：本篇为综述/无第一手实验数据，采用公开调度实践与运维经验路线。
实验目标
万卡集群最大的隐性浪费不是"机器坏了"，而是"机器空着但任务排不上"——GPU 利用率 60% 的集群，问题往往不在 GPU 而在调度。本篇目标：建立集群利用率治理的方法论——先定义"利用率到底怎么算"（口径决定一切）、再诊断碎片与排队的四类成因（申请过多、粒度不匹配、优先级混乱、占而不用）、最后给出作业打包、Backfill、优先级与 QoS 的治理动作。读完能回答"我的集群利用率为什么上不去，先查哪里"。
代码逐段拆解
第一段：利用率口径与诊断脚本
bash
# 口径 1：GPU 时间利用率（最常见的"利用率"）
# = Σ(有任务占用 GPU 的时长) / (GPU 数 × 统计时长)
# 数据来源：sacct / SLURM 会计数据
sacct -S 2026-10-01 -E 2026-10-08 --format=JobID,AllocNodes,ReqTRES,AllocTRES,Start,End,State
# 口径 2：GPU 空间利用率（时刻快照，与时间利用率结合）
# = 某时刻被分配的 GPU / 总 GPU
squeue -o "%i %C %t %R" | head -20 # 看当前排队与运行
# 口径 3：算力利用率（MFU 的近亲，训练侧）
# = 实际算力 / 理论算力，来自 DCGM SM 利用率（02 章）要点：
- 三种口径缺一不可：时间利用率看"集群满不满"，空间利用率看"当下空不空"，算力利用率看"占着的卡跑没跑满"——只说"利用率 70%"不说明口径就是耍流氓。
sacct是时间利用率的权威来源：SLURM 会计库记录了每个作业的申请/分配/起止，统计口径可复现。- 诊断三问：时间利用率低 → 作业少/排队策略问题；时间高但空间低 → 作业粒度太大（8 卡作业占着 8 卡只用了 4 卡算力）；空间高但算力低 → 占而不跑（大模型加载未推理、任务卡 IO）。
第二段：Backfill 与作业打包（治理动作示例）
bash
# SLURM 配置片段：开启 Backfill + 分区粒度
PartitionName=gpu Nodes=ALL DefaultTime=24:00:00 MaxTime=120:00:00
MaxNodes=32 State=UP
# Backfill 允许"小作业插进大作业等待的间隙"，默认开启
SchedulerParameters=bf_continue,bf_window=3600
# 作业粒度治理：限制单作业最小/最大卡数，防止"8 卡作业占满机柜"
MaxTRESPerNode=gpu:8要点：
- Backfill 是利用率的第一功臣：没有 Backfill，一个 32 卡作业等待时，集群宁可空着也不让 4 卡小作业先跑；开启后小作业填进大作业的等待窗口，空间利用率立刻上去。
- 作业粒度（MaxTRESPerNode/MinTRES）：限制单作业的卡数粒度，防止"一个 8 卡作业卡在 7 卡余量上"造成碎片；同时用
MinTRES防止小作业频繁启动浪费调度开销。 - 排队时间窗（bf_window）：Backfill 只填"确定会空出来的时间窗"，窗口设太长小作业等太久、太短填不满——按典型作业时长设 30-60 分钟。
原理讲解
四类低利用率成因与治理
| 成因 | 特征 | 治理 |
|---|---|---|
| 申请过多（over-request） | 作业申请 8 卡实际只用 4 卡算力 | 核算真实需求、培训用户、配额约束 |
| 粒度不匹配 | 大作业碎片化、小作业填不满 | Backfill、作业打包、粒度限制 |
| 优先级混乱 | 长作业占位、短作业饿死 | 优先级=公平+回填、QoS 分级 |
| 占而不跑 | 加载未推理、卡 IO/通信 | DCGM 监控告警（02 章）、超时回收 |
核心认知：利用率治理是"调度策略 × 监控反馈 × 用户习惯"三者的组合。调度策略（Backfill/QoS）是杠杆，但没有监控反馈（哪些作业占而不跑）就无法定向治理——02 章的 SM 利用率指标在这里是治理的数据底座。
治理闭环
sacct/squeue 定期统计（周报）
→ 按"时间/空间/算力"三口径归因
→ 定位主导成因（碎片/排队/占而不跑）
→ 对应治理动作（Backfill/粒度/QoS/告警）
→ 下周期复测对比 → 形成治理迭代治理不是一次性的：改完 Backfill 两周后要复测——利用率的改善可能被"用户申请习惯"反向抵消（调度变顺了，用户开始多申请），需要配额与培训配合。
实验结果
（估算口径，非实测）
| 治理动作 | 空间利用率提升 | 代价 |
|---|---|---|
| 开启 Backfill | +10%-25% | 调度器 CPU 开销、作业排队预测 |
| 作业粒度限制 | +5%-15% | 用户需改申请习惯 |
| QoS 分级（交互/批处理） | +5%-10% | 配置复杂度 |
| 占而不跑监控+超时回收 | +5%-20% | 需监控联动 |
工程启示
- 口径先行：三种利用率口径统一再谈治理，周报必须标注口径——否则"提升了"无法验证。
- Backfill 是投入产出比最高的第一个动作：先开 Backfill 和 bf_window，多数集群空间利用率立刻上一个台阶。
- 治理靠数据不靠感觉：sacct 定期导出 + 按作业粒度/时长/优先级分组分析，找出占大头的那类"坏作业"，定向治理。
- 与可观测性打通：占而不跑只能靠 SM 利用率（02 章 DCGM）发现——利用率治理和集群可观测性必须同一套数据。
下一篇预告：利用率治理依赖"调度+监控"，异构场景的调度在 07 章展开过；下一篇补 AMD 侧的生态——"ROCm 与 AMD GPU 训练生态：从移植到调优"。