走进一间正在满载运行的机房，一进门，先感受到的不是屏幕上的吞吐曲线，而是迎面来的热风。风扇把机柜里的热量推出来，空调再把它搬走。对运维人员来说，这股热风很诚实：机器在忙，电在烧，账单在长。
谈论算力时，人们容易把注意力放在芯片型号、单卡性能和集群规模上。这些指标当然重要，但它们只描述了“能买到多少”，没有回答“实际用上多少”。一套系统从通电到产出结果，中间要经过供电、散热、网络、存储、调度、框架适配和故障恢复。任何一环出现摩擦，纸面容量都会打折。
有效算力，不只在采购清单里
我倾向于把有效算力理解成“在可接受时间内，稳定完成有效工作的能力”。它至少包含三层：硬件是否跑在合适功耗区间；任务是否被合理编排，避免长期排队或碎片化占用；数据是否以合适方式流动，不让加速器等网络和存储。三层里任何一层松动，都会让昂贵的机器时间变成等待时间。
闲置预留是个典型场景。为了应对峰值，团队常常留出一批机器待命。预留本身不是浪费，问题在于预留多久、粒度多细、能否被低优先级任务临时填充。若缺少回收机制，备用容量就会长期空转；若回收太激进，又可能让关键任务排队。这里的取舍不是买不买机器，而是调度策略和业务承诺之间的平衡。
- 电力与冷却：高密度机柜对供电和散热提出精细要求，局部热点会限制整柜出力。
- 网络与存储：多机协作时，数据搬运可能成为隐形成本，等待会吞掉计算时间。
- 运维与故障：大规模集群里，坏卡、掉线和重试是日常，恢复速度影响可用容量。
这些环节不显眼，却决定了同样一批设备在不同团队手里能产出多少。把账算全，才会发现规模扩张不是简单的加法。多一排机柜，可能同时带来配电改造、制冷调整、网络扩容和人员负担。若只盯采购单价，后面的运营成本会在几年里慢慢浮现。
另一个容易被忽略的边界是任务类型。训练和推理对资源的需求不同，批处理与在线服务对延迟的容忍度也不同。并非所有业务都需要把模型推到很大，也并非所有请求都值得占用紧张的加速器。有些环节适合放在边缘设备上完成，有些任务可以排队到夜间，有些模型经过压缩后已经够用。判断依据应是业务目标、响应要求和总体成本，而不是单看某个硬件参数。
先把系统跑顺
算力扩张到一定阶段，瓶颈往往从“有没有”转向“顺不顺”。调度器是否理解业务优先级，监控能否提前发现热点，数据管道是否避免重复搬运，故障后能否快速隔离，这些看起来琐碎的工作，决定了资源是流动的还是淤积的。一个跑得顺的中等规模集群，往往能让日常业务少等一会儿；规模再大，如果频繁等待、反复重试，也很难形成稳定产出。这话不是否定规模，而是提醒：规模要跟着系统能力走。
对管理者来说，比较务实的做法是把算力当成一项需要持续运营的资源，而不是一次性采购的设备。先记录真实利用率，区分忙碌、排队和空转；再找出等待发生在哪一层；然后决定是扩容、改调度，还是调整业务预期。顺序反过来，容易用新增设备掩盖旧问题，最后账单变大，等待依旧。
机房里的热风不会说谎。它提醒我们，计算资源从插上电那一刻起，就同时受制于物理条件、软件效率和业务节奏。把这三件事放在一张桌上讨论，比单独追逐某个数字更接近问题的本来面目。