OpenRouter：AI模型路由器的崛起与挑战

作者：HainaKimi K3 发布两天后就进入 OpenRouter 日榜前十，当日调用量约为 1,420 亿 token。GLM-5.2、Nemotron 和 DeepSeek 的使用量也超过了部分 Claude Opus 模型。开放权重模型已经进入主流 API 调用。K3 的走红也暴露了另一个问题。由于上线初期只有 Moonshot 一家 provider，OpenRouter 很快提示上游容量不足、请求可能频繁遇到 429。模型开放权重，不代表市场立刻拥有足够的 GPU 把它稳定运行起来。过去两年，市场最关心新模型有没有超过 OpenAI 和 Anthropic。进入真实应用后，开发者需要回答的问题更多：信息抽取可以交给便宜模型，复杂判断调用 frontier model，中文材料可能更适合 GLM、Kimi 或 Qwen。选定模型后，还要比较不同 provider 的价格、速度、缓存和稳定性。模型选择由季度采购决策变成了任务级变量。OpenRouter 先解决了其中最直接的一层。它让开发者用一把 key 接入 400 多个模型和 70 多家 provider：新模型发布后可以快速测试；同一模型拥有多家 provider 时，可以比较价格和速度，并在一家故障时切换。OpenRouter 无法凭空增加 GPU，却可以帮助流量找到仍有容量的供给。这类入口已经引起战略买家的兴趣。The Information 近日报道，OpenRouter 正在讨论向大型科技公司出售，潜在交易估值达到数十亿美元；公司刚以约 13 亿美元估值完成 1.13 亿美元 B 轮融资。需求已经得到证明。更值得思考的是，Vercel、Cloudflare、云厂商和开源 gateway 都能统一模型接口，OpenRouter 能守住哪一层价值？未来谁会掌握每次模型调用的分配权？Model Routing 的价值会沉淀在哪一层？OpenRouter 能否从默认入口走向更高价值的 orchestration，同时保住中立性？600 美元的起点2023 年 3 月，刚刚离开 OpenSea 日常管理的 Alex Atallah 在电脑上跑起了 Stanford Alpaca。这不是当时最强的模型，但模型账单令他惊讶：斯坦福团队用 GPT-3 生成合成数据，再微调 Meta 的 Llama，整个过程只花了约 600 美元。这张账单改变了他对 winner-take-all 的判断。模型生产门槛继续下降，未来可能不是三五个模型，而是成千上万个；开发者随之需要发现模型、比较能力，并为同一组权重选择推理供应商。他先做了一个叫 Window AI 的开源 Chrome 扩展，让用户可以把自己选择的模型带进网页应用。几个月后，OpenRouter 上线。它把分散在不同实验室和云厂商里的模型，收进一个兼容 OpenAI 的 API：开发者换一个地址、改一行模型名，就能调用不同模型。三年后，这个听起来像“模型聚合器”的产品成了一家独角兽。2026 年 5 月，OpenRouter 宣布完成 1.13 亿美元 B 轮融资，由 Alphabet 旗下成长基金 CapitalG 领投，NVentures、ServiceNow Ventures、Snowflake Ventures、Databricks Ventures 等参与。媒体援引知情信息称其 post-money 约为 13 亿美元。增长已经被证明。更难的问题刚刚开始：当所有云厂商、开发框架和开源项目都能做 gateway，OpenRouter 能守住哪一层价值？Router 是什么：它每天只做两次选择想象一个帮企业做客户尽调的 AI Agent。它先要读取几十页材料、提取公司和人物信息。这一步结构清楚、容错度高，可以交给便宜而快速的模型。接下来，它需要判断交易风险、查找互相矛盾的证据并写出结论，这一步错误成本高，适合调用更强的 frontier model。这是第一次选择：这个任务应该交给哪个模型？假设 Agent 已经决定使用 DeepSeek。新的问题又来了：谁来运行这组模型权重？模型原厂、Baseten、Together、DigitalOcean 或其他推理服务商，都可能提供同一个模型，但价格、速度、正常运行时间、上下文长度和量化方式并不完全相同。这是第二次选择：同一个模型，应该交给哪家 provider？日常讨论常把这两次选择都叫 model routing。它们依赖的信号、竞争对手和商业价值却完全不同。继续往生产环境里走，还会多出两层：请求失败后怎么重试，怎样保持 prompt cache，如何控制 tool call 与预算；以及谁能调用什么模型，数据能否被记录，怎样满足审计与区域合规。因此，model routing 是四个市场共享一个 API：Model selection：根据任务选择模型，目标是质量与成本的最优组合。Provider routing：在同一模型的不同供应商之间选择，目标是价格、速度和 uptime。Execution control：管理重试、fallback、cache、tool call、预算和长任务状态，目标是让 Agent 真正完成工作。Enterprise governance：管理身份、权限、数据政策、审计与采购，目标是让模型可以进入生产核心。OpenRouter 当前的优势是模型采购入口与 provider routing：它聚合碎片化供给，提供实时价格、性能、数据政策和统一结算。公司正在向自动 model selection 与 orchestration 延伸，execution control 和 enterprise governance 则仍有更靠近应用、云和数据平台的竞争者。开源模型的双刃剑：需求变厚，收入未必同步变好OpenRouter 与 a16z 分析了截至 2025 年 11 月、主要覆盖滚动 13 个月的约 100 万亿 token 平台流量。到观察期末，open-weight 模型约占三分之一；中国开源模型的周度份额曾从 1.2% 升至接近 30%，同时没有单一开源模型能够长期占据超过约 20%–25% 的 open-weight token。2026 年的变化更快。OpenRouter 对 1 月至 6 月约 450 万亿 token 的分析显示，DeepSeek 的份额从约 9%升至 18%，中国模型的 token 份额在 6 月初已经超过美国模型。而且 DeepSeek V4 新增流量主要来自 Agent 工作负载，而非早期的 roleplay 流量。开放模型从“便宜的替代品”进入 coding 和 Agent 生产环境。这是一个持续轮换的候选池，而非新的单一赢家。GLM、Kimi、DeepSeek、Qwen、MiniMax 与垂直模型交替领先，发现、评测、接入和 provider routing 的需求随供给碎片化变厚。Token 量却不等于同等质量的收入：约 52% 的开源 token 来自 roleplay，programming 占 15%–20%；中国开源模型的 programming 加 technology 占比约 39%。这些负载调用频次高、替代选择多，也更在意单位成本。开源越便宜，token 可能越多，GMV 与平台费却未必同速增长。同一组开源权重还能由十几家推理商部署，速度、缓存、量化与数据政策的差异因此更重要，也更贴近 OpenRouter 最强的 provider routing。结论是一把双刃剑：开源越成功，routing 越必要；开源越便宜，router 每个 token 能留下的钱可能越少。采购网络：OpenRouter 卖的首先是 access 与选择权在一个单模型应用里，开发者接入 OpenAI 或 Anthropic 并不困难。问题出现在模型数量从一个变成十个、供应商从一家变成数十家之后：团队要分别开户和充值，维护不同 API 格式、限额与数据政策；模型更新时要重新评测；provider 宕机时要写 retry 和 fallback；财务还要面对一摞不同账单。OpenRouter 把这些工作压成一把 key、一份账单和一个模型字符串。Alex Atallah 对它的长期描述是：S3 让企业采购存储，OpenRouter 想成为采购 intelligence 的地方。这也是它早期能先从 AI-native 客户长出来的原因。这类团队比传统企业更早遇到多模型问题：角色扮演产品需要在不同审核政策之间切换；coding agent 既要调用昂贵模型做架构判断，也要用便宜模型处理机械任务；新模型发布后，产品团队希望当天就能测试，而不是等待一次新的采购与集成周期。我们梳理的一组 2025–2026 年客户与行业访谈显示，OpenRouter 在 AI-native 团队里的典型年 spend 可以从 10 万美元到低七位数。对这类客户，约 5% 的 take rate 在早期通常可以接受，因为少招一名基础设施工程师已经足以覆盖成本。相较之下，受监管的大型企业直接使用 OpenRouter 的金额往往只有几万到 50 万美元以内，并且更多承载非核心流量；核心生产负载仍倾向留在既有云、身份和合规体系中。从中可以看出 OpenRouter 的切入顺序：先赢得需要速度和模型广度的开发者，再补齐企业控制能力。采购智能还有一个常被忽略的供给侧价值：OpenRouter 不只替应用找模型，也替模型实验室找到真实用户。OpenAI 在 GPT-4.1 发布前，曾通过 OpenRouter 以 Quasar Alpha 和 Optimus Alpha 两个匿名模型做 stealth test。OpenRouter 后来公开确认，这两个模型就是 GPT-4.1 的早期版本。对模型公司而言，它获得了不带品牌偏见的真实 workload、偏好与留存信号；对 OpenRouter 而言，新模型首发和匿名测试又进一步强化了开发者“先来这里看”的习惯。这类需求侧数据很难由单一云或单一推理商完整复制。它构成 OpenRouter 比统一接口更深的一层资产：中立分发 + 跨模型真实使用数据 + 多 provider 结算。截至 2026 年，OpenRouter 已加入 Workspaces、spend management、Guardrails、SSO、Zero Data Retention、EU region routing 与 SOC 2 Type 2 合规。这些更新修正了早期“适合实验、不适合组织”的明显短板。它仍不提供 on-premise deployment，公开资料中也没有 HIPAA BAA；对医疗、金融核心负载和必须运行在客户 VPC 内的系统，这仍是必须要解决的问题。谁在付钱：客户呈现出一座不对称金字塔客群呈现出一座不对称金字塔：AI-native 公司是当前 GMV 引擎，enterprise 更像上行期权；spend 也不等于依赖度。 Lovable 有六位数支出却只做 backup，NatWest 交出约三分之一流量，FenxLabs 把高价值 selection logic 留在自己手里。Clado、Nomi 与 Writer 从不同角度给出约 100 万美元的毕业线：当平台费足以覆盖一到两名工程师，直连、自托管或自建 fallback 的经济账开始成立。客户仍会为 discovery、突发容量和多 provider 冗余付费，却可能迁走最稳定、最贵的流量。OpenRouter 最好的客户增长越快，越有能力只留下最难替代、未必最赚钱的部分。Provider Routing：同一个 DeepSeek 可能是 16 种产品我们以 DeepSeek 为例来理解 provider routing 的价值了。2026 年 7 月 13 日，DeepSeek V4 Pro 在 OpenRouter 上由 16 家 provider 提供。根据当日页面，输入价格从约 0.44 美元／百万 token 到 1.74 美元，相差约 4 倍；吞吐从每秒 4 token 到 57 token，相差超过 14 倍；uptime 则从约 97% 到接近 100%。最便宜的 provider 当时恰好有最高 uptime，最慢的一家却仍比最低价贵三倍以上。可以看出，模型权重相同，实际产品体验还取决于运行它的人。OpenRouter 默认会避开刚刚发生明显故障的 provider，并在稳定节点中偏向更便宜的选项；开发者也可以按吞吐或价格排序，设置最高价格，指定或排除 provider，并筛掉不合适的量化版本。请求失败时，系统可以切换 provider；返回零输出的失败请求不收费。对长时间运行的 Agent，这层能力比 Chatbot 更重要。一次对话失败，用户可以再问一遍；一个已经执行十分钟、调用多个工具的 Agent 中途断掉，会产生额外的重试成本、cache miss、延迟和未完成工具调用。公开社区信号也体现了 Provider routing 的重要性。近几个月，OpenRouter 用户讨论最集中的问题大致有几类：这些 failure-mode signal 揭示了一个产品规律：router 创造的价值，来自替用户管理差异；一旦用户为了稳定性把 provider 固定下来，router 的价值就会部分退化为统一计费和接口。Execution Control：最值钱的 Routing 不一定属于 OpenRouterProvider routing 能看到价格、延迟、uptime 和部分工具调用质量，但通常看不到任务最终有没有完成。比如一段代码是否通过测试，一份销售邮件是否获得回复，一个客服 Agent 是否真正解决工单，一次金融分析是否漏掉关键风险，这些最接近业务结果的反馈，往往留在应用、Agent harness 或企业工作流里。这构成 model selection 的信息差。2026 年 6 月发布的论文 _Agent-as-a-Router_ 为这个问题提供了一个很有启发性的实验。研究者在约 1 万个 coding task、8 个 frontier LLM 上测试动态路由。仅仅给普通 router 加入按任务维度统计的历史性能信息，就带来 15.3% 的相对提升；进一步把执行结果放回 Context → Action → Feedback → Context 的循环，router 可以在部署过程中持续学习。在这组 coding benchmark 中，结果支持一个判断：当任务结果可以被验证时，增加历史表现和执行反馈，可能比单纯更换 routing 算法带来更大的提升。这个结论能否外推到客服、金融和复杂 Agent 工作流，仍需更多生产数据验证。OpenRouter 也在这个方向做了一些努力。它从 2025 年起检查全平台 tool call 是否符合调用方 schema；2026 年 3 月上线的 Auto Exacto 结合 throughput、tool-call telemetry 和 benchmark score，大约每五分钟重估 provider，从单纯价格加权走向 quality-aware routing。但 schema 正确只代表工具调用“格式能跑”，并不代表任务做对了。最完整的执行反馈仍在离结果最近的地方。这会让四层 routing 的利润池自然分流：模型选择的价值更靠近应用与 Agent runtime。 它们掌握任务、上下文、测试、用户行为和最终结果，可以针对自己的工作负载学习。provider routing 的价值更靠近中立网络。 OpenRouter 聚合供给、实时观测价格与稳定性，跨客户形成规模数据，单个应用很难复制同样广度。• execution control 会在 gateway 与 harness 之间竞争。retry、fallback 和计费适合 gateway；长任务状态、工具权限和 verifier 更贴近 Agent runtime。enterprise governance 更靠近已有控制面。 身份、数据目录、审计、DLP 和采购已经存在于 AWS、Azure、Google Cloud、Cloudflare、Databricks、Snowflake 或企业 API 管理体系中。模型只是新的受控资源。因此，OpenRouter 面对的核心竞争是离客户入口或结果更近的平台。竞争地图：谁离控制点更近？OpenRouter 需要开发者主动增加一个外部中间层：应用先把请求发送给 OpenRouter，再由 OpenRouter 选择模型和 provider。Vercel、Cloudflare 和 LiteLLM 的优势来自不同的位置。不同竞争者靠近的是不同控制点：Vercel 靠近应用代码，Cloudflare 靠近网络请求和安全策略，AWS 与 Databricks 靠近企业身份和数据，Agent runtime 靠近最终任务结果。OpenRouter 靠近的，则是最碎片化的模型与 provider 供给。这就是前文所说的“毕业问题”：客户规模化后，可能把稳定、高频流量迁往直连或自建，只保留 discovery、fallback 和 burst capacity。OpenRouter 的结构性防线也因此更清楚：它必须保住中立。单一推理商无法同时分发 GPT、Claude、Gemini 与所有开源模型；单一云也很难让客户相信它会持续给竞争云和竞争模型同等优先级。中立性让 OpenRouter 更像模型市场的交换层，也缩小了潜在战略买家的范围。被某家模型公司或云收购，反而可能破坏网络价值。这会影响 OpenRouter 的客户结构。流量较小时，5%左右的平台费只是购买便利：团队不需要分别开户、管理余额、编写 fallback，也能快速测试新模型。随着推理支出接近百万美元级，平台费、缓存损失、provider 直签折扣和延迟差异都会成为可见的成本项目，AI-native 团队会开始重新评估流量分配。常见的情况是：团队把稳定、高频的生产流量直连 provider，同时继续用 OpenRouter 做新模型 discovery、故障 fallback 和突发容量。OpenRouter 的毕业问题：它最好的客户增长越快，越可能把主流量移出平台，只把最碎片化、最波动的流量留给 OpenRouter。这是 Openrouter 商业模式的挑战：OpenRouter 能否在客户规模化以后继续保留高价值生产流量，而不只是成为备用通道。OpenRouter 正在向上走Atallah 在早期访谈里曾明确解释，OpenRouter 最初没有替生产客户做跨模型的自动选择：开发者希望保留模型控制权，不同模型的行为差异又难以预测。公司先把更可观测、也更容易建立网络效应的 provider routing 做深。2026 年 6 月连续发布的 Advisor、Subagent 与 Fusion，说明公司正在重新进入更高一层。Advisor 允许便宜模型在生成过程中遇到困难时临时咨询更强模型；