llm-router

LLM 路由器

为每项任务选择最合适的大模型。在多 Agent 系统中，这是影响成本的最大因素——智能路由可节省 45-85% 的成本，同时保持 95%+ 的顶级模型质量。

---

何时使用

✅ 适用于：

• 决定针对特定任务调用哪个模型
• 为 Agent 工作流中的 DAG 节点分配模型
• 优化整个系统的 LLM API 成本
• 构建优先尝试低成本模型的级联模式

❌ 不适用于：

• 提示词工程（使用 prompt-engineer）
• 模型微调或训练
• 比较模型架构（学术研究）

---

路由决策树

flowchart TD
  A{Task type?} -->|Classify / validate / format / extract| T1["Tier 1: Haiku, GPT-4o-mini (~$0.001)"]
  A -->|Write / implement / review / synthesize| T2["Tier 2: Sonnet, GPT-4o (~$0.01)"]
  A -->|Reason / architect / judge / decompose| T3["Tier 3: Opus, o1 (~$0.10)"]
  
  T1 --> Q1{Quality sufficient?}
  Q1 -->|Yes| Done1[Use cheap model]
  Q1 -->|No| T2
  
  T2 --> Q2{Quality sufficient?}
  Q2 -->|Yes| Done2[Use balanced model]
  Q2 -->|No| T3

---

层级分配表

任务类型	层级	模型	每次调用成本	选择此层级的原因
输入类型分类	1	Haiku, GPT-4o-mini	~$0.001	确定性分类
验证架构／格式	1	Haiku, GPT-4o-mini	~$0.001	机械式检查
格式化输出／模板	1	Haiku, GPT-4o-mini	~$0.001	结构化转换
提取结构化数据	1	Haiku, GPT-4o-mini	~$0.001	模式匹配
总结文本	1-2	Haiku → Sonnet	~$0.001-0.01	简短摘要：Haiku；需要细致理解：Sonnet
撰写内容／文档	2	Sonnet, GPT-4o	~$0.01	创作质量很重要
实现代码	2	Sonnet, GPT-4o	~$0.01	正确性 + 风格
审查代码／差异	2	Sonnet, GPT-4o	~$0.01	需要判断力，而非单纯的模式匹配
综合研究结果	2	Sonnet, GPT-4o	~$0.01	多来源推理
拆解模糊问题	3	Opus, o1	~$0.10	需要深入理解
设计架构	3	Opus, o1	~$0.10	复杂的系统推理
评判输出质量	3	Opus, o1	~$0.10	对质量进行元推理
规划多步骤策略	3	Opus, o1	~$0.10	长期规划

---

三种路由策略

策略 1：静态层级分配（从这里开始）

在设计 DAG 时按任务类型分配模型。不需要运行时逻辑。可节省潜在成本的 60-70%。

nodes:
  - id: classify
    model: claude-haiku-4-5     # Tier 1: $0.001
  - id: implement
    model: claude-sonnet-4-5    # Tier 2: $0.01  
  - id: evaluate
    model: claude-opus-4-5      # Tier 3: $0.10

策略 2：级联（先尝试低成本模型）

先尝试低成本模型；如果质量低于阈值，则升级模型。延迟增加约 1s，但对于低成本模型能成功的节点，可节省 50-80% 的成本。

1. Execute with Tier 1 model
2. Quick quality check (also Tier 1 — costs ~$0.001)
3. If quality ≥ threshold → done
4. If quality < threshold → re-execute with Tier 2

最适合确实无法确定所需层级的节点。

策略 3：自适应（从历史记录中学习）

记录每种任务类型在每个模型上的成功／失败情况。随着时间推移，路由器会学会：

• “分类节点用 Haiku 总能成功” → 继续使用低成本模型
• “代码审查节点用 Haiku 有 40% 的失败率” → 升级到 Sonnet
• “架构节点用 Sonnet 有 90% 的成功率” → 无需使用 Opus

在约 100 次训练数据执行后，可节省 75-85% 的成本。

---

提供商选择

选择模型层级后，再选择提供商：

模型类别	提供商选项	选择标准
Haiku 类	Anthropic, AWS Bedrock	延迟、区域可用性
Sonnet 类	Anthropic, AWS Bedrock, GCP Vertex	成本、速率限制
Opus 类	Anthropic	唯一提供商
GPT-4o 类	OpenAI, Azure OpenAI	速率限制、合规性
开源	Ollama（本地）、Together.ai、Fireworks	成本（$0）、延迟、GPU 可用性

---

成本影响示例

10 节点 DAG，“重构代码库”：

策略	组合	成本	节省
全部使用 Opus	10× $0.10	$1.00	—
全部使用 Sonnet	10× $0.01	$0.10	90%
静态层级	4× Haiku + 4× Sonnet + 2× Opus	$0.24	76%
级联	6× Haiku + 3× Sonnet + 1× Opus	$0.14	86%
自适应（已训练）	动态	~$0.08	92%

---

反模式

始终使用最佳模型

错误做法：为了“保证质量”，将所有任务都路由到 Opus/o1。 实际情况：典型 DAG 节点中有 60%+ 属于分类、验证或格式化任务——Haiku 在这些任务上的表现与 Opus 完全相同。这样只会白白浪费资金。

始终使用最便宜的模型

错误做法：为了“节省成本”，把所有任务都交给 Haiku。 实际情况：复杂推理、架构设计和质量判断确实需要更强大的模型。面对困难任务时，Haiku 可能会生成看似合理、实则存在细微错误的输出。

忽视延迟

错误做法：只优化成本，忽略 Opus 的耗时是 Haiku 的 5-10 倍。 实际情况：在包含 10 个节点的 DAG 中，模型选择对总执行时间的影响不亚于对成本的影响。将时间紧迫的路径分配给速度更快的模型。

缺少反馈闭环

错误做法：设置一次模型层级后就再也不调整。 实际情况：随着模型不断改进（Haiku 每一代都会变得更聪明），上个月还需要 Sonnet 的任务，今天可能用 Haiku 就能完成。记录结果并不断调整。