很多团队接 AI 模型的时候，心态是"先跑起来再说"。功能能用就行，至于稳定性——等出了问题再处理。

这在 demo 阶段没问题。但一旦模型调用承载了真实的用户流量，你就需要像对待任何其他外部依赖一样对待它：定义清楚"什么叫正常"，想清楚"不正常的时候怎么办"。

这就是 SLO（Service Level Objective，服务等级目标）和降级策略的用处。

为什么 Gemini 3.1 Pro 特别需要这套东西

老实说，所有外部 API 都应该有 SLO 和降级设计。但 Gemini 3.1 Pro 目前处于 Preview 阶段，有几个特点让这件事变得更紧迫：

• 容量波动明显，高峰时段 429/503 频率较高

• 默认 HIGH 思考模式导致延迟方差大——同一个请求今天跑 3 秒，明天可能跑 30 秒

• 模型版本生命周期短（3 Pro 从发布到下线只有四个月），随时可能因为版本切换出现行为变化

• Thinking token 的产出量不可预测，成本方差也大

没有 SLO 和降级策略，这些波动就是"不可预期的故障"。有了 SLO 和降级，同样的波动变成"可管理的异常"。

第一步：定义你的 SLO

SLO 不是 Google 定义的，是你自己定义的——基于你的业务能容忍什么。

建议覆盖四个指标：

1. 可用性（Availability）

"在一个时间窗口内，API 请求成功返回的比例。"

比如：99.5% 的请求在 30 秒内成功返回有效响应（不含 4xx/5xx 错误）。

对于 Preview 阶段的模型，不要把目标定得太激进。99.9% 在目前的 Gemini 3.1 Pro 上可能不现实——社区反馈显示高峰时段的成功率波动很大。先定 99% 到 99.5%，根据实际数据再调整。

2. 延迟（Latency）

"P50 / P95 / P99 的端到端响应时间。"

比如：

• P50 < 5 秒

• P95 < 15 秒

• P99 < 30 秒

这里要注意，Gemini 3.1 Pro 的延迟分布不是正态的——大部分请求可能在 5 秒内完成，但 thinking token 多的请求可能跑到几十秒甚至几分钟。你的 P99 目标要考虑到这种长尾。

3. 输出质量（Quality）

这个指标不好自动化测量，但至少可以做一些基础检测：

• 响应是否为空

• 响应是否符合预期格式（JSON schema 校验）

• 工具调用是否返回了有效的 function call

• 响应内容是否出现明显的重复或乱码

如果你有业务层面的质量指标（比如分类准确率、摘要信息覆盖率），也可以纳入 SLO。

4. 成本（Cost）

"单请求的平均成本不超过 X。"

有了 thinking token 之后，单请求成本的波动比以前大。可以设一个上限，比如"P95 的单请求输出 token 不超过 5000"。超过这个阈值的请求可能意味着模型在做无效推理。

第二步：设计降级策略

SLO 定好了是告诉你"什么时候出了问题"。降级策略是告诉你"出了问题之后做什么"。

层级一：请求级降级

单个请求失败时的处理：

• 重试：429/503 错误做指数退避重试，最多 3 次

• 超时切断：设置硬超时（比如 30 秒），超时后不再等待

• Thinking Level 降级：第一次用 HIGH 失败，重试时降到 MEDIUM 或 LOW

• 端点切换：customtools 端点失败时切到标准端点，或反过来

层级二：模型级降级

当某个模型的错误率持续超过阈值时：

• 切到备用模型：比如 Gemini 3.1 Pro 连续 5 分钟可用性低于 95%，自动把流量切到 Claude 或 GPT

• 切到轻量模型：用 Gemini Flash 或更便宜的模型承接，牺牲一些质量但保证可用

• 返回缓存结果：对于某些可缓存的查询，返回之前生成过的结果

这一层如果靠业务代码自己实现，写起来不轻松——要维护多个模型的 SDK、鉴权、错误码映射，还要处理模型之间的响应格式差异。通过 PoloAPI 这类聚合网关来做，模型切换在配置层完成，业务代码只对接一套统一接口，降级逻辑和业务逻辑分开，维护成本低很多。

层级三：功能级降级

当所有模型都不可用时：

• 关闭 AI 功能，保留基础功能：比如搜索结果不做 AI 摘要，但搜索本身仍然可用

• 返回预设的兜底响应：比如"系统繁忙，请稍后再试"

• 排队处理：把请求放入队列，延迟处理而不是直接失败

第三步：建立可观测体系

SLO 和降级策略需要数据支撑。你需要监控这些指标：

必须有的：

• 请求成功率（按状态码分类）

• 响应延迟分布（P50/P95/P99）

• 错误类型分布（429 vs 503 vs 其他）

• 降级触发次数和原因

建议有的：

• 输入/输出 token 数分布

• Thinking token 占比

• 单请求成本分布

• 不同 thinking level 的质量对比

进阶的：

• SLO 达标率的时序趋势

• 错误预算消耗进度（比如这个月的 0.5% 错误预算用了多少）

• 降级后的用户行为变化（降级是否真的影响了用户体验）

自建这一套监控体系要接 Prometheus + Grafana，写采集逻辑、建 dashboard，周期不短。如果想快速拿到数据，PoloAPI 内置的调用分析面板已经覆盖了上面"必须有的"和"建议有的"两层——成功率、延迟分布、token 消耗、错误类型，开箱就能看。先用现成的工具把数据跑起来，后续再按需求接入自建监控也不迟。

第四步：定期回顾和调整

SLO 不是定一次就不管了。建议每月做一次回顾：

• 上个月的 SLO 达标率是多少？

• 降级被触发了多少次？主要是什么原因？

• 成本是否在预期范围内？

• 模型版本有没有变化？行为有没有漂移？

• SLO 的阈值是否需要调整？

Gemini 3.1 Pro 还在快速迭代——Google 的更新节奏很快，模型行为可能在一次版本更新后发生变化。你的 SLO 和降级策略也需要跟着迭代。

不要等出事了才想起来

建 SLO 和降级体系的最佳时间是接入模型之前。第二好的时间是现在。

它不需要很复杂——哪怕只是"超时 30 秒就切备用模型"这么一条规则，也比什么都没有强十倍。先把基础的骨架搭起来，后续随着数据积累再持续完善。

如果你不想从零搭这套体系，可以考虑先用 PoloAPI 把统一接入和基础监控跑起来。它的路由、超时、重试、降级能力可以直接覆盖本文"第二步"里的大部分策略，而内置的可观测面板能帮你快速积累"第三步"需要的数据。有了数据和降级骨架，再逐步迭代 SLO 阈值，整个过程会顺畅很多。