目录

🍕一、流量削峰与排队机制（第一道防线）

🍕二、LLM调用层的“熔断与重试”策略（核心难点）

🍕三、模型路由与降级（高可用关键）

🍕四、显存与计算资源隔离（针对自建模型）

🍕五、Agent循环的“防死循环”与超时控制

🍕六、可观测性（没有监控就没有稳定性）

🍕七、面试回答

---

一、流量削峰与排队机制（第一道防线）

多个用户同时请求，最怕瞬间流量击穿网关或导致模型服务OOM。

• 全局限流：在网关层使用令牌桶或漏桶算法。不仅限制总QPS（每秒查询数），还要按用户等级（如VIP/普通）设置不同的配额。例如，普通用户每分钟10次，VIP用户每分钟50次。
• 优先级队列：Agent任务往往有长有短（有的只需1秒，有的需循环调用工具5分钟）。将请求放入基于Redis的优先级队列，交互式对话（用户等着回消息）优先级高于后台批处理任务。
• 请求合并：如果并发量极大且任务相似（如简单的分类Agent），可在网关层将多个用户的请求拼成一个Batch，一次性发给LLM，显著提高GPU利用率。

二、LLM调用层的“熔断与重试”策略（核心难点）

LLM API（无论是自建还是云服务）是最不稳定的环节，经常返回超时或5xx错误。

• 超时分级控制：不要只设一个总超时。建议设置连接超时（3s）、读取超时（根据Token数动态计算，如60s）。如果用户问“写一万字小说”，超时设置应能动态伸缩。
• 指数退避重试（Exponential Backoff）：遇到限流（429）或服务端错误（503）时，必须重试，但不能立即重试。采用随机指数退避（如等待 1s -> 2s -> 4s + 随机抖动），防止“重试风暴”把服务彻底打垮。
• 熔断器（Circuit Breaker）：如果某个模型API连续失败5次，直接打开熔断，后续请求快速返回降级提示（如“模型繁忙，请稍后”），不再浪费时间等待超时，给模型服务留出恢复时间。

三、模型路由与降级（高可用关键）

不要死磕一个模型，要建立模型池。

• 主备切换：主模型（如GPT-4）挂了或太慢，立即降级到备用模型（如GPT-3.5或自研7B模型）。虽然效果差一点，但可用性高于一切。
• 语义缓存（Semantic Caching）：对于高频常见问题（如“帮我总结这篇文章”），使用向量数据库缓存之前的回答结果。如果新请求的向量相似度超过0.95，直接返回缓存，零耗时，极大释放并发压力。

四、显存与计算资源隔离（针对自建模型）

如果Agent服务使用本地私有化部署的模型（如vLLM或TGI）：

• P-D分离架构：将Prefill（计算密集型）和Decoding（带宽密集型）阶段分离。避免一个用户的长上下文预处理占满GPU，导致其他用户的生成速度骤降。
• KV Cache 动态抢占：启用vLLM的preempt机制。当显存不足时，将低优先级用户的KV Cache暂时交换到CPU内存，优先保证高优先级用户的生成，待资源空闲再恢复。

五、Agent循环的“防死循环”与超时控制

Agent会调用工具（Function Call），这比纯文本生成更危险。

• 最大迭代步数（Max Steps）：必须硬限制，如最多5轮工具调用。防止Agent因为LLM幻觉而陷入“调用-报错-再调用”的死循环，浪费海量Token和显存。
• 流式交互（Streaming）：不要等Agent完全结束再返回。将LLM生成的第一个Token立刻通过SSE（Server-Sent Events）推送给用户。用户看到文字在“蹦”出来，心理等待时间缩短50%，有效降低前端超时断开的风险。

六、可观测性（没有监控就没有稳定性）

• 全链路追踪：给每个用户请求生成唯一的trace_id，贯穿网关、Agent编排层、LLM调用层。记录每次LLM调用的TTFT（首Token时间）和TPOT（每Token输出时间）。
• 告警规则：设置“TPOT超过50ms/Token”即触发告警，这往往意味着显存碎片化严重，需要重启模型实例。

总结：
多用户并发下的LLM稳定性，30%靠模型能力，70%靠工程化策略。核心就是限流保底、熔断止损、降级求生、缓存提效。

七、面试回答

要保证多用户同时请求时 LLM 调用的稳定性，我主要从三个层面来考虑：

第一，限流和排队，防止系统被打爆。

LLM 服务（不管是 OpenAI 还是自建模型）都有并发上限。我会用令牌桶或漏桶算法做限流，比如限制单用户每分钟最多 10 次请求。超出的话，直接返回‘繁忙，请稍后’，或者用消息队列（比如 Redis 或 RabbitMQ）把请求排成队，一个一个处理，避免瞬时流量把 LLM 服务冲垮。

第二，超时和重试机制，防止卡死。

LLM 调用最怕网络抖一下或者模型推理慢了，把整个线程挂住。我会设置合理的超时时间（比如 30-60 秒），并用带指数退避的重试——第一次等 1 秒，第二次等 2 秒，最多重试 3 次。这样可以避免短时故障导致大量请求失败。另外，我会用断路器（比如 Resilience4j 或 Hystrix），如果连续失败超过阈值，直接熔断 10 秒钟，快速失败，防止雪崩。

第三，资源隔离，不让一个用户拖垮所有人。

如果某个用户发了一篇超长文档或者发了成千上万个请求，不能让他占满所有资源。我会用 Token 级别的配额，比如单用户每小时只能用 10 万个 Token，超了就拒绝。还可以把不同的业务（比如聊天和摘要）分到不同的线程池或服务实例里，互不影响。

最后，加一层缓存。如果多个用户问的是完全相同的问题（比如查询产品说明书），可以用 Redis 把结果缓存几分钟，直接返回，既省 Token 钱又提高响应速度。

总之，核心思路就是：限流防冲击、重试防抖动、隔离防互相影响、缓存防重复计算。

如果小假的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！