厂商宕机时的模型回落：回落链的顺序该怎么排

为什么单点故障不只发生在你的代码里

即使你的应用本身很稳定，上游厂商仍可能因为区域故障、容量紧张或例行维护而暂时不可用。如果你只依赖一家厂商，这段时间你的功能就会直接中断。

当你用一个 API key 调多个模型（比如 Claude、GPT、DeepSeek、Qwen、GLM、Kimi）时，天然具备了跨厂商回落的可能。但回落顺序如果排得随意，反而可能引入新的风险。

回落的第一个原则：跨厂商优先

很多人会先尝试同一家厂商的另一个模型，比如主模型不可用时，立即切到同门的轻量版或上一代版本。这在普通场景下合理，但关键请求最好回落到另一家厂商的模型。

原因是同门模型共享同一套基础设施、同一套鉴权体系和同一个区域入口。如果故障出在厂商级别（例如 API 网关异常、账号级限流、区域网络问题），切换到同门模型大概率仍然失败，白白浪费一次尝试机会。

跨厂商回落能更好地隔离故障域。不同厂商的入口、网络路径和容量池相互独立，一家出问题不影响另一家。

回落链该怎么排

一个实用的顺序是：

1. 主模型：你当前任务最匹配、质量最可控的模型。
2. 同能力跨厂商模型：在另一家厂商里找一个能力接近的模型。
3. 轻量跨厂商模型：在第三家厂商里找一个低延迟、低成本的模型，接受质量下降以保住可用性。
4. 最终兜底：如果所有模型都不可用，返回明确的错误或降级提示，而不是无限重试。

每一层之间加一个短超时和有限的快速重试（例如仅重试一次），避免在故障厂商上耗尽总超时预算。

提示兼容比模型能力更棘手

回落时最容易出问题的地方不是模型能力差异，而是提示词和参数不兼容。常见差异包括：

• 系统消息的格式和支持程度不同。
• 是否支持工具调用、结构化输出或特定停止词。
• 对上下文长度和图片输入的支持不同。
• 部分厂商对 max_tokens、temperature 等参数的取值范围要求不同。

如果想把同一个提示直接发给多家模型，需要做两件事：

• 保持提示内容与厂商无关：把系统指令写成通用自然语言，避免依赖某家特有的模板语法。
• 做参数归一化：在调用前把参数裁剪到目标模型都支持的范围内，并显式处理不支持的功能。

如何测试回落链

回落链不能只在真故障时才验证。建议：

• 人为禁用主模型，观察请求是否按预期切换到第二家厂商。
• 记录每次回落的触发原因和最终成功的模型，便于事后分析。
• 定期检查备用模型是否仍可用、参数是否仍兼容。

计费与回落的现实权衡

在同一聚合层下调用不同厂商，计费方式统一，但不同模型本身的价格和倍率可能不同。回落可能意味着单次请求成本变化，因此链路设计要在可用性和成本之间做取舍：

• 关键路径优先保可用性，允许回落到稍贵的模型。
• 非关键路径可以回落到更轻量的模型，控制成本。

无论哪种策略，都建议在调用日志里记录实际使用的模型，方便复盘和预算管理。