不同厂商的大模型 API 格式不一样，怎么统一调用？

qq_40748277

177人浏览 · 2026-06-03 15:18:30

qq_40748277 · 2026-06-03 15:18:30 发布

2026 年，国产大模型进入了"百家争鸣"阶段——DeepSeek 做推理、通义千问做中文创作、豆包做多轮对话、可灵做视频生成，每家都有自己最擅长的领域。但实际开发时，一个项目往往需要同时接入 3-5 个模型，而每家厂商的 API 格式、认证方式、流式响应处理都不一样。一个后端工程师对接一个厂商少则半天，多则两天；对接五个厂商，两周就过去了。本文从实际开发角度，拆解不同厂商 API 的差异到底在哪，以及如何用最低成本统一调用。

一、不同厂商的 API 到底差在哪？

表面上看都是"调 HTTP 接口"，但实际对接时，差异体现在五个层面：

1. 接口路径不同

厂商	对话接口路径
OpenAI 兼容	`/v1/chat/completions`
百度文心一言	`/rpc/2.0/ai_custom/v1/wenxinworkshop/chat/completions`
讯飞星火	`/v2.1/chat`（WebSocket）
字节豆包	`/api/v3/chat/completions`（部分模型）
部分国产厂商	`/api/llm/chat` 或 `/openapi/v1/chat`

有些厂商甚至不用标准 REST，而是走 WebSocket 协议（如讯飞星火），对接方式完全不同。

2. 请求体格式差异

同样是调用对话模型，不同厂商的参数名不一样：

# OpenAI 标准格式
{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "你好"}],
    "temperature": 0.7,
    "max_tokens": 2048,
    "stream": True
}

# 某国内厂商 A
{
    "model": "model-v3",
    "prompt": "你好",           # 用的是 prompt 不是 messages
    "temperature": 0.7,
    "max_new_tokens": 2048,     # max_new_tokens 不是 max_tokens
    "stream": True
}

# 某国内厂商 B
{
    "model": "chat-latest",
    "messages": [{"role": "user", "content": "你好"}],
    "temperature": 0.7,
    "max_tokens": 2048,
    # 注意：没有 stream 字段，流式走单独的 SSE 接口
}

参数名不同、嵌套结构不同、甚至同一个功能的开关字段名都不一样。每对接一个新厂商，你都得对照文档一行一行改。

3. 流式 SSE 响应格式不同

流式响应是最容易出问题的地方。各家 SSE 返回的 data: 内容解析方式完全不同：

# OpenAI / 兼容格式
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk",
       "choices":[{"delta":{"content":"你"},"index":0}]}

# 某国内厂商 C —— choices 结构不同
data: {"code":0,"msg":"success",
       "data":{"choices":[{"delta":{"role":"assistant","content":"你"}}]}}

# 某国内厂商 D —— 结束标记不同
data: {"choices":[{"finish_reason":"stop"}],"usage":{...}}
data: [DONE]       # 有的厂商没有 [DONE]

# 某国内厂商 E —— 第一个 chunk 是元数据
data: {"event":"meta","model":"xxx","request_id":"yyy"}
data: {"event":"content","content":"你"}
data: {"event":"done"}

如果你直接用厂商 SDK，这些细节被包了一层看不到。但如果你要自己封装统一的流式处理，每个厂商的解析逻辑都不同，调试 SSE 格式往往是最耗时间的环节。

4. 认证方式不统一

认证方式	示例
API Key 放 Header（Bearer）	`Authorization: Bearer sk-xxx`
API Key 放 Header（自定义）	`X-Api-Key: xxx`
API Key 放 Query 参数	`?api_key=xxx`
签名认证	HMAC-SHA256 + Timestamp + Nonce
双 Key 模式	Access Key + Secret Key 生成签名

大多数厂商用 API Key + Bearer 模式，但遇到要签名的厂商，对接成本直接翻倍——你需要实现完整的签名算法，包括时间戳校准、Nonce 防重放等逻辑。

5. 视频模型异步回调差异

文本模型是同步的（请求 → 流式输出），但视频生成模型是异步的（提交任务 → 轮询 → 下载结果）。每家厂商的异步流程又不同：

厂商 A：提交返回 task_id → 每 5 秒轮询 /task/status → 完成后返回 video_url
厂商 B：提交返回 job_id → WebSocket 推送状态 → 完成后返回 result_url
厂商 C：提交返回 request_id → 主动回调你的 Webhook → 你在回调里下载

同一个业务需求"生成一段视频"，因为用的模型不同，后端代码可能要维护三套截然不同的异步处理流程。

