OpenRouter Model Router
按任务复杂度调度模型的智能路由

过去一年,模型路由从少数团队的"优化技巧",变成了企业管理推理支出的关键基础设施。驱动力来自三个同时发生的趋势。

• Agent 推理支出爆炸。据 NotDiamond 观察,单个 Claude Code 会话可持续数小时、每分钟消耗上百万 token,不少公司在一个季度内就烧完了原本一整年的编码 Agent 预算。
• 用单一前沿模型 = 系统性溢价。真实工作负载里有一条"简单请求的长尾"(改错别字、重命名变量、总结)。让一个昂贵的前沿模型包揽一切,等于为了应对少数难题,在大量简单步骤上持续多付钱。
• 模型能力异质化。不同模型在细分任务上各有强弱。把每个请求发给它最擅长的模型,路由不仅能省钱,还可能在质量上超过任何单一模型(NotDiamond 称可带来 5–20% 的准确率提升)。

OpenRouter 本身是一个托管式网关 + 路由器:一个 OpenAI 兼容端点(https://openrouter.ai/api/v1)、一把 API Key,背后是横跨 60+ 供应商的 400+ 模型,月吞吐量约 100 万亿 token。Auto Router 是其中负责"自动选模型"的能力,调用方式极简——只需把 model 设为 openrouter/auto。

理解 OpenRouter 的关键:两层独立路由

OpenRouter 的路由由两个相互独立的决策组成。把它们分开看,后面所有配置项都会各就各位。

一个路由器要做的完整工作有四件,OpenRouter 全部覆盖:模型选择、供应商选择、负载均衡、故障转移。Auto Router 解决的是其中的第一件——也是最"智能"的一件。

用法只有一行:把模型设为 openrouter/auto,其余与调用普通模型完全一致(支持流式、工具调用等所有标准特性)。

const completion = await openRouter.chat.send({
  model: 'openrouter/auto',
  messages: [{ role: 'user', content: '用简单的话解释量子纠缠' }],
});

// 响应里的 model 字段会告诉你实际选用了哪个模型
console.log('实际使用:', completion.model);
// → "anthropic/claude-sonnet-4.5"

工作流水线(四步)

两个版本:两种"选模型"的哲学

Auto Router 目前存在两个技术路线不同的实现,理解它们的差异,是理解"按复杂度调度"的关键。

① 成本 / 质量权衡拨盘 · cost_quality_tradeoff

一个 0–10 的整数,连续地在"质量优先"与"成本优先"之间调节。默认 7——在明显省钱的同时保持较强的输出质量。

{
  "model": "openrouter/auto",
  "plugins": [{
    "id": "auto-router",
    "cost_quality_tradeoff": 3,          // 更偏质量
    "allowed_models": ["anthropic/*", "openai/*"]
  }]
}

② 限定可选模型 · allowed_models(通配符)

用通配符把路由的候选范围锁在特定供应商或模型族内(合规、成本或偏好考虑)。可按请求传入,也可在 Settings → Plugins 里设默认值,按请求的值会覆盖默认。

③ 会话粘性 · Session Stickiness(缓存感知的关键)

与固定模型不同,Auto Router 每次都可能选不同的模型。若不加约束,多轮对话里逐轮换模型会导致行为不一致、并浪费 prompt 缓存。会话粘性因此同时锁定模型 + 供应商:

• 隐式(自动):OpenRouter 对首条 system 与首条 user 消息做哈希,得出"对话指纹";一旦供应商上报了 prompt 缓存命中,就把该对话钉在同一模型+供应商上,无需配置。
• 显式(session_id):传入 session_id 后,首次成功响应即触发粘性(无需等到观察到缓存命中)。多轮对话与 Agent 工作流推荐使用。
• 过期规则:非活动 5 分钟后缓存失效;每次成功请求重置计时;若被钉的供应商报错,则不更新缓存,允许下次重新路由。

④ 定价与透明度

Auto Router 不收取任何额外费用,你只按被选中的那个模型的标准价付费——与直接调用该模型完全一致。响应中的 model 字段永远回传真实使用的模型,决策可审计、不靠猜。

要判断 Auto Router "聪明在哪、边界在哪",需要把它放进整个模型路由的技术谱系里看。路由可沿三个维度拆解:模型池、决策信号、优化目标。

确定性路由 vs 智能路由

智能路由的六种技术路径

Auto Router 的两个版本,恰好落在下面这张谱系图的不同位置:NotDiamond 版属于预测式,auto-beta 则是复杂度/任务分类与群体信号的结合。

关于"路由延迟开销"的辨析

对预测式/分类式路由最常见的质疑是"多加一步会不会拖慢"。实测框架给出的答案是:通常不会成为瓶颈。

供应商层:价格平方反比加权(确定性层实证)

当模型选定后(无论手选还是 Auto),第二层供应商路由默认这样跑:①先把"过去 30 秒内有明显故障"的供应商降权后置;②在稳定供应商中,按价格的平方反比加权,偏向最便宜者;③其余作为回退。

与训练期的 MoE 区分

模型路由 ≠ 混合专家(MoE)。MoE 在训练期把 token 分派给单个模型内部的专家子网络;模型路由在推理期把整个请求分派给多个独立训练的模型。二者类比,但处在技术栈的不同层级。

Auto Router 只是 OpenRouter 路由体系里的一员。理解周边组件,才能知道何时该用哪个。

先厘清一组常被混用的概念,再看横向对比。

选型评估清单(买或自建都适用)

• 决策信号是什么?只看 header/规则/可用性 = 确定性路由;看内容则要问:分类器、语义、预测,还是级联?
• 模型池有多大?是否锁定单一供应商?能否同时覆盖闭源与开源?新模型接入有多快?
• 目标函数可控吗?能否表达成本/质量/延迟的偏好,还是只优化单一维度?(Auto Router 用 0–10 拨盘覆盖此项)
• 路由自身开销多大?若给每个请求加 1s 与 $0.10,就吃掉了它创造的大半价值。
• 是否厂商中立?模型格局持续变动,中立方案长期通常更有价值。
• 能否处理 Agent 负载?会话上下文、工具 schema、prompt 缓存、长上下文行为都要考量。
• 是否缓存感知?对 Agent 负载这是决定性的——务必问清缓存 TTL 过期、压缩事件、子 Agent 级路由如何处理。

OpenRouter Auto Router 把"按任务复杂度选模型"这件原本需要自建分类器与评测管线的事,压缩成了一次零加价的 API 调用。

它的技术亮点不在单一算法,而在工程整合度:预测式/任务感知的智能选模型(第一层)、价格加权与自动故障转移的确定性供应商路由(第二层)、以及针对 Agent 时代最棘手问题的缓存感知会话粘性,被打包进同一个 OpenAI 兼容端点。cost_quality_tradeoff 与 allowed_models 又把控制权还给开发者,而 model 回传字段保证了决策透明可审计。

它的边界同样清晰:作为托管服务,它以放弃控制面所有权换取更低的运维负担,因此不适合强治理/自托管/可审计需求;其价值高度依赖工作负载形态——只有当流量里存在"可被便宜模型无损处理的简单长尾"时,路由的省钱效应才真正兑现。对绝大多数面向不确定输入的混合负载而言,把 openrouter/auto 作为默认、辅以会话粘性与合理的成本/质量拨盘,是一个低风险、高性价比的起点。