一把 Key 同时调 Claude / GPT / Gemini / Grok:多模型网关实战

四个模型族,一把 Key,一个 base_url。把生产流量跑在统一网关上,会得到什么、放弃什么 —— 这篇讲的是工程上的真实账。

2026-05-22 · 阅读约 12 分钟 · 适合多模型 API 用户

用 LLM 做产品的团队,最后基本都会用上不止一家模型。一开始 Claude 跑长推理,后来加 GPT-5 做日常对话,接着上 Gemini 处理超长上下文,再补一个 Grok 应对时效性强的问题。每加一个看上去都没什么。直到某个周二晚上,你停下来盘点技术栈,才发现自己同时在维护四套 SDK、四个账单账户、四种凭据轮换、四份限流监控,以及四种"为什么半夜又 401 了"的排查路径。

这篇讲的是另一种活法:把所有模型族的访问统一收到一个网关后面。下面用 Python 代码走通流式、Tool Use、模型路由,顺便把"什么时候不该用网关"讲清楚。

1. 多上游集成的真实成本

开发者经常低估多上游集成的长期成本,因为单家 API 的牌价确实不贵。真正的成本藏在别处。

认知负担。每家 SDK 的形状都不一样。Anthropic 用 messages.create,system 是顶级参数,content 是带类型的对象数组;OpenAI 用 chat.completions.create,system 是消息列表里第一条扁平消息;Gemini 暴露 generateContent,contents 和 tools 的嵌套方式又不一样。Tool Use 的 schema、finish reason、流式事件类型,甚至 temperature 的语义都不完全对齐。一个任务里来回切上游,需要切的不只是代码,还有脑子里的模型。

运维开销。每家上游都要单独开账户、过身份验证、配支付方式、建组织和项目层级,然后是一整套独立的 API Key 加各自的轮换计划。再乘上环境数(dev / staging / prod)和 monorepo 里的服务数,就是一摊不大但持续存在、却没人真正负责的运维面。

财务摩擦。卡被风控、跨境收单被反欺诈拦下、消费上限静默触发是常事。不同上游的账单周期、币种、结算节奏都不同,季度末对账常常变成一个小型财务项目。

合规和审计。安全评审问"哪些数据流向了哪些第三方"的时候,答案得把所有接入过的上游列清楚,而不是只列用得最多的那家。每一家都是供应商风险表里的一行。

这些都不构成"必须用更差的模型"的理由。但它们是"把访问层这种无聊的部分统一掉"的理由 —— 这样模型选型才能保持自由。

2. 统一网关解决了什么

BUZZ AI Gateway 把 Anthropic Claude、OpenAI GPT、Google Gemini、xAI Grok 收在同一个 HTTPS endpoint 和同一把 API Key 后面。承诺是刻意收窄的:

• 透明转发。请求体和响应体一字节不动透传。不改写 system prompt、不注入指令、不偷换便宜模型、不缓冲流式响应。你写 claude-opus-4-8,跑的就是 claude-opus-4-8。
• 零数据留存。prompt 和 completion 不写入磁盘、不进数据库、不进日志。只保留 token 计数、模型 ID 这类计费元数据。payload 不落地,自然也无从泄漏。
• SDK 兼容。Anthropic 和 OpenAI 官方 SDK 不用改代码,只换 base_url。已有的重试、流式、Tool Use 逻辑继续工作。
• 统一计费。一份账本、一张发票、一个预付余额覆盖四个模型族。单模型费率公开在 buzzai.cc/api/pricing,显著低于上游一手价。
• 切换零成本。从 claude-opus-4-8 切到 gpt-5.4 再切到 Gemini 长上下文模型,只是改一个参数,不是改一次架构。

具体到接入,只需要把客户端指向下面两个 endpoint 之一,看你想保留哪套 SDK:

整个集成就这两行。下面所有内容都是这两行落地之后能做的事。

3. 实操:同一份代码跑三家模型

