演示常在看似平静的时候出问题。屏幕那头的问题刚发出去，进度条转了两圈，回答才慢慢浮出来。产品经理下意识说：加机器吧。工程师没有立刻点头，他先看队列，再看缓存命中，然后才看那段被反复调用的模型。
这类场景容易被归为“算力不足”，但真正让体验变差的，可能是请求在错误的时间挤进同一条通道。模型推理有高峰，也有空档；有的请求可以等，有的请求一等就失去意义。把问题全部推给硬件，等于把一段复杂的调度问题简化成采购清单。
先看队列，再看机器
在推理服务里，请求进入系统后通常要排队。队列长度、超时设置、批处理策略，都会影响用户感知。若所有请求都按同一优先级处理，短问题可能被长任务拖住；若超时设得过紧，系统会在结果快出来时放弃计算。此时增加设备当然能缓解压力，却不必然改善等待的形状。
务实的做法，是把“等多久”当成产品参数来设计。哪些请求需要即时返回，哪些可以后台完成，哪些可以在结果未就绪时给出可理解的中间状态，这些选择决定了资源怎么被消耗。把算力当成库存，就会只盯着总量；把它当成调度能力，才会去看波峰、闲置和重试。
限流不是拒绝，而是承诺边界
限流常被误解为把用户挡在门外。其实它更像一种公开的承诺：系统在什么条件下保证响应，在什么条件下坦白等待。没有边界的服务，会在压力上来时让所有人一起变慢；有边界的服务，至少能让一部分请求稳定完成，让另一部分请求知道何时再来。
这也会反向影响产品设计。如果某个功能依赖即时生成，就需要谨慎评估调用频率；如果某个功能可以异步完成，就可以把任务放到空闲时段。缓存、模板、轻量模型和人工兜底并不是权宜之计，它们是在算力预算内维持体验连续性的手段。
边界在哪里
调度和限流并不能替代基础设施。当请求量持续超过系统吞吐，当模型能力本身成为瓶颈，硬件仍然是绕不开的投入。区别在于，扩容应该建立在看清瓶颈之后，而不是把“慢”直接翻译成“买”。
对产品团队来说，算力紧张时难的并不是做一次技术选择，而是承认体验需要分层：有些等待可以解释，有些等待会伤害信任。把这件事说清楚，比单纯承诺“马上扩容”接近长期解法。