模型路由与 Fallback：多模型降级、重试、超时和质量成本权衡 —— 主题精读 未开始

题记与说明

• 日期：2026-11-04
• 形式：主题研究（检索并精读 5 个来源：2 篇学术论文 + 1 份网关文档 + 2 篇工程实践文章）
• 来源清单：
  1. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance — Chen, Zaharia, Zou (Stanford), arXiv:2305.05176（摘要页 + ar5iv 全文）https://arxiv.org/abs/2305.05176
  2. RouteLLM — LMSYS 官方博客（2024-07-01）+ GitHub README + 论文 arXiv:2406.18665 https://www.lmsys.org/blog/2024-07-01-routellm / https://github.com/lm-sys/RouteLLM
  3. LiteLLM Proxy Reliability 文档（Fallbacks / Retries / Timeout / Cooldown）https://docs.litellm.ai/docs/proxy/reliability
  4. LLM API retry logic: Backoff, jitter and what to skip — learnwithparam.com https://www.learnwithparam.com/blog/retry-patterns-llm-api-errors-production
  5. LLM Inference Resilience Patterns on AWS — hidekazu-konishi.com（2026-10 更新版）https://hidekazu-konishi.com/entry/llm_inference_resilience_patterns_on_aws.html

0. 总览：把主题拆成两个正交问题

精读后我认为"模型路由与 fallback"实际是两个互补的层次，文献也明显分两派：

把两者混为一谈会出错：路由是省钱的统计问题（需要标注数据训练），fallback 是保命的工程问题（需要错误分类与预算控制）。成熟系统两者都要：路由层负责常态下的成本效率，fallback 链负责异常时的可用性底线。

1. 核心问题

商业背景：FrugalGPT 开篇指出，付费 LLM API（GPT-4、ChatGPT、J1-Jumbo 等）定价差异高达两个数量级，而"using LLMs on large collections of queries and text can be expensive"。作者据此提出："we outline and discuss three types of strategies that users can exploit to reduce the inference cost associated with using LLMs"——prompt adaptation、LLM approximation、LLM cascade。

核心问题可以精确表述为：并非每个查询都需要最强（最贵）的模型，但事先无法确定哪些查询不需要。于是问题变成：

1. 统计问题：如何为每个 query 动态选择模型，使期望质量 ≥ 约束下期望成本最小（或等价地在成本预算下最大化质量）？
2. 工程问题：无论路由到哪个模型，API 都会失败（429 限流、5xx、超时、上下文超限、内容策略拒绝），如何在失败后既不雪崩（retry storm）也不静默降质？

RouteLLM 把问题陈述得更直白：目标是在 strong model（GPT-4）与 weak model（Mixtral 8x7B）之间路由，"all queries that can be handled by weaker models should be routed to these models, with all other queries routed to stronger models"，即"minimize cost while maintaining response quality"。

2. 主要主张

1. FrugalGPT 的头条主张（摘要原文）："can match the performance of the best individual LLM (e.g. GPT-4) with up to 98% cost reduction or improve the accuracy over GPT-4 by 4% with the same cost."
2. RouteLLM 的头条主张（博客原文）："cost reductions of over 85% on MT Bench, 45% on MMLU, and 35% on GSM8K" vs 纯 GPT-4，"while still achieving 95% of GPT-4's performance"；且比 Martian、Unify AI 等商业路由器"achieving the same performance as these commercial routers while being over 40% cheaper"。
3. 重试的第一原则（learnwithparam 原文）："Retry errors that can succeed on the next attempt without any change on your side." —— 不能在下一次尝试中凭空成功的错误（401、400、spend-cap 429、内容策略拒绝）一律立即抛出。
4. 降级链设计原则（AWS 文章原文）："keep the fallback simpler and more robust than the primary." 兜底路径必须比主路径更简单、更健壮。
5. 流式的最大陷阱（learnwithparam 原文）："A stream that fails after the first tokens is not covered by SDK retries." SDK 的自动重试只保护首字节之前；流中断后要靠应用层决策（重开/续写/带部分输出降级）。
6. 重试叠加陷阱（learnwithparam 原文）："Four attempts in your layer times three in the SDK is twelve calls for one request." 多层重试是组合爆炸，SRE 语境下会放大故障。

