深夜的机房，风扇声像退不掉的潮水。屏幕上那条利用率曲线来回抖，偶尔冲到高处，更多时候在半山腰徘徊。机器是新的，卡是贵的，电费一分没少交，可真正在干活的时间，说不清有多少。
这类场景问的问题其实很朴素：我们买的到底是什么？
峰值只是起点
谈算力，最容易滑向参数表上那个峰值。它是理想条件下的数字：数据已经就位，计算单元不等待，散热充足，供电稳定。真实任务很少这么配合。
更常见的瓶颈在别处。数据要从内存搬进显存，权重和中间结果在两者之间来回，带宽跟不上，计算单元就空转。这有点像厨房：灶眼再多，配菜跟不上，出菜速度还是提不上去。而参数表不会告诉你配菜间有多宽。
卡与卡之间的那段路
规模一大，问题就从机器内部跑到机器之间。并行训练时，节点要频繁交换梯度或激活值，互联带宽、网络拓扑、通信与计算怎么排布，都会把这个过程拖慢或者理顺。有时只是把通信藏进计算里，看起来什么都没变，实际吞吐却不同。
这一段常被忽略，因为它不在宣传页上。但它决定了多张卡能不能像一张卡那样协同。
电和热，更硬的边界
功率密度上去之后，机柜的供电能力、配电冗余、散热路径，往往会先于芯片本身成为约束。风冷有它的物理上限，液冷则意味着改造管道、核算地板承重、重写运维流程，甚至影响机房选址。这些事没有一行代码优雅，却直接决定能不能把机器装满、装满之后能不能一直跑。
所以很多时候，卡住算力的不是买不到卡，而是买回来之后放不下、供不起、散不掉。
利用率藏在调度里
还有一个指标很少被摆到台面上：这些资源到底被用了多少。集群里排队、抢占、碎片化，一个任务要八张卡，集群里恰好空着七张，它就继续等。任务规格和资源形状对不上，算力就停在等待里。
调度器做的事不显眼，却常常比再添一批机器划算。把任务切分、把优先级排好、允许小任务填缝，这些是工程活，不是采购活。
也不是所有活都需要它
反过来也要说一句：并非所有任务都值得往最大的机器上放。小模型、低延迟的推理、规则清晰的业务，更在意的往往是响应稳定和成本可控。把这类任务塞进大集群，可能只是把简单问题复杂化。
判断的起点应该是任务本身：需要多快的响应，多长的上下文，多高的并发。答案不同，配置就该不同。
回到那个机房。风扇照旧响，曲线照旧抖。真正要回答的，不是设备的峰值有多高，而是它在一天里有多少时间在做有用的事，以及为了这些时间，我们付出了什么。