先这样答
主要瓶颈会按排队顺序出现。第一层是模型推理并发。GPU 吞吐到上限后，请求会排队，延迟会快速上涨。第二层是外部工具和检索。Agent 发起的调用会把下游 QPS 打满，整个请求就会在工具调用处等待。第三层是状态和记忆存储。并发读写增加后，存储会成为新的等待点。
应对时，我会按层处理推理层。先扩容，再加入分级路由，让简单请求走小模型，把有限的推理资源留给更复杂的请求。工具层可以增加缓存，并设置限流，避免下游被并发请求压垮。状态层可以做租户分片，让并发读写分散到不同分片。
我不会根据用户量直接判断瓶颈，也不会只靠堆机器解决问题。上线前先做压测，观察请求在推理、工具与检索、状态和记忆存储各层的排队情况。确认真实瓶颈后，再选择对应的扩容、路由、缓存、限流或分片方案。
面试官会怎么追问
-
「为什么不能只扩 GPU？」
GPU 只能缓解模型推理层的并发压力。工具与检索的下游 QPS 仍可能先打满，状态和记忆存储也可能因并发读写成为瓶颈。所以要先压测定位排队位置，再决定扩哪一层。 -
「简单请求走小模型，会不会影响回答质量？」
分级路由不是让所有请求都走小模型，而是把简单请求和更复杂的请求区分处理。这样可以减少简单请求对推理资源的占用，把资源留给需要更强模型的请求。具体边界仍要通过压测确认。 -
「工具层为什么要同时做缓存和限流？」
缓存可以减少重复的外部工具与检索调用。限流可以控制并发请求，避免下游 QPS 被打满。两者都服务于减少工具层的排队，但解决的方向不同。
回答的坑
- 只说扩 GPU，忽略外部工具、检索以及状态和记忆存储也会排队。
- 没有先压测定位真实瓶颈，就凭感觉堆机器或直接改架构。
同系列的题
—— 本题完 ——