生产级 AI 网关的稳定性与故障转移

AI 供应商会宕机、限流、延迟飙升。如果你的产品直连单一上游，这些问题就会变成你的问题。带有完善故障转移的 API 网关，能把供应商的不稳定变成"无感事件"。本文讲清楚在生产中真正重要的稳定性模式。

稳定性难题

任何单一 AI 供应商都会偶尔：

返回 429（限流）或 5xx 错误。
延迟飙升。
出现区域性或全局性宕机。
改变行为或下线某个模型。

网关位于所有上游之前，让你在一个地方一致地处理这些故障。

核心模式

1. 自动故障转移

配置一组有序的上游或模型。主通道失败或超时，网关就重试下一个健康选项。你的应用只看到一个稳定入口。

2. 带退避的智能重试

对瞬时错误（429、5xx、超时）用指数退避 + 抖动重试。不要重试非幂等或明显非法的请求。限制总尝试次数以约束延迟。

3. 超时与熔断

设置合理超时，别让卡住的上游拖垮你的应用。熔断器在某上游持续失败时临时停止向它发送，给它恢复时间，同时保护你的延迟预算。

4. 多区域路由

路由到就近节点以降低延迟，并扛住区域性事故。对受限地区用户，多区域接入让连接保持稳定。

5. 优雅降级

当最优模型不可用时，退到更便宜或更快的模型，而不是直接让请求失败。略简单的答案通常好过一个错误。

一个实用兜底示例

def robust_complete(client, messages, models, max_attempts=3):
    last_error = None
    for model in models:
        for attempt in range(max_attempts):
            try:
                return client.chat.completions.create(
                    model=model, messages=messages, timeout=30
                )
            except Exception as e:
                last_error = e
                continue
    raise RuntimeError(f"所有模型都失败了: {last_error}")

把这种应用层逻辑和同样会做故障转移的网关搭配，你就有了两层保护。

监控与 SLO

按模型和 Key 跟踪成功率、延迟（p50/p95/p99）和错误类型。
定义 SLO（例如 99.9% 成功率），违反时告警。
关注每个成功结果的成本，捕捉静默的质量或价格回退。
用状态页（你的和网关的）来沟通事故。

运营清单

至少配置一个兜底模型或供应商。
给每次调用设超时。
对瞬时错误开启带退避的重试。
备 2-3 家，让任何单一厂商都不是硬依赖。
在真正需要前压测你的故障转移路径。
轮换密钥并按服务限定作用域。

常见问题

故障转移会拖慢延迟吗？ 调优良好的方案在正常路径几乎不增加开销，只有在主通道真正失败时才多花时间——而那正是你希望它生效的时刻。

重试该自己写还是靠网关？ 都要。网关层故障转移处理上游问题；应用层逻辑处理你特定的业务规则与幂等性。

怎么避免重试风暴？ 用指数退避 + 抖动、限制尝试次数，并用熔断，避免猛击一个已经吃力的上游。

TokenVoke 提供内置故障转移、多区域路由和按 Key 的可观测性，让你的 AI 应用持续在线。读文档或获取 API Key，默认就具备韧性。