AI Day 27: 多模型编排与Fallback策略 — 永远不让服务挂在一棵树上

日期: 2026-04-28 阶段: 第二阶段 — 工程实践 (Day 16-30) 标签: #多模型编排 #Fallback #模型路由 #A/B测试 #版本管理 #LiteLLM #Portkey

---

学习路径

第二阶段：工程实践 (Day 16-30)
├── Day 16-17: LLM应用架构 + 安全Guardrails ✅
├── Day 18: 可观测性与监控 ✅
├── Day 19-21: 生产级RAG三部曲 ✅
├── Day 22-25: Agent系统工程化四部曲 ✅
├── Day 26: LLM成本工程 ✅
├── Day 27: 多模型编排与Fallback ← 你在这里
├── Day 28: LLM应用测试策略
├── Day 29: 案例分析：企业LLM平台架构
└── Day 30: 第二阶段总结

---

核心概念

一句话定义

多模型编排(Multi-Model Orchestration) = 在生产系统中同时管理多个LLM Provider/Model，通过智能路由、自动Fallback、版本管理和A/B测试，实现高可用、高质量、低成本的AI服务。

金融类比：多模型 = 多银行账户

每个成熟企业都不会只开一家银行的账户：

多银行账户策略                  多模型编排策略
├── 主力银行(日常结算)          ├── Primary Model (日常请求)
│   → 工商银行(费率低,覆盖广)   │   → Claude Sonnet (性价比高)
├── 备用银行(主力故障时)        ├── Secondary Model (主力不可用时)
│   → 招商银行(服务好,速度快)   │   → GPT-4o (兼容性好)
├── 紧急通道(大额/特殊)        ├── Premium Model (高质量需求)
│   → 央行清算(最终保障)       │   → Claude Opus/o3 (最强推理)
└── 资金池调度中心              └── 模型路由网关
    (根据金额/紧急度/成本分配)      (根据任务/质量/成本分配)

核心原则：
1. 永远有备选方案 (Never single point of failure)
2. 按场景选最优 (Right model for right task)
3. 自动切换机制 (Auto failover on error)
4. 成本与质量平衡 (Optimize across providers)

---

知识点1: 多模型架构模式

模式一：Primary-Secondary (主备模式)

请求 → [Primary: Claude Sonnet] ──成功──→ 返回
              │ 失败/超时
              ▼
       [Secondary: GPT-4o] ──成功──→ 返回
              │ 失败/超时
              ▼
       [Tertiary: Gemini Flash] ──成功──→ 返回
              │ 全部失败
              ▼
         [降级响应/人工兜底]

最简单也最常用。金融类比：支付路由 — 先走费率最低的通道，不通再走备用。

模式二：Load Balance (负载均衡模式)

              ┌──→ [Claude Sonnet]  40%流量
请求 → [LB] ──┼──→ [GPT-4o]        35%流量
              └──→ [Gemini Flash]   25%流量

策略：Round-Robin / Weighted / Least-Latency / Rate-Limit-Aware

适合高流量场景。按权重+配额余量动态分配。

模式三：Capability-Based Routing (能力路由)

任务分类器
├── 代码生成     → Claude Sonnet (SWE-bench最高)
├── 数学推理     → o3 / Claude Opus (推理能力强)
├── 长文档分析   → Gemini 2.5 Pro (1M上下文)
├── 简单分类     → Haiku / GPT-4o-mini (便宜快速)
└── 数据敏感     → 本地Qwen-72B (不出内网)

"专人做专事"。为每种任务选最擅长的模型。

模式四：Cascade (级联模式)

请求 → [Haiku] → 置信度>0.9? ──是──→ 返回(成本1x)
                    │否
                    ▼
              [Sonnet] → 置信度>0.85? ──是──→ 返回(成本10x)
                    │否
                    ▼
              [Opus] → 返回(成本50x)

