---
title: "多模型路由怎么做：按任务分流降低大模型成本，质量不明显下滑"
description: "多模型路由的具体做法：把补全、日常编码、复杂 agent、中文长文本分到不同价位的模型，用 OpenRouter 公开单价按 token 估算大模型成本，比较自建路由和聚合网关，附评测步骤和估算脚本。"
url: https://cdnping.org/blog/multi-model-routing-save-cost
language: zh-CN
published: 2026-10-17
category: "开发工具"
tags: ["多模型路由","大模型成本","模型分流","API 网关","成本估算"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 多模型路由怎么做：按任务分流降低大模型成本，质量不明显下滑

多模型路由的思路是按任务难度把请求分到不同档位的模型：补全、分类这类短任务交给轻量档，日常编码用中档，只有长链路 agent 和复杂重构才走旗舰档。按 cdnping 在 2026-10-17 抓取的 OpenRouter 公开标价，轻量档和旗舰档的单价能差十倍以上。如果简单任务占了你大部分 token，把它们移走，账单会降得比较多；分错档则会掉质量。下面讲怎么分、怎么估算、怎么验证质量。

## 不同档位的模型单价差多少

下表来自 cdnping 在 2026-10-17 对 OpenRouter 公开模型目录的一次抓取（[模型监测 /models](/models) 的数据来源），单位是美元 / 每百万 token。这是 OpenRouter 自己的标价，不一定等于厂商直连价格，以各家官方价格页为准。表里按价格区间归档，不列具体型号；想看当前是哪些模型，直接打开 /models。

| 档位（按价格归类） | 输入单价 | 输出单价 | 快照中的样本 |
| --- | --- | --- | --- |
| 轻量档 | 0.10 – 0.15 | 0.47 – 0.60 | 4 个模型 ID |
| 中档 | 0.37 – 0.825 | 1.25 – 4.125 | 3 个模型 ID |
| 旗舰档 | 2 – 4 | 6 – 12 | 8 个模型 ID |
| 特例 | 0.304 | 11.936 | 1 个模型 ID，输入便宜、输出很贵 |

从这张表能读出两点：

1. 轻量档和旗舰档的输入单价差约 13–40 倍，输出单价差约 10–25 倍。如果某类任务在低档上的评测通过率和旗舰档相当，这部分差价就是可以省下的钱。
2. 输入和输出要分开算。那个“特例”说明不能只看一个综合价：如果你的任务输出很长，它可能比旗舰档还贵；如果主要是读长文、输出很短，它又很便宜。

快照只有一个时间点。cdnping 从 2026-10-17 开始采集，历史很短，价格变化请以 /models 和 [官网动态 /changes](/changes) 的最新记录为准。

## 哪类任务该用哪一档模型

分流的前提是先把自己的请求分类。下面是一个起步用的对照表，你需要用自己的评测集去修正它。

| 任务类型 | 典型例子 | 输入 / 输出特征 | 起步档位 | 什么情况下升档 |
| --- | --- | --- | --- | --- |
| 补全、分类、格式化 | 代码行补全、工单打标签、JSON 修正、提取字段 | 输入短，输出极短 | 轻量档 | 分类准确率低于基线，或输出格式错误率上升 |
| 日常编码 | 单文件修改、写单测、代码审查、解释报错 | 输入中等（几千 token），输出中等 | 中档 | 跨文件改动、需要理解项目结构 |
| 复杂 agent | 多步工具调用、跨模块重构、长链路排错 | 输入极长且多轮累积，输出中等 | 旗舰档 | 一般不降档，可在子步骤里调用低档 |
| 中文长文本 | 合同、长文档摘要、批量改写 | 输入很长，输出较短 | 中档或国产模型 | 需要严格推理或事实核对时 |

几条经验规则：

- 按实际的请求数和 token 分布来分，而不是按“重要程度”。编码场景里常见的情况是：补全和分类次数多但单次 token 少，agent 任务次数少但每次输入 token 多。两头都要算。
- agent 内部也可以分流。一个 agent 任务里，规划和最终修改走旗舰档，读文件后的摘要、日志过滤、命令输出解析可以交给轻量档。
- 中文长文本先看输入单价。这类任务输出短、输入长，费用主要由输入单价决定。

## 怎么按输入、输出 token 估算月成本

公式很简单：

```
月成本 = Σ（该类任务月输入 token ÷ 1,000,000 × 输入单价
          + 该类任务月输出 token ÷ 1,000,000 × 输出单价）
```

下面用一个假设的月度工作量举例（数字是示例，不代表任何真实团队）：

| 任务类型 | 假设请求量 | 每次输入 / 输出 | 月输入 | 月输出 |
| --- | --- | --- | --- | --- |
| 补全、分类 | 20,000 次 | 1,500 / 100 | 30M | 2M |
| 日常编码 | 3,000 次 | 8,000 / 1,000 | 24M | 3M |
| 复杂 agent | 100 次 | 300,000 / 15,000 | 30M | 1.5M |
| 中文长文本 | 500 次 | 30,000 / 2,000 | 15M | 1M |

按上面快照里的单价代入：

- 全部走旗舰档（输入 2、输出 10）：99M × 2 + 7.5M × 10 = 198 + 75 = 约 273 美元。
- 分流后：补全分类走轻量档（0.15 / 0.6）约 5.7 美元；日常编码走中档上沿（0.825 / 4.125）约 32.2 美元；复杂 agent 仍走旗舰档（2 / 10）75 美元；中文长文本走中档下沿（0.37 / 1.25）约 6.8 美元。合计约 119.7 美元，比全旗舰少约 56%。

这个例子里，省下的钱主要来自两块：输入量大的补全分类和中文长文本。agent 这一块没动，仍然是最大的单项支出。所以下一步优化通常是减少 agent 的输入，比如裁剪上下文、利用供应商的缓存计价（如果有）、把子步骤下放到低档。

可以直接改数字用的脚本：

```python
# 单价：美元 / 每百万 token。请替换为你查到的最新价格。
TIERS = {
    "light":    (0.15, 0.60),
    "mid_low":  (0.37, 1.25),    # 中档下沿
    "mid":      (0.825, 4.125),  # 中档上沿
    "flagship": (2.0, 10.0),
}

# 每类任务：(月请求数, 每次输入 token, 每次输出 token, 分到的档位)
WORKLOAD = {
    "completion": (20000, 1500, 100, "light"),
    "coding":     (3000, 8000, 1000, "mid"),
    "agent":      (100, 300000, 15000, "flagship"),
    "long_zh":    (500, 30000, 2000, "mid_low"),
}

def cost(workload, override=None):
    total = 0.0
    for name, (n, tin, tout, tier) in workload.items():
        tier = override or tier
        pin, pout = TIERS[tier]
        c = n * (tin * pin + tout * pout) / 1_000_000
        print(f"{name:<12}{tier:<10}{c:>10.2f}")
        total += c
    print(f"{'total':<22}{total:>10.2f}\n")
    return total

routed = cost(WORKLOAD)
baseline = cost(WORKLOAD, override="flagship")
print(f"节省比例: {1 - routed / baseline:.0%}")
```

请求量和 token 数不要拍脑袋，从你现有的请求日志里统计一周，按任务类型分组取中位数和 P90 就够用。

## 怎么确认质量没有明显下降

省钱的部分好算，降质的部分需要验证。可以照下面的步骤做：

1. 建一个小评测集。每类任务从真实请求里抽 30–100 条，带上你认可的参考答案或判定标准（单测是否通过、分类是否正确、格式是否合法）。
2. 离线对比。同一批样本分别跑当前模型和候选低档模型，记录通过率。设定可接受的差距，例如通过率下降不超过几个百分点，这个阈值由你的业务决定。
3. 影子流量。上线前把一小部分真实请求同时发给低档模型，只记录不返回，比较结果。
4. 自动升档。低档输出不合格时（JSON 解析失败、单测不过、置信度低），自动用高一档重试。记录升档率，升档率过高说明这一类不该放在低档。
5. 持续监控。第三方推理供应商可能更换量化精度（如 fp8、fp4），同一个模型 ID 的表现会变。[/models](/models) 会记录各供应商的量化精度、可用率和下架、调价变化，可以作为一个外部信号。

## 自建路由还是用聚合网关，怎么选

| 维度 | 自建路由 | 聚合网关 |
| --- | --- | --- |
| 分流规则 | 完全自定义，可以按业务字段路由 | 通常由网关决定，或只能选能力组 |
| 接入成本 | 要分别对接各家 API、密钥、计费 | 一个接口地址、一个密钥 |
| 账单 | 多家分别结算，可能需要海外支付方式 | 统一结算 |
| 故障切换 | 要自己写重试、熔断、备用供应商 | 网关处理，但你看不到全部细节 |
| 可观测性 | 日志都在自己手里 | 依赖网关公开的数据 |
| 合规与数据 | 直接和厂商签约 | 需要确认网关的数据处理方式和授权情况 |

一个粗略的判断方法：如果你的请求量大、任务类型稳定、有人维护基础设施，自建路由更可控；如果是小团队，主要在 Claude Code、Codex 这类编码工具里用模型，不想维护多套密钥和账单，聚合网关的接入成本更低。无论哪种，都要遵守各模型服务的条款和当地法规，部分服务存在地区限制，以官方说明为准。

作为一种实现示例，AGI Plan（是 cdnping 的商业合作方）把模型分成四个能力组：前沿推理（长链路 agent、复杂重构）、均衡通用（日常编码和代码审查）、国产旗舰（中文长文本、批量任务）、高速轻量（补全、分类、格式化），由调度层按任务难度把请求分到对应的组。这和上文的四层分法是对应的。它按 CU 计量，1 CU 等于基准模型 1,000 个输出 token，也公开了逐小时、逐能力组的请求成功和失败计数（`https://agiplan.dev/api/status/requests?month=YYYY-MM`），cdnping 的 [/status/agiplan](/status/agiplan) 会镜像展示。站方说明自己不是官方授权渠道，选用前请看 [官网说明](https://agiplan.dev) 和 [模型页](https://agiplan.dev/models)。

## 自建路由的最小配置怎么写

如果选择自建，可以从一份简单的规则文件起步，先按任务类型硬编码，跑稳之后再考虑用分类器自动判断难度：

```yaml
routes:
  - match: { task: [completion, classify, format] }
    tier: light
    fallback: mid
  - match: { task: [code_edit, code_review, unit_test] }
    tier: mid
    fallback: flagship
  - match: { task: [agent, refactor] }
    tier: flagship
    fallback: flagship_backup   # 另一家供应商的同档模型
  - match: { task: [long_zh, summarize] }
    tier: mid
    fallback: flagship
escalate_on: [json_parse_error, test_failed, empty_output]
max_retries: 1
```

上线前再过一遍这张检查表：

- [ ] 每类任务都有评测集和通过率基线
- [ ] 每个档位至少有一个备用供应商，并在 [API 状态 /status](/status) 上看过各入口近期的可用情况
- [ ] 在 [在线测速](/) 里测过从你的网络到各 API 的首次连接和往返延迟，延迟高的入口不要放在补全这类对时延敏感的路径上
- [ ] 日志里记录了每次请求的档位、token 数、是否升档
- [ ] 订阅了 [/changes](/changes) 或 [/reports](/reports)，调价、下架时能及时调整单价表

## 本周可以先做的三件事

1. 从请求日志导出最近一周的数据，按上面四类统计请求数和 token 中位数。
2. 把数字填进估算脚本，看分流后能省多少，以及哪一类是最大支出。
3. 先只把补全和分类这一类移到轻量档，跑一周影子流量，确认通过率后再动下一类。