LiteLLM 路由/级联 (M6)

阶段: B10 · p95/cost 测量 + 成本级联 + tau2-bench（Day 91-100） 标签: #model-cascade #routing #cost-optimization #litellm

今日导引（由浅入深）

B10 前三天把延迟（Day 91）、并发（Day 92）、成本（Day 93）量化清楚。 现在我们有了「全程用 V4-Flash 的成本基线」和「纯 V4-Pro 的质量基线」。 今天进入「主动优化成本」：model-cascade（成本级联）模式。 在 B1→B18 曲线上，这是从「测量」迈向「编排决策」的一步——一个 AI Solutions Architect 必须能论证「便宜模型先答、贵模型兜底」的 build-vs-buy/质量-成本取舍。 今天搭好级联机制，量化升级触发率（多少请求落到贵模型）；明天 Day 95 再看它换来的 $-vs-pass 权衡曲线。 今天的「最小可判定产出」：跑出落到 V4-Pro 的请求百分比（真实值待 key）。

1. 机理精读

model-cascade（cheap-first）模式。 先用便宜模型（V4-Flash）回答，仅当低置信度时才升级到贵模型（V4-Pro）。 直觉是——多数查询简单，便宜模型就答对了；只有少数难题需要贵模型。 于是「平均成本」被压到接近便宜模型，而「质量」靠少数升级兜底，逼近贵模型。 这是用成本换可接受质量的经典编排，对应 FrugalGPT 一类「LLM cascade」思想。

机制的命门是「置信度判定」和「路由键设计」。 置信度判定决定哪些便宜模型的答案被放行、哪些触发升级。 判定信号可以是：模型自报置信、输出格式校验、规则启发式、或一个轻量判别器。 路由键（按任务类型 / 置信度 / 预算）决定升级触发率。 判得太松，难题被便宜模型放行 → 省钱但质量掉；判得太严，简单题也升级 → 质量稳但省不动。 所以级联不是「免费午餐」，而是一条可调的 trade-off 曲线（这正是 Day 95 的主题）。

LiteLLM router 的角色。 LiteLLM 提供统一的多模型路由层（2026 仍活跃主流），可按规则/成本/负载在多个 provider/model 间路由。 但本项目自建了 src/agent/runtime/cascade.ts，不依赖 LiteLLM 运行时。 这符合计划的「自建优先」原则：自己实现过同等物，才能讲清托管路由层每个组件存在的理由。 LiteLLM 在这里是对标研究对象，不是运行时依赖——build-vs-buy 论证要靠这种「我自己造过」的底气。

关键边界。 今天只搭机制 + 量化「升级触发率」这一个数。 不评估省了多少钱、pass 率掉没掉（那是 Day 95，要对照纯贵模型基线）。 机制（纯函数）可立即测，真实触发率需 key 跑真实任务才有。

2. 推导 / 手算 / 代码走读

项目自建的 src/agent/runtime/cascade.ts 真实走读：

• cascade<T>(opts)（cascade.ts:17）：参数是 { cheap, expensive, isConfident } 三个注入项。
• cheap/expensive 是返回 TierOutput<T>{ value, costUsd? } 的异步函数，isConfident(value) 是置信度判定。
• 模型被注入而非硬编码 → 纯函数、无 key 可测（seed 说「纯函数」属实）。
• 核心逻辑（cascade.ts:23-27）：先 await opts.cheap()；若 opts.isConfident(c.value) 为真，直接返回 { tier:'cheap', escalated:false, costUsd: c.costUsd ?? 0 }。
• 否则 await opts.expensive()，返回 { tier:'expensive', escalated:true, costUsd: (c.costUsd ?? 0) + (e.costUsd ?? 0) }。
• 注意升级路径的成本是 cheap + expensive 之和——升级请求要付两次钱（便宜模型白跑一次），这点在算省钱比例时不能忽略。
• cascadeStats(results, expensiveUnitCost)（cascade.ts:39）：聚合一批级联结果对照「全程贵模型」基线。
  • escalationRate = escalated / n：升级触发率，今天要产出的数。
  • cascadeCost = Σ r.costUsd：级联实际总花费（含白跑的便宜模型成本）。
  • allExpensiveCost = n × expensiveUnitCost：假设全用贵模型的成本（基线分母）。
  • savedFraction = max(0, 1 - cascadeCost / allExpensiveCost)：省钱比例，用 max(0, …) 防止极端情况下出现负省（升级太多反而更贵时夹到 0）。
• seed 说「cascade.ts + cascadeStats 已建并测试（纯函数）」——逐字属实，符合 cascade.ts:17/39 的纯函数实现。

手算示例（说明「升级要付两次钱」）：

• 设 V4-Flash 单次 $0.0003、V4-Pro 单次 $0.0009，跑 100 题、升级率 20%。
• cascadeCost = 80 题×$0.0003（命中便宜）+ 20 题×($0.0003+$0.0009)（升级，便宜白跑）。
• = 0.024 + 0.024 = $0.048。
• allExpensiveCost = 100×$0.0009 = $0.09。
• savedFraction = 1 - 0.048/0.09 ≈ 47%。
• 若不计便宜模型白跑成本会误算成省更多——cascade.ts 把白跑成本算进去了，是诚实口径。
• （数字为演示量级，真实升级率与省钱待 key。）

