一次内部评审，投影上第一页是几张卡的规格表，峰值数字加粗居中。翻到最后一页，才是机柜功率、线路改造和一年的电费估算。讨论到后半段，问题从“买哪种卡”变成了“这层楼还能不能再加两个机柜”。
峰值数字和实际吞吐之间隔着一段路
规格书上的数字，是在理想条件下测出来的。真跑起来，卡常常在等：等数据从存储里搬过来，等调度分配任务，等一个批次凑齐再一起算。内存带宽、互联带宽、存储读写，任何一环跟不上，峰值就只是纸面上的数字。
所以业内更愿意谈“有效算力”——它不是买来的，是调出来的。批大小怎么设、精度压到哪一档、并行策略怎么切，这些参数改一改，同一批硬件的实际吞吐能差出不小的一截。这部分收益不需要新增采购，但需要人，也需要反复试。
利用率是个不太好看的指标
很多集群的麻烦不在于总量不够，而在于闲。任务集中提交时排队，跑完一段又空着。利用率低的时候，继续扩容带来的边际收益会被摊薄得很厉害。
- 空转的设备照样耗电，风扇照转，制冷照跑；
- 显存被切得很碎，大任务排不上，小任务又占不满；
- 长尾任务收尾时，整机在等最后一个进程。
这些问题芯片解决不了，属于调度、配额和队列设计的事。先看利用率，再看采购单，顺序反过来容易花冤枉钱。
电和热是绕不过去的硬约束
单机柜功率往上走之后，供电改造、制冷方式、甚至楼层承重都会变成前置条件。有时候不是买不到设备，是没地方插、没地方散热。把算力当成一项基础设施而不是一件设备来看，预算表的结构就会变：机房、配电、运维人力，这些原本被归到“其他”的条目，权重会明显上升。
不是所有活都需要更多
推理侧有不少任务，用中等规模的模型就能做完，响应还更快。把训练侧的标准直接套到推理上，很容易过度配置。反过来，一些看起来轻的活——长上下文、多轮检索、批量文档处理——对显存和带宽的要求并不低，按参数量估算常常会漏掉这部分开销。
值得先分清的是：这批任务属于训练、微调，还是在线推理？三者的资源曲线差别很大，混在一张表里算，结论往往失真。
换个问法
与其问“需要多少算力”，不如问“在多长时间内要跑完多少活”。把单位任务的成本、排队等待时间、电费和维护摊进去，得到的数字未必好看，但至少能用。比如一个 nightly 的批处理作业，允许跑六小时还是必须两小时完成，对应的配置方案可能完全不同。
回到那张采购单，比较务实的做法是先量一量手里现有的设备有多少时间在真正干活，再看瓶颈卡在哪一环。如果利用率本身还有很大空间，先做调度和参数优化，往往比直接下单更划算。