One API：统一管理30+大模型的开源API网关完全指南

在大模型百花齐放的今天，开发者往往需要同时对接多个 LLM 服务商的 API。不同的接口规范、不同的鉴权方式、不同的计费逻辑，让 API 管理变成了一场噩梦。GitHub 上一个名为 One API 的开源项目，正在用优雅的方式解决这个问题——它已经收获了超过 32,800 颗 Star，成为 LLM API 管理领域最受欢迎的开源方案之一。

什么是 One API？

One API 是由开发者 songquanpeng 创建的 LLM API 管理与分发系统。它的核心理念很简单：用一套统一的 API 接口，将市面上所有主流大模型服务聚合在一起。无论你后端对接的是 OpenAI、Anthropic Claude、Google Gemini，还是国内的 DeepSeek、文心一言、通义千问，前端应用只需要调用同一个接口格式即可。

简单来说，One API 就像是大模型世界的「API 网关」，它站在你的应用和各家大模型服务之间，承担着协议转换、密钥管理、流量分发和用量统计的职责。

API 网关（API Gateway）是微服务架构中的核心基础设施组件，最早由 Netflix 在其大规模微服务实践中推广开来。它作为所有客户端请求的统一入口点，承担请求路由、协议转换、认证鉴权、限流熔断、日志监控等横切关注点。在传统的 Web 服务领域，Kong、Nginx、AWS API Gateway 等产品已经非常成熟。而在 LLM 时代，由于各模型服务商的接口规范差异巨大——例如 OpenAI 使用 Chat Completions 格式，Anthropic 使用 Messages 格式，国内厂商则各有自己的协议——专门面向大模型的 API 网关成为了新的刚需。One API 正是在这一背景下应运而生。

LLM API 碎片化问题的技术根源

大模型服务商之间的接口差异不仅体现在表面的字段命名上，更深层的分歧在于各家对「对话」这一抽象概念的不同建模方式。OpenAI 将系统提示（System Prompt）作为 messages 数组中 role=system 的一条消息；而 Anthropic Claude 则将 system 字段独立于 messages 之外，作为顶层参数传入。Google Gemini 更是使用了完全不同的 contents 结构和 parts 嵌套格式。这些差异导致即便是语义完全相同的请求，在不同服务商之间也无法直接复用，必须进行结构性转换。此外，各家在错误码体系、速率限制响应头、模型版本命名规范上也各行其是，使得多服务商适配工作的复杂度远超表面所见。One API 通过在每个渠道适配器中封装这些差异，将转换逻辑集中管理，避免了业务代码中的重复适配工作。

One API 支持哪些大模型？

One API 目前支持的大模型服务商覆盖面相当广泛，几乎囊括了市面上所有主流选择：

国际厂商

• OpenAI（GPT-4o、GPT-4、GPT-3.5 系列）
• Azure OpenAI
• Anthropic Claude（Claude 3.5 Sonnet、Claude 3 Opus 等）
• Google Gemini（Gemini Pro、Gemini Ultra）

国内厂商

• DeepSeek（DeepSeek-V3、DeepSeek-R1）
• 字节豆包
• 百度文心一言
• 阿里通义千问
• 讯飞星火
• 智谱 ChatGLM
• 360 智脑
• 腾讯混元

这种广泛的兼容性意味着，开发者可以在一个统一的管理面板中配置和切换不同的模型供应商，而不需要修改任何业务代码。

Token 计量与计费模型的复杂性

各大模型服务商在 Token 计量方式上存在显著差异，这是 API 管理复杂性的重要来源之一。OpenAI 使用 tiktoken 库进行 BPE（字节对编码）分词，中文字符通常被编码为多个 Token；而国内厂商如通义千问、文心一言则采用各自优化的中文分词器，同样的中文文本在不同服务商处消耗的 Token 数量可能相差 30%-50%。此外，各家对输入 Token 和输出 Token 的定价比例也不尽相同，部分服务商还对缓存命中的 Token 给予折扣（例如 Anthropic 的 Prompt Caching 功能可将重复前缀的输入成本降低约 90%）。One API 的用量统计功能需要在这种复杂性下，尽可能准确地归一化各渠道的费用数据，这也是其工程实现中的难点之一。

One API 核心功能详解

统一 API 协议适配（OpenAI 兼容格式）

One API 最核心的价值在于 API 协议的统一。它将所有模型服务商的接口统一转换为 OpenAI 兼容格式。这意味着任何支持 OpenAI API 的客户端、SDK 或应用，都可以无缝接入 One API 背后的任意模型。

OpenAI 的 Chat Completions API 格式已经成为大模型接口的事实标准（de facto standard）。这种格式以 messages 数组（包含 role 和 content 字段）作为输入，以 choices 数组作为输出，支持流式响应（Server-Sent Events）和函数调用（Function Calling）。由于 OpenAI 最早实现大规模商业化，围绕其 API 格式已经形成了庞大的生态系统——包括 LangChain、LlamaIndex、Dify、OpenWebUI 等主流框架和工具都以 OpenAI 格式作为首选适配目标。因此，将其他模型的接口转换为 OpenAI 兼容格式，本质上是让这些模型能够无缝接入整个已有的 AI 应用生态，而不仅仅是解决接口差异的问题。

流式响应的协议差异与统一处理

流式响应是现代 LLM 应用的标配特性，它让用户能够看到模型「逐字输出」的效果，而不是等待完整响应后一次性显示。OpenAI 采用 Server-Sent Events（SSE）协议实现流式传输，每个数据块以 data: 前缀开头，以 data: [DONE] 标记结束。然而不同服务商在流式协议的细节实现上存在差异：部分厂商的流式响应中不包含 usage 统计信息，部分厂商的错误信息格式与正常响应不同，还有部分厂商在网络不稳定时会发送心跳包以维持连接。One API 作为中间代理层，需要处理这些边界情况，将上游的各种流式格式统一转换为标准的 OpenAI SSE 格式后再转发给下游客户端，同时还需要在流式传输过程中实时累计 Token 用量以支持计费统计。

对于已经基于 OpenAI SDK 开发的项目来说，切换到其他模型供应商的成本几乎为零——只需要修改 API 的 base URL 即可：

# 原来直接调用 OpenAI
client = OpenAI(api_key="sk-xxx")

# 切换为通过 One API 调用任意模型
client = OpenAI(
    api_key="your-one-api-key",
    base_url="https://your-one-api-domain/v1"
)

API Key 管理与二次分发

One API 提供了完善的密钥管理机制。管理员可以在系统中配置各家服务商的原始 API Key，然后生成新的访问令牌分发给团队成员或下游用户。

API Key 二次分发本质上是一种代理令牌（Proxy Token）机制，其设计思想类似于 OAuth 2.0 中的令牌委托模式。在传统做法中，如果团队有 10 个开发者需要使用 OpenAI API，要么共享同一个 Key（存在安全风险和审计困难），要么为每人申请独立 Key（管理成本高且难以统一控制额度）。二次分发机制通过引入中间层，将原始凭证与用户凭证解耦：系统持有真实的服务商 Key，对外签发独立的访问令牌，每个令牌可以绑定独立的配额、速率限制和模型访问权限。这种架构在企业环境中尤为重要，因为它满足了最小权限原则和审计追踪的合规要求。

这种二次分发机制带来了几个