深夜的机房走廊，风噪比白天更清楚。运维的人常站在配电柜前看负载，而不是先盯监控大屏：屏幕告诉他集群跑得满不满，配电柜告诉他电还撑不撑得住。这两个数字有时对不上，对不上的时候，说话管用的是后者。
它不是一个可以横向比较的数
把「算力」当成一个数字来谈很省事：多少张卡、多大集群、峰值多少。这套说法在预算表上够用，到了工程现场就开始失真。真正决定跑得快慢的，是几个更琐碎的量：
- 显存放不放得下当前批次的中间结果；
- 卡间互联带宽能不能喂饱计算单元；
- 存储与数据管道会不会在关键时刻慢半拍；
- 框架版本与并行切分方式是否和模型结构对得上。
其中任何一处偏窄，整体的有效吞吐都会被压下来。买回来的是标称值，跑出来的是由短板决定的那个值。所以需要被管理的往往不是总量，而是匹配度：同一批机器，换一种切分方式，效率差别可能比换一代硬件还明显。
排队的人与空转的机器
还有一个经常被忽略的落差：忙闲不均。训练任务是脉冲式的，一次大任务能把资源吃满几周，任务结束，队列清空，机器就在那里空转。为了让资源不闲着，团队会往里塞推理、微调、离线评测，甚至一些可做可不做的实验。填充提高了利用率，也让调度变复杂——谁能插队、谁必须排队、什么时候该抢占，规则没写好，混乱比闲置更贵。
于是「够不够用」这个问题，答案常常不在总量上，而在调度策略上。排队时间长的团队去申请新机器，往往只是让排队的人变多。
不是所有问题都要往里砸
这段时间，很多需求被默认交给更大的模型解决。但有些任务是分类、抽取、格式校验，用小模型加上工程约束就能稳住；有些场景对延迟敏感，端侧推理反而更合适；蒸馏、量化这些手段，也在把一部分计算搬出机房。这并不意味着大集群失去意义，只是提醒一件事：算力是成本项，不是荣誉项。评估一次需求，先问清楚效果提升的那一点点，值不值得多出来的电费、机位和运维人力。
当预算管，别当口号报
如果让我给一条建议，大概是：把算力写进预算表，而不是写进汇报的标题里。预算的意思是可核算、有周期、要交代去向——这批资源这个季度服务了哪个目标，实际利用率多少，峰值和均值差在哪里，下一季度是续租还是退回。能回答这些问题，规模大小就没那么要紧；回答不了，规模再大也只是把不确定性一起放大。
电表还在转。它不关心集群叫什么名字，只关心这一度电换回了什么。