你在生产里同时接 Claude 和 OpenAI，最怕的不是单点故障，而是慢故障：超时变多、429 变密、质量飘忽，系统还“看起来活着”。

这篇给一套可直接落地的双栈降级方案：先做超时探测，再做熔断切流，最后用错误预算看板兜住业务节奏。

结论先给

  • 入口统一走 provider-gateway，所有调用都打上 provider/model/tenant 三维标签。
  • 先限时再重试：单次请求超时上限必须小于用户 SLA 的 60%。
  • 熔断切流按“软切 → 硬切 → 灰度回流”三段执行，不要一步到位全量切。
  • 错误预算按 30 天窗口滚动，预算烧穿就降级功能，而不是硬扛。

1) 超时探测：先看“慢”，再看“错”

把超时拆成三段：connect_timeout、ttfb_timeout、total_timeout。只看 total 会错过前兆。

# 1. 核心探针：每 30s 拉一次双供应商健康
curl -sS http://gateway.internal/health/providers | jq '.providers[] | {name,p95_latency,error_rate,timeout_rate}'

# 2. Prometheus 快速查看 15 分钟超时率
curl -G 'http://prometheus.internal/api/v1/query'   --data-urlencode 'query=sum(rate(llm_requests_total{status="timeout"}[15m])) by (provider) / sum(rate(llm_requests_total[15m])) by (provider)'

告警阈值建议：

  • timeout_rate > 3% 连续 5 分钟：进入软降级观察态
  • timeout_rate > 8% 或 p95 > SLA x 1.8：触发硬降级候选

2) 熔断切流：三段式，不赌运气

2.1 软切（Soft Shift）

先把 20% 流量切到备用供应商，观察 10 分钟：

# gateway-routing.yaml
routes:
  - tenant: default
    policy:
      primary: claude
      secondary: openai
      weights:
        claude: 80
        openai: 20
      failover:
        on_timeout: true
        on_5xx: true
        max_retries: 1

2.2 硬切（Hard Cut）

当主供应商触发熔断条件（如 5 分钟错误率 > 12%）后，直接切到备用并冻结回切：

gatewayctl circuit open --provider claude --reason 'timeout_storm_5m'
gatewayctl route set --tenant default --primary openai --secondary claude

2.3 灰度回流（Canary Return）

恢复时不要直接回 100%，按 10% → 30% → 50% 递增，每阶段至少观察 15 分钟。

3) 错误预算看板：让降级有“刹车线”

以 99.5% 可用性为例，30 天预算约 216 分钟不可用时间。推荐按租户拆账：

  • L1（付费核心租户）：预算使用率 > 70% 时，关闭高成本模型回退。
  • L2（普通租户）：预算使用率 > 85% 时，强制降级到“短上下文 + 单次重试”。
  • 内部工具流量：预算烧穿时直接限流，避免挤占生产通道。
-- 示例：按 provider + tenant 看预算消耗
SELECT
  provider,
  tenant,
  SUM(error_requests) / NULLIF(SUM(total_requests),0) AS error_rate,
  SUM(timeout_requests) / NULLIF(SUM(total_requests),0) AS timeout_rate
FROM llm_sli_5m
WHERE ts >= now() - interval '30 days'
GROUP BY provider, tenant;

4) 常见错误与排障

错误 A：切流后成本暴涨

原因通常是备用模型默认上下文更大、重试策略没收敛。处理：

  1. 立即把 max_tokens 降到基线的 70%。
  2. 重试次数统一收敛到 1 次。
  3. 仅对幂等任务允许自动重放。

错误 B：双供应商都慢，切谁都不稳

这不是路由问题，是请求形态问题。优先做：

  • 把长 prompt 拆成“检索摘要 + 生成”两段。
  • 打开缓存命中（语义缓存 + TTL 分层）。
  • 把非实时任务丢到 batch 队列。

错误 C：熔断频繁抖动（开-关-开）

说明阈值太敏感。加 cooldown（建议 8-15 分钟）和最小样本阈值，避免小流量误判。

5) 最小可行落地（MVP）

今天就能上线的版本：

  1. 网关加三指标：timeout_rate、p95_latency、5xx_rate。
  2. 增加软切策略（80/20）。
  3. 增加硬切命令和 10 分钟冻结回切。
  4. 建一个 30 天错误预算面板并接告警。

你先把“可观测 + 软切”做起来，系统稳定性就会立刻上一个台阶；剩下再迭代成本和质量策略。