作者：Lei阅读 --

深读 OpenRouter：它不是一个聪明路由器，是一个开源模型推理的现货市场

同一个 Llama 3.3 70B，OpenRouter 上挂着 13 家供应方，prompt 报价差 10.4×、量化精度混着 fp8/bf16/fp16。这不是路由问题，是市场问题。本文用亲手跑的 API 数据 + 7 篇 arXiv 论文把 OpenRouter 拆到根本约束：开源权重让推理商品化，边际买家要的是发现与切换、不是智能。围绕这条主线看 provider preference（拍卖）、Auto Router（Hayek 价格系统聚合）、BYOK 5% 抽成、per-provider sticky 缓存怎么各自落成市场机制，以及在闭源模型面前先崩在哪里。

AILLMAI Infra论文深读系统设计

一件小事，先摆事实：同一个 Meta Llama 3.3 70B Instruct，我今天从 OpenRouter 的 /api/v1/models/.../endpoints 拉下来，13 家供应方在挂牌。最便宜的 DeepInfra 报 prompt 0.10 美元/百万 token、completion 0.32；最贵的 Together 报 1.04 / 1.04——prompt 差 10.4×，completion 差 3.25×。量化精度混着 fp8、bf16、fp16、unknown，max_completion_tokens 从 2,048 到 128,000 差 63×。挂的都是”Llama 3.3 70B Instruct”，卖的其实是十几个不同的服务。

RouteLLM 那类”给这条 query 打胜率、选一个模型”的聪明路由器不是在解这个问题。这个数字暴露的问题是市场问题——同一件商品在多个卖家手里、价格质量差一个数量级、买家需要发现和切换。这才是 OpenRouter 的形状。

这篇把 OpenRouter 当”LLM 推理现货市场”来读——它的 API 设计、Auto Router 的机制、BYOK 的定价、缓存的 sticky——每一条都是市场机制的落地，不是路由器的落地。

名词速查

术语一句话解释
Provider（供应方）实际托管并推理模型的一方，如 DeepInfra、Groq、Together。同一个模型可能有 N 家
Endpoint一个「provider × model × 配置」的实例，是 OpenRouter 挂牌的最小单位
Quantization权重的存储精度（fp16 / bf16 / fp8 / fp4 / int8 / int4），量化越低越省显存、越快，但质量可能下降
BYOKBring Your Own Key。用你自己的 provider 账号 key 走 OpenRouter，OpenRouter 抽 5%
ZDRZero Data Retention。请求不留痕的合规模式
现货市场 vs 路由器前者是”多个卖家挂牌、买家挑单”；后者是”给一个 query 决定唯一目的地”
揭示偏好（revealed preference）经济学术语：不问用户”喜欢什么”，看用户”花钱买了什么”。OpenRouter 的 Auto Router 靠这个

门槛铺垫

这篇假设你已经知道：OpenAI 兼容协议是什么样（chat/completions + messages + tools）、权重和推理服务的分离（Meta 放出 Llama 3.3 70B 的权重，但你不用它自己的服务——托管它的是 DeepInfra、Together、Groq 这些第三方 GPU 云）、KV 缓存和 prefill/decode（不熟先读《一把 Key 背后》的六层解剖）。

也假设你读过我上一篇《RouteLLM 深读》——那篇讲清了”聪明路由器”这个方向：给 query 学一个胜率、按阈值切强弱模型。本文的立论是另一个方向：OpenRouter 处理的问题不在预测 query 的胜率上，而在同一个模型的多个供应方之间做发现和切换。两篇不重叠，读起来是配对的。

一、从数字开始：同一个模型，13 张牌

数据是我今天用 curl https://openrouter.ai/api/v1/models/meta-llama/llama-3.3-70b-instruct/endpoints 拉的，脚本粘在文末。挑关键几行摆出来：

ProviderPrompt $/MCompletion $/MQuantizationContextMax Completion
DeepInfra0.100.32fp8131,07216,384
Nebius0.130.40fp8131,072117,964
Novita0.1350.40bf1612,28811,059
Crusoe0.250.75bf16131,072117,964
Cloudflare0.2932.253fp824,00021,600
Groq0.590.79unknown131,07232,768
CoreWeave0.710.71fp16128,000115,200
Together1.041.04unknown131,0722,048

