夜里收到告警，说推理接口的响应时间涨了几倍。打开监控面板，加速卡的占用率却停在四成上下。硬件没坏，流量也没有突然翻番，问题卡在中间那一段：请求在队列里排着，模型在等数据搬过来，卡在等活干。这种场面看多了，会慢慢觉得，「算力」这个词被用得太顺手，反而把真正的形状遮住了。
标称的峰值，和真正跑起来的那部分
参数表上的数字往往是理论峰值，前提是数据喂得足够满、精度设置刚好、通信不拖后腿。真到业务里，一个模型要经过预处理、批处理拼装、显存搬运、结果回收，中间任何一环慢一点，卡就得空等。空等的时候，占用率看着不低，实际吞吐上不去。所以讨论算力时，比起总量，更值得问的是有效利用率——同样的机器，一小时里究竟有几个分钟在真的做乘加。
容易被忽略的堵点：显存与调度
把模型塞进显存是一门手艺。上下文变长、并发变多，显存占用会非线性地往上走，于是要么降并发保延迟，要么加机器保吞吐。很多所谓「不够用」的抱怨，拆开看是显存不够，而不是计算不够。另一头是调度：谁先跑、跑多久、能不能被打断，这些策略决定了队列的形态。调度写得粗糙，高峰时就会出现小任务被大任务堵住的情况，用户感知到的慢，和芯片本身无关。
还有一种更隐蔽的浪费：为了应对偶尔的峰值，按峰值配置资源，其余时间它就在那儿亮着灯，电力、机位、运维人力都跟着走。设备一旦变成固定资产，成本结构就和使用率脱钩了，这也是自建与租用之间反复拉扯的原因之一。
有些问题，加机器解决不了
延迟高，不一定是算得慢。可能是网络往返太长，可能是模型本身太大，也可能是业务逻辑里串了太多同步调用。这时候再堆机器，只是把同一个瓶颈复制了若干份。判断的方法不复杂：先看时间花在哪一段，再看那一段是不是并行能解决的。若瓶颈在数据搬运或串行逻辑，扩容的边际效果会很薄。
反过来，有些场景确实该加，比如批量离线任务、可以容忍排队的训练作业，以及请求之间彼此独立、加机器就能线性摊薄的服务。区别在于任务形态，而不在于数字大小。
一个更实用的提问方式
与其问「需要多少算力」，不如问三件事：这批任务的延迟底线是多少；峰值会持续多久；能不能接受排队。答案不同，配置的思路完全不同。有的团队把离线任务挪到夜里，白天的资源就宽松了；有的把长上下文请求单独分池，短请求的体验立刻稳了。这些都是调度层面的事，成本远低于添置设备。
机器会继续变快，这一点大概不会变。但真实系统里的瓶颈，总是从一处挪到另一处：今天卡在显存，明天可能卡在存储读写，后天卡在机房间的数据同步。把这个迁移过程看清楚，比盯着一个总量数字有用。算力是必要条件，却很少是全部条件——这句话听着平淡，但每次排查到深夜，它都站得住。