凌晨两点，机房的走廊灯只留了一半。风扇声没停，监控屏上的利用率曲线却滑到很低的位置。设备是好的，只是没活干。
这类画面在讨论“够不够”的时候很少出现。采购单按最忙的那一周估算，实际使用却跟着业务节奏起伏，中间的差额不会消失，它变成电费、折旧，以及被占住却排不上用场的机位。
峰值买，均值用
按峰值配置本身没有错。业务会突发，模型会临时重跑，留出余量是常识。问题在于余量留多少、留多久，往往没人专门负责。预算批下来的那一刻，故事就结束了；真正难的部分——谁在用、用多久、什么时候该收回——被推到后面。
于是出现一种奇怪的状态：一边是排队等资源的团队，一边是闲着的机器。两者同时存在，说明瓶颈不在算力总量上。
它不是一种均匀的东西
把算力想象成电力，容易得出“多拉几根线就行”的结论，但机器并不是同质的。显存容量、卡间互联带宽、单卡性能，任何一项成为短板，整体就会卡在那里。加机器不一定更快，有时候只是让等待的队伍变长。需要判断的是任务究竟卡在哪一环，是访存、是通信，还是调度排队。
训练与推理的差别也在这里显出来。前者要长时间稳定占用，后者要低延迟和弹性，两者混在同一批机器上，谁都不舒服。
调度的天花板常在组织里
技术上的调度器并不稀奇，排队、优先级、配额都能做。难的是规则：谁的任务可以让路，什么情况下可以插队，闲置多久才算浪费。这些不是代码问题，是分配问题。很多闲置并非因为没有工具，而是因为没有人愿意承担“把别人的机器收回来”这件事。
省电费是最容易看见的那一步
电费醒目，却未必是最大的一块。设备折旧按时间走，不看忙闲；为峰值准备的那部分容量，闲时依然占着预算和机房空间。反过来，把利用率当成唯一指标也有风险：一点余量都不留，团队不敢试新东西，一次突发就能把排期打乱。
所以更实际的做法，可能是把算力当成有保质期的资源来管——它按小时老化，不按库存计价。买之前看峰值，买之后看曲线；扩容之前，先确认瓶颈落在哪一层。深夜机房的风扇声不会骗人，它转着的每一分钟，都在回答同一个问题：这些机器，到底在替谁干活。