优势：70%请求在第一层解决，整体成本极低
关键：置信度评估器设计(长度合理性/不确定性检测/格式完整性/LLM-Judge)

四种模式对比

生产推荐组合: 入口用Capability-Based分类，简单任务走Cascade，复杂任务走Primary-Secondary，高流量任务走Load Balance。每条路径都有Fallback兜底。

---

知识点2: Fallback策略深度设计

触发条件分类

1. 硬性故障 — HTTP 500/502/503, 连接超时, 429限流, 401鉴权失败
2. 软性故障 — 响应超时, 空响应, 格式错误, 内容异常(幻觉/答非所问)
3. 质量降级 — 评估分数低于阈值, 一致性变化, 延迟飙升, 模型静默更新

软性故障和质量降级最容易被忽略，却最影响用户体验。

超时策略分层设计

不同场景需要不同超时阈值：

场景                    连接超时    读取超时    总超时    原因
实时聊天                3s         15s        20s     用户等不了太久
后台分析                5s         60s        120s    可以慢，要准
流式输出(Streaming)     3s         首token5s   90s     首token快就行
批量处理                10s        120s       300s    吞吐优先

降级响应设计

全部Fallback耗尽后，不应该简单返回500错误

降级层级：
Level 1: 返回缓存中最近一次相似请求的结果(标注"缓存结果")
Level 2: 返回预置模板回答(FAQ场景)
Level 3: 转人工/转规则引擎(金融计算场景)
Level 4: 友好提示 + 请求入队列后台重试 + 通知运维

金融类比：ATM取不了钱时
├── 先试另一台ATM (Fallback Provider)
├── 再试手机银行 (Fallback Channel)
├── 最后去柜台 (人工兜底)
└── 不能说"系统故障请明天再来" (绝不裸500)

熔断器模式 (Circuit Breaker)

金融类比：自动止损

三种状态：
CLOSED ──连续5次失败──→ OPEN ──等待5分钟──→ HALF_OPEN
  ↑                                           │
  └────────────测试成功────────────────────────┘
                                  │
                              测试失败 → 回到 OPEN

CLOSED: 正常放行
OPEN: 全部跳过，直接走下一个Fallback
HALF_OPEN: 试探放行少量请求，测试是否恢复

Fallback链核心代码思路

class FallbackChain:
    """每个节点含: Provider + 超时配置 + 熔断器"""

    async def execute(self, request):
        for node in self.chain:
            if node.circuit_breaker.is_open:
                continue  # 跳过熔断中的节点
            try:
                response = await node.call(request)
                if self.validate_response(response):
                    return response
                # 软性故障：响应格式/质量不达标
                node.circuit_breaker.record_failure()
            except (HardFailure, TimeoutError):
                node.circuit_breaker.record_failure()

        # 全部失败 → 降级响应(不是简单报错)
        return self.degraded_response(request)
        # 降级策略：提示用户稍后重试 + 请求入队列后台重试

---

知识点3: 模型版本管理

为什么版本管理如此重要？

2024-2025 血泪教训：
├── OpenAI gpt-4-turbo "悄悄变笨" → 没Pin版本的应用受影响
├── Claude 3→3.5→4 迁移 → 每次大版本prompt需调整
├── Gemini API Breaking Change → JSON解析失败
└── 教训：模型版本≠软件版本，它会"悄悄变"

版本管理策略三板斧

Pin版本 + Shadow Testing + 渐进迁移

# BAD: 使用别名(随时可能变)
model = "claude-sonnet"           # 危险！

# GOOD: Pin到具体版本
model = "claude-sonnet-4-20250514"  # 明确版本

Shadow Testing: 新模型在后台"跟跑"，不影响用户。异步发送10%请求到候选模型，离线对比质量/延迟/成本/格式兼容性。累积1000+样本后再做迁移决策。

渐进迁移(Canary Release):

