深夜的机房走廊，运维同事盯着配电柜上的电流读数，恒温送风的声音盖过了说话声。新到的一批加速卡还堆在纸箱里，机柜的功率上限先到了。接下来的会不再是“要不要上”，而是“哪几台先上、哪几台等改造”。这一幕很少出现在关于大模型的公开讨论里，却决定了纸面数字能落地多少。
标称的数字，和能用的数字
设备手册上的峰值指标，是在供电充足、散热到位、任务足够大且规整的条件下跑出来的。真实机房很少这么理想。风冷机柜能承载的功率密度有限，改液冷要重新规划管路、承重和消防，周期以季度计；同样的机器，换一个机柜、换一个季节，实际能跑出的有效算力就不同。问题通常不在设备本身，而在它周围的配套。
让设备闲下来的，往往不是设备
训练任务排队时，常有人先怀疑卡不够。把监控曲线摊开看，情况往往是另一回事：
- 网络：多机训练时节点之间的通信把时间吃掉，卡在等数据；
- 存储与数据管道：读盘和解码跟不上，预处理变成瓶颈；
- 任务形态：小任务切得太碎，单卡装不满，显存和带宽一起浪费；
- 排队策略：高峰挤在一起，低谷整排机柜空转。
这几项里，前两项靠采购解决，后两项靠调度和管理解决。后者不需要新预算，但要有人愿意花时间读监控、改流程。
有些场景，改方法比加机器划算
不是所有任务都值得往上堆设备。推理服务的并发不高时，量化、批处理、结果缓存这些手段往往更快见效，交付周期也短。反过来，如果模型迭代节奏快、训练任务重，压缩和剪枝省下的时间，可能还抵不上重新调参、重新验证的成本。判断依据不是“越大越好”，而是任务形态、迭代频率和延迟要求三者之间的取舍。
这里有个容易被忽略的边界：增加算力能缩短训练时间，但对已经接近收敛的任务，多出来的部分可能只是把同样的实验跑得更快，而不是跑得更好。投入之前先问一句“多出来的时间用来做什么”，比问“还能加多少”更有用。
把它当成一项需要计量的预算
机房里的电表、冷却水的流量、任务的排队时长，其实都是可以记录的。把这些数据攒起来，容量规划才有依据：哪些时段紧张、哪些任务可以错峰、哪些项目长期占着资源却少有人用。算力一旦按预算来管理，讨论就会从“有多少机器”转向“这批资源用在了哪里、换回了什么”。这个转变不热闹，但通常比再买一批设备更能缓解紧张。
回到那间机房。后来他们做的是把新卡分批上架，先补齐供电和监控，再按任务优先级排班。设备还是那些设备，等待的时间短了一些。这类工作很少被写成故事，但它正是计算资源从参数表走进日常的那一段路。