gateway 治理 — 路由策略、fallback 链、预算闸与意图感知路由

日期: 2026-07-30 阶段: Phase 2 - AI-native 参考架构 标签: #llm-routing #fallback #budget-governance

核心问题

Day 43 把 LiteLLM gateway 的五层职责讲了个全貌，Day 45 单独深挖了缓存层。今天补完最关键的两层——路由层（routing）和韧性层（resilience），外加治理层的预算闸。这三件事决定 agent-v2 在生产里**「请求该发给哪个模型、挂了怎么办、超预算怎么拦」**。

具体三问：(A) 多模型路由有几种策略，分别按什么决策（成本/延迟/usage/语义）？(B) fallback 链和熔断器怎么配，数字是多少？(C) 把路由从「规则」升级为「意图感知」——vLLM Semantic Router v0.3 Themis（2026-06-05 发布）做了什么，和 LiteLLM 的静态路由是什么关系？

这对 AML Copilot 是「成本可持续 + 不间断服务」的底座：orchestrator 一次广度检索能烧 15× token（Anthropic，2025-06），没有预算硬闸会失控；一个 provider 429 整条合规链就断，没有 fallback 就是事故。

关键内容

A. 多模型路由：六种策略，按什么决策

LiteLLM 内置六种路由策略，差别在「优化什么」（digitalapplied LLM gateway 工程参考，2026）：

OpenRouter 的自动加权值得对照：优先选「过去 30 秒无故障」的 provider，再用反平方成本加权——「贵 3 倍的 provider 被选中概率约低 9 倍」（digitalapplied，2026）。它还能按性能分位（p50/p75/p90/p99）降权而非剔除慢端点，比硬切更平滑。

对 agent-v2 的路由决策逻辑：不同 agent 该走不同策略，不能一刀切——

请求 → 按 agent 角色选路由策略：
  orchestrator(lead, 需强推理) ──► Cost-Based 反向：选强模型(claude-sonnet-4-6)
                                    宁可贵，质量优先（lead 决定整链质量）
  knowledge/research/portfolio   ──► Cost-Based：选便宜 sub-agent 模型
  (sub-agent, 量大)                  (claude-haiku-4-5 / mi-large)，量大省钱
  典型分类(typology)             ──► 走小模型 + Day 45 语义缓存

这正好对应仓库 providers.ts 里 defaultChatModel（lead）vs defaultSubAgentModel（sub）的分层——lead 用贵的强模型、sub 用便宜的快模型是 Anthropic orchestrator-worker 的核心成本结构（2025-06），路由策略要把它编码进 gateway。

B. fallback 链 + 熔断器：分类配置与具体数字

fallback 不是一种，是三类（digitalapplied，2026），各需独立 provider 列表：

retry 先于 fallback：先在同一模型上重试（Portkey：最多 5 次指数退避），重试耗尽才走 fallback 链。fallback 链至少三级，按成本排序：主模型 → 同 provider 备份 → 跨 provider 备份（digitalapplied，2026）。跨 provider 这级是关键——它保证「一家宕机不级联拖垮整栈」。

熔断器（circuit breaker）具体数字（LiteLLM cooldown 实现，digitalapplied，2026）：

熔断状态机（per provider+model 粒度）:

  [CLOSED 正常]
     │ deployment 失败率 >50% 或返回 429
     ▼
  [OPEN 熔断] ── 冷却 5s（默认）── 期间该 model 不被选
     │ 冷却结束
     ▼
  [HALF-OPEN 探测] ── 周期性试探恢复
     │ 成功 → CLOSED ；失败 → 回 OPEN（再冷却）

反直觉洞察①（熔断粒度必须是「provider+model 组合」，不是「provider」）：直觉按 provider 熔断——「Anthropic 挂了就别发 Anthropic」。但 LiteLLM 的粒度是 provider+model 组合（digitalapplied，2026），因为「同一 provider 的某个 model 出问题（如 claude-sonnet-4-6 限流）不应阻塞同 provider 的其他 model（claude-haiku-4-5）」。按 provider 粗粒度熔断会误伤健康模型，把可用容量白白冷却掉。社区另有「5 次失败触发、60s 冷却」的口径（getmaxim，2026），与 LiteLLM 默认「50% 失败率、5s 冷却」是不同实现取舍——冷却太长牺牲可用性，太短可能在 provider 没恢复时反复撞墙，需按 provider 实际恢复时间调。

