错误率从0.1%飙到47%，AI网关容灾我踩了3个坑

去年双十一，我们团队负责的智能客服系统在流量峰值时突然挂了——不是服务挂了，是上游的 GPT-4 API 限流了，导致整个链路雪崩。那天晚上我盯着监控大盘，眼看着错误率从 0.1% 飙到 47%，心里只有一个念头：API 网关的容灾降级，真不是“加个重试”就能搞定的。

那次事故之后，我花了整整两周重构了网关层的容灾逻辑。现在回过头看，AI API 网关的容灾降级跟传统 API 网关完全是两码事——你要面对的不只是超时和 500，还有 Token 配额、模型限流、多模态切换这些新问题。

为什么 AI API 网关需要专门的容灾设计？

传统 API 网关处理的主要是网络抖动、服务宕机这类问题，三板斧（重试、熔断、降级）基本够用。但 AI API 有几个特殊之处，我踩过坑才搞明白。

第一，限流维度复杂。 OpenAI 的限流不是简单的 QPS，而是 RPM（每分钟请求数）+ TPM（每分钟 Token 数）双重限制。比如 GPT-4 的 RPM 是 500，但 TPM 只有 10000——如果你每个请求消耗 500 Token，那 RPM 还没到上限，TPM 先爆了。这事我一开始真没注意到，直到看到 OpenAI 后台的报错日志才反应过来。

第二，成本差异巨大。 GPT-4 的价格是 GPT-3.5 的 20 倍，Claude 3 Opus 比 Sonnet 贵 5 倍。你不能像传统服务那样“无脑切备用”，每次降级都意味着成本变化。我们第一个月就多花了三千多刀，财务那边差点找我谈话。

第三，模型能力不对等。 从 GPT-4 降到 GPT-3.5，不只是响应速度变了，而是整个输出质量断崖式下跌。你的降级策略必须考虑业务场景——客服总结可以用便宜模型，但合同审核你敢降级吗？

嗯...这个比较复杂。我下面用三个真实案例来说明。

三个真实踩坑案例

案例一：Token 预算超支导致的“假熔断”

去年 3 月，我们接入了某个金融客户的文档分析场景。每次请求要处理 50 页 PDF，单次消耗 8000-12000 Token。上线第一周就出问题了：熔断器频繁触发，但检查 GPT-4 API 状态一切正常。

排查了两天才发现根因：我们设置的熔断阈值是“错误率 > 50%”，但 OpenAI 返回的不是 500，而是 429（Too Many Requests），并且错误信息里带了 retry-after 头。问题在于，我们的熔断器把所有 4xx 都当成客户端错误，没区分 429 和真正的 400。

等等，这里我要更正一下——其实不是“没区分”，是我们用的 Hystrix-go 默认就把 4xx 算进错误统计了，我们当时图省事没改配置。结果就是，限流触发了熔断，熔断又加剧了限流，整个一死亡螺旋。

修复后的代码大概是这样：

# 错误示范：把所有 4xx 当熔断触发条件
if response.status_code >= 400:
 circuit_breaker.record_failure()

# 正确做法：区分限流错误
if response.status_code == 429:
 retry_after = int(response.headers.get('retry-after', 5))
 rate_limiter.wait(retry_after)
 # 不计入熔断统计，因为这不是服务故障
elif response.status_code >= 500:
 circuit_breaker.record_failure()

案例二：多模型降级时的成本失控

我们接入了 GPT-4、Claude 3、Gemini Pro 和国内的文心一言、通义千问，做了个“主备降级链”：GPT-4 → Claude 3 → 通义千问 → GPT-3.5。

看起来很美对吧？结果第一个月账单出来，我差点从椅子上摔下来——成本比预期高了 3 倍。

分析发现，问题出在降级链的中间环节。当 GPT-4 触发限流后，请求切到 Claude 3，但 Claude 3 的 Opus 版本价格跟 GPT-4 差不多，根本没起到降本作用。更糟的是，有些场景从 Claude 3 又降级到通义千问，但通义千问对长文本的处理很烂，导致大量请求重试，反而增加了总调用次数。

我当时的表情，大概就是“瞳孔地震.jpg”。

后来我们改成这样：

degradation_chain:
 - model: gpt-4
 max_cost_per_1k: 0.03 # $0.03/1K tokens
 fallback_trigger: 
 - error_rate > 10%
 - p99_latency > 8s
 - model: claude-3-sonnet # 注意是 Sonnet 不是 Opus
 max_cost_per_1k: 0.003
 fallback_trigger:
 - error_rate > 20%
 - model: gpt-3.5-turbo
 max_cost_per_1k: 0.0005
 # 最后一层不降级，直接返回兜底回复

关键改动：明确指定降级模型的版本（Sonnet 而非 Opus），并且每一层都标注了成本上限。 这样在做降级决策时，网关会先检查目标模型的单价，如果超过当前模型的 50%，就跳过这一层直接到下一级。

案例三：上下文丢失导致的降级失效

