同一批GPU,换一种排队方式,利用率能差33个百分点——这是Dharma-AI团队最新公布的数字。他们做了一个“约束感知”的GPU分配器,在完全相同的硬件、完全相同的负载下,把它和最朴素的FIFO调度器放进同一个集群,跑了7组基准测试。结果没有例外:利用率涨了,优先级加权的产出也涨了,最猛的一个场景涨幅过一倍。硬件一张没多,变的只是谁先谁后。
这事有意思的地方不在于“调度算法又聪明了一点”,而在于它把一句听起来很虚的话——“把GPU用满”——拆成了两笔可以分开算账的成本:一笔是给实时流量留的空座,一笔是排队顺序本身吃掉的容量。账拆开看,才看得清企业到底在为什么样的浪费买单。
一张网格,两种脾气不合的活
“让GPU忙起来”不是一个系统能直接执行的指令。真正要做的决定,是每一张GPU、每一个任务、每一个时间片上的一次二选一:跑还是不跑。把整个调度周期铺开,就是一张网格,每个格子要么写着任务名,要么空着。
四类任务在抢这张网格:训练、实时推理、批量推理、量化。训练、批量推理、量化脾气相近,统称batch-like——一旦开工,就要占住一整块连续的GPU,直到跑完,中途不能打断。实时推理正好相反,它是弹性的,需求随流量涨落,这一秒要六张卡,下一秒可能只要两张。
两种脾气的活,同一时间抢同一批硬件,这是问题的根。
FIFO的两笔隐性账
FIFO调度器处理这个矛盾的办法很直接:给实时推理按全天峰值预留GPU,剩下的按谁先到给谁。近水楼台先得月,先到的先占坑,不管这坑对整体产出值不值。
第一笔账是预留成本。一个应用中午要六张卡、凌晨只要两张,FIFO没办法在低谷把多余的卡收回来借给别人,只能把六张卡焊死一整天。四张闲卡不是没人用,是不能给别人用——这笔钱不管集群忙不忙都在付,只是不忙的时候看不出来。原文里两个以预留为主的场景,基线利用率都卡在五成出头,大概就是这个原因。
第二笔账是顺序成本。集群一旦紧张,谁的任务能塞进去,不再只取决于还剩多少容量,也取决于先来后到的顺序本身。高优先级的任务排在无关紧要的任务后面,等它轮到,合适的空间已经被占掉了。这就像一家航空公司把飞机先派给最早打电话的包机客户,轮到真正赚钱的航线时,已经无机可派。
两笔账叠在一起,就是FIFO在竞争下的真实代价:整天焊死的座位,加上按到达顺序乱塞的剩余空间。
最猛的一次:53.6%到87.0%
7个场景里,5个专门构造出竞争的场景,利用率从52%-85%的区间整体挪到72%-88%;优先级加权的产出,涨幅在24.6%到105.1%之间,平均52%。
| 场景 | 利用率变化 | 价值提升 |
|---|---|---|
| 混合控制(8卡) | 51.6%→72.4% | +54.8% |
| 训练密集型(8卡) | 53.6%→87.0% | +105.1% |
| 规模测试(64卡) | 44.9%→44.9%(持平) | +15.9% |
| 统一优先级(14卡) | 76.8%→87.5% | +23.1% |
最强的一例出在8卡的训练密集型场景:利用率涨了33个百分点,加权产出直接翻倍还多。规模测试和统一优先级这两组更值得多看一眼——前者利用率一分没涨,产出却多了近16%,说明“填满机器”和“填对东西”是两件事;后者把所有任务优先级强行拉平,利用率照样从76.8%冲到87.5%,证明这套方法不是单纯靠“谁重要谁先上”取巧,把任务在整个时间窗里统筹摆放本身就有增量。
好看的利用率,可能只是挑了好放的货
前半段的数字很硬,但作为读者,我更想追问一句:这些提升是从哪儿来的。
原文把FIFO简化成“按到达顺序分配,不看优先级”,却没说清它对照的到底是最原始的头部阻塞,还是带插队填空能力的更成熟的FIFO变体。两种基线的差距可能很大——如果对照组本来就选了一个偏弱的版本,33个百分点的意义就要打折扣。
更关键的问题是:利用率涨了,到底是“回收了闲置的预留卡”,还是“把难安置的大任务往后推甚至挤出了队列”。原文自己给出的规模测试场景已经提示了答案的复杂性——利用率原地不动,产出却涨了近16%,说明同样的占用率背后,机器上跑的东西可以完全不同。这也意味着,如果分配器倾向于优先安放容易拼凑的小任务,利用率和优先级加权产出都能好看,但真正卡资源、卡进度的那批大任务,排队时间、完成率、有没有被反复预占,原文一个数字都没给。
- 风险.利用率和产出双双上涨,不能排除是靠优先安放"好放的活",把难啃的大任务往后压
企业采购决策要看的从来不是一份利用率曲线,而是队列里那些等得起、等不起的任务分别等了多久。这套方法目前展示的是“整体产出更高”,还没展示的是“每个任务被公平对待到什么程度”。这道题不解开,GPU管理的“成熟实践”这顶帽子戴得还早。
排队顺序不是效率的余项,是一次实打实的容量决策
判断
这篇东西的价值,不在于33个百分点这个数字本身,而在于它把“利用率低”这句抱怨拆成了两笔可以分别核算的账:预留浪费和顺序浪费。这个拆法比单纯喊“要用满GPU”进步得多,企业审自己的调度器时,应该按这个框架去查账,而不是只看仪表盘上一个笼统的百分比。
但一份由团队自己发布、自己评测、自己写基线的benchmark,天然带着“选择性展示”的嫌疑。要真正验证这套方法,还得看三样东西:多组随机种子和置信区间、对抗性的极端负载比如大任务集中同步到达、以及公平性和排队时延这些用户侧指标。这些原文目前都没给。
- 结论.利用率提升的机制解释比数字本身更硬,值得企业照着这个框架审自己的调度器
利用率和优先级加权产出这两个指标都在涨,这件事我信;涨的代价由谁来承担,现在还看不清。