3. 方法（技术路线深读）

3.1 FrugalGPT：质量门控的 LLM 级联（cascade）

机制：原文定义"LLM cascade sends a query to a list of LLM APIs sequentially. If one LLM API's response is reliable, then its response is returned, and no further LLMs in the list are needed." 两个核心组件：

• 打分函数 g(·,·): Q × A → [0,1]：对 (query, answer) 对输出可靠性分数。实现上"obtained by training a simple regression model that learns whether a generation is correct"，案例中用 DistilBERT 回归——"DistilBERT is considerably smaller and therefore less expensive than all LLMs considered here"。
• 路由器选 LLM 序列 L 与阈值序列 τᵢ：第 i 个 API 的回答分数 > τᵢ 就接受返回，否则传给下一个（更贵的）模型。

优化：学习 L 和 τ 被表述为约束优化（预算 b 下最大化期望奖励），"inherently a mixed-integer optimization and thus computationally expensive to solve"。作者的近似方法：剪枝（忽略 LLM 间答案分歧低的组合）+ 少量样本插值。

学到的具体级联（HEADLINES 数据集、预算 $6.5）：

GPT-J → 若 score > 0.96 接受
否则 J1-L → 若 score > 0.37 接受
否则 GPT-4

注意阈值不等距：第一级极保守（0.96），意味着便宜的 GPT-J 只在几乎确定对时才被采用；中间级放宽到 0.37。

互补性发现（这是 cascade 有效的根本原因）：便宜模型能修正贵模型的错误——"GPT-4 errs on ~6% of cases where GPT-J, J1-L, or GPT-C are right; on COQA, 13% of points where GPT-4 fails are answered correctly by GPT-3"。这不是"弱模型凑合用"，而是模型多样性本身产生信息增益。

3.2 RouteLLM：偏好数据训练的前置路由器

• 数据：Chatbot Arena 人类偏好对（prompt + 两模型回答的胜负平），加 LLM judge 与 golden-label 数据增强。
• 四种 router（README 原文）：mf（矩阵分解，"recommended"）、sw_ranking（相似度加权 Elo）、bert、causal_llm，另有 random 基线。
• 阈值即成本旋钮：模型名内嵌阈值 router-[ROUTER NAME]-[THRESHOLD]，如 model="router-mf-0.11593"；用 python -m routellm.calibrate_threshold --task calibrate --routers mf --strong-model-pct 0.5 校准出"For 50.0% strong model calls for mf, threshold = 0.11593"。阈值越高 → 越多请求走便宜模型 → 越省但可能越差。这是把质量-成本权衡显式变成一个可调参数。
• 关键数据增强效果：MT Bench 上 Arena-only 的 MF router 用 26% GPT-4 调用达到 95% 质量；加 LLM-judge 增强后 GPT-4 调用"further halved at 14% of total calls, 75% cheaper than the random baseline"。
• 泛化：在 Claude 3 Opus / Llama 3 8B 这对替代组合上"without any retraining"仍有效（README 也称 routers "generalize well to other strong and weak model pairs"）。

3.3 LiteLLM：网关层的 fallback 分类学

LiteLLM 把 fallback 按失败原因分类，这一点在工程上很重要——不同失败需要不同的兜底目标：