三个可读到的事实：

  1. 量化精度在报价里公开对齐：fp16 全精度贵 7×，bf16 中间价位，fp8 最便宜。买家能选、能过滤——provider.quantizations 就是把这一列变成请求参数。
  2. 上下文与生成上限不是模型的属性、是这家部署的属性：Novita 只给 12k context，Together 只给 2k output。这两家都在挂”Llama 3.3 70B”这块牌子，但拿去做长文场景会当场翻车。
  3. 价格反直觉的地方：Groq 的 prompt 0.59 比大多数贵，但 output 0.79 比 CoreWeave 便宜——不同的推理栈在 prefill 和 decode 上分别有优势。同一个”贵不贵”这个问题在这里都不成立，得分 prefill/decode 两头看。

亲手算一笔账，验证这个价差有多真（脚本一次性验算过）：

日流量 1M input + 1M output token：

  • DeepInfra fp8：0.10×1+0.10 × 1 + 0.32 × 1 = $0.42/天
  • Groq unknown：0.59+0.59 + 0.79 = $1.38/天（3.3×）
  • Together：1.04+1.04 + 1.04 = $2.08/天（4.95×）
  • 一个月的差距：cheapest→expensive = $49.80/月/模型

50 美元不算多。但如果你有 50 个模型接入点、生产流量是这个数的百倍——市场机制值不值得学清楚就是另一个数量级的答案。

根本约束的第一次落地：OpenRouter 之所以要暴露 13 张牌、暴露量化、暴露每一列价格差，是因为在开源权重模型上，“同一个模型” 这个词已经不足以描述你在买什么。这条约束一旦成立，剩下所有设计都是它的推论。

二、差价从哪里来：四篇论文解释了 90% 的分歧

上面那张 10× 价差表如果只是”竞争激烈”，故事就没深度。真实原因是：同一份权重，在不同推理栈上根本不是同一个服务——差价买的是不同的产品，不是同一件商品的折扣。四篇论文把这个故事拆到根本层：

2.1 The Silent Hyperparameter：光换推理引擎就能让分数差 16.6 pp

Pape, Evertz, Schönherr（CISPA）在 arXiv:2605.19537 系统性测了 vLLM、SGLang、llama.cpp 等 5 个推理引擎，权重、解码参数、硬件全对齐，光是换后端 benchmark 分数就能差最多 16.6 个百分点。他们扫了 35,000 篇 ML 论文，发现推理栈几乎从不被披露——他们把这称作”沉默的超参”。

对市场的含义直接：DeepInfra 和 Together 报”Llama 3.3 70B”的时候，他们跑的 prefix caching 策略、CUDA graph 用不用、自定义 kernel 有几个，决定了输出。你不换 provider 就相当于把一个 16.6 pp 的自由度默默让给了 provider。OpenRouter 之所以要给 endpoints 页展示每家的独立 uptime、latency、throughput，正是承认这个自由度存在。

2.2 vLLM/PagedAttention：为什么 provider 之间吞吐能差 4×

Kwon 等在 arXiv:2309.06180 提出的 PagedAttention——KV cache 分页，消除碎片、允许跨请求共享前缀——把开源推理分成了两个时代：论文里报的是相对 FasterTransformer/Orca 2–4× 的吞吐提升（相同 latency 目标下）。

一家 provider 跑 vLLM，另一家跑改过的 SGLang 或自研栈，还有的用老 HF Transformers——同样的权重，服务的单卡容纳并发数能差一个数量级。这就是为什么我上面那张表里 CoreWeave 的 latency 短、Together 的 completion 长度上限只有 2048（batch 挤不下）——每家的推理栈都是自己的商业秘密，公开出来的只是价格和额度。

2.3 Speculative Decoding：同价位延迟差 2–3×

Leviathan, Kalman, Matias 在 arXiv:2211.17192 的推测解码——用一个便宜的 draft 模型先生成 K 个 token、大模型并行 verify——输出分布可证明与直接解码等价，但 T5-XXL 上直接换来 2–3× 的 wall-clock 加速。

于是就有了这一层公开博弈：如果你的 provider 上线了推测解码，你的 token/秒会突然翻倍，但用户请求的账单不变（还是按 token 数付）——provider 单卡赚得更多，也可以选择降价打市场。反过来，一家没上的 provider 只能靠降 fp 精度或压 context 来打平。这一层”技术上非公开、结果上公开”的博弈，就是市场存在的直接理由：你需要一个中立方，把结果层公开给买家看。

2.4 Numerical Nondeterminism：连”同一个 seed” 都不能承诺

