核心 GUIDE
Model Routing 与 Fallback
生产级 LLM Application 不应把所有请求永久绑定到一个 Model；应根据 Task、Risk 与当前 System Condition 做 Routing，并在首选路径不可用、过慢、过贵或不够可靠时提供显式 Fallback。
核心心智模型
Routing 是根据可观察 Task Feature 与 Operational Signal 选择 Model 或 Execution Path 的 Policy。Fallback 是能力差异已知、有明确边界的 Alternative，而不是故障时随便切到任何可用模型。
为什么重要
Single-model Architecture 会把 Trade-off 隐藏到 Incident 才暴露。不同 Model 在 Latency、Cost、Tool Support、Context Limit 与 Behavior 上都有差异。Routing 让应用把高能力资源花在真正需要的地方，Fallback 则在首选 Dependency 失败时保持服务，同时避免悄悄改变产品 Guarantee。
01
先按 Requirement Routing，再给 Fallback 定边界
定义 Task Class 与每类任务的最低 Capability：Structured Output、Tool Use、Latency Ceiling、Context Size、Cost 或 Quality Floor。选择 Preferred Route 后，预先定义仍能满足 Hard Constraint 的 Fallback。如果没有任何 Fallback 能保持关键 Guarantee，就应显式 Degrade、Queue 或 Human Handling，而不是假装不同 Model 完全等价。
02
示例：快速 Chat Model 不能直接替代 Tool-capable Model
Customer-support App 把普通 FAQ 路由到快速低成本 Model，把 Account Change 交给 Tool-capable Model。发生 Outage 时，FAQ 可以切到第二个 Small Model，但 Account Change 会进入 Queue，因为 Fallback 不具备所需 Tool Contract。这样既保持 Availability，也不会悄悄改变行为边界。
常见失败模式
- 只按 Model Price 做 Routing，忽略 Capability 与 Consequence。
- Fallback 无法满足同样 Output 或 Tool Contract，却仍直接切换。
- Incident 中换 Model，却不测 Quality、Latency 与 Error Distribution Shift。
工程启发
- 优化 Cost 前先定义 Hard Capability Constraint。
- 把 Fallback 的 Quality 与 Feature Loss 写进 Product Contract。
- 在 Production 中观察 Route Selection、Fallback Frequency 与 Outcome Quality。
关键结论
- 01Routing 是 Application Policy，不是 Model 自带 Feature。
- 02只有 Capability Loss 可理解、可约束时，Fallback 才成立。
- 03显式 Degradation 比 Silent Model Substitution 更安全。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。