模型能随便切，路由商反而更难切

每天 10 万亿以上 token。

400 多个模型，80 多家模型提供商，超过 1000 万开发者和企业。

现在，这条横跨模型、价格、延迟和可用性的路由层，要进入 Stripe 了。

OpenRouter 在官方公告里确认将加入 Stripe，Stripe 也发布了收购确认。交易仍需满足惯例成交条件，预计未来数周完成。官方没有披露价格，媒体爱聊的那个数字先放一边。

我更在意公告里的另一组排比。

使命不变，名字不变，产品不变，路线图不变。现有集成不变，路由仍然以用户利益为准。

这当然是一份很重要的承诺。可对一个把 OpenRouter 放进生产链路的团队来说，承诺不是验收项，接口、账单、故障和数据流向才是。

好家伙，模型路由原本是为了降低模型锁定。走到今天，它自己已经长成了一层值得被收购的关键基础设施。

模型确实更容易切了。

路由商呢？

OpenRouter 官方发布的联名图，两个基础设施平台正式走到了一起。

收购公告里，最重的不是 10 万亿

很多朋友可能会把 OpenRouter 理解成一张模型菜单。一个 API key，一套接近 OpenAI 的接口，后面挂着 Claude、Gemini、DeepSeek、Llama 和一大堆新模型。今天想省钱就换便宜的，明天要效果就换旗舰的，哪个 provider 挂了就让系统自动找下一家。

这只是它露在水面上的部分。

OpenRouter 的官方路由文档已经把选择条件铺得很细。你可以指定 provider 顺序、允许或禁止失败回退、要求参数完整支持、限制数据收集、只走零数据留存端点，还能按价格、吞吐和延迟排序。吞吐与延迟甚至可以按最近五分钟的 p50、p90、p99 来筛。

模型选择只是一个字段，真正复杂的是那张实时变化的矩阵。

同一个模型可能由不同 provider 提供。它们的价格、首 token 延迟、每秒输出速度、限流、量化版本、上下文长度和数据策略都不同。缓存命中时，最佳路线可能是 A。A 抖了一下，下一次请求就去了 B。B 不支持你传的某个参数，又得去 C。

然后账单也跟着走。

OpenRouter 的费用说明写得很直白，平台按请求最终消耗的 token 和实际模型价格扣减余额，底层推理价格不加价，购买 credits 时收取费用。它的模型失败切换也会因为限流、宕机、上下文长度错误或内容过滤切到下一个模型，费用按最终真正执行的模型计算。

到这里，路由已经不是一个简单的反向代理了。

它同时掌握模型目录、provider 状态、策略选择、故障切换、用量计量、成本结算和调用分析。请求往哪里走，花多少钱，失败后换谁，最终在报表里长什么样，越来越像同一套控制系统里的不同模块。

Stripe 看中的恰好也是这一层。双方今年 1 月公布的合作已经把路径写出来了，OpenRouter 负责路由模型请求，Stripe 追踪用量、应用价格并处理计费。如今 Stripe 的说法更直接，它希望把收入优化与 token 成本优化放到一起。

支付基础设施和模型路由器看起来隔着两个行业，代码一摊开却很像。

支付系统在回答，走哪条支付通道，授权成功率更高，欺诈风险更低，成本更合适。

模型路由在回答，这个任务该走哪个模型、哪个 provider，质量够不够，延迟能不能接受，价格有没有越线。

都是在一堆动态约束里，替每一笔请求找一条能成交的路。

有点子牛逼，也有点需要警惕。

当路由、计量与失败切换进入同一层，方便与控制面依赖会一起增长。

模型切得动，不等于路由商切得动

统一 API 很容易给人一种自由感。配置里把 model 从一个名字改成另一个名字，服务照跑，于是团队觉得自己已经摆脱了模型锁定。

可生产系统真正依赖的，往往不是 model 那一行。

它依赖你在平台控制台里排好的 provider 顺序，依赖平台替你维护的价格表，依赖余额和月度预算，依赖失败时自动尝试的下一条路线，依赖 Activity 页面里的调用记录，也依赖平台对各个端点数据策略的判断。

假设一个常见架构，应用只保存了 OpenRouter API key。provider 偏好配在网页里，成本分析看平台报表，告警引用平台返回的错误码，隐私要求靠账户里的 ZDR 开关。平时很省事，厉害了，一个人就能管 400 多个模型。

可当团队真想迁移，才会发现自己只有业务代码，没有完整策略。

你知道主模型是谁，却不一定保存了实际 provider 的选择规则。你知道这个月花了多少钱，却不一定能把一次用户请求、一次模型回退和最终成本对到同一条 trace。你知道开启了零数据留存，却不一定留有当时哪些端点符合要求的策略快照。

甚至同一个 model 名字，在不同时间也可能不是同一条推理链路。