Yuan 等在 arXiv:2506.09501 把非确定性追到浮点层：float 加法在数值上不满足结合律，一旦 batch size、GPU 数、GPU 型号变了，累加顺序就变了；temperature=0 的贪心解码也不再是可复现的。DeepSeek-R1-Distill-Qwen-7B 在他们的实验里准确率能飘 9%，回答长度能飘 9,000 token——仅仅因为切了 GPU 型号或 batch 分布。

对一个市场买家的含义：你的 eval 数字如果不 pin provider，就是白测。同样的请求参数，DeepInfra 一批、Nebius 一批，你以为的模型质量差异可能只是 batching noise。OpenRouter 的 provider.order 和 provider.only 就是为这个约束准备的——如果你想 eval 得住，你得能把请求钉死到一家。

三、Provider preference：把请求变成一份 bid（订单）

上面四篇解释了”为什么差价真实存在”。接下来看 OpenRouter 怎么把这个市场结构化成 API。核心在请求里那个 provider 对象——它的字段不是配置，是订单的规格。

先看完整字段（官方文档，我逐一对照过）：

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "messages": [...],
  "provider": {
    "order":                    ["DeepInfra", "Nebius"],
    "only":                     ["DeepInfra", "Nebius"],
    "ignore":                   ["Together"],
    "allow_fallbacks":          true,
    "require_parameters":       true,
    "data_collection":          "deny",
    "zdr":                      true,
    "enforce_distillable_text": false,
    "quantizations":            ["fp8", "bf16"],
    "sort":                     "price",
    "preferred_min_throughput": 20,
    "preferred_max_latency":    2000,
    "max_price": {
      "prompt":     0.5,
      "completion": 1.0,
      "request":    0.001,
      "image":      0.01
    }
  }
}

用市场化的语言翻译一遍：

字段市场角色
order / only / ignore白名单/黑名单，买家选交易对手
sort: price/throughput/latency/exacto你想按哪个维度先排的偏好，等于告诉市场”我优先看哪个字段”
quantizations商品规格过滤（“只要 fp8 及以上”）
zdr / data_collection合规规格过滤（“只要不留数据的柜台”)
preferred_min_throughput / preferred_max_latency软约束偏好（推排序、不 hard filter）
max_price.*硬价格上限——超了就放弃这个请求，不成交
enforce_distillable_text”输出的所有权能不能拿来蒸馏”这个法律条款也进请求接口
allow_fallbacks首选交易对手失败时，允不允许开中间人成交

值得单独讲的是默认路由本身。文档里的原话：“select one weighted by inverse square of the price”——Provider Routing 页 明文写着这一句。翻译成人话：1/M的provider被选中的概率是1/M 的 provider 被选中的概率是 3/M 的 9×。这不是”选最便宜”，是按价格倒平方权重的抽样。

这个选择挺讲究。纯贪心”选最便宜”会把所有流量砸给最低价——那家一旦被打挂、市场瞬间崩掉。均匀轮询又浪费价差。倒平方权重是一个 soft 版的价格加权 lottery：便宜的拿走大部分流量、贵的仍分到一小份（用来维持它的存活、维持竞争）。做过 ad auctions 的会认得——这是 GSP 拍卖那类价格分层拿量的思路在 LLM 推理市场上的翻译。

补一条工程细节，来自同一页文档：“providers that have not seen significant outages in the last 30 seconds” 是唯一被公开的降级阈值，而 latency 百分位（p50/p75/p90/p99）用的是 “rolling 5-minute window”——这两个短时窗口一起决定了权重轮盘的”存活候选池”。5 分钟已经短到能把慢慢劣化的供应方剔出、30 秒短到能对短时故障响应；但都够长到不会被单次抖动打乱决策。这是拍卖市场里典型的”波动过滤 + 快速止损”设定。

四、Auto Router：Hayek 机制在 LLM 上的一次落地

到目前为止，路由决策还都是买家侧做的：你在请求里写 provider.sort、写 quantizations。OpenRouter 还有另一手——openrouter/auto 这个”模型”。你把请求发给它，它替你选 model + provider。

这个东西容易被误读成”又一个 RouteLLM”。它不是。 官方文档原话（Model Routing 页）：

“powered by the market: the aggregate spend of millions of people using OpenRouter, measured over a trailing 7-day window”

再补一句：

“assigns each prompt one of ~30 fine-grained task types — for example code:debugging, agent:multi_step_planning, qa_knowledge, math, customer_support, or research_report”