从 OpenAI SDK 开始,因为大多数团队已经装了。同一个 client 对象就能调到 GPT、Claude、Gemini,不同请求之间唯一变的就是 model。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["BUZZ_API_KEY"],
    base_url="https://buzzai.cc/v1",
)

def ask(model: str, question: str) -> str:
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "You are a precise technical assistant."},
            {"role": "user", "content": question},
        ],
        max_tokens=400,
    )
    return resp.choices[0].message.content

print(ask("claude-opus-4-8",  "Outline a fault-tolerant job queue."))
print(ask("gpt-5.4",           "Outline a fault-tolerant job queue."))
print(ask("gemini-2.5-pro",    "Outline a fault-tolerant job queue."))
print(ask("grok-4",            "Outline a fault-tolerant job queue."))

四家上游、四个回答、一个 client、一份账单。没有重复初始化、没有第二套 SDK、没有第二把 Key 进 secrets manager。

3.1 流式

流式是检验代理是否"虚假"的一道硬考题 —— 一个偷偷缓冲后再吐出来的"流式"完全失去了意义。BUZZ 在收到上游 SSE chunk 的瞬间转发给客户端,逐 token UI 体验和直连官方 API 一致。

stream = client.chat.completions.create(
    model="gpt-5.4",
    messages=[{"role": "user", "content": "Explain CRDTs in three paragraphs."}],
    stream=True,
)

for event in stream:
    delta = event.choices[0].delta.content or ""
    print(delta, end="", flush=True)

同样的代码换成 claude-sonnet-4-6、gemini-2.5-pro 或任意 Grok 模型都能跑。如果你更喜欢 Anthropic 原生流式协议,把 Anthropic SDK 的 baseURL 指到 https://buzzai.cc,继续用 messages.stream 就行。

3.2 Tool Use / Function Calling

Tool Use 通常是漏抽象代理翻车的地方。BUZZ 不做跨上游归一化,这是有意的。调 Claude 拿到 Anthropic 形状的 tool blocks,调 GPT 拿到 OpenAI 形状的 function calls,各上游的 spec 一字不动保留。

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather for a city.",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

resp = client.chat.completions.create(
    model="gpt-5.1-codex",
    messages=[{"role": "user", "content": "Should I bring an umbrella in Tokyo?"}],
    tools=tools,
)

call = resp.choices[0].message.tool_calls[0]
print(call.function.name, call.function.arguments)

如果要走 Anthropic 风格的 tool 调用调 Claude,换成 Anthropic SDK 加 base_url="https://buzzai.cc",用标准的 tools=[{"name": "...", "input_schema": {...}}] 即可。两种格式网关都原样转发。

3.3 Claude Code 一行命令接入

常驻 Claude Code 的话,最快的接入方式是安装脚本:

curl -fsSL https://buzzai.cc/sh/claudecode.sh | sh

脚本会写好环境变量和 base URL,让 claude 用你的 BUZZ key 走网关。脚本源码:buzzai.cc/sh/claudecode.sh。

4. 按任务挑模型

同时挂多家模型不是为了花式秀,是为了"对症下药"。把模型名当成运行时参数,按任务路由。下面这张默认映射可以当起点,真正的选型应该放进配置文件,而不是写死在业务代码里。

完整的支持模型 ID 实时清单看 buzzai.cc/models。上面这张表是经验起点,不是 benchmark 结论。锁定默认模型前,自己拿自己的数据跑一轮 eval。

5. 什么时候不要用多模型网关

网关是一个工具,不是万能解。下面几种情况,直连更合适:

• 你只用一家上游。如果路线图就是"GPT-5 一条道走到底"或"只用 Claude",中间这一跳就是多余的。直连就好。
• 你对单跳延迟极度敏感。任何代理都会加一跳网络。绝大多数业务里这点延迟被 token 生成时间吃掉了,但如果你在死磕每毫秒 TTFT,直连就是直连。
• 你和上游签了带量企业合同。如果你公司已经拿到承诺用量额度、数据处理附加协议或量价折扣,这份合同可能已经比任何网关价更香,而且也限制了数据能流向哪里。
• 有合规边界网关无法满足。如果监管要求数据"必须由 X 厂商在 Y 范围内终结",那就尊重这个边界。网关改不了监管的边界。
• 你的应用绑了某个上游独家、网关还没暴露的特性(比如刚发布的 beta endpoint),临时直连可能更省事。

