做VerdictAI X的时候，我踩了一个多智能体系统的经典坑：一次用户点击背后要触发21次大模型调用，但Google AI Studio免费版只给15 RPM（每分钟请求数）。Token额度还剩一大半，接口先炸了。

这不是理论问题。我的系统里有五个专门化的AI代理——策略师、守护者、远见者、人道主义者、反对派——它们要对用户的人生困境进行多轮辩论。单次查询的调用链长这样：初始分析5次，第一轮辩论5次，第二轮攻防10次，最后综合裁决1次。21次请求，15 RPM上限，数学上直接溢出。

打开网易新闻 查看精彩图片

瓶颈根本不是Token。按30,000 TPM（每分钟Token数）算，21次调用撑死用掉几千Token，但RPM硬 ceiling 一碰就429 RESOURCE_EXHAUSTED。免费 tier 的算盘很清楚：限制请求频率比限制Token消耗更能卡脖子。

打开网易新闻 查看精彩图片

我的解法叫动态降级队列（Dynamic Fallback Queue），核心逻辑就四句：先打主模型，撞墙就换下一个，循环到成功为止，UI里给用户飘一行小字通知。代码层面我在gemini_client.py里维护了一个模型优先级数组：

FALLBACK_MODELS = [
"gemini-3.1-flash-lite-preview",
"gemini-2.5-flash",
"gemma-4-31b-it",
"gemma-4-26b-a4b-it"
]

主模型根据用户是否勾选"Pro模式"动态选择：gemini-2.5-pro或gemini-2.5-flash。每次请求按数组顺序遍历，非首模型触发时通过yield塞一段带样式的系统提示进流式输出，让用户知道"主模型RPM触顶，正在切换至XXX"。

这套机制的关键在于把"失败"变成"延迟"而非"崩溃"。传统做法是单模型配指数退避重试，但在RPM场景下退避再久也解不了根本矛盾——你的请求密度超过了服务商允许的并发水位。多模型轮询本质上是把负载分散到不同的RPM配额池里，用空间换时间。

打开网易新闻 查看精彩图片

实现上有几个脏细节。一是模型能力对齐，flash-lite和pro的输出质量差距客观存在，我的做法是在系统提示里统一约束输出格式，降低模型切换带来的风格漂移。二是错误分类，只有429和明确的配额相关错误才触发降级，其他异常直接抛给上层处理，防止把网络抖动误判为配额耗尽。三是UI状态同步，流式输出里插HTML标签的做法虽然土，但比单独开WebSocket通道通知轻量得多。

最终效果：单用户场景下21次调用被平滑消化在降级队列里，最坏情况也不过是多等几百毫秒、多看一行黄字提示。免费 tier 的15 RPM硬限制被"绕过"了——不是突破，是用弹性架构消化了它的刚性。

这个模式可以迁移到任何多步骤LLM流水线。核心认知是：RPM限制比TPM限制更致命，因为前者卡的是并发架构设计，后者只卡成本。当你的系统从"单次对话"进化到"多代理协作"，第一件事就该问自己：如果主模型突然拒绝服务，我的降级路径在哪里？