这是最隐蔽的一个坑。

我们的客服系统用了 LangChain 做多轮对话，每次请求都会带上历史消息。某次 GPT-4 降级到 GPT-3.5 后，突然大量用户反馈“机器人失忆了”。

排查发现，GPT-3.5 的上下文窗口是 16K，而 GPT-4 是 128K。当对话历史超过 16K Token 时，降级后的请求直接报错——但网关层没感知到这个差异，因为错误是 LangChain 在应用层抛出的。

我记得当时是凌晨两点，我对着日志看了半天，突然意识到问题在哪。那种感觉，怎么说呢，就像你找了半天钥匙，发现它一直在你手里。

我们的解决方案：

def select_fallback_model(request, primary_model):
 fallback = degradation_chain.get_next(primary_model)
 
 # 检查能力集匹配
 if request.context_length > fallback.max_context:
 # 裁剪历史消息，保留最近 N 轮
 request.messages = trim_history(request.messages, fallback.max_context)
 logger.warning(f"上下文从 {primary_model.max_context} 裁剪到 {fallback.max_context}")
 
 if request.requires_vision and not fallback.supports_vision:
 # 功能降级：去掉图片，只传文本
 request.images = []
 request.add_system_message("图片解析功能暂时不可用")
 
 return fallback

我们最终落地的架构

经过这几次事故，我总结了一套 AI API 网关容灾设计的核心原则：

1. 四层防御体系

第一层：客户端限流（SDK 内置 Token 桶）
第二层：网关层熔断（基于错误率和延迟）
第三层：多模型降级（成本感知的降级链）
第四层：兜底回复（静态答案 + 缓存）

每一层都有独立的监控，出问题时能快速定位是哪一层失效。我们用的是 Grafana + Prometheus，配了 Loki 做日志聚合，大概花了三天搭完。

2. 成本感知的路由

我们在网关里加了个“成本计算器”，每次请求前预估 Token 消耗，然后根据预算选择模型。比如客户 A 的 SLA 是“95% 请求用 GPT-4，月预算 $5000”，那网关会实时计算剩余预算，快超支时自动提高降级概率。

这个功能救了我们一命。有个客户突然把日调用量从 1 万涨到 50 万，按原来的逻辑直接破产。现在网关检测到预算消耗速度异常，会自动切换到便宜模型，同时发告警给客户经理。

据我了解，2024 年 Anthropic 也推出了类似的预算控制功能，不过我们是自己造的轮子。

3. 上下文感知的降级

不再简单粗暴地“换模型”，而是根据请求特征做精细降级：

• 长文本摘要 → 裁剪输入，保留关键段落
• 多模态识别 → 降级为纯文本描述
• 代码生成 → 优先保证模型能力，其次考虑成本
• 闲聊对话 → 直接降级到最便宜模型

一些实用的配置建议

如果你现在就要搭一套 AI API 网关，我建议先把这几个参数调好：

gateway_config:
 # 熔断器：用滑动窗口，别用固定窗口
 circuit_breaker:
 type: sliding_window
 window_size: 60s
 error_threshold: 20% # 别设太高，AI API 的波动比传统 API 大
 half_open_max_requests: 5 # 半开状态先放 5 个请求试探
 
 # 限流器：区分 RPM 和 TPM
 rate_limiter:
 gpt-4:
 rpm: 400 # 留 20% buffer，别顶着上限配
 tpm: 8000
 claude-3:
 rpm: 450
 tpm: 9000
 
 # 重试策略：只重试 429 和 5xx，别重试 4xx
 retry_policy:
 max_attempts: 3
 backoff: exponential # 1s, 2s, 4s
 retryable_status: [429, 500, 502, 503]
 
 # 降级链：必须配成本上限
 fallback_chain:
 enabled: true
 cost_aware: true
 max_cost_multiplier: 1.5 # 降级模型不能比主模型贵 50% 以上

说实话，这些配置我调了大概四五版才稳定下来。最开始 error_threshold 设的 50%，结果等触发的时候已经晚了，用户早跑光了。

写在最后

AI API 网关的容灾降级，本质上是在成本、质量、可用性之间找平衡。没有银弹方案，只有根据业务场景持续调优。

我们现在的策略是：核心业务（合同审核、金融分析）走“高成本高可用”路线，宁可多花钱也不降级；边缘业务（客服闲聊、内容摘要）走“低成本弹性”路线，出问题直接返回缓存答案。这个策略运行了大概半年，目前看还行，但谁知道下个月会不会又出幺蛾子。

最后抛个问题给大家：你们在接入多个 AI 模型时，是怎么做 A/B 测试和灰度发布的？我们试过按用户 ID 哈希分流，但效果不太好——因为同一个用户可能同时需要高质量和低质量场景。圈子里有人用 LangSmith 做实验管理，有人直接用 LaunchDarkly 搞特性开关，我觉得都差点意思。如果你有更好的方案，欢迎在评论区聊聊。

标签： #AI网关 #容灾设计 #API降级 #OpenAI #架构设计