Day 1-3:  1%流量 → 新模型 (监控错误率)
Day 4-7:  10%流量 (对比质量评分)
Day 8-14: 50%流量 (A/B测试统计显著性)
Day 15+:  100%流量 (旧模型保留为Fallback 30天)

回滚条件(任一触发): 错误率>2x / P99延迟>3x / 质量下降>5%

版本管理配置示例

VERSION_CONFIG = {
    "production": {
        "primary": "claude-sonnet-4-20250514",
        "secondary": "gpt-4o-2024-11-20",
        "last_validated": "2026-04-20",
        "next_review": "2026-05-20",      # 每月Review一次
    },
    "staging": {
        "primary": "claude-sonnet-4-20250514",
        "secondary": "gpt-4o-2025-03-15", # 新版本先在staging验证
        "shadow": "gemini-2.5-pro-preview", # 候选模型跟跑
    }
}
# 原则：staging领先production一个版本周期
# Review时检查：质量分数趋势 + 成本变化 + 新版本Release Notes

---

知识点4: 2025-2026 多Provider管理

Provider特点速览

                质量    速度    成本    上下文   特色
Anthropic       ★★★★★  ★★★★   ★★★    200K    代码/安全/指令遵循
OpenAI          ★★★★★  ★★★★★  ★★★    128K    生态最广/推理模型
Google          ★★★★   ★★★★★  ★★★★   1M      长上下文/多模态
Meta/Qwen(开源) ★★★★   ★★★★   ★★★★★  128K    可本地部署/可微调

LiteLLM 统一接入

from litellm import Router

router = Router(
    model_list=[
        {"model_name": "smart",
         "litellm_params": {"model": "claude-sonnet-4-20250514"},
         "rpm": 4000},
        {"model_name": "smart",  # 同名 = 自动负载均衡+Fallback
         "litellm_params": {"model": "gpt-4o"},
         "rpm": 10000},
        {"model_name": "smart",
         "litellm_params": {"model": "gemini/gemini-2.5-flash"},
         "rpm": 15000},
    ],
    routing_strategy="least-busy",
    num_retries=2, timeout=30, allowed_fails=3,
)
# 使用时完全透明，一行代码切Provider
response = await router.acompletion(model="smart", messages=[...])

Portkey AI Gateway 企业级

from portkey_ai import Portkey

portkey = Portkey(api_key="pk-xxx", config={
    "strategy": {"mode": "fallback"},  # fallback/loadbalance/ab-test
    "targets": [
        {"provider": "anthropic", "override_params": {"model": "claude-sonnet-4-20250514"},
         "retry": {"attempts": 2, "on_status_codes": [429, 500]}},
        {"provider": "openai", "override_params": {"model": "gpt-4o"}},
    ],
    "cache": {"mode": "semantic", "max_age": 3600},
})
# 自动处理路由/Fallback/缓存/监控，Dashboard可视化一切
response = portkey.chat.completions.create(messages=[...])

---

自建网关 vs 第三方选择

选择决策树：

团队<5人 且 月请求<100万 → 直接用LiteLLM (开源免费)
团队5-20人 且 需要Dashboard → Portkey/Helicone (SaaS付费)
团队>20人 或 强合规要求 → 自建Gateway (投入大但可控)
特殊场景：金融/医疗数据 → 必须自建或私有化部署

自建网关核心模块：
├── Auth Layer: API Key管理 + 按用户限流
├── Router: Capability/LB/Cascade路由引擎
├── Adapter: 每个Provider的SDK封装
├── Cache: 语义缓存 + Exact Match缓存
├── Observability: 日志 + Metrics + Trace
└── Admin: 配置热更新 + A/B测试管理

---

知识点5: A/B测试框架

Champion-Challenger 模型

金融类比：基金"赛马制"

├── Champion: claude-sonnet-4 → 90%流量
├── Challenger A: gpt-4o-new  → 5%流量
├── Challenger B: gemini-2.5  → 5%流量
└── 每周评估: 质量×0.5 + 成本×0.3 + 延迟×0.2 → 决定是否切换