拆开看：

  • 不是学一个胜率预测器（RouteLLM 是学 Chatbot Arena 偏好数据得到 P(wins∣q)P(\text{win}_s | q)）
  • 是查 7 天滑动窗口内、这一类 task 上，社区实打实花了最多钱 的模型是哪一个
  • 然后按用户设的 cost_tier（low / medium / high / xhigh / max）在 top-N 里选一个
  • 多轮对话通过 session_id 保持粘性，不让每一轮跳模型

用一个更古的名字讲：这是 Hayek 的价格系统在 LLM 上的一次实例化。Hayek 1945 年的《The Use of Knowledge in Society》讲过：没有任何一个中央规划者能知道”这道菜配这瓶酒好不好”这种局部知识，但市场价格能把所有分散的判断聚合成一个可读信号——价格是知识的压缩。

Auto Router 就是这个思路的落地：不去学”code:debugging 这类 query 上 Claude 强还是 GPT-4o 强”这种命题——它只统计过去 7 天在 code:debugging 上大家的钱都往哪里去了。你可以把它当成”用户群体级别的 revealed preference”：不问用户”你喜欢哪个模型”，看用户”给哪个模型付了钱”。

拿它和 RouteLLM 并排比一下：

维度RouteLLMOpenRouter Auto
训练数据Chatbot Arena 偏好对平台 7 天滑动窗口的花费
决策单元(query, 强/弱模型对)(task_type, cost_tier)
决策粒度每条 query每类 task
反馈延迟数据集是历史静态7 天滚动更新
冷启动换新模型要重训新模型只要有人开始花钱就自动进入候选
偏见继承评测器偏见（LLM-as-judge 里三种偏差）继承用户群体的从众和马太效应
崩点分布外 query（未见过的任务类型）冷门 task_type 数据稀疏；新模型早期抗不过老王

不做优劣判断，只指出：两者是两条完全不同的路径，各自在自己的假设成立时最强。RouteLLM 的假设是”我能拿到有质量的评测偏好数据”；OpenRouter Auto 的假设是”我有足够大的用户群、他们的花钱行为是有信息的”。前者是学习问题，后者是聚合问题。

OpenRouter 有底气做后者的原因，OpenRouter 团队自己在 arXiv:2601.10088 发的论文 报了个数：过去一段时间平台跑了 100 T tokens、覆盖数百万用户——这个规模才让 revealed preference 变成可信信号。规模不够时，Hayek 机制就退化成”少数早期用户的偏见被放大”。这也是决策地图那篇《Eval 到 Router》里遗漏的一支——评测蒸馏不是路由预测器的唯一训练信号，spend 数据是另一支。

五、崩点：这个市场设计先在哪里塌

一个成立的设计必然有一个前提，前提不成立时它先崩在哪里——这一条是”根本约束”是否真的立得住的验证。

崩点 1：闭源模型上，市场机制不存在。 GPT-5、Claude 4.5、Gemini 2.5 这几个只有一家 provider——就是模型厂商自己。OpenRouter 在这些模型上无法提供 provider 竞争，退化成一个 5% 抽成的转售商（准确点说，非 BYOK 时它抽成来自和厂商的批量协议）。所有 provider.sort/only/ignore/quantizations 字段对这类模型都是无操作——用户界面还在，语义已经没了。

崩点 2：BYOK 的 5% 抽成不是白拿。 官方文档明文写着 “5% of what the same model/provider would cost normally on OpenRouter”（用你自己的 provider 账号 key，OpenRouter 从你的 credit 里扣走 5% 的等价金额）。你自然会问：都自带 key 了，凭什么再抽 5%？答案：你买的不是转售，是上面所有的东西——observability、fallback、provider-sticky 缓存、Auto Router 的 revealed preference、账单聚合、通用协议。如果这些你都不需要，5% 就是纯税，你应该直接找 provider。这是这个市场的清晰的失效边界：当买家的需求塌到”只要 API 通”，市场结构对他就没价值了。

崩点 3：缓存的沟壑。 OpenRouter 的 prompt caching 是per-provider 粘性的（Prompt Caching 页）——同一个 session 内的后续请求会被 pin 到上一次那家 provider，10 分钟不活动才断粘。这是最经济的设计，因为 KV cache 是每家自己家的东西。但这条粘性和 provider.sort=price 天然矛盾：你想按最低价重新分发，就会打断 cache hit；你想吃 cache hit，就得放弃再选。这是市场机制在有状态服务上最难的一段——KV 让”哪家最便宜”的答案在中间就变了。

