压测跑完，工程师盯着监控看了一会儿。请求延迟的曲线在某个并发点突然抬起来，卡的利用率却还停在并不饱和的区间。有人提议加机器，有人说先把批处理策略改一改。这类争论在很多团队里反复出现——采购单上的数字和夜里的真实吞吐之间，隔着的不是一颗芯片，而是一串容易被跳过的环节。
损耗发生在看不见的地方
真正被用起来的计算能力，和名义上买回来的，往往不是一回事。数据从存储读到显存要走一段路，样本预处理跟不上，卡就在等；多机训练时通信占掉时间，梯度同步一慢，整批任务跟着停；推理侧请求长短不齐，凑批凑得不好，长请求拖住短请求。这些环节单看都不起眼，叠在一起，就把纸面数字磨掉一截。
- 数据管道：读取、解码、增强，任何一段堵塞都会让卡空转
- 通信：多卡多机之间的同步开销，随规模放大
- 调度：任务排队、资源碎片、抢占与重试
- 软件栈：算子、编译、框架版本之间的匹配程度
这些不是买卡能解决的问题，但它们决定了一部分有效算力到底有多少。看到利用率曲线偏低时，先别急着下采购结论。
空转的成本藏在时间表里
还有一种损耗不在机器里，在排期里。为了应对偶尔的峰值，预留一批资源常年待命；白天训练、夜里推理的错峰安排，说起来简单，做起来要改流程；临时任务插进来，队列前面的作业就得让路。资源闲置不会出现在账单的显眼位置，但它确实在消耗预算。
这也解释了为什么「租」和「买」的讨论经常吵不出结果。自建意味着长期占用和运维负担，租用意味着单价之外还有调度自由度的问题。判断依据不在方式本身，而在负载的波动有多大、团队有没有能力把资源管细。业务曲线平稳、长期跑满的，和需求忽高忽低、试错频繁的，本来就不该用同一套答案。
把它当成一个数，就容易失真
把算力当成一个可以单独采购、单独比较的数字，是不少误判的起点。同一批卡，跑不同的模型、不同的框架、不同的批大小，结果差得很远；同一套集群，换一种调度策略，可用容量也会变。它更像一个随负载和软件状态浮动的区间，而不是一个固定值。
所以对外沟通时，「我们有多少算力」这句话的信息量其实有限，更有用的说法是「在什么延迟要求下，能稳定支撑多少并发」。后者不好看，但它可验证。
先问清要跑什么
需求侧的问题往往比供给侧更值得先回答。模型以训练为主还是以推理为主，请求的延迟底线在哪里，峰值能持续多久，排队是否可接受——这些答案会直接改变资源配置的形状。反过来，先定机器再找用途，多半会留下一堆利用率不好看的报表。
先把要跑的东西说清楚，再问需要多少算力，顺序颠倒过来，后面这笔账就很难算平。