模型定价文档关于
登录[ 获取 API Key ]
cd ../返回博客
$Guide//2026年6月4日//7 min read

从 OpenRouter 迁移到第一方级网关：一次诚实的取舍

OpenRouter 胜在广度，第一方级网关胜在保真度。看清各自适合什么，以及只需两行 diff 的迁移做法。

先从公道话说起：OpenRouter 是广度上的领跑者。一个 key、一个 base URL， 你就能触达 300+ 个模型 —— 包括任何第一方 API 都不会开放的开源长尾 （Llama、Qwen、DeepSeek、Mistral，以及几十种社区微调版）。如果你的活儿 是横向评测一大批模型、在多家供应商之间绕开宕机，或是要够到某个冷门的 开源权重模型，那份目录就是一种实打实、难以复制的优势。这篇文章不是 来唱衰它的。

它是一篇各自适合什么的指南。还有另一类活儿 —— 你要的是货真价实的第一方 旗舰模型，原生特性原封不动、计费能逐 token 审计、图像和视频共用一个 key， 外加一个小到可信的按模型折扣。这种时候，团队会在 OpenRouter 之外再接上一个 像 Brievio 这样的第一方级网关，或者干脆把生产链路整个迁过去。迁移本身只是 一行 base_url 的改动，外加把模型 slug 重命名一下。下面就把这个诚实的取舍和具体做法讲清楚。

什么时候该选 OpenRouter

动手改任何东西之前，先把这点看明白。在以下情形里，OpenRouter 是更合适的 那一个：

  • 你需要开源长尾。Llama、Qwen、DeepSeek、Mistral 以及 社区微调版都不在任何第一方 API 上。如果你的路线图会碰到开源权重模型， 那份目录就是你要的。
  • 你在跑一场大范围评测。横跨五家供应商比较二十个模型， 正是一个 300 模型聚合器的拿手好戏。一个 key、一套结构、所有模型。
  • 你想把跨供应商故障转移当成一项功能。 对某个模型，OpenRouter 能在上游多家供应商之间回退。对某些可用性诉求 来说，这种路由广度正是关键所在。
  • 你在为某个开源模型货比三家、找最便宜的托管方。这个市场会把同一模型的多家供应商都摆出来，让你按价格排序。这是一个 实实在在的杠杆。

接上 Brievio 并不会让上面这些消失。很多团队会专门为这些活儿留着 OpenRouter，只把第一方的生产流量指到别处。两个 base URL，一套代码库。

什么时候第一方级网关更合适

要切换（或拆分流量）的理由更窄、更具体。当下面这些事要紧时，再考虑它：

  • 你需要货真价实的第一方模型，原生特性原封不动。不是 微调版，也不是「近似等价」—— 而是真正的 Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 和 Gemini 2.5 Pro / Flash，原生工具调用、视觉、提示缓存都 按供应商文档所写的那样工作。当一款旗舰模型的行为本身就是你的产品时， 「差不多就行」是不够的。
  • 你想要能审计的诚实 token 计费。你的真实成本是 单价 × token 数，而 token 数恰恰是最容易被灌水的那个数字。Brievio 上报货真价实的第一方 token 数，并照实计费。如果你从没查过，这有一段 二十行的自测。
  • 你想让图像和视频共用一个 key。Nano Banana 和 Nano Banana Pro、GPT-Image-2、Veo 3 都藏在与你的对话模型相同的凭证、 相同的 OpenAI 结构客户端之后 —— 不用第二个供应商账号，也没有另一处 计费入口。
  • 你想要一个小到可信的折扣。 对话模型大约比官方目录价低 15%，图像和视频大约低 37.5%，每个模型都对照官方参考费率公开列出， 让你能审计这道价差。一个不大、说得清的折扣，是建立在走量上的利润 —— 而不是一笔得在你看不见的地方再补回来的补贴。
  • 失败的调用不收费。4xx 和 5xx 响应不计费，所以上游 某天状态不佳，也不会悄悄变成你账单上的一行。

迁移：一个 base_url，一个 key

因为两个网关都实现了 OpenAI Chat Completions API，这次切换是你代码库里 最小的那个 diff。你把 SDK 指向一个新主机，再换掉 key。流式、函数调用、 JSON 模式，还有你的请求结构，统统不动：

swap_base_url.py
# 从 OpenRouter 迁走只是两行 diff：换掉 base_url，换掉 key。
# 其余一切 —— OpenAI SDK、你的请求结构、流式、工具调用 ——
# 完全不动，因为两边说的都是 OpenAI Chat Completions API。

from openai import OpenAI

# --- 之前：OpenRouter ---
client = OpenAI(
    api_key="sk-or-...",
    base_url="https://openrouter.ai/api/v1",
)

# --- 之后：Brievio ---
client = OpenAI(
    api_key="sk-brievio-...",
    base_url="https://api.brievio.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",                 # 模型名映射见下文
    messages=[{"role": "user", "content": "Summarize this contract clause…"}],
)

