工程實務：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 配置。很多「服務中斷」的問題，其實可以透過簡單的降級策略解決。