第 11 讲 | LLM 运行时治理：模型路由、版本控制与容灾降级⭐
本节我们将掌握：
- 模型路由的三种模式：静态路由 → Cascade（级联）→ Classifier（分类器），以及 Cascade Trap 的量化陷阱
- Prompt 版本管理四件套：模型版本/Prompt 版本/知识库版本/Agent 工作流版本的协同灰度
- 容灾降级四级路径：主模型 → 备模型 → 降级模型 → 本地规则兜底，强调用户可选择、不"偷偷切换"
- LLM 调用观测落盘数据结构和异常告警指标设计
从模型选型到运行时治理
详见第 09 讲（模型选型与抽象层）解决了"选哪个模型、怎么建抽象层"的问题。详见第 10 讲（RAG 全链路架构）说 RAG 时提到检索结果的生成环节依赖 LLM。但模型选好了，生产环境里还有另一组问题：
- 同一个用户问"怎么退款"，昨天用 Claude Opus 4.6 回答得很好，今天突然返回 503。
- 同一个 Prompt，上周在 GPT-5.4 上测试通过，这周 OpenAI 发了个小版本更新，输出格式变了。
- 凌晨 3 点，某租户的 Token 用量突增 10 倍，是正常业务还是被攻击？
这就是 LLM 运行时治理要解决的问题。它不是"模型选型"的一次性决策，而是"模型在生产环境里怎么管、怎么控、怎么优化"的持续过程。
2026 年的共识：模型是易耗品，运行时治理能力才是资产。
模型路由：让每个请求找到最合适的模型
为什么需要路由
生产环境的 LLM 调用不是"一个模型打天下"。原因至少有三个：
- 成本差异巨大：Claude Opus 4.6 的单价是 Qwen 3-72B 的 5-10 倍，但简单问题（"今天几号"）用 Opus 是浪费
- 单点故障风险：OpenAI 在 2025 年发生过多次区域性宕机，单模型依赖 = 全挂
- 质量波动：模型厂商会悄悄更新版本，同一 Prompt 在不同时间的输出可能不一致
路由的目标：每个请求都找到"性价比最优"的模型，同时保证可用性。
三种路由模式（按生产演进顺序）
| 方式 | 业界标准名 | 做法 | 适合场景 |
|---|---|---|---|
| 静态/规则路由 | Static / Rule-based | 按输入长度、关键词、用户等级、task_type 硬编码映射模型 | 初期快速上线；有明确路由信号的工作负载 |
| 轻量分类器 | Classifier-up-front | 小模型（Qwen3.5-9B / fine-tuned Haiku / distilled BERT）读请求 → 判复杂度 → 挑模型 | 流量大、难度信号跟表面特征相关性弱的场景，企业级最常用的方案 |
| 级联 | Cascade | 便宜模型先跑 → 质量信号判 → 不够升档强模型 | 规则用完了、分类器养不起时的折中（需要质量信号靠谱，如缺少字段、高级模型评价，决不能自证） |
我们逐一拆解。
静态路由：初期够用，但不是终点
最简单的路由就是按任务类型或用户等级硬编码：
def route_model(task_type, user_tier):
if task_type == "complex_reasoning":
return "claude-opus-4.6"
elif task_type == "simple_qa":
return "qwen-3-7b"
elif user_tier == "premium":
return "gpt-5.4"
else:
return "qwen-3-72b"这在项目初期完全够用。但有两个问题：
- 规则膨胀：任务类型从 3 种变成 30 种，规则表越来越难维护
- 信号不足：有些任务的复杂度不能只看 task_type，还要看输入长度、领域、用户历史行为
Cascade（级联）：先便宜后升级，但要警惕陷阱
Cascade 的核心逻辑：先用便宜模型跑，如果质量信号不达标，再升级到强模型重跑。
用户请求 → Qwen 3-72B（便宜）运行
│
├── 质量信号通过 → 直接返回（省了 80% 成本）
└── 质量信号不通过 → 升级到 Claude Opus 4.6 重跑质量信号三选一（不能全选，否则太贵）：
| 信号类型 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 置信度分数 | 模型输出时附带 confidence score（如 <0.7 则升级） | 零成本，模型原生支持 | 很多模型的 confidence 不可靠 |
| 轻量裁判模型 | 用小模型（Qwen 3-9B）判输出是否合格 | 相对准确 | 多一次 LLM 调用 |
| 确定性规则 | 检查输出是否包含关键字段（如 JSON schema 校验） | 零 LLM 成本 | 只能判结构性问题，不能判语义质量 |
⚠️ Cascade Trap（double pay 陷阱）：
这是级联最大的坑——如果质量信号判错（false-fail），我们会付两次钱：cheap 那次和 strong 那次都花了。
选型顺序：有明确路由信号 → 先静态路由 → 规则用完了上级联 → 流量大到能摊分类器成本 → 上 Classifier。跳级直接上 Classifier 是经典过度工程，除非是企业级大项目一步到位。
Classifier（分类器）：企业级最常用的方案
当流量足够大（日均 10 万+ 请求），我们可以用一个独立的小模型做"前置路由器"：
用户请求 → Classifier（Qwen 3-9B fine-tuned）
│
├── 判"简单" → 走 Qwen 3-7B
├── 判"中等" → 走 Qwen 3-72B
└── 判"复杂" → 走 Claude Opus 4.6这个 Classifier 是一个独立的 fine-tuned 模型，训练数据来自历史请求的人工标注（"这个问题实际需要多强的模型"）。
优势：一次判定，零 double pay 风险。
代价：需要维护一个额外的模型，训练数据和推理成本都要算进去。
2026 年的产品化：LiteLLM、Portkey 等网关已经内置了 Router 功能，支持基于规则的静态路由和基于历史的动态路由。但 Classifier 部分通常还是需要自研，因为每个业务的"复杂度定义"不一样。
案例举例：国内某Agent开发者助手中，用一个 fine-tuned 的 GLM-5.1-9B 做 Classifier，训练数据来自过去 3 个月的内部工单（约 5 万条，人工标注为"简单/中等/复杂"）。上线后，相比全部用顶级模型，成本降低了 62%，且回答质量没有明显下降。关键在于训练数据的质量——他们花了 2 周时间让 3 个标注员独立标注，取多数投票作为标签，避免了单人标注偏差。
Classifier 的核心不在模型本身，而在训练数据。如果我们已经有历史请求日志，可以用"实际用了什么模型 + 用户是否满意"反推复杂度标签。如果没有历史数据，先用静态路由跑 1-2 个月积累数据，再训练 Classifier。
路由模式对比总结
| 维度 | 静态路由 | Cascade | Classifier |
|---|---|---|---|
| 实现复杂度 | 低 | 中 | 高 |
| 额外成本 | 无 | 有（double pay 风险） | 有（Classifier 推理成本） |
| 准确率 | 取决于规则覆盖 | 取决于质量信号 | 最高（可 fine-tune） |
| 适合阶段 | MVP / 小规模 | 中期优化 | 大规模精细化运营 |
Prompt 版本管理：为什么需要、怎么管
为什么 Prompt 需要版本管理
传统软件有代码版本管理（Git）。但 LLM 应用里，Prompt 也是"代码"的一部分，而且更容易出问题：
场景 1：
上周测试通过的 Prompt，今天模型厂商更新了版本，输出格式变了。
谁负责？怎么回滚？
场景 2：
产品经理改了 Prompt 里的两句话，上线后发现某个边缘场景的回答质量下降。
怎么定位是哪次修改导致的？
场景 3：
A/B 测试需要同时跑两个版本的 Prompt，各占 50% 流量。
怎么实现灰度发布？核心问题：Prompt 不是"改了就完事"，它和模型版本、知识库版本、Agent 工作流版本是耦合的。改一个，其他可能都要跟着变。
版本四件套⭐
生产环境的 LLM 应用，一次"发布"实际上涉及四个维度的版本：
| 版本维度 | 示例 | 变更频率 | 影响范围 |
|---|---|---|---|
| 模型版本 | gpt-5.4 → gpt-5.5 | 厂商控制，不定期 | 全局 |
| Prompt 版本 | system prompt 微调、few-shot 示例更换 | 高频（每周几次） | 特定任务 |
| 知识库版本 | RAG 索引 v1.2 → v1.3 | 中频（每天/每周更新） | 检索相关任务 |
| Agent 工作流版本 | 工具调用链增加一个步骤 | 低频（每月几次） | 特定 Agent |
这四个维度是正交的——改任何一个都可能影响最终输出。所以生产环境必须记录完整的"版本快照"：
# 每次发布的版本快照示例
release:
id: rel-20260714-001
model: "claude-opus-4.6" # 模型版本
prompt: "prompt-v2.3.1" # Prompt 版本（Git commit hash）
knowledge_base: "kb-v1.2.8" # 知识库版本（向量库 snapshot ID）
agent_workflow: "workflow-v0.9" # Agent 工作流版本
timestamp: "2026-07-14T10:30:00Z"这样出了问题可以精准回滚："把 prompt 回退到 v2.3.0，其他不变"。
灰度发布三层策略
Prompt 修改不是"全量上线"，需要分三层灰度：
第一层：内部 Canary（1%-5% 流量）
→ 团队内部账号 + 少数种子用户
→ 观察错误率、延迟、Token 消耗
第二层：小比例灰度（10%-20% 流量）
→ 随机抽取一部分用户
→ A/B 测试关键指标（回答质量、用户满意度）
第三层：全量发布（100% 流量）
→ 所有用户使用新版本
→ 保留旧版本作为快速回滚路径关键原则：每一层都要有明确的"通过标准"和"回滚触发条件"。比如：
- 通过率：新版本的回答质量评分 ≥ 旧版本（由人工或裁判模型评判）
- 回滚触发：错误率 > 5% 或 P95 延迟 > 10s
Prompt 版本管理的工具链
2026 年已经有专门的 Prompt 版本管理工具：
| 工具 | 定位 | 特点 |
|---|---|---|
| Promptfoo | 开源 Prompt 评测框架 | 支持多版本对比、回归测试、CI/CD 集成 |
| LangSmith（LangChain） | LangChain 生态的观测平台 | Prompt 版本追踪 + 执行轨迹 + 评测 |
| Weights & Biases Prompts | ML 实验追踪扩展 | Prompt 版本 + 模型输出对比 |
| Portkey / LiteLLM | 网关层内置 | 路由 + 缓存 + 版本管理一体化 |
选型建议：小型团队用 Git + 自建脚本就够了（但要做好版本四件套的记录）；中型团队上 LangSmith 或 Portkey；大型团队用 Promptfoo 做自动化回归测试。
版本冲突的实际案例：某金融科技公司做 RAG 问答系统，有一次产品经理改了 Prompt（从"请简洁回答"改成"请详细回答"），但知识库还是上周的版本（包含旧的合规要求）。结果是模型按照新 Prompt 生成长答案，但引用了旧知识库的过时条款，导致合规风险。事后复盘发现，问题在于 Prompt 版本和知识库版本没有绑定——改 Prompt 时应该同步更新知识库索引。
版本四件套不是"记录一下"，而是要在发布流程中强制校验。可以在 CI/CD pipeline 里加了一个检查点：每次发布前，自动比对四个版本的 hash，如果任何一个和上一次发布不同，必须重新跑评测集，通过后才能上线。
容灾降级：四级路径，用户可选择
为什么需要容灾降级
这里我们展开讲多模型容灾、降级的具体路径和用户体验。
2026 年的生产环境，单模型依赖 = 单点故障。OpenAI、Anthropic、Google 都发生过区域性宕机。架构师必须假设"主模型随时可能挂"。
四级降级路径
主模型：Claude Opus 4.6（默认，最强能力）
↓ 超时 / 限流 / 500 错误（连续 3 次）
备模型：GPT-5.4（同梯队，质量接近）
↓ 也挂了
降级模型：Qwen 3-72B（能力降级，但至少能响应）
↓ 也挂了
本地规则兜底：模板回复 + 人工通道关键原则：
- 主备模型能力梯队接近：Opus 挂了换 GPT-5，质量不会断崖式下跌
- 可以降级模型但不能不可用：Qwen 3-72B 可能在某些场景不如 Opus，但至少能回答问题
- 本地规则兜底是最后防线：当所有 LLM 都不可用时，用预设模板回复（如"系统繁忙，请稍后再试"）+ 引导用户走人工通道
降级的代价和缓解
| 降级维度 | 风险 | 缓解手段 |
|---|---|---|
| 质量下降 | 回答准确度降低、幻觉增多 | 关键场景加护栏（输出校验 + 人工审核） |
| 能力丢失 | 小模型不支持 Tool Calling / Function Calling | 降级路径中跳过需要工具调用的步骤 |
| 上下文窗口缩小 | 无法处理长文档 | 降级时先做上下文压缩或分段处理 |
| 语言支持变差 | 非英语/中文质量下降 | 选择多语言能力强的降级模型 |
Russell经验⭐
- 高风险场景保质量，尽量不降级。
- 高风险领域（金融、医疗、法律）保质量，不降级或只降半档。
- 用户明确选择的场景，或者企业明确承诺的，不要“偷偷切换”（Claude Code 偷偷降智，被全世界口诛笔伐；有些算力节点降智，会被OpenRouter监控并降级）。
- 降级要有明确的回退路径，最好是用户可选择，不是"挂了再说"。
观测与告警：每次 LLM 调用落盘什么
在02章节，我们已经讲了LLM和传统的观测、告警内容不同，下面详细展开。
为什么需要观测
传统系统监控 QPS、P99 延迟、错误率。LLM 系统在这些基础上，还需要监控：
- Token 消耗：每次调用花了多少 Input/Output Token，折合多少钱
- 回答质量：是否有幻觉、是否偏离主题、是否满足用户需求
- 缓存命中率：语义缓存是否生效，同样的问题是否重复调 API
- 路由决策：为什么这个请求走了模型 A 而不是模型 B
没有这些数据，出了问题是"黑盒"——只知道"好像不对"，但不知道哪里不对。
LLM 调用落盘的数据结构举例
注：仅供参考，每家模型返回不同，每个产品可能也有自己相关的LLM数据。
{
"request_id": "req-20260714-abc123",
"timestamp": "2026-07-14T10:30:00Z",
"tenant_id": "tenant_001",
"user_id": "user_12345",
"task_type": "code_generation",
"model": "claude-opus-4.6",
"prompt_version": "prompt-v2.3.1",
"knowledge_base_version": "kb-v1.2.8",
"input_tokens": 1200,
"output_tokens": 450,
"total_cost_usd": 0.0078,
"latency_ms": 3200,
"ttft_ms": 800,
"status_code": 200,
"error_message": null,
"routing_decision": {
"router": "static",
"reason": "task_type=code_generation"
},
"cache_hit": false,
"retry_count": 0,
"quality_metrics": {
"hallucination_score": 0.1,
"relevance_score": 0.92,
"source_citations": ["doc_123", "doc_456"]
}
}字段说明：
request_id：全局唯一 ID，用于链路追踪tenant_id / user_id：成本归因和配额控制prompt_version / knowledge_base_version：版本回溯input_tokens / output_tokens：成本核算latency_ms / ttft_ms：性能监控（TTFT = Time To First Token）routing_decision：路由决策记录，方便事后分析cache_hit：缓存是否命中retry_count：重试次数quality_metrics：质量评分（可由裁判模型或后处理模块打分）
异常告警指标
基于上述落盘数据，我们需要设置以下告警：
| 指标 | 阈值 | 含义 |
|---|---|---|
| 单日成本突增 | 相比 7 日均值 +50% | 可能有异常流量或被攻击 |
| 平均延迟超标 | P95 延迟 > 10s（持续 5 分钟） | 模型负载过高或网络问题 |
| 错误率飙升 | 错误率 > 5%（持续 2 分钟） | 模型服务不可用或 API 变更 |
| 缓存命中率低 | 命中率 < 10%（日均） | 缓存策略可能需要优化 |
| 幻觉率超标 | hallucination_score > 0.3（连续 10 次） | Prompt 或知识库可能有问题 |
| Token 用量异常 | 单个用户日用量 > 均值 +3σ | 可能有滥用或 Bug |
观测工具链
2026 年的主流方案：
| 方案 | 定位 | 特点 |
|---|---|---|
| LangSmith | LangChain 生态观测平台 | 完整追踪 + 评测 + Debug |
| Portkey | 云网关内置观测 | 零配置接入 + 成本追踪 + 多租户 |
| Prometheus + Grafana | 传统监控扩展 | 自定义指标 + 灵活 Dashboard |
| Phoenix（Arize） | LLM 专用观测平台 | 质量评估 + 漂移检测 |
选型：用 LangChain/LlamaIndex 的团队直接上 LangSmith；用网关的直接开 Portkey 观测；需要深度定制的用 Prometheus + Grafana 自建。
国内监控工具链选择：
| 工具 | 类型 | 特点 | 适用场景 |
|---|---|---|---|
| Prometheus + Grafana | 开源自建 | 灵活性强，社区生态丰富 | 有运维团队的企业 |
| 阿里云 ARMS | 云托管 | 开箱即用，与阿里云深度集成 | 阿里云用户 |
| 腾讯云观测平台 | 云托管 | 一站式可观测，支持 LLM 监控 | 腾讯云用户 |
| Portkey Cloud | SaaS | 专为 LLM 设计，自带成本分析 | 快速起步，不想自建 |
| LiteLLM + Self-hosted Grafana | 开源 + 自建 | 成本低，需要自己维护 | 预算有限的团队 |
实践建议：小团队可以从云厂商的托管服务起步（如阿里云 ARMS），零运维成本。当 LLM 调用量达到一定规模后，再考虑自建 Prometheus + Grafana 方案以获得更大的灵活性。
观测数据不仅是"监控"，更是"优化依据"。举例：每周看一次路由决策分布图——如果某个任务类型 90% 的请求都走了强模型，说明静态路由的规则可能太粗了；如果缓存命中率连续一周低于 10%，说明语义缓存的阈值可能需要调高。观测数据驱动优化，比拍脑袋靠谱得多。
选型决策
架构师决策清单：
- 模型路由必建：初期静态路由，中期 Cascade，成熟期 Classifier。避免过度工程
- Cascade Trap 要量化：质量信号的 false-fail 率直接决定账单，选什么信号比"要不要级联"更重要
- Prompt 版本四件套：模型版本、Prompt 版本、知识库版本、Agent 工作流版本必须同时记录，支持精准回滚
- 灰度发布三层：内部 Canary → 小比例灰度 → 全量，每层有明确通过标准和回滚触发条件
- 容灾降级四级路径：主模型 → 备模型（同梯队）→ 降级模型 → 本地规则兜底，用户可选择、不"偷偷切换"
- 观测落盘要完整：每次调用记录 request_id、模型、Token、延迟、路由决策、缓存命中、质量评分
- 告警指标要量化：成本突增 50%+、P95 延迟 > 10s、错误率 > 5%、缓存命中率 < 10%
面试回答要点
Q：生产环境的 LLM 系统怎么做运行时治理？
答（抓治理 + 讲闭环）：
核心框架——运行时治理解决的是"模型选好后怎么管、怎么控、怎么优化"。我们从四个维度入手：路由、版本、容灾、观测。
路由——初期用静态路由（按任务类型映射模型），中期用 Cascade 降本（便宜模型先跑，质量不够升档），成熟期用 Classifier 精细化运营（小模型预判复杂度直接挑模型）。注意 Cascade Trap：质量信号的 false-fail 率决定账单，不能只看"能省多少"。
版本——Prompt 版本和模型版本、知识库版本、Agent 工作流版本是耦合的，必须记录完整的"版本四件套"。灰度发布分三层：内部 Canary → 小比例灰度 → 全量，每层有明确通过标准。
容灾——四级降级路径：主模型 → 备模型（同梯队）→ 降级模型 → 本地规则兜底。关键是用户可选择、不"偷偷切换"。高风险场景（金融、医疗）尽量不降级。
观测——每次调用落盘 request_id、模型、Token、延迟、路由决策、缓存命中、质量评分。告警指标包括成本突增 50%+、P95 延迟 > 10s、错误率 > 5%。
深度追问：
- "Cascade 和 Classifier 怎么选？" → 看流量规模。日均 10 万以下用 Cascade 够了；日均 100 万+ 上 Classifier 更划算，虽然要多维护一个模型，但避免了 double pay 风险。
- "Prompt 版本管理用什么工具？" → 小团队用 Git + 脚本；中型团队用 LangSmith 或 Portkey；大型团队用 Promptfoo 做自动化回归测试。
- "降级时怎么保证用户体验？" → 透明告知用户"模型切换了"，提供选项（继续用备用/等待恢复/手动选其他），主模型恢复后询问是否切回。用户能接受降级，但不能接受被偷偷降智。
小结
- 模型路由是成本优化的核心：静态路由 → Cascade → Classifier 三级演进，根据流量规模选择，避免跳级过度工程
- Cascade Trap 是最大陷阱：质量信号的 false-fail 率直接决定账单，选什么信号比"要不要级联"更重要
- Prompt 版本管理是基础设施：版本四件套（模型/Prompt/知识库/Agent 工作流）必须同时记录，支持精准回滚和灰度发布
- 容灾降级要透明：四级路径（主→备→降级→兜底），用户可选择、不"偷偷切换"，高风险场景不降级
- 观测落盘要完整：每次调用记录完整数据结构，告警指标量化（成本、延迟、错误率、缓存命中率）
思考题
我们的团队有一个客服系统，日均 50 万条对话，目前全部用 Claude Opus 4.6。从路由角度，我们会怎么设计 Cascade 策略？假设 cheap 模型用 Qwen 3-72B（成本是 Opus 的 1/10），我们希望命中率达到多少才能显著降本？如果质量信号的 false-fail 率是 40%，实际能省多少钱？（提示：false-fail代表质量信号判错，要传给strong再判断，所以要花两份钱）
凌晨 2 点，我们的系统触发告警：OpenAI API 区域不可用，我们的业务 80% 流量依赖 GPT-5.4。从运行时治理的角度，我们的系统应该怎样自动应对？事后复盘时，我们会补上哪些架构缺失？（提示：从路由切换、版本回滚、用户通知、降级路径四个维度回答）
参考资料
- VDF.ai: LLM Routing — Cut AI Costs 60-80% Without Losing Quality
- LiteLLM: Unified LLM API - Router & Fallback
- Portkey: AI Gateway with Observability
- Promptfoo: Open-source Prompt Testing Framework
- LangSmith: LangChain Observability Platform
- Arize Phoenix: LLM Observability & Evaluation
- Anthropic: Prompt Caching
- Cloudflare AI Gateway: Caching & Observability