翻开任何一家模型厂商的 API 文档——DeepSeek、通义千问、Kimi、智谱，或者本地部署工具 vLLM、Ollama、LM Studio——你几乎总能看到一句话：「我们提供 OpenAI 兼容接口」。这句话背后是过去两年 AI 工程领域最重要的一个事实标准：大家不约而同地把接口做成 OpenAI 的样子，于是为 OpenAI 写的代码，改个地址和 Key 就能调别家的模型。
这篇文章讲清它到底是什么、兼容到什么程度、以及它的边界——因为「兼容」两个字经常被理解得过于乐观。
OpenAI 兼容接口是行业自发的「事实标准」：没有委员会规定，但人人都照着做。
它不是标准，是「事实约定」
先破除一个误解：OpenAI 兼容接口不是 OpenAI 官方发布的、供他人遵循的开放标准，OpenAI 没有定义过「兼容规范」这种东西。它的形成路径是市场选择的结果：
OpenAI 的 API 最早流行，海量工具、SDK、框架（LangChain、各类客户端）都是围绕它的 /v1/chat/completions 接口写的。后来者要想让这些现成生态直接用上自己的模型，最省力的办法就是——把自己的接口做得和 OpenAI 一模一样。于是 messages 数组、model 字段、stream 参数、SSE 流式格式、Authorization: Bearer 鉴权，成了大家默认长的样子。这是典型的「先发者定义接口形态，后来者主动对齐」。
好处是实实在在的：你用 OpenAI 官方 SDK 写好的代码，通常只改两个东西就能切到别家——
from openai import OpenAI
# 调 OpenAI
client = OpenAI(api_key="sk-openai-xxx")
# 切到 DeepSeek：只改 base_url 和 key
client = OpenAI(
api_key="sk-deepseek-xxx",
base_url="https://api.deepseek.com/v1",
)
# 后面的 client.chat.completions.create(...) 代码一字不改这也是为什么 AI 网关普遍选择「对内统一暴露 OpenAI 格式」——它是当前生态覆盖面最广的接口方言。
兼容的核心是哪几样
所谓「OpenAI 兼容」，业界默认指对齐这几块最常用的能力：
- Chat Completions 接口：
POST /v1/chat/completions，messages用role（system/user/assistant）+content结构； - 流式响应：
stream: true时返回 SSE 格式的data:分块，以[DONE]结尾； - 鉴权：HTTP 头
Authorization: Bearer <key>； - 基础参数：
temperature、max_tokens、top_p、stop等； - [工具调用](/wiki/tool-calling)：
tools/tool_calls字段（这块兼容度参差，见下文）； - 用量返回：响应里的
usage（prompt_tokens / completion_tokens）。
覆盖这些，就能让绝大多数按 OpenAI 写的应用跑起来。也正因如此，本地部署框架把兼容接口当标配——vLLM、Ollama、LM Studio 起一个服务就是 OpenAI 格式，你的应用感知不到后面跑的是云端 GPT 还是本机的开源模型。
「兼容」不等于「等价」：边界在哪
这是最需要泼冷水的部分。兼容的是接口形状，不是模型行为，更不是全部功能。 实际迁移时最容易踩的不兼容点：
| 领域 | 常见差异 |
|---|---|
| 工具调用 | 有的模型工具调用格式或稳定性和 OpenAI 有出入，并行工具调用、流式工具调用支持不一 |
| 结构化输出 | response_format / JSON 模式并非家家都实现，或行为不同 |
| 多模态 | 图片、音频输入的字段各家扩展方式不同，兼容性差 |
| 参数细节 | temperature 取值范围、max_tokens 上限、特殊参数（如推理模型的思考控制）各不相同 |
| 独有能力 | 各家的缓存标记、联网、内置工具等专有功能，兼容接口里根本没有 |
| 模型行为 | 同样的提示词，不同模型的输出风格、遵循指令的程度天差地别——这不是接口问题，是模型问题 |
一句话：「改个 base_url 就能跑」多半成立，「改个 base_url 效果一样」几乎不成立。 迁移后一定要用自己的评估集重测一遍，尤其是依赖工具调用和结构化输出的应用。
换了兼容接口，代码能跑不代表效果一致——提示词往往要针对新模型重新调。
怎么用好它
- 用官方 SDK + 可配置 base_url：别自己拼 HTTP 请求，用 OpenAI 官方 SDK 并把
base_url、api_key、model做成配置项，切换成本最低； - 抽象一层自己的模型客户端：即便都兼容，也建议在应用里包一层薄封装，隔离各家的细微差异（如工具调用格式），换厂商时只改这一层；
- 交给网关：多模型场景直接用 AI 网关统一入口，应用永远只说 OpenAI 方言，翻译和路由交给网关，见《从零设计一个 AI API 网关》；
- 本地开发省钱：开发调试阶段用 Ollama 起本地开源模型（OpenAI 兼容），代码不动，上线再切云端旗舰模型。
把 base_url、api_key、model 做成配置项，切换模型就只是改配置——这正是兼容接口的最大红利。
适用人群与替代方案
适合需要在多家模型间切换、或想让代码不锁定单一厂商的开发者。要知道的替代/例外：
- Anthropic 有自己的原生 API 格式（Messages API），字段和 OpenAI 不完全一样，但官方也提供 OpenAI 兼容端点，且各大网关都能做转换，接入不难；
- 深度用某家独有能力时，兼容接口反而是束缚——它只覆盖公约数，用不到厂商的杀手锏功能。这时该用原生 SDK；
- 框架封装（LangChain、LlamaIndex 等）在兼容接口之上又抽象了一层，多模型切换更省事，但引入框架本身有成本，按需选择。
常见问题
Q：用兼容接口调国产模型，需要科学上网吗？ A：不需要。DeepSeek、通义、Kimi 等国产模型的 API 服务在境内，直接访问其 base_url 即可，这也是它们相比 OpenAI 官方接口在国内的一大便利。
Q：为什么有的「兼容」模型工具调用总出问题？ A：工具调用是兼容度最参差的部分。接口字段对齐了，但模型本身对工具调用的训练程度不同，输出的 tool_calls 可能格式不规范或不稳定。生产前务必针对目标模型专门测试工具调用链路。
Q：本地模型的 OpenAI 兼容接口可靠吗？ A：接口层面很成熟（vLLM、Ollama 等都久经使用），但要注意本地开源模型在工具调用、长上下文、指令遵循上通常弱于云端旗舰模型，接口兼容掩盖不了能力差距。
小结
OpenAI 兼容接口是市场自发形成的事实标准：后来者主动对齐先发者的接口形态，换来「改个地址就能切模型」的便利。但要记住它兼容的是接口形状而非模型行为——迁移时代码大概率能跑，效果却要重新验证。把 base_url 做成配置、包一层自己的客户端、或干脆交给网关，你就能在享受生态红利的同时，不被任何单一厂商锁死。