有一次去看朋友的机房，他指着新上的一排机器说，这批卡买得很值。我问他电价多少、每柜功率上限多少、冷通道有没有做过封闭。他愣了一下，说这些是运维的事。三个月后，同一排机器被降频运行，原因不复杂：电来了，热出不去。
这类场景在近两年并不少见。谈算力，人们习惯先看规模，多少卡、多少P、峰值多高；真正让系统跑得稳的，往往是旁边那几个不太起眼的数字。
电先到，热后到
一台高功率加速卡满载时的发热，和它标注的功耗基本同量级。也就是说，采购单上写的是计算能力，账单上写的是电费，而机房里真正每天要面对的，是把这些热量搬出去。
风冷机柜的承载能力有物理上限。当单柜功率往上走，靠提高风速换散热效率会先撞上噪音和能耗的墙。于是液冷被反复提及，但改造不是换个水冷板那么简单：地板承重、管路走向、漏液检测、运维人员的操作习惯，都要跟着改。
很多团队的顺序是反的——先把机器订下来，再找地方放。更稳妥的顺序是，先确认电力容量与散热余量，再决定买多少、摆多密。这一步没做，后面所有的调度优化都是在补窟窿。
被忽略的中间层
除了电和热，还有一层常被跳过：网络与存储。训练任务里，卡与卡之间的等待时间，很多时候不是算得慢，而是数据没跟上。存储带宽不足，读取队列就会空转；网络拓扑不合理，跨节点通信会把并行效率吃掉一大截。
于是出现一种尴尬：设备的利用率数字看着还行，但有效产出的任务量并不理想。把算力当成单一指标去考核，很容易掩盖这些中间层的损耗。更实用的做法是把链路拆开看——供电、散热、互联、存储、调度，逐段找瓶颈，而不是笼统地问“还够不够用”。
调度是一种省钱手段
在硬件确定之后，能动的空间主要在调度上。几个方向值得留意：
- 按任务类型分层：把对延迟敏感的推理和对吞吐敏感的批处理分到不同的资源池，避免互相挤占。
- 允许弹性降级：非关键任务在用电高峰时段降低并行度，换取整体电费与散热压力下降。
- 提高小任务密度：碎片化的资源通过更细的切分被复用，减少长时间空置。
- 记录真实利用率曲线：按小时看，而不是只看月度平均，峰值和谷值的差距往往说明配置不合理。
这些动作不新，但需要有人对全链路负责。如果采购、运维、算法三方各管一段，调度优化就很难落地。
边界在哪里
也要承认，不是所有场景都需要追高。推理服务的负载相对平稳，对单卡峰值的要求没那么极端，把预算放在稳定性、网络时延和冗余上，往往比堆叠规模更划算。反过来，短期集中的训练任务，租用比自建更灵活，前提是算清迁移和调试的隐性成本。
把算力理解成一条有上限的供给链，而不是一个可以随时加购的数字，很多决策会变得具体：先问电，再问热，然后问数据能不能及时送到卡边。至于买多少，答案通常藏在那张按小时画出的利用率曲线里。
机房里那排被降频的机器后来做了冷通道封闭，功率上限重新核算，任务也按优先级重排了一遍。没有换硬件，可用容量却回来了一部分。这大概就是算力这件事的日常面貌——它不总在发布会的参数里，更多时候，在电表转动的速度里。