多模型路由怎么做：按任务分流降低大模型成本，质量不明显下滑
多模型路由的思路是按任务难度把请求分到不同档位的模型：补全、分类这类短任务交给轻量档，日常编码用中档，只有长链路 agent 和复杂重构才走旗舰档。按 cdnping 在 2026-10-17 抓取的 OpenRouter 公开标价，轻量档和旗舰档的单价能差十倍以上。如果简单任务占了你大部分 token，把它们移走，账单会降得比较多；分错档则会掉质量。下面讲怎么分、怎么估算、怎么验证质量。
不同档位的模型单价差多少
下表来自 cdnping 在 2026-10-17 对 OpenRouter 公开模型目录的一次抓取（模型监测 /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，输入便宜、输出很贵 |
从这张表能读出两点：
- 轻量档和旗舰档的输入单价差约 13–40 倍，输出单价差约 10–25 倍。如果某类任务在低档上的评测通过率和旗舰档相当，这部分差价就是可以省下的钱。
- 输入和输出要分开算。那个“特例”说明不能只看一个综合价：如果你的任务输出很长，它可能比旗舰档还贵；如果主要是读长文、输出很短，它又很便宜。
快照只有一个时间点。cdnping 从 2026-10-17 开始采集，历史很短，价格变化请以 /models 和 官网动态 /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 的输入，比如裁剪上下文、利用供应商的缓存计价（如果有）、把子步骤下放到低档。
可以直接改数字用的脚本：
# 单价：美元 / 每百万 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 就够用。
怎么确认质量没有明显下降
省钱的部分好算，降质的部分需要验证。可以照下面的步骤做：
- 建一个小评测集。每类任务从真实请求里抽 30–100 条，带上你认可的参考答案或判定标准（单测是否通过、分类是否正确、格式是否合法）。
- 离线对比。同一批样本分别跑当前模型和候选低档模型，记录通过率。设定可接受的差距，例如通过率下降不超过几个百分点，这个阈值由你的业务决定。
- 影子流量。上线前把一小部分真实请求同时发给低档模型，只记录不返回，比较结果。
- 自动升档。低档输出不合格时（JSON 解析失败、单测不过、置信度低），自动用高一档重试。记录升档率，升档率过高说明这一类不该放在低档。
- 持续监控。第三方推理供应商可能更换量化精度（如 fp8、fp4），同一个模型 ID 的表现会变。/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 会镜像展示。站方说明自己不是官方授权渠道，选用前请看 官网说明 和 模型页。
自建路由的最小配置怎么写
如果选择自建，可以从一份简单的规则文件起步，先按任务类型硬编码，跑稳之后再考虑用分类器自动判断难度：
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 上看过各入口近期的可用情况
- 在 在线测速 里测过从你的网络到各 API 的首次连接和往返延迟，延迟高的入口不要放在补全这类对时延敏感的路径上
- 日志里记录了每次请求的档位、token 数、是否升档
- 订阅了 /changes 或 /reports，调价、下架时能及时调整单价表
本周可以先做的三件事
- 从请求日志导出最近一周的数据，按上面四类统计请求数和 token 中位数。
- 把数字填进估算脚本，看分流后能省多少，以及哪一类是最大支出。
- 先只把补全和分类这一类移到轻量档，跑一周影子流量，确认通过率后再动下一类。