这不是 OpenRouter 独有的问题，也不能因为一桩交易就推断平台会立刻改价格、改中立策略或偏向某些模型。官方已经明确承诺不会这么做。把没有发生的事写成结论，不严谨，也没啥用。

真正的问题更朴素。

任何替你吞掉复杂度的平台，都会逐渐保存一部分原本属于你的系统状态。平台越好用，这部分状态越容易只存在它那里。

所以我自己的判断是，Stripe 收购 OpenRouter 并没有让多模型路线失效，反而把一件事照得更亮了。

别只做模型可替换。

把路由控制面也做成可替换。

真正可迁移的控制面长什么样

这里不需要再造一个 OpenRouter。大多数团队也不该自己维护 80 多家 provider 的实时价格和健康度，那会把一个产品团队活活写成基础设施公司。

你真正需要保留的，是最小但完整的策略所有权。

可以先把业务对模型的要求收敛成一份与平台无关的配置。名字随便起，字段要能说清楚意图，而不是照抄某一家接口。

task: code_review
models:
  - frontier_coding
  - balanced_coding
limits:
  max_cost_usd: 0.18
  max_p90_latency_ms: 8000
privacy:
  zero_data_retention: true
fallback:
  cross_provider: true
  cross_model: true

frontier_coding 不是某个固定模型，而是你自己的能力别名。今天它可以映射到 OpenRouter 上的模型列表，明天也可以映射到 OpenAI、Anthropic 或 Google 的直连端点。业务代码只表达需要什么，适配层再决定去哪里拿。

这层薄薄的映射很值钱。

它让产品逻辑不用认识 OpenRouter 的 provider 字段，也不用认识另一家网关的 deployment 名字。更重要的是，映射文件要进 Git，跟代码一起 review、留历史、能回滚。不要让生产路由策略只活在某个控制台的下拉框里。

然后是成本账。

平台账单可以继续用，而且应该用。人家对 400 多个模型的计价维护，比你手搓一张表靠谱得多。但团队自己的 trace 里，至少要留下请求 ID、业务任务、请求模型、实际返回模型、provider、输入与输出 token、缓存 token、延迟、重试次数和平台返回成本。

不是为了跟平台对账抬杠，而是为了回答三个生产问题。

这笔钱是谁花的，这次回退为什么发生，换路由后质量和成本到底变好了没有。

如果这三问只能打开供应商后台回答，你拥有的是访问权，不是可观测能力。

数据策略也一样。OpenRouter 的数据收集说明称，默认不保存 prompt 与响应内容，但会保存 token 数量、延迟等请求元数据。平台还提供零数据留存路由，能把请求限制到符合 ZDR 要求的端点。

这些功能很好用，别因为担心锁定就反着把安全能力关掉。

但你需要在自己的审计记录里保存策略意图。某类任务要求 ZDR，某类任务禁止 provider 收集数据，某类任务不允许跨区域。平台负责执行，你负责记住自己当时要求它执行什么。

责任不能也一起路由出去。

可迁移，不是把所有 SDK 再接一遍

聊到供应商锁定，很容易走到另一个极端。

团队拉一个新仓库，把 OpenAI、Anthropic、Google、DeepSeek 的 SDK 全装上，写四套鉴权，抹平四种流式响应，再维护一张价格表。三周后模型接口更新，某家多了 reasoning 字段，某家工具调用格式换了，抽象层开始长出一排 if provider ==。

不是哥们，这条路很快就会把自己写成另一个不太好用的 OpenRouter。

可迁移的目标不是随时在本地复刻整个模型市场，而是让关键业务不依赖某一家平台才能解释、运行和验收。

适配器可以很薄，只统一团队真的用到的能力。文本生成、流式输出、工具调用、结构化结果，也许再加一个多模态输入。某个 provider 的独有能力不要硬塞进最低公分母，明确挂在扩展字段里，并给调用方一个能力检测。

type RouteResult = {
  requestedModel: string
  servedModel: string
  provider: string
  inputTokens: number
  outputTokens: number
  cachedTokens?: number
  costUsd?: number
  latencyMs: number
  attempts: RouteAttempt[]
}

这份返回结构比请求结构还重要。请求只表达一次愿望，返回才记录系统刚刚做了什么。没有 servedModel 和 provider，模型回退发生后，评测会把结果算到错误对象头上。没有 attempts，一次成功响应背后的两次限流和一次超时会从监控里消失。没有平台成本与自算成本的双份记录，账单异常只能靠月底猜。

然后给适配器准备一组很小的合同测试。

不需要追求跑分榜。挑二三十条最贴近业务的固定请求，覆盖工具调用、长上下文、结构化输出、超时和内容过滤。每次改路由策略或切换网关，都验证返回格式、关键字段、错误分类和成本上限没有飘。测试数据里别放客户隐私，省得迁移演练先制造一个合规事故。

