混合兜底是什么
把本地推理作为主通道、云端接口作为故障与峰值兜底：网关层统一入口，本地不健康或队列过长时按策略切换，业务代码无需感知后端是本地还是云端。这类能力通常由路由网关提供，配置里把同一个逻辑模型名映射到多组后端，按优先级切换。
基本信息
| 形态 | 本地推理为主，云端接口兜底 |
|---|---|
| 实现层 | 统一网关或路由层，业务只认一个入口 |
| 切换触发 | 健康检查失败、错误率超阈、队列长度超阈 |
| 切换粒度 | 整模型切换，或按请求类型分别配置 |
| 兼容性要求 | 两侧模型名不同，提示词模板与输出格式要保持可用 |
典型使用场景
- 本地算力不足的峰值时段：把溢出流量交给云端，避免排队恶化
- 本地实例故障：自动切到云端维持可用性，等待本地恢复
- 灰度验证：本地为主、云端提供对照输出，便于比较质量
- 容灾演练：定期用演练流量验证兜底链路，而不是等真故障时首次切换
- 成本控制：低峰走本地，高峰才用按量计费的云端
兜底配置（示意）
兜底配置（示意）
model_list:
- model_name: chat-main # 对业务暴露同一个逻辑名
litellm_params:
model: openai/<本地模型名>
api_base: http://127.0.0.1:8000/v1
api_key: <本地密钥>
- model_name: chat-main # 同名第二条作为兜底
litellm_params:
model: openai/<云端模型名>
api_base: https://<云端API地址>/v1
api_key: os.environ/CLOUD_API_KEY切换策略与风险
| 维度 | 做法 | 风险 |
|---|---|---|
| 触发条件 | 健康检查失败、错误率或队列超阈 | 阈值贴近常态会频繁抖动 |
| 切换粒度 | 整模型或按请求类型切 | 粒度过细时配置难维护 |
| 回切机制 | 故障恢复后自动回切并设冷却时间 | 无冷却会在阈值附近来回震荡 |
| 用量上限 | 给云端设置配额与告警 | 兜底流量失控导致成本飙升 |
兜底链路平时就要用演练流量验证：故障当刻才第一次切换，配置错误、鉴权失效、模型名不匹配这类问题会集中爆发。
把云端模型当作「另一个模型」对待：系统提示、对话模板与后处理都要分别验证，不能假设换过去就等价。