C. 预算闸 + 意图感知路由：从「规则」到「语义」

预算硬闸（治理层）：gateway 在调 provider 之前做钱包检查——余额不足直接返 HTTP 402（digitalapplied，2026），或静默把 max_tokens 截到剩余余额。这是「请求级」闸，比应用层的步数闸更硬。本项目要双闸：应用 Budget（给好的 UX 报错）+ gateway 402（兜底防超支），呼应 Day 43。

意图感知路由——把路由升级一个维度。前面 A 节的策略都是「按成本/延迟/负载」这些运营信号路由，不看请求内容本身。vLLM Semantic Router v0.3 Themis（2026-06-05）做的是按语义意图路由（vLLM blog，2026-06）：

核心是一条 signal → projection → decision → algorithm → model 流水线（不是单分类器）：

query
  │
  ▼ 抽取多信号族(signal families): embedding/complexity/context/domain...
  │   · complexity 信号：捕捉「推理难度」，识别多步推理/硬综合
  │   · embedding 信号：对候选锚点算语义相似度(支持文/图/音多模态)
  ▼ 归一化为命名策略概念(projections): 如 support_fast / support_escalated
  ▼ decisions：显式、可测的路由策略
  ▼ algorithms 选模型：
      简单事实问题 ──► 非推理小模型（省钱省延迟）
      多步推理任务 ──► 推理模型（chain-of-thought 开启）

v0.3 相对 v0.2 的关键新增是 Session-Aware Agentic Routing（SAAR）：在活跃工具循环中防止不安全的模型切换、维持会话连续性（vLLM blog，2026-06）。

反直觉洞察②（agent 工具循环中途换模型会出事，所以路由要「有状态」）：直觉觉得「每次调用独立挑最优模型」最省钱。但 SAAR 揭示一个坑——agent 在一个工具循环里（边想边调工具）中途被路由切换到另一个模型，会破坏推理连续性（不同模型的工具调用风格、上下文理解不一致），导致循环卡死或结论漂移。所以 agentic 负载的路由必须是 stateful 的：一旦进入工具循环就锁定模型，不在循环中途为省一点钱而换模型。 这和 Day 44 MCP stateless 的「单次请求无状态」是不同层面——协议层无状态，但 agent 推理循环的模型选择必须有状态。

vLLM-SR 的效果（RouterArena 榜，2026-06）：#1，加权 Arena 分 75.4，准确率 76.0%，每千次查询 $0.11，鲁棒性 73.1。这证明「按意图把简单问题分流给小模型」能在几乎不掉准确率的前提下显著降成本。

LiteLLM 静态路由 vs vLLM-SR 意图路由的关系——不是替代，是两层：

设计要点/决策表

对本项目的落地

• gateway 路由配置（接 Day 43 infra/litellm/config.yaml，规划）：router_settings 里给 lead 模型组配「质量优先」、给 sub-agent 模型组配 cost-based；fallbacks 配三级链（如 claude-sonnet-4-6 → claude-haiku-4-5(同provider) → gpt-5(跨provider)）；cooldown_time: 5、num_retries: 3 指数退避。
• 熔断/fallback 对接 orchestrator/budget.ts 与 orchestratorAgent.ts：现 Budget 已有 assertCanStep/assertCostOk/assertNotTimedOut 应用层闸；新增把 gateway 返回的 402/cooldown 事件回传到 useTraceStore.ts，让 trace 树显示「哪一跳熔断、走了哪级 fallback」，补齐 Day 26 失败归因面板的「LLM 跳熔断」维度。
• 意图路由作为 lead 的前置（规划，P2 进阶）：在 orchestrator 分发前加一个轻量意图判定（借鉴 vLLM-SR 的 complexity 信号思路）——简单事实类子查询直接给小模型，多步推理类才上强模型；agentic 工具循环内锁定模型（SAAR 思路），不在循环中途切换。本项目体量可先用「关键词+长度」启发式近似，不必引入完整 vLLM-SR 部署。
• 双预算闸：Budget.assertCostOk() 仍是应用层先触发（给用户友好报错），gateway 402 是账本层兜底；两者用 Day 43 回填的 x-litellm-response-cost 对账，确保应用层估算不偏离真实成本。
• 诚实标注：路由/fallback/熔断/意图路由均为 P2 规划配置，当前 agent-v2 直连无 gateway；落地当周须确认 LiteLLM router_settings/cooldown schema 当周版本，以及是否实际部署 vLLM-SR（v0.3 Themis 2026-06-05）还是仅用启发式近似。