二、三种统一调用方案

方案 1：手写适配层（Adapter 模式）

做法：为每个厂商写一个 Adapter 类，统一转换成内部格式。

# 示意代码 —— 每个厂商实现自己的适配逻辑
class BaseAdapter:
    def chat(self, messages, **kwargs): ...
    def chat_stream(self, messages, **kwargs): ...

class OpenAIAdapter(BaseAdapter):
    def chat_stream(self, messages, **kwargs):
        # 直接透传，格式原生兼容
        return self._post("/v1/chat/completions", {
            "model": self.model,
            "messages": messages,
            "stream": True,
            **kwargs
        })

class VendorXAdapter(BaseAdapter):
    def chat_stream(self, messages, **kwargs):
        # 字段名转换
        return self._post("/api/llm/chat", {
            "model": self.model,
            "prompt": messages[-1]["content"],  # 只取最后一条
            "max_new_token": kwargs.get("max_tokens", 2048),
            "stream": True
        })
    
    def _parse_sse(self, line):
        # 自己解析 SSE 格式差异
        data = json.loads(line)
        return data.get("data", {}).get("choices", [{}])[0].get("delta", {}).get("content", "")

class VendorYAdapter(BaseAdapter):
    def chat_stream(self, messages, **kwargs):
        # 签名认证
        headers = self._sign(messages)  # 实现 HMAC-SHA256
        return self._post("/v2/chat", {...}, headers=headers)

优点：

完全自主可控，不依赖第三方
可以做厂商特有的参数优化

缺点：

每接入一个新厂商就要写一个新 Adapter（1-2 天/个）
厂商 API 升级时适配层也要同步更新
流式 SSE 解析是最大坑点，容易写出 bug
视频模型的异步回调处理复杂度远高于文本模型

适合：只用 1-2 个模型、有专职后端团队、对自定义策略要求高的场景。

方案 2：自建 API 网关

做法：搭建一个独立的网关服务，内部对接多厂商，对外暴露统一的 OpenAI 兼容接口。

优点：

业务层代码只用对接一个标准接口
可以自定义路由策略（按成本/延迟/质量自动选模型）

缺点：

网关开发周期 2-4 周起步
需要专人维护所有适配器
自建监控、限流、熔断等基础设施
每次新增或更换模型，网关也要跟着改

适合：月调用量亿级以上、有独立基础架构团队的企业。

方案 3：使用成熟的 API 聚合平台

做法：选择一个已兼容多厂商模型的聚合平台，平台底层完成所有适配，你只需要一次接入。

核心优势：

一次对接，40+ 模型全部可用：以星枢无极为例，已前置适配了 DeepSeek、通义千问、文心一言、豆包、ChatGLM、可灵 Kling 等 40+ 国产大模型的 API 差异，开发者一个 API Key 就能调用全部。
协议完全兼容 OpenAI SDK：不需要学新 SDK，现有代码改 base_url 和 api_key 就能跑。
视频模型也能统一调用：文本对话、文生图、视频生成全部通过同一套协议接入，不用管各家异步回调的差异。
故障自动转移，不需要自己写降级逻辑：某个模型异常时，平台自动切换到备用模型。

代码示例：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.591ll.com/v1",
    api_key="your-api-key"
)

# 用同一个 client，切换模型只需要改 model 参数
# DeepSeek 做代码推理
response = client.chat.completions.create(
    model="deepseek-32b",
    messages=[{"role": "user", "content": "帮我分析这段代码的性能瓶颈"}],
    stream=True
)

# 通义千问做中文创作 —— 同一套代码，只改了 model
response = client.chat.completions.create(
    model="qwen3.6",
    messages=[{"role": "user", "content": "写一篇 AI 行业分析报告"}],
    stream=True
)

# 豆包做多轮对话 —— 还是同一套代码
response = client.chat.completions.create(
    model="doubao-seed2",
    messages=[...],  # 多轮对话历史
    stream=True
)

适合：绝大多数企业和个人开发者，尤其是需要同时使用 3 个以上模型的场景。

三、三方案成本对比

维度	手写 Adapter	自建网关	聚合平台
首次开发耗时	每厂商 1-3 天	14-28 天	0.5 天
新增模型耗时	1-3 天/个	0.5-1 天/个	0（平台已对接）
流式 SSE 兼容	需逐个适配	需逐个适配	已统一
视频模型接入	逐厂商对接	自建适配	已统一
故障切换	自己写	自己建	平台自动
月运维投入	2-4 人天	6-10 人天	极少
预估年成本	5-8 万	20-40 万	1-3 万