一句话判断
OpenRouter 的核心价值，不只是“一个 API 调用很多模型”，而是把 模型、Provider、价格、延迟、吞吐、可用性、参数兼容、数据政策、Fallback 和可观测性 封装成了一套可配置的路由系统。
这意味着，AI 基础设施的竞争正在从“接入更多模型”，进入到“如何稳定、低成本、可治理地使用多个模型和多个供应商”。
OpenRouter 官方文档中明确写到，它提供一个 API 访问 400+ 模型和 Provider，并且 Models API 可以按输出模态、支持参数等维度查询模型能力。
1. OpenRouter 的本质：不是模型市场，而是模型路由层
很多人理解 OpenRouter，会把它看成一个“模型聚合平台”：
一个 API，可以调用 GPT、Claude、Gemini、DeepSeek、Llama 等模型。
这当然是它最直观的价值，但不是最关键的价值。
真正值得研究的是它背后的 Provider Selection。
同一个模型，可能由不同 Provider 提供。例如某个开源模型，可能同时跑在 DeepInfra、Together、Fireworks、Novita 或其他推理平台上。用户表面上请求的是一个 model slug，但系统真正要决定的是：
这一次请求，应该交给哪个 Provider？哪个 endpoint？用什么策略排序？失败后是否 fallback？是否满足参数和数据政策要求？
这就是 OpenRouter Provider Routing 的核心。
它不是简单的 API 代理，而是一层模型执行控制面：
用户请求
↓
模型选择
↓
Provider 候选池
↓
路由策略
↓
参数 / 价格 / 数据政策过滤
↓
Provider 执行
↓
Fallback
↓
返回结果与元数据OpenRouter 官方文档也把 Provider Routing 描述为：将请求路由到最合适的可用 Provider，并允许用户通过请求体中的 provider 对象自定义路由方式。
2. 默认路由：低价优先，但不是机械最低价
OpenRouter 默认会在可用 Provider 之间做负载均衡，并且优先考虑价格。它的默认策略大致是三步：
第一，优先选择最近 30 秒内没有明显故障的 Provider。
第二，在稳定 Provider 中选择低成本候选，并按价格倒数平方进行加权。
第三，把剩余 Provider 作为 fallback。
这点很关键。
OpenRouter 不是简单地“永远选最便宜的 Provider”。如果永远只打最低价 Provider，会带来几个问题：
低价 Provider 一旦波动，请求会集中失败；
所有流量打到一个 Provider，容易触发限流；
其他 Provider 没有流量探测，健康状态会变得不透明；
Fallback 只在失败后发生，用户体验更容易抖动。OpenRouter 的默认策略更像是：
成本敏感型加权负载均衡 + 近期健康状态过滤 + 自动失败转移。
这说明 LLM Router 的关键不只是“便宜”，而是要在 成本、稳定性和恢复能力 之间做动态平衡。
3. provider 对象：一次请求里的路由策略合同
OpenRouter 把 Provider Selection 封装进请求体中的 provider 对象。这个对象可以配置 order、allow_fallbacks、require_parameters、data_collection、zdr、only、ignore、quantizations、sort、preferred_min_throughput、preferred_max_latency、max_price 等字段。
这其实是一个很重要的产品抽象：
路由策略不应该只写死在平台后台，而应该可以在单次请求级别动态声明。
不同任务，对模型路由的要求完全不同：
聊天问答：低延迟优先；
批量生成：低成本优先；
企业数据：数据不留存优先；
代码任务：工具调用和上下文能力优先；
结构化输出：必须支持 JSON mode / response_format；
长任务 Agent：高可用和 fallback 优先。OpenRouter 的设计说明，模型调用已经从“选择一个模型”升级成了“声明一次执行策略”。
4. sort 与 order：一旦显式指定，默认负载均衡就会关闭
OpenRouter 支持用 sort 显式排序 Provider，目前主要支持三个方向：
price → 最低价格优先
throughput → 最高吞吐优先
latency → 最低延迟优先但文档里有一个很关键的细节：如果设置了 sort 或 order，OpenRouter 默认的负载均衡会被关闭，Router 会按指定顺序尝试 Provider。
这说明 OpenRouter 把路由分成两种模式：
默认模式：系统自动负载均衡，兼顾价格和可用性；
显式模式：用户指定排序或 Provider 顺序，系统按用户策略执行。它还提供了两个快捷后缀：
:nitro = provider.sort = throughput
:floor = provider.sort = price也就是说，请求某个模型时加上 :nitro，就是吞吐优先；加上 :floor，就是价格优先。
这类快捷策略值得关注。因为 AI 基础设施不应该只给开发者一堆复杂参数，也应该提供可以被快速理解的策略入口：
更快
更便宜
更稳定
更合规
更严格这才是模型路由产品化的方向。
5. partition：从“模型优先”到“目标优先”
OpenRouter 最值得研究的高级设计，是 sort.partition。
当用户使用多个 fallback models 时，sort 可以配置成对象，并设置 partition：
{
"sort": {
"by": "throughput",
"partition": "none"
}
}默认情况下，partition 是 "model"。这意味着 Router 会先按模型分组：主模型的 endpoint 永远先尝试，只有主模型失败后，才进入 fallback 模型。设置为 "none" 后，Router 会把多个模型下的所有 endpoints 放在一起全局排序。
这背后有一个非常关键的范式变化：
到底是模型优先，还是目标优先？
如果是 partition: "model"，逻辑是：
我想优先用 Claude；
Claude 不行，再用 GPT；
GPT 不行，再用 Gemini。如果是 partition: "none"，逻辑变成：
我不执着于某个模型；
哪个 endpoint 当前最快、最便宜、最符合性能要求，就用哪个。OpenRouter 官方示例中，当同时传入 Claude、GPT、Gemini 等多个模型，并设置 partition: "none" 与 sort.by: "throughput" 时，Router 会选择所有模型 endpoint 中当前吞吐最高的那个，而不是永远先尝试列表里的第一个模型。
这代表了 LLM Router 的一个重要趋势：
AI 应用会从“指定模型”走向“指定目标”。
未来用户未必关心到底是哪一个模型完成任务，而是关心这次任务是否在成本、速度、稳定性和策略约束下被完成。
6. 性能阈值：软偏好，而不是硬过滤
OpenRouter 支持设置性能偏好，例如：
preferred_min_throughput
preferred_max_latency它还支持用 p50、p75、p90、p99 这些分位数表达性能要求。OpenRouter 文档说明，它会基于滚动 5 分钟窗口，追踪每个 model/provider 的 latency 和 throughput 分位数。p50 代表典型性能，p90/p99 更适合观察坏情况表现。
但这里还有一个关键点：
这些性能阈值不是绝对保证，而是偏好排序。
如果某些 endpoints 不满足阈值，它们不会被彻底排除，而是被降级到候选列表后面。OpenRouter 明确说明，preferred_max_latency 和 preferred_min_throughput 不会阻止请求执行；与之不同，max_price 会阻止请求运行在超过价格上限的 Provider 上。
这是一种很成熟的路由思想：
硬约束：价格上限、数据政策、ZDR、参数兼容、白名单；
软偏好：延迟、吞吐、成本优先级。硬约束决定“能不能用”。
软偏好决定“优先用谁”。
如果所有条件都做成硬过滤，系统会变得过于脆弱；如果所有条件都只是软偏好，系统又缺乏边界。OpenRouter 的设计，是在可用性和控制力之间找到平衡。
7. Provider 控制：order、only、ignore 是三种不同权力
OpenRouter 的 Provider 控制主要有三种方式。
第一种是 order，用于指定 Provider 尝试顺序。文档说明，如果 order 中的 Provider 都不可用，OpenRouter 仍会继续尝试其他 Provider，除非同时关闭 fallback。
第二种是 only，用于只允许某些 Provider。OpenRouter 也提醒，限制 Provider 会显著减少 fallback 选项，降低请求恢复能力。
第三种是 ignore，用于跳过某些 Provider。文档同样提醒，忽略多个 Provider 也可能减少 fallback 选项。
这三者其实对应三种不同的治理语义：
order = 偏好顺序
only = 白名单
ignore = 黑名单这很重要。因为模型路由不只是技术问题，也是策略问题。
有些场景只是“优先选择某个 Provider”；有些场景是“只能使用某些 Provider”；还有些场景是“临时排除某些 Provider”。这三类意图必须分开，否则系统会很难解释，也很难治理。
8. Endpoint 级别路由：真正的差异不只在 Provider，而在 endpoint
OpenRouter 文档中还有一个细节：同一个 Provider 可能为同一个模型提供多个 endpoint，例如默认 endpoint、turbo endpoint，或者不同区域 endpoint。比如 google-vertex 可以匹配所有 Vertex endpoints，而 google-vertex/us-east5 只匹配某个区域；deepinfra 可以匹配默认 endpoint 和 turbo endpoint，而 deepinfra/turbo 只匹配 turbo。
这说明模型路由的真实层级不是：
Model → Provider而更像是：
Model → Provider → Endpoint / Region / Variant这对理解 AI 基础设施非常关键。
真正影响稳定性、价格和性能的，往往不是抽象意义上的“某个 Provider”，而是具体 endpoint：
某个区域延迟更低；
某个 turbo endpoint 吞吐更高；
某个 endpoint 不支持特定参数；
某个 endpoint 当前错误率上升；
某个 endpoint 的价格或量化方式不同。所以，未来的模型路由不会停留在“选模型”或“选 Provider”，而会进入更细粒度的 endpoint 选择。
9. 参数兼容：防止“请求成功但行为错了”
OpenRouter 的 require_parameters 是一个非常关键的参数。
默认情况下，如果某些 Provider 不支持请求中的部分 LLM 参数，它们仍可能接收请求，只是忽略未知参数。设置 require_parameters: true 后，请求不会被路由到不支持全部参数的 Provider。
这背后解决的是一个 AI 系统中常见但隐蔽的问题：
请求没有失败，但行为已经偏离预期。
比如开发者以为自己启用了 JSON output，实际 Provider 忽略了 response_format，最终返回自然语言；或者以为启用了 tool calling，实际 endpoint 并不完整支持工具调用。
在 Agent 场景里，这类“静默降级”比显式报错更危险。
因为它会让系统看起来正常运行，但下游流程开始失败：
结构化解析失败；
工具调用格式异常；
计划步骤丢失；
长上下文被截断；
输出不可复现。OpenRouter 的 Models API 也支持按 supported_parameters 查询模型能力，例如筛选支持 tools 的模型。
这说明，未来模型能力表不会只是“上下文长度、价格、模型名”，还需要包括：
是否支持 tools；
是否支持 structured outputs；
是否支持 response_format；
是否支持 reasoning；
是否支持 vision；
是否支持指定 max_tokens；
是否支持特定 provider headers。模型路由本质上正在变成“能力匹配”。
10. 数据政策：路由也开始承担合规功能
OpenRouter 的 Provider Selection 不只处理性能和成本，也处理数据政策。
data_collection 可以设为 allow 或 deny。设置为 deny 时，只使用不收集用户数据的 Provider。OpenRouter 同时说明，某些 Provider 可能会记录 prompts，OpenRouter 会在模型页面显示 Data Policy 标签，但这只是其当前掌握的信息，并不是第三方数据政策的最终权威来源。
zdr 参数则用于 Zero Data Retention。设置 zdr: true 时，请求只会路由到不保留 prompts 的 ZDR endpoints。文档还说明，ZDR 可以在 request-level、account-level 或 guardrail 层启用，请求级参数只能确保 ZDR 被启用，不能覆盖账户级或 guardrail 的强制要求。
此外，OpenRouter 还支持 enforce_distillable_text，用于只路由到允许文本蒸馏的模型，适合构建训练集、微调或蒸馏工作流。
这释放出一个很明确的信号：
模型路由正在从性能工程，变成合规工程。
企业或严肃应用最终关心的不只是“模型能不能用”，还会关心：
数据是否被留存？
是否会被用于训练？
是否满足 ZDR？
是否只走指定区域？
是否能解释一次请求为什么去了某个 Provider？
Fallback 时会不会绕过数据政策？未来 AI 基础设施的核心能力，不只是调用能力，而是可解释、可审计、可约束的执行能力。
11. Model Fallback 与 Provider Fallback：两层不同的可靠性机制
OpenRouter 有两类 fallback。
第一类是 Provider Fallback：同一个模型下，不同 Provider 或 endpoint 之间切换。
第二类是 Model Fallback：主模型失败后，切换到备用模型。
OpenRouter 的 Model Fallbacks 文档说明，用户可以传入一个按优先级排列的模型数组。如果第一个模型返回错误，OpenRouter 会自动尝试下一个模型。触发 fallback 的错误包括上下文长度校验错误、内容审核过滤、限流和宕机等。最终计费按实际使用的模型计算，并在响应体的 model 字段返回。
这说明可靠性也有层次：
Provider 失败：同模型换 Provider；
模型失败：换模型；
参数不兼容：换支持能力的 endpoint；
性能不达标：降级到备选 endpoint；
价格超限：直接阻止执行。但 fallback 不是越多越好。
跨模型 fallback 会带来输出风格、能力边界、工具调用行为、结构化格式的一致性问题。对于普通问答，fallback 可能很合理；对于代码生成、结构化输出、品牌内容、企业流程，fallback 就需要更严格的能力约束。
这也是为什么 OpenRouter 同时提供 models、provider、require_parameters、data_collection、zdr、max_price 等多种约束字段。
12. Router Metadata：黑盒路由变成可审计基础设施
OpenRouter 还提供 Router Metadata。用户可以通过请求头 X-OpenRouter-Metadata: enabled 打开 metadata，成功响应中会出现 openrouter_metadata 字段。官方说明，这个能力用于调试路由决策、归因延迟或成本、审计 pipeline 行为。
Metadata 里会包含：
requested：用户请求的模型；
strategy：实际使用的路由策略；
region：处理请求的边缘区域；
summary：路由摘要；
attempt：成功的是第几次尝试；
is_byok：是否使用 Bring Your Own Key；
endpoints：候选 endpoint 与最终选择；
attempts：尝试记录；
pipeline：上下文压缩、guardrail、工具等处理阶段。OpenRouter 文档还说明，Router Metadata 支持多个公开 completion 路由，包括 Chat Completions、Anthropic Messages、OpenAI Responses 和 legacy completions；流式响应也会在最终 chunk 中返回 metadata。
这点非常重要。
当模型调用进入多 Provider、多 endpoint、多 fallback、多策略阶段，如果没有 metadata，系统就会变成黑盒：
为什么这次变慢了？
为什么这次价格更高？
为什么没有走指定 Provider？
为什么 fallback 了？
为什么实际模型和请求模型不同？
为什么工具调用行为变了？Router Metadata 的意义，就是让一次模型调用从“不可解释的 API 请求”，变成“可追踪的执行链路”。
13. 健康检测：不是简单 ping，而是实时质量反馈
OpenRouter 的 Uptime Optimization 文档说明，它会持续监控 AI Providers 的健康和可用性，实时跟踪 response times、error rates、availability，并基于这些反馈做智能路由。
这说明 OpenRouter 的健康判断不是简单的：
HTTP 是否可访问？而是更接近：
这个 Provider 最近是否稳定？
响应时间如何？
错误率如何？
可用性如何？
是否适合继续承接请求？对大模型调用来说，传统健康检查是不够的。
因为 AI endpoint 的问题经常不是“完全不可用”，而是：
返回 200，但输出为空；
首 token 很慢；
流式中断；
限流；
上下文长度不支持；
工具调用格式异常；
某些参数被忽略；
Provider 短时间错误率升高。所以 LLM Router 的健康检测，必须从“服务可达”升级为“任务可完成”。
这也是模型基础设施和传统 API 网关最大的差异之一。
14. OpenRouter 暴露出的基础设施趋势
OpenRouter 的 Provider Selection 文档背后，至少有五个趋势值得关注。
第一，模型不再是单点资源，而是可调度资源
过去调用模型，就像调用一个固定服务。
现在同一个模型可能有多个 Provider、多个 endpoint、多个区域、多个量化版本、多个价格档位。
模型正在从“一个 API endpoint”，变成“可调度资源池”。
第二，模型选择正在从静态配置变成动态决策
过去开发者会在代码里写死：
用 GPT-4；
用 Claude；
用某个开源模型。而 OpenRouter 的策略说明，未来更常见的是：
在满足性能要求下选最便宜；
在多个模型中选当前吞吐最高；
只选不留存数据的 endpoint；
失败后自动 fallback；
要求 endpoint 必须支持全部参数。这不是静态选择，而是动态决策。
第三，成本优化会进入请求级别
OpenRouter 的 sort: price、:floor、max_price、基于性能阈值找最低成本模型等设计，说明成本优化正在从月度账单分析，前移到每一次请求的执行策略里。
未来真正成熟的 AI 应用，不会只在月底看账单，而是在每一次请求发生前，就做成本边界控制。
第四，合规策略会进入路由层
data_collection、zdr、enforce_distillable_text 说明，路由层正在承担数据政策和合规约束。
这意味着 AI 基础设施的控制面，不仅要知道“哪个模型好用”，还要知道：
哪个 Provider 可以保存数据；
哪个 endpoint 不留存数据；
哪个模型允许蒸馏；
哪个区域可以处理请求；
哪个 fallback 不违反策略。第五，可观测性会成为 LLM Router 的核心能力
当请求经过多阶段 pipeline，包括模型选择、Provider 排序、fallback、上下文压缩、guardrail、工具调用等环节时，metadata 不再是附加能力，而是基础设施必需品。
没有 metadata，就没有可解释性。
没有可解释性，就无法真正治理模型调用。
15. 最后的判断
OpenRouter Provider Selection 的真正意义，不是提供了多少模型，而是把模型调用变成了一套可治理的执行系统。
它把一次 LLM 请求拆成多个变量：
用哪个模型？
用哪个 Provider？
用哪个 endpoint？
按价格、吞吐还是延迟排序？
是否允许 fallback？
是否跨模型 fallback？
是否要求支持全部参数？
是否限制数据留存？
是否强制 ZDR？
是否有价格上限？
是否返回路由元数据？这些变量组合在一起，构成了 AI 时代新的基础设施层：
LLM Router / Model Control Plane。
过去，AI 应用的核心问题是“怎么接入一个模型”。
现在，问题正在变成：
如何在多个模型、多个 Provider、多个策略、多个约束之间，稳定、可控、可解释地完成一次智能调用？
OpenRouter 的文档给出的信号很清晰：
模型越多，真正稀缺的不是接入能力，而是路由能力。
更进一步说：
AI 基础设施的下一层，不是更大的模型列表，而是更强的模型治理系统。
