沒有 fallback 的 AI infra 不算 infra
r/openclaw 上最近有串討論很有意思，話題是「6/15 之後如果 OpenClaw 不能再走 Claude 訂閱怎麼辦？」底下有人說他本來就走 API key，所以政策怎麼變影響不大。但更多人才意識到自己整套流程是押在一個方案上的，一旦條件改變就得重來。
說穿了就是這樣：如果你的 AI 服務今天換一個模型供應商、或者訂閱條款調整，你要花多少時間恢復正常？如果答案是「不知道」或「可能要幾天」，那你的 infra 架構有問題，不是供應商有問題。
這不是 OpenClaw 獨有的問題。任何依賴單一 SaaS 訂閱做核心推論的架構，都面對同一個風險：供應商的政策、定價、限流規則是他們說了算，你能控制的只有怎麼應對。
實務上我觀察到的模式是：多數人在第一次選模型的時候選了 Claude，因為效果好、整合簡單，就這樣了。沒有人回頭建 routing logic，沒有人設 fallback，cost dashboard 也沒有。早期 MVP 階段說得通，但服務跑超過三個月還是這個狀態，就是在欠技術債。
model routing 的概念不複雜：不是每個任務都需要 Opus。高精度、長脈絡、複雜推論才需要最強的模型；日常分類、摘要、格式化用 Sonnet 就夠，甚至可以混本地跑的 Llama 3.3 70B 或 Gemma 4。成本差距不是一點點，Opus API 價格大概是 Sonnet 的 5 到 6 倍，本地模型如果你已經有 GPU infra，邊際成本幾乎是零。
在 OpenClaw 的 config 裡設 routing 大概長這樣：
models:
primary: claude-opus-4-5
fallback:
- claude-sonnet-4-5
- openai/gpt-4o
local:
- llama3.3:70b
routing:
high_complexity: primary
default: fallback[0]
cost_threshold_usd_per_hour: 5.0
auto_fallback_on_error: true
cost_threshold_usd_per_hour: 5.0 這條是關鍵。超過閾值自動降到 fallback 模型，不需要人工干預。這不是省錢的 trick，是讓服務有可控的成本邊界，不會因為一個 spike 把當月預算燒完。
fallback 的部分更重要。我之前跑過一次沒設 fallback 的架構，在 Anthropic 維護窗口期間整個服務掉線，當時沒有告警，是使用者先發現的。那次之後我的原則是：任何對外的 AI 推論服務，至少設兩個 fallback，而且供應商要不同，不能兩個都是 Anthropic。
監控要盯的不只是錯誤率。你應該同時追 latency P95、token throughput、cost per request、以及 fallback activation rate。最後一個最容易被忽略，但它告訴你 primary 模型有多穩，如果 fallback activation rate 連續三天超過 10%，那就是 primary 有問題，不是偶發。
Prometheus alert rule 大概是：
alert: HighFallbackRate
expr: rate(ai_fallback_total[5m]) / rate(ai_requests_total[5m]) > 0.1
for: 15m
labels:
severity: warning
annotations:
summary: "AI fallback rate > 10% for 15min"
說這些不是要批評用 Claude 訂閱這件事，訂閱有訂閱的好處，整合快、不用管 API key 輪換。問題是你有沒有同時建好應對策略，還是把「方便」跟「穩定」混為一談了。
OpenClaw 走不走 Claude 訂閱是一個 policy 問題，infra 能不能在一個小時內切到另一個模型然後服務繼續跑，是一個架構問題。這兩件事不一樣。
作者：CtrlC