模型质量本来就有随机性，合同测试也不该要求每个字完全一致。它验的是系统边界，能不能返回合法 JSON，工具参数是否完整，超时有没有在预算内结束，失败后是否去了允许的备选模型，ZDR 要求有没有被保留。

这套东西平时看着很薄，真到平台变更时却特别顶用。

你不用在公告发布当天判断 Stripe 会不会改变 OpenRouter。只要定期拿同一组请求看路由分布、实际 provider、单位任务成本和失败率，就能观察承诺有没有落到运行结果里。

中立不是一句只能相信或不信的口号。

它可以被持续验收。

还要给这层策略一个明确的负责人。不是让某个人背锅，而是避免模型选择散落在产品、后端、财务和安全四个群里。新增模型谁批准，价格涨到什么程度自动降级，质量下降由哪组评测触发回滚，数据策略变化要通知谁，都应该在同一份运行手册里找到答案。

密钥也别混成一团。日常网关 key、BYOK provider key 和紧急直连 key 分开保存，权限与额度分别设置。逃生通道如果和主链路共用同一个余额、同一个组织管理员或同一份会被一起轮换的密钥，它看着是备份，事故来时大概率会陪主链路一起躺下。

再给迁移演练记一个恢复时间。十分钟能切还是两小时能切，对业务决策完全不同。没有计时的预案通常只是一篇让人心安的文档。真正跑过一次，团队才知道缺的是 DNS、环境变量、SDK 兼容，还是某个只有原平台才返回的隐藏字段。

这些工作不性感，也不会出现在收购公告里。可平台关系变化时，能让团队睡得着的往往就是这些小事。

故障切换要有一条平台外的路

路由商最大的价值之一就是提高可用性。provider A 限流了去 B，模型 X 挂了去 Y，应用不用挨个处理。用过一次就很难回到每家 SDK 自己接的日子，确实省命。

可这里有一个经典的可靠性问题。

如果所有后备路线都经过同一个网关，那是多 provider，不是多故障域。

OpenRouter 支持 BYOK，也就是带上自己的 provider key，让请求仍通过统一接口，但优先消耗自己的直连额度。这能减少账户与额度层面的绑定，不过请求路径依旧经过同一网关。

对普通内容生成，网关故障时等几分钟通常没事。对客服回复、代码发布门禁、实时风控或生产告警摘要，几分钟可能已经够群里刷满红字。

所以关键业务最好留一条极窄的直连逃生通道。

不用覆盖所有模型，也不用追求和平时完全一致。选一个能力足够、合同清楚、配额独立的 provider，只支持最关键的任务。定期用测试流量跑一下，确认密钥没过期、SDK 没坏、返回格式还能接住。

平时 99% 的流量继续走 OpenRouter，享受它的模型覆盖、动态路由和统一账单。极端情况下，剩下 1% 能绕开平台独立完成。

这不是唱衰谁，是基础设施最普通的礼貌。

数据库要备份，DNS 要有预案，消息队列要测积压恢复。模型网关已经重要到每天穿过 10 万亿 token，也该得到同等级别的故障演练。

平台可以照亮多条航道，关键业务仍要留一条能独立抵达的路线。

不必连夜搬家，先演练一次撤退

收购消息出来后，最省脑子的反应有两种。

一种是宣布天塌了，马上迁走。

另一种是看见官方写了「一切不变」，然后把这件事从待办里删掉。

我觉得都太快。

OpenRouter 与 Stripe 的组合很可能会让路由、计费、反欺诈和企业采购变得更顺。Stripe 官方披露，OpenRouter 已经服务 NVIDIA、Zoom 和 Lovable 这类客户。对小团队而言，更稳定的基础设施、更完整的用量计费与更多企业能力，都是实打实的好处。

同时，平台越强，越应该把边界画清楚。

找一个非高峰时段，做一次纸面迁移演练就行。假设 OpenRouter 暂停两小时，你能不能指出关键任务该走哪个直连端点。假设 Activity 页面暂时不可用，你自己的日志能不能算出当天成本。假设某个 provider 的数据政策变化，你能不能找出受影响的任务。假设要换另一家网关，你的路由意图是否能从 Git 里的配置重新生成。

能回答，继续安心用。

答不上来，也不必慌，把缺的那一小层补起来。

很多基础设施收购，真正改变系统的并不是公告当天，而是之后一年里悄悄增加的默认值。新的计费入口，新的企业套餐，新的路由选项，新的控制台开关。每一项单看都合理，叠起来才会慢慢改变迁移成本。

模型的未来大概率真是多模型的。OpenRouter 对这一点的判断，我认同。

但多模型不是终点。

真正的选择自由，是模型、provider 和路由层里任何一个环节变化时，你都知道状态在哪，账怎么算，数据往哪走，也留着一条能离开的路。

灯塔可以替你照亮航道。

罗盘，还是放在自己船上。