国产大模型接入实践：一个统一网关搞定多模型调度

这篇文章记录的是我最近做的一件小事：给团队内部搭了一个统一的大模型接入网关，把 DeepSeek、通义、Kimi 几个模型的调用收敛到一个入口。听起来简单，做起来有几个值得说的点。

背景：为什么要做这个网关

团队内部的需求很具体：

1. 多个项目都在用大模型，各自接各自的，代码里散落着好几套鉴权配置
2. 模型在换，今天用这家，明天想换那家，换起来成本很高
3. 成本看不清楚，每个项目各付各的账，没人说得清一共花了多少

要解决这三件事，最直接的办法就是——统一入口。

架构设计：就三层

我的网关只有三层，没有过度设计：

应用层（各业务服务）
    ↓ 统一走 OpenAI 兼容接口
网关层（统一鉴权 + 路由 + 故障转移）
    ↓ 按 model 字段路由
模型层（DeepSeek / Qwen / Kimi / GLM）

网关层做三件事：

• 统一鉴权：所有应用只用一套密钥体系（子密钥按项目隔离）
• 统一路由：请求里的 model 字段决定发给哪个模型
• 故障转移：一条上游渠道挂了，自动切下一条

关键技术点：OpenAI 兼容救了大忙

这个设计能落地，最核心的前提是——所有模型厂商都兼容 OpenAI 接口格式。

这意味着：

• 应用层代码永远只写一套（用 openai SDK 即可）
• 换模型只是改 model 字段，业务代码零改动
• 网关本身也很薄，不需要为每家模型做适配

我用的网关实现方式：直接选用一个现成的 OpenAI 兼容聚合平台（词元云，tokenfreeai.com）作为统一接入层，而不是从零自研。原因很实际：自研网关要处理多渠道故障转移、密钥管理、用量统计，这些它都内置好了，没必要重复造轮子。

具体落地：应用怎么接入

应用侧接入极其简单：

from openai import OpenAI

client = OpenAI(
    api_key="项目子密钥",
    base_url="https://api.tokenfreeai.com/v1"
)

# 换模型 = 换一个字符串
resp = client.chat.completions.create(
    model="deepseek-chat",   # 或 qwen-plus / kimi-latest
    messages=[{"role": "user", "content": "你好"}]
)

三个项目接入，每项目一个子密钥，后台能按密钥看用量。

落地后的三个收益

1. 模型切换成本趋近于零

以前想从 A 模型换到 B 模型，要改代码、改配置、重新联调。现在改一个 model 字段，跑几条真实任务对比，完事。这个能力带来的灵活性，比省下的钱重要。

2. 成本终于能算清了

三个项目，一个后台，按密钥、按模型看用量。哪个项目在烧钱、哪个任务跑得冤，一目了然。上个月发现一个定时任务在反复调用无效请求，关掉后每月省了几十块。

3. 晚高峰稳定了

多渠道故障转移的效果在晚高峰最明显。之前官方直连时 20:00–23:00 频繁 429，现在基本无感。

一个提醒：别把敏感数据放进通用网关

统一网关方便是方便，但涉及客户隐私、公司机密的数据，别走通用通道。我们内部规定：敏感场景单独走合规通道，通用网关只跑常规业务。

总结

统一网关这件事，核心价值不是省多少钱，而是把"换模型"从一次工程改造变成一次配置变更。在这个模型三个月一迭代的时代，这个能力比任何具体模型都值钱。