提到这个词，多数人想到机房里成排的卡。真正跑过线上服务的人会发现，账单上跳动的数字和卡的数量关系没那么直接。
先把概念拆开看。它不是一个速度值，更像一条链路的通行能力：显存带宽决定数据搬得快不快，卡间互联决定多张卡能否像一张那样工作，调度决定空转占了多少时间。任何一处卡住，继续堆硬件都像在拓宽一条下游设有收费站的公路。
卡多，不等于队列短
推理服务里，一次请求要经过排队、组批、逐字解码。批量调大能提高吞吐，却把首字延迟推高；调小则让昂贵的显存空转。这是一道取舍题，不是一个可以买到的参数。
- 显存带宽与容量常常互斥，要装下更长的上下文，往往得在速度上让步
- 组批策略既决定单位时间能处理多少请求，也决定最慢那位用户要等多久
- 跨卡互联的差距在单机测试里几乎看不出来，一上多机就暴露
- 空闲率最容易被忽略，白天与深夜的曲线完全是两种形状
一次性支出，与每天的水电
训练更像盖房子，投入集中；推理更像每天的房租，按调用量持续流出。调用量翻倍，算力需求不一定跟着翻倍——输入输出的长度、缓存的命中率、请求到达的形状，都会改变结果。所以按月看账单，比按峰值看更有意义。
也正因如此，一部分团队把注意力从“买更多”挪到“用更少”：量化、蒸馏、结果缓存、把简单请求路由给更小的模型。这些手段都有代价，回答质量、维护复杂度，以及在某些场景下反而更慢，需要逐项权衡，而不是一把梭。
有些瓶颈不在机器里
排队变长的时候，第一反应往往是加卡。但问题也可能出在数据管道、鉴权链路，或者一次不必要的重试风暴上。把这类问题归到算力头上，钱花出去了，曲线依然平。
更值得先问一句：这次请求值得动用多少算力？一个能被规则处理清楚的字段抽取，送去大模型只是让账变得更复杂。
硬件会继续变快，这一点大概不用怀疑。但在变快之前，把链路上每一段都看清楚，是更便宜的一件事。账单不会说谎，它只是不解释。