• General fallbacks：限流、5xx 等一般错误 → 换同规格备选模型。fallbacks: [{"zephyr-beta": ["gpt-6-luna"]}]，列表按序尝试。
• Context window fallbacks：ContextWindowExceededError → 换更大上下文的模型（context_window_fallbacks: [{"small-model": ["large-model", "claude-opus"]}]）。换同规格模型没用，因为输入本身超限。
• Content policy fallbacks：ContentPolicyViolationError → 换策略更宽松的模型。
• 前置检查：enable_pre_call_checks: true 在调用前估算 token 是否放得进该部署的上下文窗口，避免必然失败的调用浪费配额（文档称这是"required for context-window enforcement"）。
• 重试与降级的分层：num_retries 是组内先重试 N 次再走 fallback；num_retries: 0 只关组内重试，不关跨组 failover。
• 不健康部署熔出：allowed_fails: 3 + cooldown_time: 30（秒）——"cooldown a deployment once it fails more than 3 calls within cooldown_time"，冷却中的部署移出轮询。

3.4 重试工程：错误分类 + full jitter + 预算

错误分类表（learnwithparam，与 AWS 分类一致）：

退避公式（AWS 原文）：delay = random(0, 1) × min(cap, base_delay × 2^attempt)，单次等待上限 20s；瞬时错误 base 为"tens of milliseconds"，限流错误 base "around a second"。jitter 缺失的后果（引 AWS/Brooker 分析）：无 jitter "did the most work and took the longest"——重试波同步造成 retry storm。

重试预算（两层）：

• 单请求：交互场景 3–4 次尝试，总时长 ~1 分钟封顶（stop_after_attempt(4) | stop_after_delay(60)）。
• 单客户端：learnwithparam 引 retry-budget 实践——重试请求占比超过 ~10% 就停止重试（新请求），使负载放大从 ~3× 降为 ~1.1×。
• AWS SDK 实现：token bucket 重试配额，"Each retry deducts tokens; a successful request restores tokens"，耗尽即快速失败；日志信号 "Retry needed but retry quota reached, not retrying request"。2026-11 起可 opt-in AWS_NEW_RETRIES_2026=true：桶容量 500，瞬时错误重试成本从 5 token 涨到 14。

熔断器（AWS 示例参数）：failure_threshold=5、recovery_timeout=20.0s、半开态放行 1 次试探；冷却时间建议"seconds to low tens of seconds"起步。注意 AWS 强调 SDK 的 retry quota 是每客户端的窄熔断，不能替代应用层熔断。

Agent 场景特有规则（learnwithparam）：只重试失败的那一步；checkpoint 已成功的工具结果；有副作用的工具必须幂等（run ID + step number 作幂等键）；"never re-run a tool with side effects because a later model call failed"；持续失败开熔断并降级。

3.5 超时：三层预算 + 流式语义

• 默认值陷阱："both SDKs default to 10 minutes. Set a shorter timeout on calls with small outputs." 小输出短超时；长输出"stream long generations instead of raising the timeout"。
• AWS 三层：connect timeout（例 3s，botocore 默认 60s 被批过长）→ read timeout（例 60s，按最长真实生成时间定）→ 总预算：重试会乘法放大，总时间趋近"timeout × max_attempts plus the accumulated backoff"，必须按调用方预算反推。
• 流式超时语义："the read timeout applies between chunks, not to the whole response" —— 只要 chunk 持续到达，长流不会超时。
• 流中断恢复（AWS 的 stream recovery 模式）：buffering / 重开整轮 / 带上下文续写 / 保留部分输出并显式标记降级。Anthropic 的 mid-stream 错误以 200 后的 error event 下发，"so your code must restart the turn"。

3.6 优雅降级链（graceful degradation）

AWS 给出兜底链的完整排序（从优到劣）：

1. Fallback model：备用模型，或同家族跨 Region 部署；
2. Cached response：精确或语义缓存，命中即返回；
3. Non-generative floor（非生成式保底）："a canned answer, results from a plain keyword search over your knowledge base, a template, or a clear message that the AI feature is temporarily degraded."

两条告诫：降级必须可观测（不能静默）；兜底路径必须比主路径更简单。

4. 数据与证据

FrugalGPT（Table 3，达到最佳单模型精度的成本节省）：