如果你的场景是"在做产品,要在多家模型族之间比较和路由,不想再做 API Key 管家",网关就是答案。如果是上面那几种情况,直连才是诚实的答案。

6. 你不需要放弃的东西

用网关有时候被描述成"用便利换信任"的取舍。BUZZ 这边,信任相关的几个问题答案都很短:

• 我的 prompt 会被拿去训练吗?不会。不存,自然不会。
• 我的 system prompt 会被改写吗?不会。转发器不动 body。
• 会不会偷偷把我请求的模型换成别的?不会。claude-opus-4-8 就是 claude-opus-4-8。
• 流式会被缓冲吗?不会。SSE 来一个 chunk 就转一个。
• tool 调用形状会被归一化吗?不会。原样保留上游的格式。

原则就一句:少做点事。一个少做事的网关,出错少、惊喜也少。

7. 一个完整的小例子:在同一个应用里路由

下面是一个偏真实的小模式。应用有三类任务:收件箱前面挡一层快速分类、用平衡型模型起草回复、长文档让深度推理模型 review。三种工作、三个模型族、一个 client。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["BUZZ_API_KEY"],
    base_url="https://buzzai.cc/v1",
)

ROUTES = {
    "classify":  "claude-haiku-4-5",      # 便宜、快、量大
    "draft":     "gpt-5.4",               # 平衡型日常对话
    "review":    "claude-opus-4-8",       # 深度推理
    "long_doc":  "gemini-2.5-pro",        # 超长上下文
    "fresh":     "grok-4",                # 时效敏感
}

def run(task: str, prompt: str, max_tokens: int = 800) -> str:
    model = ROUTES[task]
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=max_tokens,
    )
    return resp.choices[0].message.content

两个值得点出来的特性。第一,加第六类任务就是加一个字典条目,不是装新 SDK。第二,下个季度 eval 说 claude-sonnet-4-6 在 draft 任务上比 gpt-5.4 强,那也只是 ROUTES 里改一行的事,业务代码动都不用动。

同样的思路用 TypeScript 配 OpenAI Node SDK、Go 配任意 OpenAI 兼容客户端,或者直接 fetch 都能跑。线协议才是契约,客户端只是顺手。

8. 一份精简的生产清单

1. BUZZ_API_KEY 放 secret manager,不进 repo。
2. base_url 集中在一份配置里:OpenAI SDK 用 https://buzzai.cc/v1,Anthropic SDK 用 https://buzzai.cc。
3. model 写成配置项,按任务类别路由,不要写常量。
4. 客户端侧设单次调用超时和有界重试 —— 网关不会替你重试。
5. 从响应体里取 token usage,按 model 和 task class 聚合。这数据决定下次要不要换更便宜的模型。
6. 大量调用场景优先用流式,这样可以在结构化停止条件命中时提前掐断生成。
7. 每个季度复盘一次默认模型选型。前沿一直在动,你的配置也要跟着动。

9. 常见问题 FAQ

10. 总结

多模型网关不是什么魔法。它就是一块小而无聊的基础设施,把 LLM 集成里"本来就该商品化"的部分 —— 访问、计费、Key 管理 —— 真的商品化掉。剩下的部分 —— 模型选型、prompt 设计、eval —— 都还在你手里,本来也该在你手里。

如果生产里已经在跑两家或更多模型族,问题已经不是"要不要把访问层统一",而是"要不要继续每个季度都为 N 套集成付一遍税"。如果只跑一家,那就把网关当作一份 optionality:不用花成本,但下一家模型上线那天就立刻可用。

从 buzzai.cc 开始,实时费率看 buzzai.cc/api/pricing,完整模型清单看 buzzai.cc/models。