深夜的机房走廊，风扇声像退不掉的潮水。隔着一道玻璃，机柜上的指示灯密得像星图。可值班的人往往知道另一件事：这些机器并非时时刻刻都在满负荷运转。屏幕上那条利用率曲线，多数时候趴在低位，偶尔窜起一个尖峰，然后回落。买来的算力就停在那里，等数据、等调度、等一个还没写完的脚本。
账面数字和实际吞吐之间，隔着一段路
采购清单上写的峰值性能，是在理想条件下测出来的。真实任务里，卡要等存储把样本喂过来，要等节点之间把梯度同步完，要等框架把算子排好。任何一环慢下来，整条流水线就跟着慢。于是出现一种落差：纸面上的性能很充裕，能跑完的批次却不见得多。
所以比起盯着峰值，更值得看的是单位时间内真正完成的步数，也就是所谓有效算力。它不体面，不写在合同里，却决定了项目要熬几个通宵。把它当成一个需要持续测量的指标，而不是买完就自动获得的属性，很多困惑会消失。
电表和散热，是另一半故事
计算最终要落在电上。功率密度上去以后，机柜不再只是放服务器的地方，它变成一个需要认真设计的散热单元。有些团队把预算全压在设备上，机房还是老样子，结果设备降频运行，性能被悄无声息地削掉一截。这类损失不会报错，只会让任务慢一点点，慢到你以为是自己的代码写得不好。
位置也变得重要。电价、网络时延、可用容量，三者很难同时让人满意。把训练放在电价低的地方、把推理放在离用户近的地方，是很自然的分工，但它会把一个问题推到台面上：计算资源并不是一处集中的水池，而是分布在不同约束里的若干块资源，调度它们的难度常常高于添置它们。
有些需求，其实不该用更多机器解决
遇到响应慢，第一反应是加设备。可慢的原因可能是模型规模与任务不匹配，可能是每次都从头算而没有缓存，可能是单条请求走了串行流程。量化、蒸馏、批处理、结果复用，这些手段不新，效果却往往能省下可观的资源。反过来，如果业务本身就需要更强的推理能力，省是省不出来的，这时候添置机器才是对的答案。
判断的分界线在于：你要解决的是吞吐问题，还是延迟问题。两者对硬件的诉求不一样，混为一谈就会出现“机器加了一倍，等待时间没变”的局面。
一个不太确定的判断
单位算力的价格大概率还会往下走，这一点我比较有信心。但“能立刻用上、不用排队、不用折腾环境”的那部分计算能力，恐怕会长期偏紧，因为瓶颈正在从芯片转向电力、机房和调度水平。这意味着，未来拉开差距的，可能不是谁囤得多，而是谁让手里的资源空转得更少。
回到那条利用率曲线。它不好看，但它诚实。