OpenAI兼容接口正在成为LLM领域事实标准

两三年前，"OpenAI compatible"（OpenAI 兼容）大多还只是一句营销话术——规模较小的提供商借此表明"我们和 OpenAI 类似，但更便宜"。如今它有了更具体、更有实际意义的内涵：越来越多的提供商，无论是开源还是商业化，都开始暴露与 OpenAI Chat Completions API 完全相同的请求/响应结构。相同的 JSON 字段、相同的流式格式、相同的 SDK 兼容性。

我认为值得关注的理由与任何单一厂商无关：它正在悄然成为 LLM 领域的事实 API 标准，正如 SQL 成为关系型数据库的事实标准一样——尽管每种数据库底层都有各自的扩展和quirks。

为什么事实标准比"更好的 API"更重要

没有人刻意把 OpenAI Chat Completions 格式设计成行业标准。它成为标准的原因平凡却有力：它被最先采用，围绕它建立了工具链（LangChain、LlamaIndex、无数内部 SDK），而不支持它的切换成本不断攀升。一旦生态系统中足够多的组件假设了某种请求结构，匹配它就成为新进入者的最小阻力路径——不是因为它是可能存在的最佳设计，而是因为兼容性比略微干净的 API 更有价值。

在 AI 领域之外，这也是一种熟悉的模式。SQL 作为语言设计并非普遍受欢迎，但"只要支持 SQL"成为新数据库的理性选择，因为替代方案是要求每个用户重写他们的查询。REST 之所以战胜了更"正确"的 API 风格，原因类似。标准会产生复合效应：支持它的东西越多，不支持它的代价就越高。

这对开发者实际意味着什么

如果你在 LLM API 之上构建，这种收敛的实际效果是可移植性。原则上，针对 OpenAI SDK 格式编写的代码应该能够通过更改 base URL 和 API key 指向其他提供商的端点，而无需重写请求构建或响应解析逻辑。在实践中，对于核心的聊天补全流程，这套机制运行得相当不错；而对于提供商特定的功能（function calling 变体、扩展上下文处理、多模态输入），这些尚未完全收敛的特性，效果就没那么好了。

我认为，这种部分收敛才是比"现在每个人都支持 OpenAI 的格式"更有意思的故事。在使用提供 OpenAI 兼容端点的多个提供商时，我注意到以下几个要点：

• 基础聊天补全和流式输出——通常可靠
• 标准参数名称（temperature、max_tokens 等）——通常可靠
• Function/tool calling——不一致程度足以让我在依赖之前仍需针对每个提供商单独测试
• 供应商特定扩展（如某些提供商原生的 reasoning-trace 字段）——不可移植，而且可能本就不该被当作可移植的功能来使用

这一点对于团队应该如何看待供应商锁定很关键。关于这个领域的大量"避免锁定"建议将 OpenAI 兼容端点视为完全可移植的保证。更准确的表述是：这一兼容层有效地降低了常见路径的切换成本，但并未消除你对任何提供商特定功能的依赖所产生的成本。

这在实践中的体现

许多网关风格的服务应运而生，专门位于这种收敛之上——提供一个 OpenAI 兼容端点，将请求路由到多个底层模型。RouteAI 是我用过的一个例子；它有用的部分与其说是网关本身，不如说是它所暗示的意义：足够多的提供商现在认同一种共享的请求格式，以至于在其上构建路由层变得可行。这在几年前是没有意义的——那时每个提供商的 API 外观差异明显。

我预计这种收敛会在常见场景（聊天、流式输出、基础 tool calls）中继续推进，而在任何接近给定模型能力边界的功能上保持真正的碎片化——长上下文处理、原生多模态输入或模型特定的推理功能。标准往往在技术的稳定且成熟的部分固化，而在仍在演进的部分保持争议。

"OpenAI compatible"值得被视为一种新兴的 API 惯例，而不是一个值得怀疑的供应商声明。它不会让每个 LLM 变得可互换，也不会消除实际测试模型对你用例适用性的必要——但对于核心的请求/响应结构，你可以越来越放心地基于它构建，就像你完全知道底层存在供应商特定扩展的情况下基于 SQL 构建一样。

很好奇其他在多个 LLM 提供商之上构建的团队是否遇到了同样的分裂——基础功能可靠、高级功能碎片化——还是你的体验有所不同。

TL;DR：，"OpenAI compatible"已从一句营销话术演变为 LLM 的事实 API 惯例，类似于 SQL 成为数据库标准的方式。基础聊天/流式输出在提供商之间是可移植的；高级功能（tool calling 变体、提供商特定扩展）仍然不是——所以把兼容性视为降低切换成本，而不是消除切换成本。

以下是我在这篇文章中引用的工具： www.fastrouteai.com