实施要点

实验生命周期：
1. 定义假设: "Challenger在代码任务上质量高于Champion"
2. 确定指标: primary=quality_score, secondary=latency,cost
3. 计算样本量: 功效分析(Power Analysis) → 最少N=2000
4. 分流: 按user_id哈希分桶，保证同一用户始终在同一组
5. 运行: 持续2-4周，不中途偷看结果
6. 分析: t-test + effect size + 分层分析
7. 决策: Promote / Reject / Extend

统计显著性要点

LLM A/B测试常见陷阱：

1. 样本量不够就下结论 → 至少1000请求，高方差任务5000+
2. 只看平均值忽略分布 → 要看P50/P90/P99
3. 多指标冲突没有优先级 → 提前定义权重
4. 没有按任务类型分层 → Stratified Analysis
5. 窥探效应(天天看) → 提前确定评估时间点或用Sequential Testing

决策矩阵：
├── p_value < 0.05 且 effect_size > 0.1 → PROMOTE (Challenger上位)
├── p_value < 0.05 且 effect_size < -0.1 → REJECT (Challenger淘汰)
├── p_value >= 0.05 → INCONCLUSIVE (继续收集数据)
└── |effect_size| < 0.1 → NEUTRAL (差异无实际意义，按成本选)

---

今日思考

思考1: 多模型编排的"隐性成本"

多模型看起来完美，但有隐性成本：(1) Prompt不一致 — 不同模型对同一Prompt理解不同，需要为每个模型调参；(2) 输出格式差异 — 需要更健壮的Parser或每个模型写Adapter；(3) 评估复杂度 — N个模型横向对比工作量呈N^2增长。建议：先做Primary-Secondary，稳定后再按需加复杂模式。

思考2: Fallback应该"静默"还是"通知用户"？

B端API用户：透明(response header标注实际模型)。C端用户：静默切换，但如果质量评分低于阈值，显示"当前回答可能不够准确"。核心是不让用户困惑"今天AI怎么变笨了"。

思考3: AI时代如何避免供应商锁定？

抽象层隔离。应用代码不直接调用任何Provider SDK，通过统一接口层(LiteLLM/自建Gateway)。Prompt模板化为每个模型维护微调版本，输出Schema强约束标准化，合同不签排他协议。Provider只是"可插拔的实现"。

---

面试表达

30秒版本

生产级LLM应用必须多模型编排。四种模式组合使用：Primary-Secondary做基础Fallback，Capability-Based按任务路由最擅长的模型，Cascade逐级升级控制成本，Load Balance处理高流量。关键是熔断器防级联故障，Shadow Testing验证新模型，A/B测试做科学决策。用LiteLLM或Portkey统一接入，避免Provider锁定。

追问准备

Q: Anthropic和OpenAI同时宕机怎么办？ → Fallback至少3层，第三层用Google或本地开源模型。核心服务还要有非AI降级方案 — 回退到规则引擎或预置模板。

Q: 不同模型输出不一致怎么保证体验？ → 三层保障：JSON Schema强约束 + 后处理标准化层 + 每个模型维护独立Prompt版本。90%不一致可通过Schema约束解决。

Q: A/B测试中如何评估LLM"质量"？ → 多维度：自动指标30%(格式/长度/延迟) + LLM-as-Judge 30% + 人工抽检20% + 下游业务指标20%。

Q: 多模型编排会增加多少延迟？ → 正常路径零额外延迟(路由决策<1ms)。Fallback路径多一次完整调用(+2-10s)。Cascade模式可能多一层调用但总体成本更低。关键是Fallback是异常路径不是常规路径，99%请求在Primary就成功了。

---

学习资源

---

明日预告

Day 28: LLM应用测试策略 — 如何为非确定性系统设计测试：单元测试、集成测试、评估驱动开发(Eval-Driven Development)。