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

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

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

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

1. 接口路径不同

有些厂商甚至不用标准 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 + 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 个以上模型的场景。

三、三方案成本对比

四、实际开发中的避坑建议

坑 1：只看了文本模型，忘了视频模型

很多团队选方案时只考虑了文本对话，等到需要接入视频生成能力时才发现——视频模型的异步回调流程和文本模型完全不同。同一套适配层能不能兼容视频模型，选型前就要确认。

坑 2：SSE 只兼容了"常见格式"

适配了 OpenAI、DeepSeek 的 SSE 格式，自认为"应该都兼容了"。结果改天换个厂商，SSE 的数据结构完全不同，解析器直接报错。SSE 解析器的健壮性决定了你后续加模型时的痛苦程度。

坑 3：认证方式的"例外"比想象中多

大部分国产大模型用 Bearer Token，但总有那么几个厂商用签名认证、或者要求 API Key 放 Query 参数。适配层如果不能轻松扩展认证方式，每加一个"非标"厂商就要大改。

坑 4：忽视了限流和错误码的差异化

不同厂商的 HTTP 错误码含义不同：有的用 429 表示限流，有的用 503；有的错误信息在 error.message，有的在 msg。适配层要统一处理这些差异，否则监控和告警会非常混乱。

五、总结

不同厂商大模型 API 格式不统一，本质上是一个"适配成本"问题。你的选择取决于模型用量和团队规模：

1. 只用 1-2 个模型 + 有专职后端 → 手写 Adapter，维护成本可控，灵活性最高
2. 3+ 个模型 + 没有基础架构团队 → 聚合平台是最优解，API 格式、SSE 解析、认证差异、视频异步回调、故障转移这些"适配债"全部由平台消化
3. 月调用量极大 + 有基础架构投入 → 长期可自建网关，但初期用聚合平台快速验证模型组合投入产出比更高

大原则：先跑通业务，再优化架构。 前期用聚合平台把 3-5 个模型先跑起来、验证效果，远比花两周写适配层最后发现选错了模型强。

本文基于 2026 年 6 月国内大模型 API 市场现状撰写。不同厂商的 API 格式和认证方式可能随时间变化，接入前请以各厂商最新文档为准。文中的代码示例为示意逻辑，完整实现需结合实际 SDK 版本。

本文以技术选型分析为目的，不构成对任何具体产品或服务的推荐。