凌晨三点，值班同事发来一张截图：推理接口的耗时曲线抬头，队列里堆着请求。第一反应往往是“算力不够”，接着就是加卡、扩机器。可真正把服务拖慢的，未必是芯片数量。
把算力理解成“能跑多少模型”，容易漏掉另一半：数据从内存搬到计算单元要多久，请求能不能被均匀分到不同设备，缓存命中率是否稳定，批次大小是否合适。这些环节只要有一处卡住，机器再多，等待也会留在原地。
排队的位置，比总数更能说明问题
观察一个推理服务，先看队列出现在哪里。是请求进入时排，还是模型加载时排，抑或输出阶段排。不同位置指向不同瓶颈。若是输入长度波动大，短请求被长请求挡住，问题可能在调度策略；若是显存接近上限，系统频繁换入换出，增加设备未必立刻改善体验；若是网络把中间结果来回搬运，计算单元反而在等数据。
这也是“算力”常被误读的地方。它不是一个孤立数字，而是一组资源协同后的可用能力。采购清单上的峰值参数，和业务侧感受到的稳定吞吐，中间隔着软件栈、并发模型和运维习惯。把所有延迟都归因于硬件，容易让真正的问题继续藏在监控盲区里。
先做减法，再决定是否加机器
遇到性能压力，可以先做几件不花钱或很少花钱的事：
- 把请求按长度和优先级分开，避免长任务阻塞短任务；
- 记录排队时长、设备利用率和内存占用，区分“忙”与“等”；
- 检查批次策略，确认批量增大后延迟仍在可接受范围；
- 为缓存和中间结果设定清晰的生命周期，减少重复计算。
这些动作不能替代扩容，但能回答一个关键问题：当前缺口是持续性的，还是局部调度造成的。若是前者，扩容有明确目标；若是后者，新机器可能只是把排队从一个环节挪到另一个环节。
边界感也是一种工程能力
并非所有场景都需要把模型留在云端。对时延敏感、数据不宜外传或网络不稳定的任务，边缘侧的小模型可能更贴近约束；对离线批处理，错峰调度可以作为选项。这里没有通用答案，只有任务约束下的取舍。把“算力”当作唯一变量，容易忽略产品体验、维护成本和团队能力这些同样真实的限制。
我更愿意把算力看成一种需要被经营的基础设施：知道它在哪里被消耗，知道哪些等待值得容忍，知道什么时候该加，什么时候该改。凌晨三点的队列不只是容量问题，它也在提醒我们，系统的瓶颈常常藏在“以为已经解决”的地方。