机房里最热闹的时刻往往在凌晨。白天的训练任务排队等着，夜里腾出窗口才轮到自己，进度条爬得很慢，机柜风扇的声音始终没停。站在走廊里听一会儿，会觉得所谓智能，首先是一阵风和一片电表读数。
买回来不等于跑得起来
关于算力的讨论常从采购数字开始：多少张卡、多大集群。但设备到位和任务跑完之间隔着一段距离——卡间通信、任务切分、故障重启、等待数据加载，每一样都要吃掉时间。利用率上不去的时候，扩容只是把等待摊薄，单位时间的产出并没有变多。这也是为什么有些团队设备翻了一倍，交付周期却没怎么缩短。
电和热开始有发言权
单机柜功率密度一路往上走，风冷越来越吃力，液冷从可选项变成需要认真算账的方案。选址的逻辑也在变，从“离用户近”转向“离电近、离水近、气候凉”。算力的扩张第一次这么明确地撞上物理条件：不是买不到设备，而是供不上电、排不出热。这一层约束不像芯片型号那样容易被讨论，却更难绕开。
调度本身也在生产产能
同一批机器，怎么分配任务，结果差别很大。训练任务能吃满整机，推理任务更在意延迟；把两者混跑、错峰填谷，能让闲置窗口少一些。碎片化的资源如果能被拼起来，等于凭空多出一部分产能，而不必新添设备。反过来，调度粗糙的集群，看起来规模可观，实际能交付的部分要打折扣。
不是所有问题都值得加卡
也有另一面。量化、蒸馏、端侧小模型这些年进展不小，很多业务场景对延迟敏感，对参数量并不敏感。先把瓶颈搞清楚——是模型能力不够、数据不行，还是工程链路太慢——再决定要不要扩集群，通常比直接下单更省钱。计算资源是通用的，但把它用在刀刃上需要具体判断，而不是默认越多越好。
我倾向于认为，接下来一段时间里，制约会更多来自电、散热和调度能力，而不是设备本身的数量。它会越来越像水电：平时不觉得，断了才知道。