凌晨一点，机房里的风扇声比白天更明显。屏幕上，一个训练任务停在排队状态，预计开始时间一栏写着几个小时后。值班的人没有别的办法，只能等。
这种等待很常见，也很容易被归结成一个简单的结论：机器不够。但如果把排队的那段时间拆开看，答案往往没那么干脆。
停在排队，不等于卡在芯片
集群真正忙起来的时候，情况通常是这样：一部分机器满负荷，另一部分机器空着，中间隔着一层调度。任务提交上去，先等资源匹配；匹配上了，再等数据从存储里读出来；读完还要等各张卡之间的梯度同步。任何一环慢，整条链路就停在那里。
于是会出现一种错位：从外部看，集群的整体利用率并不高；从使用者的角度看，自己的任务却迟迟跑不起来。这两件事同时成立，说明瓶颈不在总量，而在流动。
很多人把算力理解成一个可以买来的数字，买到就归自己用。实际用起来才知道，它是一个被切分、被排队、被争抢的东西。同一批机器，换一种调度方式，能交付的可用时间可能差别很大。
峰值和实际之间，隔着几道坎
厂商标称的性能，通常在理想条件下测得：批处理大小合适、数据就在本地、通信开销可以忽略。真实的训练任务很少这么整齐。序列长度参差、显存吃紧、卡与卡之间要频繁交换参数，每一步都在吃掉一部分理论值。
还有一类损耗更隐蔽——为了省显存而降精度、为了稳妥而调小批量、为了兼容而绕开某些加速路径。这些选择单独看都合理，叠在一起，就让同一块卡跑出了不同的效率。同样标称的算力，落到具体任务上，差别可能比想象中大。
所以当有人问“要不要再加一批机器”，更值得先问的是：现在这批机器，平均有多少时间在真正计算？如果这个问题说不清，加机器只是把排队的位置往后挪了一点。
把已有的资源用满，是一种能力
我倾向于认为，多数团队当下缺的不是峰值，而是把资源用扎实的工程能力。这听起来不够体面，做起来也琐碎：监控要细到每个任务占了多少显存，队列要能区分紧急和可等待，空闲资源要能被小任务填上，失败的任务要能快速重跑而不是整批重来。
这些事没有一件能带来演示效果，但它们决定了一台机器一天里有多少小时在干活。利用率提上去一点，效果接近多了一批机器，而且不用等交付周期。
也不是所有活都需要大集群
另一头的问题同样值得说。有些任务被塞进了大集群，其实并不需要。小规模微调、常规推理服务、批量文本处理，用更小的资源单元跑，成本更低，调度也更灵活。把它们和训练任务混在同一套池子里抢资源，往往两头都不舒服。
区分什么该上大集群、什么该留在小池子，比一味扩容更能缓解拥挤。这条分界线因团队而异，没有通用答案，但值得每年重新问一次。与其反复争论算力够不够，不如先分清任务类型。
电、热和机位，是更硬的约束
再往下，是机房本身。机柜的供电上限、制冷能力、可用机位，这些条件不会因为需求上涨而跟着上涨。机器可以下单，电力和空间不行。当集群规模到一定程度，真正决定能跑多少任务的，可能是配电柜还剩几路空开。
这也解释了为什么有些团队明明买到了设备，却要分几个季度才能陆续上架。风扇转得再快，电表上的数字是诚实的。
回到凌晨那间机房。第二天任务跑完了，排队的人换了一批。问题没有消失，只是暂时被消化掉了。在讨论要不要再买一批机器之前，先弄清楚现有的机器有多少时间在真正计算，大概是更划算的一步。