参考资料

1. digitalapplied — LLM Gateway Architecture: 2026 Engineering Reference（一手工程参考）：LiteLLM 六路由策略（simple-shuffle/latency/usage-v2/least-busy/cost/custom）、OpenRouter 反平方成本加权与分位降权、三类 fallback（general/content-policy/context-window）、retry 先于 fallback（≤5 指数退避）、熔断 50% 失败率触发/5s 冷却/provider+model 粒度/half-open 探测、预算 HTTP 402 钱包检查 (2026)
2. vLLM Blog — vLLM Semantic Router v0.3 Themis: From Signals to Stateful Production Routing（一手原文）：signal→projection→decision→algorithm→model 流水线、complexity/embedding 信号、命名策略概念(support_fast/escalated)、SAAR 会话感知 agentic 路由防工具循环换模型、RouterArena #1（75.4 分/76.0% 准确/$0.11 每千查询/73.1 鲁棒）、350+ commits (2026-06-05)
3. Red Hat — Bringing intelligent, efficient routing to open source AI with vLLM Semantic Router：ModernBERT 等轻分类器判意图/复杂度、简单事实 vs 多步推理分流 (2026)
4. getmaxim / truefoundry — LLM Failover Routing Gateways 2026：5 次失败触发/60s 冷却社区口径、跨 provider failover 防级联 (2026)
5. 本仓库 src/agent/config/providers.ts（lead/sub 模型分层）、src/agent/orchestrator/budget.ts、src/agent/orchestrator/orchestratorAgent.ts、src/agent/trace/useTraceStore.ts (2026-06)

SOTA 检查 (2026-06-11)

• 多模型路由+三类 fallback+熔断是 2026 gateway 韧性的标准三件套：LiteLLM 六策略、OpenRouter 成本加权、5s/50% 熔断口径在 digitalapplied/getmaxim/truefoundry 多份 2026 文一致；本日 WebSearch 未见替代范式。
• 意图感知路由是 2026 上半年最活跃的前沿：vLLM Semantic Router v0.3 Themis（2026-06-05）刚发布，RouterArena 登顶，把「按语义意图分流推理/非推理模型」从研究推向生产；SAAR（会话感知 agentic 路由）是针对 agent 工作负载的关键新增——这是「路由」从运营信号向语义信号演进的拐点，须持续跟踪。
• 过时认知警示：「单一 fallback 策略走天下」过时——general/content-policy/context-window 三类需分别配置；「按 provider 熔断」过时——须 provider+model 组合粒度；「每次调用独立挑最优模型」在 agentic 负载下过时——工具循环须锁模型（SAAR）。
• 与本项目体量的诚实匹配：完整 vLLM-SR 部署对单租户教学 demo 偏重，本项目计划先用启发式近似意图判定，把 vLLM-SR 列为进阶选项；落地以 LiteLLM 静态路由+三级 fallback+双预算闸为主线。
• 待跟踪：vLLM-SR v0.3 之后版本（signal 族扩展）、RouterArena 榜单变化、LiteLLM 是否原生集成意图路由；执行当周按顶层时效硬规则重新核验 vLLM-SR 与 LiteLLM 版本号。