一个 Key 调 12 个模型：多模型 API 统一接入的实测记录

最近三个月我在做一个 AI 内容管线，需要同时调用文本、图像、视频三类模型。踩的坑比写的代码多，这篇把过程记下来，尤其是「多家 API 怎么统一管」这件事。

为什么会走到「统一接入」这一步

一开始我是老实做法：每家单独接。

到第五家的时候项目变成这样：

• 4 套鉴权方式（Bearer、AK/SK 签名、query 参数带 key、还有一家要先换临时 token）
• 3 种异步任务轮询协议，返回字段各不相同（task_id / id / request_id）
• 5 个账号的余额要分别盯，其中两家余额用光只在响应里给 insufficient_balance，不发邮件
• 每家的错误码语义都不一样，429 在一家是限流、在另一家是配额耗尽

真正让我受不了的是换模型的成本。视频模型这半年迭代太快，Seedance 2.0、Kling V3、Veo 3.1、Wan 2.7 各有擅长，一个需求换个模型试试是常态。但我每换一家就要重写一次请求构造、重写一次轮询、重写一次错误处理。试模型的时间全花在接口适配上了。

三条路的取舍

路线 A：自己写抽象层。 定义统一的 VideoTask 接口，每家写一个 adapter。我做了，能用，但维护成本被低估了——上游改一次响应结构我就得改一次 adapter，而这半年上游改得很勤。而且我写的抽象层只服务我一个项目，没有复用价值。

路线 B：用开源框架的多 provider 支持。 LangChain、LiteLLM 这类。对 LLM 覆盖得不错，但图像和视频模型的支持稀疏，尤其是国内几家（豆包系、通义系、Kling）经常没有或者滞后。我要的三模态它只给我一模态。

路线 C：用聚合网关。 一个 OpenAI 兼容端点，一个 key，换模型只换 model 字段。

最后我走了 C，原因很实在：我需要的是试模型的速度，不是一套优雅的抽象。

OpenAI 兼容到底兼容到什么程度

这是选网关时最需要验证的一点，因为「OpenAI 兼容」是个很宽泛的说法。我的验证清单：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://<gateway-host>/v1",
)

resp = client.chat.completions.create(
    model="YOUR_MODEL_ID",
    messages=[{"role": "user", "content": "ping"}],
)
print(resp.choices[0].message.content)

要逐项确认的：

1. SDK 不用换。 官方 openai 包直接用，只改 base_url 和 api_key。如果要装网关自己的 SDK，那就不是真兼容，迁移成本没降。
2. 流式响应格式一致。 stream=True 时 SSE 的 chunk 结构要和 OpenAI 一样，否则前端要改。
3. 错误对象结构一致。 这条最容易被忽略，但重试逻辑全靠它。
4. 图像和视频模型也走同一个端点。 有些网关只统一了 LLM，图像视频另开一套 API，那统一的意义就打了对折。

第 4 条是分水岭。我要的是文本图像视频都从同一个 key 出去，这样账单、限流、监控才是一份。

实际接入后的四个真实收益

1. 换模型变成改一个字符串。

同一个需求跑四个视频模型对比，代码只有 model 不同：

CANDIDATES = [
    "doubao-seedance-2-0-text-to-video",
    "kling-v3-video-generation",
    "veo-3.1-fast-generate-preview",
    "wan2.7-t2v",
]

for model_id in CANDIDATES:
    task = submit(model_id, prompt=PROMPT)   # 同一个函数，不用分支
    results[model_id] = wait(task)

以前这段要写四份。这个改动听起来小，但它改变了我的工作方式：以前选模型靠看别人的 demo 猜，现在直接四个都跑一遍看结果。

2. 一份账单看清成本结构。

跑完上面那个对比我才发现，我原以为最贵的模型其实不是最贵的——视频模型的计费按时长和分辨率走，同一个 prompt 在不同模型上的实际花费能差三四倍。分散在五个账号里的时候，我根本没算清过这件事。

3. 故障转移从「半夜起床」变成配置项。

上游模型 5xx 或者排队超时是常态，尤其是新模型刚发布那几天。走网关之后这层可以配路由，主模型不可用时落到备选模型。我的图像管线现在是 GPT Image 2 主、Seedream 5.0 备，两个都出问题才真的失败。

4. 免费额度让试错成本归零。

试模型这件事怕的不是贵，是「为了试一次要先充值一笔」。有免费额度的话，评估阶段基本不花钱。

我现在在用的方案

我目前用的是 Velokey，一个统一 AI API 网关：一个 OpenAI 兼容的端点 https://api.velokey.ai/v1，一个 API key 访问 100+ 模型，覆盖文本、图像、视频三个模态，按 token 用量付费、没有套餐门槛。迁移时我只改了 Base URL 和 key 两处，原有的 openai SDK 代码没动。

选它的具体原因是模型清单对得上我的需求：视频侧有 Seedance 2.0、Kling V3、Veo 3.1、Wan 2.7、Vidu Q3、PixVerse V6、Grok Imagine；图像侧有 GPT Image 2、Seedream 5.0、Nano Banana Pro、Qwen Image 2.0；LLM 侧有 GPT 5.5、Claude Opus 5、Gemini 3 Pro、DeepSeek v4 Pro、Kimi K3、Qwen3.7 Max、GLM 5.2。国内外模型在同一个 key 下面，这是我接五家单独 API 时最想要的东西。它支持模型路由和故障转移，注册送 $0.5 额度、不过期，够跑二十来张图做评估。

接入实际就这几行，原有 openai SDK 代码不动：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_VELOKEY_API_KEY",
    base_url="https://api.velokey.ai/v1",   # 只改这一行
)

resp = client.chat.completions.create(
    model="kimi-k3",        # 换模型只改这个字段，deepseek-v4-pro / claude-opus-5 同理
    messages=[{"role": "user", "content": "ping"}],
)

单价都在官网定价页公开挂着，调用前能查到每个模型的价，事后账单能拆到模型粒度。

说清楚适用边界：如果你只调一个模型、而且不打算换，直接接官方 API 更简单，网关这层是多余的。网关的价值只在模型数量 × 更换频率上体现，两个数都小的时候不划算。

选型时我会问的六个问题

给同样在做这件事的人一份清单：

最后一条是我的真实教训：有个模型发布两周我等不到上架，那两周的内容窗口就错过了。这个赛道里上架速度本身就是产品能力。

想自己按这张表核一遍的，各家的模型清单和单价一般在定价页都能查到，Velokey 的在 velokey.ai/pricing，按文本 / 图像 / 视频分了三栏，可以直接拿来对着上游官方价比。

小结

多模型统一接入不是架构洁癖，是为了把「试模型」的成本压到接近零。判断你该不该做这件事，就看一个问题：过去一个月你换过几次模型？ 三次以上，这层网关就值。

我踩的坑大致这些，欢迎交流你们的做法——特别是异步视频任务的轮询和重试，我总觉得还有更省心的写法。

本作品采用《CC 协议》，转载必须注明作者和本文链接