如果你当初就是从官方 OpenAI SDK 转到 OpenRouter 的，这会很眼熟 —— 和我们那篇 十分钟从 OpenAI 迁移是同一个动作，只是换了个出发点。不用换新 SDK，也不用重写你的调用点。

你唯一要改的东西：模型 slug

这里是唯一一处值得花几分钟当心的行为差异。OpenRouter 把每个模型都按 vendor/model 加命名空间 —— anthropic/claude-sonnet-4.6、 google/gemini-2.5-flash —— 因为在跨众多供应商的 300+ 个模型里， 加命名空间能避免撞名。Brievio 提供的是一套精选的第一方模型集，所以 slug 是直白的： claude-sonnet-4-6、gemini-2.5-flash。没有 vendor/ 前缀。

model_mapping.py
# 你唯一真正要动的东西：模型 slug。
# OpenRouter 把每个模型都按 "vendor/model" 加命名空间，这样来自众多供应商的
# 300+ 个模型才不会撞名。Brievio 提供的是一套精选的第一方模型集，
# 所以 slug 是直白的 —— 没有 "vendor/" 前缀。

MODEL_MAP = {
    # OpenRouter slug                ->  Brievio slug
    "anthropic/claude-opus-4.7":         "claude-opus-4-7",
    "anthropic/claude-sonnet-4.6":       "claude-sonnet-4-6",
    "anthropic/claude-haiku-4.5":        "claude-haiku-4-5",
    "google/gemini-2.5-pro":             "gemini-2.5-pro",
    "google/gemini-2.5-flash":           "gemini-2.5-flash",
    # 图像 + 视频就在同一个 key 上 —— 不用再开一个供应商账号：
    # "nano-banana", "nano-banana-pro", "gpt-image-2", "veo-3"
}

def to_brievio(slug: str) -> str:
    return MODEL_MAP.get(slug, slug.split("/")[-1])

# 给 Claude/Gemini 用的实用捷径：去掉前缀，把版本号里的点改成横杠。
# "anthropic/claude-sonnet-4.6" -> "claude-sonnet-4-6"。每一个都对照 /models
# 核一遍，让打错字时当场大声报错，而不是悄悄路由到错误的地方。

对 Claude 和 Gemini，规则是机械化的：去掉前缀，把版本号里的点写成横杠 （4.6 → 4-6）。别盲目地做字符串拼改，而是留一个 小小的映射字典，并把每个 slug 都对照 模型列表核一遍，这样打错字会在启动时当场大声 报错，而不是悄悄路由到错误的地方。这是这次迁移真正需要做的唯一一次 查找替换。

务实的上线节奏

你不必一次性全部切换。风险最低的路径是把这两个网关当成互补关系：

  • 让它们并行跑。把 OpenRouter 继续指向开源长尾和你的 评测装置。再把 Brievio 作为第二个客户端，接到你生产链路里的第一方 旗舰模型上。两个 base URL，一个仓库。
  • 切换前先做影子流量。把一部分线上流量镜像到 Brievio， 对比响应和 usage 对象。你要核的是：模型确实是货真价实的第一方那一个， 而且 token 数和你的预期对得上 —— token 自测 正是这道核对，只是自动化了。
  • 先把多模态的活儿迁过去。如果你今天还在把一个单独的 图像或视频供应商东拼西凑地接起来，那么把 Nano Banana / GPT-Image-2 / Veo 3 整合到一个 key 上，往往是最干净利落的早期收益 —— 更少账号、 一份账单、一条鉴权路径。
  • 等到 diff 变得平淡无奇时再扶正。一旦影子流量对得上、 数字也能对账，就把生产默认切过去。万一出现意外，回退一个 base_url 就能滚回去。

诚实的结论

OpenRouter 和第一方级网关其实并不是在争同一份活儿。OpenRouter 为触达面而优化 —— 一个 key 之下最广的目录和开源长尾，这是一件 实在而有价值的事。Brievio 则为精选集上的保真度而优化 —— 货真价实的第一方旗舰模型、原生特性原封不动、诚实可审计的 token 计费、 图像和视频共用一个 key，外加一个小到可信的按模型折扣。两者都藏在同一个 OpenAI 兼容的 base_url 之后，这恰恰就是为什么这么多团队 两个都用：需要广度的地方用广度，紧要的地方用保真度。

如果你要的是货真价实的第一方模型、它们原生的行为，外加你能亲自核验的 计费，那么这次迁移要花的只是一个 base_url、一个 key， 和一次模型 slug 重命名。去看 Brievio vs OpenRouter的逐项对照， 在模型列表上浏览确切的模型和 slug，并在把真实 流量放到任何一边之前，先对两边都跑一遍 token 自测。无论 你最后选哪一边，这个决定都经得起推敲 —— 而经得起推敲，才是唯一值得 发布的那种决定。

$ ls ./related