凌晨的机房走廊，冷通道地板下送风，声音比白天更清楚。运维人员先看的往往不是监控大屏，而是配电柜上的表：负载到了哪一档，哪一路温度偏高，风扇是不是在满转。这个动作很朴素，却比很多参数页更能说明问题。
先看电表，再看参数
谈算力，习惯从芯片说起：制程、显存带宽、互联速率。这些当然重要，但它们描述的是单点能力。真正决定一套系统能不能稳定跑起来的，常常是更土的东西——市电容量够不够，机柜能不能把热带走，网络会不会在横向扩展时堵住，任务排布是否让设备长时间空转。参数写在纸上，电表读的是现实。
功率密度把老机房逼到墙角
机柜功率密度在往上走，这是看得见的趋势。过去一间机房按较低密度设计，风和电都留有余量；现在同样面积的机柜要塞进更多计算单元，风冷的边界就露出来了。不是买不到设备，而是电送不进去、热带不出来。改造往往涉及配电、消防、承重和楼板开孔，周期比采购长得多。于是出现一种错位：设备到货很快，能通电的地方却有限。
集群不是单卡的加法
把很多计算单元连在一起，并不会自动得到等比例的产出。通信开销、任务切分、故障恢复都在吃掉效率。训练任务对网络抖动敏感，推理任务又常常受限于请求的波峰波谷。调度做得好，碎片时间能被拼起来；调度做得粗，设备看着在忙，实际有效时间很短。算力的边界往往不在计算单元本身，而在把这些单元组织起来的那层软件和网络。
效率提升不会让需求消失
模型侧一直在做压缩、蒸馏、稀疏化，单位任务的计算开销在下降。但开销下降之后，原本因为太贵而不做的事开始被尝试，总用量未必跟着降。这个规律在其他基础设施上也出现过，不必急着下结论，但至少说明：只盯着单次成本，容易误判整体压力。
把它当水电，而不是清单
更务实的做法，是给算力配上计量和调度：知道每一类任务吃了多少电、占了多少时间，才能在波峰时错开，在闲置时回收。这听起来不新鲜，落地却需要把机房、网络、平台团队拉到同一张桌子上。采购清单解决的是有没有，计量和调度解决的是用不用得上。
回到那条走廊。电表上的数字慢慢爬，风扇声跟着变调。它不会告诉你模型效果如何，却能诚实地反映这套系统被用到了什么程度。看懂了这块表，再谈扩容，判断会稳一些。