最便宜的模型并非 Token 单价最低的模型，而是在重试、升级、验证、延迟与人工审查全部计入后，能以最低总成本产出可验收结果的模型。模型选型由此从排行榜决策变成路由问题。
路由的稳定单位是任务形状，而非模型名称。
证据核验日期：2026 年 8 月 19 日。OpenRouter 统计只描述该平台流量，Hugging Face 下载量只描述 Hub 活动，两者均不代表全部模型市场。
阅读时间：约 8 分钟 · 全文约 2800 字
核心结论
- OpenRouter 的 100 万亿 Token 研究显示，真实工作负载正在变长，工具调用增加，输入与输出高度不对称。平均 prompt 从约 1500 Token 增至 6000 以上，平均 completion 从约 150 增至 400。
- 低成本 worker 适合边界清晰的抽取、摘要、格式转换、分类和草稿任务，前提是输出能够低成本验收。
- 路由需要同时考虑六个维度：任务边界、答案合同、失败代价、时限、可验证性和局部运行轨迹。
- 优化目标是每个完成任务的期望成本，而非每百万 Token 价格。
- 每次路由、结果、重试、升级、最终验收和人工时间都要记录。模型、价格、prompt 或流量变化后重新校准边界。
任务形状为什么变得重要
OpenRouter 分析了超过 100 万亿 Token 的真实交互。报告描述的工作负载变化，使单一全局模型越来越低效。
平均 prompt 长度约增长四倍，从 1500 左右增至 6000 以上；平均 completion 接近增长三倍，从约 150 增至 400。编程请求经常超过 2 万输入 Token，其他类别则相对平稳。工具调用比例也在提高，平台上的 Agent 式工作逐渐增加。
真正有用的信号是这种不对称。一项 2 万 Token 的代码调查、一项 12 字段 JSON 抽取和一项两句话分类可以进入同一个 API，却拥有完全不同的上下文需求、输出合同、失败代价和延迟预算。
全部使用前沿模型可以降低路由复杂度，同时付出不必要的成本。全部使用便宜模型可以降低单次价格，同时增加重试和逃逸错误。路由让每个任务为自己真正需要的能力付费。
把低成本模型定义为运营角色
小模型这个词缺乏稳定口径。OpenRouter 研究把 150 亿参数以下定义为 small，Hugging Face 报告重点统计 10 亿参数以下模型，一些常用 API 模型则没有公开参数量。
生产系统可以采用运营定义：
低成本 worker 是在冻结任务单元中，比当前主模型更便宜或更快，同时仍能满足该单元验收合同的模型层级。
这一定义能跨越供应商变化。模型可能参数少、采用稀疏架构、经过蒸馏，或只是价格更低。路由器只关心它能否在风险与时间预算内完成可验收工作。
OpenRouter 官方 subagent 模式使用同一逻辑：强 orchestrator 把聚焦摘要、抽取、格式转换和草稿任务交给便宜 worker。文档同时提醒，每次委派都会增加一次模型调用，带来额外成本与延迟。只有节省的生成成本超过编排与验证开销时，worker 才真正创造收益。
六维路由合同
一、任务边界
边界清晰的任务拥有明确输入、输出和停止条件。从文档抽取这些字段比调查服务为何不稳定更容易路由。
记录任务领域、工具权限、上下文规模，以及任务能否在不丢失关键状态的前提下拆分。
二、答案合同
输出形状是一项实用路由特征：
- 从有限集合选一个标签；
- 满足 schema 的 JSON；
- 有来源约束的短摘要；
- 边界明确的格式转换；
- 开放式建议；
- 带测试的多文件产物。
短答案不等于简单任务。法律或医疗问题的一字结论可能具有极高失败代价。答案形状必须与风险和证据联合判断。
三、失败代价
估算一个看起来合理但实际错误的输出穿过系统后会发生什么。低成本层适合可逆、可审查任务。安全决策、资金动作、破坏性工具调用和公开发布内容即使输出很短，也应进入更强模型或强制人工复核。
四、时限与并发
交互延迟、夜间批处理和队列吞吐拥有不同最优解。慢而便宜的模型可能适合六小时批处理窗口，却无法进入两秒交互界面。稍贵但更快的 worker 如果能明显缩短排队，也可能降低总成本。
五、可验证性
验收越确定，便宜模型越有价值：schema 校验、字段精确检查、单元测试、参考答案比对或确定性计算都能降低质量判断成本。若必须由高级专家判断输出是否可用，人工验证可能吃掉价格优势。
六、局部运行轨迹
部分任务只有开始执行后才暴露真实难度。低成本模型可以先检查仓库、运行测试或尝试抽取，再暴露上下文缺失、工具连续失败、低置信或验收失败等信号。
SWE-Router 在软件任务中形式化了这个思路：先让便宜模型执行一小段探索轨迹，再判断继续或升级。当探索能产生信息时，它可以优于只看初始 prompt 的路由。第一次尝试由此成为诊断探针，未必属于浪费。
计算每个完成任务的成本
使用期望成本公式：
完成任务期望成本
= worker 推理成本
+ 编排成本
+ 验证成本
+ P(重试) × 重试成本
+ P(升级) × 前沿模型成本
+ 期望人工审查时间
+ 期望逃逸失败成本
Token 单价位于前几项，生产经济性经常藏在后几项。
T2MO 同样把目标定义为每个完成任务的期望成本，并按任务类别与难度单元路由。其公开结果解释了为什么只按大类路由仍然太粗：同一模型在 Git workflow 的 easy 和 medium 单元达到 100% pass，在 Frontend 中则从 easy 的 100% 降至 medium 的 50% 和 difficult 的 25%。
因此，路由器应在冻结单元中比较：
任务类型 × 难度 × 上下文区间 × 输出合同 × 风险等级
模型先满足该单元的质量底线，才获得候选资格。合格模型之间再选择每个完成任务成本或延迟目标最低的一项。
从简单级联开始
第一个生产版本可以很小：
- 确定性策略把高风险或难验证任务直接送入主模型。
- 合格的有界任务进入低成本 worker。
- worker 同时返回答案、机器可读置信信号和证据字段。
- 验收检查立即运行。
- 验收失败、工具循环、上下文溢出或低置信触发升级，并携带完整轨迹。
- 最终验收结果和全部成本回写路由数据集。
不要让 worker 自己决定权限。路由器执行策略，worker 只提供证据。
数据积累后，可以用分类器或学习型 router 替换粗规则。风险硬约束继续留在学习组件之外。
最小评测矩阵
冻结代表性任务并记录：
| 维度 | 最小指标 |
|---|---|
| 质量 | 分任务单元验收通过率 |
| 成本 | 每个可验收结果的美元成本 |
| 延迟 | 到达可验收结果的 p50 与 p95 |
| 可靠性 | 重试、超时、schema 与工具失败率 |
| 升级 | 升级率、原因与挽回成功率 |
| 人工工作 | 审查与修正分钟数 |
| 漂移 | 模型、prompt、价格或工具变化后的差异 |
OpenRouter rankings 能观察采用信号，但官方明确说明其排名依据是 prompt 与 completion Token 总量，而非准确率。Hugging Face 下载量能观察生态热度，却混合了 embedding、CI、容器和依赖重复下载。任何一个指标都不足以直接决定生产路由。
这与AI Agent 评测单元采用相同纪律：模型、harness、任务、预算与 grader 共同构成被测系统。单 Token 行为指纹随后可以监测一条原本稳定的路由是否发生静默漂移。
常见路由错误
只按 prompt 长度路由。 长上下文可能只做简单抽取，短 prompt 也可能要求困难推理。
只相信模型自报置信度。 置信度需要用可验收结果和失败类型校准。
升级时丢掉已有轨迹。 把同一请求原样交给强模型，会浪费 worker 已完成的诊断。工具结果、错误、证据和尝试过的修复应一起传递。
只优化 Token 支出。 推理成本下降但人工审查翻倍，整条路径会更贵。
使用永久阈值。 模型行为、价格、流量、prompt 和工具都会变化。路由是一项持续校准策略。
常见问题
LLM 模型路由是什么？
它根据任务特征、风险、成本、延迟和执行中暴露的信号，为每个请求选择模型层级，而非把全部流量送给同一模型。
什么时候适合低成本模型？
任务边界清晰、可以低成本验收、可逆、逃逸失败代价低，并且计入重试和升级后的每任务总成本更低时。
输出长度能否预测模型层级？
它只能作为一个特征。还需结合上下文、推理需求、工具调用、风险、时限和验收证据。
路由应该使用规则、分类器还是另一个 LLM？
先用显式规则与风险硬门。积累带结果标签的任务数据后，再增加分类器或学习型 router。安全与权限约束保持确定性。
什么时候应该升级？
验收失败、工具连续错误、上下文缺失、策略风险、时间预算耗尽、校准后低置信，或轨迹特征与历史失败相似时。