其余：节省范围 50%–98%；等成本下最多 ~5% 精度增益；HEADLINES 案例研究"its cost is reduced by 80%, while the accuracy is even 1.5% higher"。级联长度固定为 3（"cascade length of 3, as this simplifies the optimization space and already demonstrates good results"）。涉及 12 个 API（OpenAI、AI21、Cohere、ForeFrontAI、Textsynth）。

RouteLLM：MT Bench 85%+/MMLU 45%/GSM8K 35% 成本下降、保持 95% GPT-4 质量；比商业路由器便宜 40%+；增强数据仅 ~1500 条（<2% 训练集）就把 MMLU 上最佳 router 的 GPT-4 调用需求降到 54%。

反例（同样是证据）：RouteLLM 在 MMLU 上，只用 Arena 数据训练时"all routers perform poorly at a near-random level"——归因于 MMLU 问题分布外。偏好数据不是免费的泛化。

工程数字：AWS token bucket 500 容量 / 瞬时重试 5→14 token；熔断 5 次失败 / 20s 冷却 / 半开 1 试探；交互请求 3–4 attempts + 60s 总预算；retry 占比 10% 预算线。

证据充分性评估：

• 学术侧：FrugalGPT/RouteLLM 都有公开代码与可复现 benchmark，主张与表格数据在原文可查证；但 benchmark 是 2023–2024 年的静态快照——模型价格、能力、分布均已漂移，98%/85% 这类数字不应照搬到今天的模型对上。
• 工程侧：LiteLLM/AWS/learnwithparam 是文档与从业者经验，无受控实验对照，数字（3 次重试、10% 预算、5 次熔断）是启发式起点而非最优解。AWS 文章的参数是可运行的示例配置，不是调优结论。
• 未覆盖：AWS 文章明确没有讨论 request hedging（对冲请求，同时发多个副本取最快）。按 The Tail at Scale（Dean & Barroso 2013）的背景知识，hedging 是对付长尾延迟的另一路径，但对 LLM API 成本翻倍，是否划算取决于 p99 长尾的成因——此点我标注为背景知识，未在本次精读来源中验证。

5. 结论

1. 质量-成本权衡可以显式参数化：FrugalGPT 的阈值序列 τ 和 RouteLLM 的 router-mf-0.11593 都是"把权衡变成旋钮"。与其争论"用哪个模型"，不如定义"愿意为 p95 质量付多少钱"，再让路由器在曲线上选点。
2. 级联有效的根本原因是模型多样性：便宜模型在贵模型错的 6–13% 样本上是对的。这说明 fallback 的上限不只是"保可用"，配质量门控后还能提质量。
3. 可靠性工程的主轴是分类与预算：先分类错误（可重试/不可重试/换目标重试），再给每一层预算（重试次数、退避上限、总时长、token bucket、熔断阈值），最后定义降级底线（fallback 模型 → 缓存 → 非生成式保底）。没有预算的重试等于把故障放大器写进系统。
4. 流式改变了超时与重试的语义：read timeout 作用于 chunk 间，SDK 重试不覆盖 mid-stream 失败——生产 LLM 应用里一半以上的"可靠性 bug"可能出在这里。
5. 路由省成本，fallback 保可用，两者都依赖可观测性：没有 attempt/success ratio、fallback 命中率、路由强模型占比这些指标，两个层次的旋钮都无法校准。

6. 局限

作者承认的局限：

• FrugalGPT：需要与测试分布同源的标注数据（"we need some labeled examples"）；级联学习本身是一次性投入，要靠 query 量摊销；"sometimes all cascade LLMs give the same answer, but uncertainty forces querying the whole chain"——整条链跑满的浪费是"open problem"；延迟、公平、隐私、环境影响均未纳入优化。
• RouteLLM：Arena 偏好数据在 MMLU 上近乎随机的 OOD 失败；泛化验证仅覆盖一对替代模型组合。
• AWS 文章：给出的是模式与示例参数，未提供跨负载的实证对比；boto3 直到 2026-10-31 仍默认 legacy 模式，需要显式 mode: "standard"——文档与默认行为的差距本身就是运维陷阱。

我推断的局限（标注为推断）：