共同祖先：这三个崩点其实是一件事——元数据分界定律（我在《一把 Key 背后》提过一次）：只靠请求元数据能做的决策，网关能全权收编；一旦决策依赖模型内部状态（KV 谁家有、logits 长什么样、权重在哪块 GPU），网关只能靠 sticky 这种半吊子机制。OpenRouter 的市场机制在无状态请求上工作得漂亮，越靠近有状态的场景（多轮、长上下文、prompt cache），它越必须让位给 provider 内部的东西。

六、这个市场未来长什么样

只保留两条我在数据里看得到的方向、其余留白。

方向 1：spec 层继续细化。 现在 quantizations 只到 fp16/fp8/bf16/int8/int4；下一步大概率会有 speculative decoding 是否开启、prefix cache 命中率保证、context 内容审查是否强制等更细的规格字段。理由：The Silent Hyperparameter 那篇把 16.6 pp 的分歧摆到台面上以后，买家开始要求 spec 透明——市场上供应方越多、买家越会用 spec 差异化商品。

方向 2：Auto Router 会往 spend + benchmark 的混合方向走。 纯 revealed preference 会被马太效应主导（用得多的更容易被推荐，形成正反馈）。RouteLLM 那类偏好数据是天然的反马太校正——它挂钩的是”这类 query 到底谁答得好”，不是”哪家最热”。两条信号融合是自然的下一步。OpenRouter 已经上线的 Pareto Code Router（按 Artificial Analysis 编码分位排序，用户设 min_coding_score 阈值）是往这个方向迈的第一步——benchmark 打底、spend 加权。

至于闭源模型侧那块被割掉的市场结构——我不猜，猜出来也是灰产。

小结

  • 一句根本约束：OpenRouter 之所以长成”provider 竞价市场”这个形状（而不是聪明路由器 或通用网关），是因为开源权重把推理服务商品化了——同一个模型名下有 N 家、报价能差 10×、质量能差 16.6 pp，边际买家真正需要的是”发现和切换”，不是”智能”。这条约束不存在时（闭源模型），设计立刻退化成 5% 抽成的转售商，所有 provider preference 字段变成无操作——所以它必然长成市场，别无选择。
  • 崩点：三种情形下市场机制先塌：闭源模型（无竞争）、单纯 API 转发需求（价值≤5%）、有状态请求（KV cache 打破 sticky 之外的重新竞价）。这些边界正是 OpenRouter 主动让位、把选择权交回给 provider 的地方。
  • 共同祖先：这是 Hayek 价格系统在 LLM 推理上的一次实例化。inverse-square weighting 是 soft 版价格加权 lottery（拍卖机制），Auto Router 是 revealed preference 聚合器（社会计算），provider.spec 字段 是商品规格披露（信息经济学）。这三个古老思想合起来，就是 OpenRouter 在开源模型市场上的一整套动作。
  • 可带走的动作：如果你在 eval，务必 pin provider.only 到一家（否则你测的是 batching noise，不是模型质量，见 arXiv:2506.09501）；如果你要跑生产，provider.max_price + provider.zdr + provider.quantizations 是最先该配的三个硬约束；如果你不需要 fallback / observability / Auto Router，直接找 provider 拿 key 比走 OpenRouter 便宜 5%。

说明与后续验证

我软的地方：Auto Router 的 30 类 task 分类器具体是什么模型、怎么训的，官方没披露，我没读到代码，判断只到”存在一个轻量分类器”这一步。Fusion 和 Pareto Code 这两条特殊路由的实测行为我也没跑（Fusion 是多模型 panel + web search，Pareto Code 是 min_coding_score 阈值），只从 model 列表和描述里读到了它们的存在。

一个可执行的自测（一杯咖啡的时间）：拿 API key 后跑一次

curl -sS https://openrouter.ai/api/v1/models/meta-llama/llama-3.3-70b-instruct/endpoints \
  | jq '.data.endpoints[] | {provider:.provider_name, prompt:.pricing.prompt, completion:.pricing.completion, quant:.quantization}'

看看今天的 13 张牌是不是还是 13 张、价差还是不是 10×。这个数会漂——一个月后再跑一次，看谁掉队、谁新进——就是你亲手观察这个市场的最低成本方法。

参考

工程实践

arXiv 论文

相关站内文章