升级率与省钱的盈亏平衡分析（什么时候级联反而更贵）：

• 设 cheap 单价 c、expensive 单价 e（e>c）、升级率 r。
• 级联单均成本 = c + r×e（每请求都付 c，升级的额外付 e）。
• 全贵基线 = e。级联省钱当且仅当 c + r×e < e，即 r < (e-c)/e = 1 - c/e。
• 用上例 c=0.0003、e=0.0009：盈亏点 r < 1 - 1/3 ≈ 0.667。
• 含义：只要升级率低于 ~67%，级联就比全贵省钱；升级率逼近 100% 时级联反而最贵（每请求都白跑一次 cheap）。
• 这给「置信度阈值」一个硬约束：阈值不能松到让升级率超过盈亏点，否则级联失去意义。

isConfident 判定信号的工程选项（从易到难）：

• 格式/规则校验：输出是否合法 JSON、是否命中必填字段——最便宜、零额外调用。
• 自报置信：让 cheap 模型输出 confidence 分，低于阈值升级——简单但模型自评易过自信。
• 启发式：答案长度异常、出现 hedging 词、与参考答案规则不符。
• 轻量判别器：单独训一个小分类器判 cheap 答案对错——最准但要额外建模与标注。

3. 今日实战

1. 新建 bench/cascade.ts（驱动脚本，bench/ 目录仍属待建脚手架），复用项目已有的 src/agent/runtime/cascade.ts 的 cascade + cascadeStats（cascade.ts:39）。
2. 配置：cheap = deepseek-v4-flash 调用、expensive = deepseek-v4-pro 调用、isConfident = 置信度判定（不硬编码 legacy 模型 id 作 fallback 目标）。
3. 跑 src/agent/eval/tasks.ts（约 30 任务的 EVAL_TASKS）的子集。
4. 把每个任务的 { escalated, costUsd } 收集成数组，喂 cascadeStats(results, expensiveUnitCost)，读 escalationRate。
5. 产出落到 V4-Pro 的请求百分比（= escalationRate），为 Day 95 的省钱/质量对比做准备。

4. 今日实测 / 产出

• cascade.ts + cascadeStats 已建并测试（纯函数）——确定性部分可立即用单测断言验证。
• 升级触发率（% 落到贵模型）= 待跑(需 key 跑)。
• 跑后产出 落到 V4-Pro 的请求百分比。
• 状态如实：触发率待 key，不预填任何百分比；机制已建不升级为「省钱结论已出」。

5. 常见误区 / 陷阱

• 忽略升级请求的双重成本：升级路径要付 cheap+expensive 两次钱，算省钱比例时若只算贵模型那次会高估省钱——cascade.ts 已把便宜模型白跑成本算进 costUsd。
• 把 LiteLLM 当运行时依赖：本项目自建 cascade.ts，LiteLLM 只是对标研究对象，不要误以为代码依赖它。
• 硬编码 legacy 模型 id 作 fallback：fallback 目标用现行 deepseek-v4-pro，禁用 deepseek-chat/-reasoner（2026-07-24 退役）。
• 置信度判定设计草率：判定逻辑直接决定升级率与质量，必须可调、可解释，不能拍脑袋；这条曲线的形状全靠它。

6. 学习资源（每条带 YYYY-MM）

• LiteLLM router 文档（2026 重验）——多模型路由层主流方案，对标研究对象。
• 项目源码 src/agent/runtime/cascade.ts（本仓，cascade at line 17、cascadeStats at line 39，纯函数注入模型）。
• 项目源码 src/agent/eval/tasks.ts（本仓，EVAL_TASKS 约 30 任务，级联跑子集）。
• 「FrugalGPT: How to Use LLMs While Reducing Cost…」arXiv:2305.05176（2023-05）——LLM cascade/cheap-first 成本优化的奠基论文，机理打底。

SOTA检查 (2026-06 更新)

• 当前主流：LiteLLM router 仍是主流路由层（2026 活跃）；small-first / model-cascade 编排是 2026 成本优化主线，仍 SOTA。
• 过时黑名单：避免硬编码 legacy 模型 id（deepseek-chat/-reasoner，2026-07-24 退役）作为 fallback 目标；不要把自建 cascade.ts 误当成依赖 LiteLLM 运行时。
• 下次复查点：LiteLLM router 活跃度与 API 执行当周重验；DeepSeek 模型 id 在 2026-07-24 legacy 退役节点复查 fallback 目标。

衔接

• 昨天：Day 93 — $/query 成本测量（token usage × 单价，报 mean+p95，REAL 基线 $0.0139/run）
• 今天：搭 model-cascade 机制（自建 cascade.ts），cheap-first + 置信度升级，量化升级触发率
• 明天：Day 95 — 级联省钱 vs 质量权衡（M6）：对照纯 V4-Pro 基线（pass 89.7%）画 $-vs-pass 曲线，产出「省 $X% + pass delta」