• 路由器是新的故障点与延迟源：打分模型本身会挂、会增加首 token 延迟；DistilBERT 打分虽便宜，但增加了系统复杂度。
• 静默降质比失败更危险：fallback 到更弱模型时输出仍合法，用户/下游无法感知质量下降。必须打标可观测，否则 SLO 的"质量"维度会慢性腐坏。
• 路由质量随模型代际漂移：今天校准的 0.11593 阈值在新一代模型对上语义失效，需要再校准（RouteLLM 的 calibrate 命令暗示了这一点，但"多久校一次"没有来源给出答案）。
• 工程来源的数字多来自 AWS/OpenAI 生态，对国产模型 API（限流行为、Retry-After 规范性参差）的适配未验证。
• FrugalGPT 的打分器需要"知道正确答案长什么样"的回归训练；对开放生成任务（写作、代码）"正确性"难以定义，g(·,·) 的适用面比分类/QA 任务窄。

7. 对我的启发

1. 网关集中化，应用层归零重试：参考 LiteLLM 的分层（组内重试 → 跨组 fallback → 熔断冷却），把 retry/fallback/timeout 收敛到一个网关层；应用 SDK 设 max_retries=0，杜绝"4×3=12 次调用"的叠加（learnwithparam 明确警告的坑）。
2. 先写错误分类表，再写重试代码：把 429-with/without-Retry-After、spend-cap 429、内容策略拒绝、上下文超限逐一映射到"重试 / 换目标 / 立即抛"。这是整个可靠性模块的第一张表，比任何退避参数都优先。
3. 成本旋钮显式化并写进配置：像 RouteLLM 那样用 strong-model-pct 校准阈值，而不是在代码里 hardcode "都用最强模型"或"都用便宜模型"。省钱的上限（85%+）来自差异化，不是一刀切。
4. Agent 工作流的幂等纪律：本机 nightshift 这类多步工作流应 checkpoint 每步结果、只重试失败步骤、给有副作用的步骤加幂等键——这直接适用于我自己的编排系统。
5. 流式必须自己兜底：任何 SSE/流式集成都要回答"第 37 个 chunk 后断了怎么办"：buffer？续写？部分输出+显式降级标记？SDK 不会替你回答。
6. 监控三件套：retry 占比（>10% 触发预算熔断）、fallback 命中率（降质可见化）、路由强模型占比（成本漂移警报）。AWS 的 "Retry needed but retry quota reached" 日志行是个好范本——预算触发必须留痕。
7. 给降级链一个非生成式保底：缓存、关键词检索、模板、明确声明"功能暂时降级"。AI 功能的可用性底线不该是"再调一次大模型"。

附：关键原文引述索引

• FrugalGPT 摘要："match the performance of the best individual LLM (e.g. GPT-4) with up to 98% cost reduction or improve the accuracy over GPT-4 by 4% with the same cost"
• FrugalGPT 级联定义："LLM cascade sends a query to a list of LLM APIs sequentially. If one LLM API's response is reliable, then its response is returned, and no further LLMs in the list are needed."
• RouteLLM 博客："cost reductions of over 85% on MT Bench, 45% on MMLU, and 35% on GSM8K ... while still achieving 95% of GPT-4's performance"
• RouteLLM README：router-[ROUTER NAME]-[THRESHOLD]；--strong-model-pct 0.5 → threshold = 0.11593
• LiteLLM：fallbacks / context_window_fallbacks / content_policy_fallbacks；num_retries；request_timeout；allowed_fails: 3 + cooldown_time: 30；enable_pre_call_checks
• learnwithparam："Retry errors that can succeed on the next attempt without any change on your side."；"A stream that fails after the first tokens is not covered by SDK retries."；"Four attempts in your layer times three in the SDK is twelve calls for one request."
• AWS："keep the fallback simpler and more robust than the primary."；delay = random(0,1) × min(cap, base_delay × 2^attempt)；"the read timeout applies between chunks, not to the whole response"；token bucket 500 容量