在生产环境中，仅依赖单一 AI 模型供应商是有风险的。API 停机、速率限制和区域延迟都可能降低用户体验。高可用 (HA) AI 涉及构建一个冗余系统，该系统可以在无需人工干预的情况下自动切换供应商。
为什么模型故障转移至关重要
当你构建在 OpenAI 或 Anthropic 等单一供应商之上时，你的应用程序很容易受到以下影响：
- 供应商停机：即使是最好的供应商也会经历停机。
- 速率限制：意外的流量激增可能会触发
429 Too Many Requests。 - 延迟激增：网络拥塞或模型负载可能会减慢响应速度。
ModelRiver 使用原生的模型故障转移 (Model Failover) 解决了这些问题。
使用 ModelRiver 实现故障转移
ModelRiver 在网关级别处理故障转移的复杂性。你不需要在应用程序代码中编写复杂的重试逻辑。
1. 在工作流中配置备选模型
在 ModelRiver 控制台中，你可以在工作流 (Workflow) 中定义主模型和备选模型列表。
- 主模型 (Primary)：GPT-4o
- 备选 1 (Fallback 1)：Claude 3.5 Sonnet
- 备选 2 (Fallback 2)：Gemini 1.5 Pro
如果 GPT-4o 返回错误或超时，ModelRiver 会立即将请求重定向到 Claude 3.5 Sonnet。
2. 自动重试逻辑
ModelRiver 能够智能地检测到需要进行故障转移的错误，例如：
- 连接超时
- 来自供应商的 5xx 服务器错误
- 429 速率限制错误
网关处理重试状态，确保客户端从任何健康的供应商处收到成功的响应。
AI 冗余的最佳实践
使用不同的模型家族
不要只是在同一模型的不同版本之间进行故障转移（例如，从 gpt-4o 到 gpt-4o-mini）。如果 OpenAI 宕机，两者可能都会受到影响。相反，应跨不同的公司进行故障转移（例如，从 OpenAI 切换到 Anthropic）。
监控故障转移事件
使用 可观测性 (Observability) 来跟踪故障转移发生的频率。如果你看到频繁的回退，这可能表明你的主模型的速率限制需要提高或需要更换地区。
测试故障转移
你可以在 游乐场 (Playground) 中模拟供应商故障，或者通过为你的主供应商临时提供一个无效的 API 密钥来测试，以确保你的工作流正确地路由到备选方案。
现实世界的影响
通过实现高可用性 AI，你可以确保：
- 99.99% 的可用性：即使在主要的供应商停机期间，你的 AI 功能也能保持在线。
- 改进的 UX：用户不会在流量激增期间看到 “Server Error” 消息。
- 开发者的坦然：基础设施处理极端情况，所以你不需要亲自处理。