多模型路由与负载
第 13 章讲了如何接入多种模型供应商。但「接进来」只是第一步——生产里你希望不同任务用最合适的模型，并且在某个供应商抖动能自动切换。本章讲路由与容灾。
1. 为什么需要路由
- 成本：简单分类用便宜小模型，复杂生成才用大模型
- 质量：中文问答用本土模型，代码用强推理模型
- 可用：单一供应商限流/故障时，有备用通道不中断
2. 按任务类型路由
用工作流的「分类节点 + 条件分支」实现：先判断任务类型，再选模型。
[Start] → [分类 LLM] 输出 task_type
→ IF task_type == "分类" → 用 小模型A（便宜）
→ IF task_type == "创作" → 用 大模型B（强）
→ ELSE → 用 默认模型C# 路由策略示意
routing:
- match: "简单分类"
model: gpt-3.5-equivalent
- match: "长文创作"
model: flagship-large
- match: default
model: flagship-mid💡给每条路由设成本画像
在配置里记录每个模型的单价与延迟，路由时不仅看「能不能做」，也看「划不划算」。高频简单任务尽量下沉到小模型，成本能降一截。
3. 故障转移（Fallback）
主模型调用失败或超时时，自动切到备用模型，对用户无感知。
fallback_chain:
primary: model-b
on_error: [model-c, model-a]
timeout_ms: 8000
retry: 1⚠️Fallback 要验证输出兼容
不同模型的输出格式、语气可能不同。若下游依赖固定结构（如 JSON），切换到备用模型后仍需走同一套解析与兜底，避免格式突变导致流程崩。
4. 负载与限速
多应用共用模型配额时，用中间代理做统一限速与排队，避免互相踩踏：
请求 → 模型网关（限流/排队）→ 具体供应商
↑ 监控各供应商剩余配额，超阈值则优先走有额度的通道🎯动手做
在你的工作流里加一个分类节点，把输入分为「简单/复杂」两类，分别接不同模型节点，运行几条样例，观察是否按预期走了不同模型。
小结
- 路由按任务类型选模型，兼顾质量与成本
- Fallback 链提供故障转移，但要保证输出兼容
- 用模型网关统一限流与配额管理
- 下一步用评估体系量化这些策略的效果 →