工程实践：AI 推理链路的熔断与降级

在 SFD 的日常 Lab 实验中，我们维护着一套本地的 AI 推理栈。之前有篇文章提到，把生产推理全压在外呼链路上，偶尔会遇到路由不可用、排队延迟高、甚至整套链路断开的情况。今天这篇文章，补充一个关键工程点：当外部路由不可用时，你的本地模型能否自动接棒？

问题场景

假设你运行着一套完整的本地推理栈，配置如下：

ROUTER=http://127.0.0.1:4000
# 上游模型
UPSTREAM=qwen3.6-plus
# 本地回退模型
LOCAL_MODEL=Qwen3-Embedding-8B

当你通过路由器调用 `qwen3.6-plus` 时，路由器会尝试转发到上游服务。如果上游不可用（网络超时、服务宕机、API Key 过期），路由器通常会返回 502 或 504 错误。

**问题**：这时候，你的本地模型没有被触发，整个请求链直接中断。

工程方案：熔断 + 降级

这个方案的核心思路是：**在路由器层面配置 fallback 策略，当上游模型返回特定错误状态码时，自动切换到本地模型。**

配置示例

在 `~/.openai-router/config.json` 中，你可以为每个模型定义 `fallback_on_status`：

{
  "models": {
    "production-gpt": {
      "upstream_id": "gpt-4",
      "deployments": [{
        "api_base": "https://api.example.com",
        "api_key": "${API_KEY}"
      }],
      "fallback_on_status": [408, 429, 500, 502, 503, 504],
      "fallback_model": "local-gpt-3"
    },
    "local-gpt-3": {
      "deployments": [{
        "api_base": "http://127.0.0.1:8050",
        "model": "gpt-3.5-turbo"
      }],
      "timeout_sec": 120
    }
  }
}

这里的 `fallback_on_status` 字段定义了哪些 HTTP 状态码触发降级。当上游返回 502/504 等错误时，请求会自动路由到 `local-gpt-3` 模型。

实际案例

有一次，我们的上游推理服务在周末凌晨进行维护。请求发送到上游后，路由器等待超时，最终返回 504。由于我们配置了 `fallback_on_status: [504]` 并指定了 `fallback_model: "local-model"`，请求自动降到了本地模型。虽然本地模型的推理速度较慢（30 秒 vs 5 秒），但用户感知不到服务中断。

关键注意事项

1. **降级模型的响应质量**：本地模型通常与上游模型的精度不同，降级后可能产生不同的结果。对于关键业务，需要评估降级后的输出是否符合预期。

2. **超时设置**：降级模型通常较慢，需要设置更长的超时时间，避免请求过早被终止。

3. **回退链**：可以配置多级回退，例如 `上游模型 → 本地模型 A → 本地模型 B`，形成更完善的弹性策略。

4. **监控告警**：即使配置了自动降级，也应该对降级事件进行监控和告警，以便了解降级发生的频率和原因。

总结

在生产环境中，完全依赖外部推理服务存在风险。通过合理配置路由器的熔断和降级策略，可以在保证核心可用性的同时，维持基本的推理能力。这不是要替代外部服务，而是作为安全网，应对突发的服务不可用场景。

**写给自己的提醒**：如果你已经有一套本地推理栈，今晚就检查一下路由器的 fallback 配置。很多"服务中断"的问题，其实可以通过简单的降级策略解决。