机房的风扇声一直响，监控面板上的利用率曲线却贴着底部走。设备是新的，采购单上的数字也漂亮，可真正在跑的作业没几个——队列里有任务在等数据落盘，有任务卡在调度，还有的因为一个算子没适配，只能退回慢路径。这类场景在不少团队里反复出现，问题往往不在机器不够，而在于把算力当成了一个可以单独购买、单独计量的东西。
一台机器跑满，靠的不只是芯片
把一张卡放进机箱，只是完成了最前面的一步。它要变成能产出结果的能力，中间隔着几层：编译器能不能把模型映射到硬件上，算子库覆盖得够不够，卡与卡之间的互联带宽是否匹配训练时的通信模式，存储能不能及时把样本喂进来。任何一层掉链子，利用率就掉下来。反过来，同样的硬件，换一套更贴合的推理引擎，吞吐可能明显不同。这也是为什么两台配置相近的机器，跑同一个模型，表现可以差出一截。
于是「有效算力」这个词更有意义：它不是标称值，而是单位时间里真正被消耗掉的计算。关心它，意味着要盯着利用率、通信占比、数据加载耗时这些不起眼的指标，而不是只盯着到货清单。
需求侧同样需要被追问
另一个常见的错位发生在需求侧。训练和推理对硬件的要求并不相同：前者看重互联与显存容量，后者更在意延迟、并发和单位成本。把一个训练集群的规格直接套到线上服务上，往往留下一堆闲置。有些任务其实可以先做量化、蒸馏，或者把重复请求缓存起来，用更小的模型解决；还有些任务，瓶颈在检索和数据处理，增加机器并不会让答案变好。
- 先量清楚业务的请求形态：峰值、平均、突发长度。
- 再判断模型是否需要改小、改快，能否分层处理。
- 然后才是选型，把互联、存储、电力一并算进去。
顺序颠倒，钱就容易花在前面、效果落在后面。
把它当作一套系统来规划
所以规划的顺序大概应该反过来：从工作负载出发，测出真实吞吐，再倒推需要多少机器；留出弹性，而不是一次买满；把运维人力、机房电力、软件栈的适配成本都记进账。算力的账不该只记在采购单上，这套账不好看，但更接近实际。
一个谨慎的判断是：随着模型结构和推理框架继续演进，单位任务所需的计算量会怎么走，目前还不好下结论——模型在变大，压缩和调度也在变强，两个方向同时在动。能确定的是，把机器买到手只是开始，让它持续跑满，才是那件更难、也更容易被忽略的事。