用户点下“生成”按钮，界面开始转圈。刚点下去时，多数人还会等；等到进度不明，手指可能已经移到返回键。对产品团队来说，这个瞬间会暴露一个常被忽略的问题：不是所有等待都来自模型能力，有些来自算力安排。
等待从哪里来
一次生成请求背后，通常要经过输入处理、模型计算、结果整理等环节。只要其中一个环节被排队，前端就会表现为“慢”。算力不足时，团队容易先想到增加机器，但资源并不是唯一变量。请求是否集中、任务是否被重复执行、缓存是否有效，都会改变等待时间。把这些环节拆开看，才能判断该扩容，还是该改流程。
把任务拆开看
有时用户只需要一个简短答复，系统却调用了完整推理路径；有时页面已经展示结果，后台还在做非必要计算。这类浪费不会写在界面上，却会占据资源。一个朴素的做法是把任务分层：哪些必须实时完成，哪些可以延后，哪些可以复用已有结果。这样做的目的不是把资源压到很紧，而是让关键步骤获得稳定空间。
推理侧也有取舍。降低输出长度、限制并发、设置超时，都会影响体验，需要和用户预期一起设计。与其让所有人一起等，不如在界面上给出明确状态：正在处理、预计还要多久、是否可以稍后查看。等待本身不一定破坏信任，模糊的等待才会。
边界感也是产品能力
算力规划常被当成基础设施问题，但它也会反过来塑造产品。一个功能如果在高峰时频繁超时，就不适合被放在主路径上；一个结果如果需要长时间计算，就应该允许异步交付。团队不必把所有能力都做成实时响应，也不必用同一套资源服务所有场景。把边界说清楚，用户反而知道什么时候该等、什么时候可以换一种方式。
回到那个转圈的界面。算力不够时，先改哪一步，没有通用答案。可以先看等待发生在哪里，再看任务能否拆分，最后确认产品是否给出了可理解的反馈。资源受限是常态，克制地设计路径，往往要从等待发生在哪里开始，而不是只增加机器。