One API：一套接口管理30+大模型的开源API网关

项目概览：为什么需要 One API

大模型百花齐放的当下，开发者和企业往往需要同时对接多个 LLM 服务商——OpenAI、Anthropic Claude、Google Gemini、DeepSeek、通义千问、文心一言……每家的 API 格式、认证方式、计费逻辑各不相同，管理成本急剧上升。

One API（GitHub: songquanpeng/one-api）正是为解决这一痛点而生的开源项目。它以统一的 OpenAI 兼容接口对外提供服务，在后端将请求智能路由到 30 多家主流大模型提供商，同时提供完善的 Key 管理、额度控制和二次分发能力。从架构角色上看，One API 本质上是一个面向 LLM 场景的垂直 API 网关。API 网关（API Gateway）是微服务架构中的经典模式，负责请求路由、认证鉴权、限流熔断等横切关注点，Kong、Envoy、APISIX 等都是知名的通用 API 网关方案。而 One API 在此基础上深度适配了大模型特有的业务逻辑——Token 计费、流式响应（SSE）透传、多模型协议转换等，使其成为连接应用层与大模型服务层的专用中间件。

项目在 GitHub 上已获得超过 32,800 Star，Fork 数超过 6,200，是目前最受欢迎的开源 LLM API 网关方案之一。

核心功能详解

统一 API 适配层：一套接口对接所有大模型

One API 最核心的价值在于协议统一。无论后端对接的是 Azure OpenAI、Anthropic Claude、Google Gemini、DeepSeek、字节豆包、ChatGLM、讯飞星火、通义千问、360 智脑还是腾讯混元，对外暴露的始终是标准的 OpenAI API 格式。

这里所说的「OpenAI API 格式」，具体是指以 /v1/chat/completions 为核心端点、使用 JSON 格式的 messages 数组传递对话上下文的 Chat Completions API 规范。OpenAI 凭借 ChatGPT 的爆发式增长，其 API 格式已成为大模型调用的事实标准——几乎所有后来的模型服务商都提供了 OpenAI 兼容模式，这为 One API 的协议统一策略奠定了基础。这一标准化趋势类似于早年 REST API 取代 SOAP 成为 Web 服务主流协议的过程：当一种接口范式获得足够大的生态惯性后，后来者为了降低开发者迁移成本，往往会主动兼容而非另起炉灶。One API 在此之上进一步处理了各家在认证头格式（如 OpenAI 使用 Authorization: Bearer，而部分国内厂商使用自定义 Header）、错误码定义、流式数据块结构等细节上的差异，真正实现了「一次对接，处处可用」。

这种设计带来了几个直接好处：

• 一套 SDK 走天下：前端应用只需对接一次，即可无缝切换底层模型
• 生态无缝兼容：ChatGPT-Next-Web、LobeChat、Chatbox 等 OpenAI 生态工具可以直接接入，无需任何改造
• 迁移成本趋近于零：模型切换和 A/B 测试只需在后台修改渠道配置，业务代码完全不用动

Key 管理与二次分发

One API 内置了一套完整的多租户 Key 管理体系，这也是它区别于简单反向代理工具的关键所在。

多租户（Multi-tenancy）是 SaaS 架构中的核心概念，指一套系统同时为多个相互隔离的用户或组织提供服务。在 LLM API 管理场景中，多租户意味着不同的团队、项目或客户可以共享同一套基础设施，但各自拥有独立的访问凭证、用量配额和计费记录。与之相对的是「单租户」模式——每个用户独占一套系统实例，虽然隔离性更强但运维成本也成倍增加。One API 采用的是逻辑隔离的多租户方案：所有租户共享同一个数据库和服务进程，通过令牌（Token）和用户 ID 在应用层实现数据隔离。One API 的多租户设计具体体现在以下几个层面：

• 渠道管理：可配置多个上游 API Key，支持按优先级、权重进行负载均衡，某个渠道出错时自动切换到备用渠道
• 令牌管理：可为不同用户或应用生成独立的访问令牌，单独设置额度上限和过期时间
• 用量追踪：详细记录每个令牌的调用次数、Token 消耗和费用统计，账单一目了然

关于 Token 计费需要多说几句：大模型的计费通常以 Token 为单位——Token 是模型处理文本的最小单元，它并不等同于「字」或「词」，而是由分词器（Tokenizer）根据训练语料的统计规律切分出的子词片段。英文中大约每个单词对应 1-1.5 个 Token，中文中每个汉字通常对应 1-2 个 Token（因为中文字符在 BPE 等分词算法中往往被拆分为多个字节组合）。不同模型的 Token 单价差异巨大，例如 GPT-4o 的输入价格约为 GPT-3.5-turbo 的数倍，而 DeepSeek 等国产模型的定价往往更具竞争力——DeepSeek-V3 的输入价格仅为 GPT-4o 的约 1/30。此外，大模型通常对输入（Prompt）和输出（Completion）分别计价，输出 Token 的单价通常是输入的 2-4 倍，因为生成过程的计算开销更大。One API 的额度系统将上游各家不同的定价体系换算为统一的内部额度单位（默认以 1:500000 的比例将美元换算为内部额度），实现跨模型的成本核算，让管理者能够清晰掌握整体 AI 支出。

这套机制特别适合团队内部共享 API 资源、对外提供 API 转售服务，或者在教育场景中为学生分配有限额度。

负载均衡与自动故障转移

One API 支持为同一模型配置多个渠道，并按优先级和权重分配流量。当某个渠道返回错误或响应超时时，系统会自动将请求转发到下一个可用渠道，整个过程对调用方完全透明。

负载均衡（Load Balancing）和故障转移（Failover）是分布式系统中保障高可用性的两大基石技术。负载均衡通过将请求分散到多个后端节点来避免单点过载，常见策略包括轮询（Round Robin）、加权轮询、最少连接数等。One API 采用的是优先级+权重的调度模型——优先使用高优先级渠道，同优先级内按权重比例分配流量。这种两级调度策略在实践中非常灵活：例如可以将价格最低的渠道设为最高优先级，将响应最稳定但价格较高的渠道设为次优先级作为兜底，同时在同一优先级内通过权重实现流量的精细分配。故障转移则是指当主节点不可用时，系统自动将流量切换到备用节点，无需人工干预。

在 LLM API 场景中，故障转移机制尤为重要：大模型服务商的 API 经常出现限流（Rate Limiting）、服务降级甚至临时宕机的情况，尤其是在新模型发布或流量高峰期。限流是 API 服务商保护后端资源的常见手段，通常表现为返回 HTTP 429（Too Many Requests）状态码，并在响应头中通过 Retry-After 字段告知客户端应等待的时间。不同服务商的限流策略差异很大：OpenAI 按分钟内的请求数和 Token 数双重限制，而部分国内厂商则按并发连接数限制。One API 通过检测 HTTP 状态码（如 429、500、502、503）和超时信号来判断渠道健康状态，实现秒级自动切换。比如同时配置 DeepSeek 和通义千问，一个挂了另一个自动顶上，保障服务连续性。

支持的模型服务商一览

截至目前，One API 已适配的主流大模型服务商包括但不限于：

类别	服务商
国际厂商	OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini、Cohere
国内厂商	DeepSeek、字节豆包、百度文心一言、阿里通义千问、讯飞星火、腾讯混元、360 智脑、智谱 ChatGLM
中转与聚合	Cloudflare Workers AI、OpenRouter、自定义渠道

值得注意的是，Azure OpenAI 与直连 OpenAI 虽然底层模型相同，但 API 端点格式、认证方式和部署模型有显著差异——Azure 采用资源组+部署名的 URL 结构，认证使用 Azure AD 或 API Key，且模型需要在 Azure Portal 中手动部署后才能调用。One API 对这些差异进行了透明封装，用户只需填入 Azure 的 endpoint 和 key 即可像使用原版 OpenAI 一样调用。

这种广泛的兼容性使得 One API 成为了事实上的 LLM API 中间件标准。无论企业选择哪家模型供应商，都可以通过 One API 进行统一纳管，后续增减供应商也只需在后台添加渠道即可。

One API 部署教程：Docker 一行命令搞定

One API 后端采用 Go 语言编写，前端使用 React，编译后为单可执行文件，同时提供官方 Docker 镜像。

Go（Golang）是 Google 于 2009 年发布的编程语言，以编译速度快、并发模型优秀（基于 goroutine 的轻量级协程）、部署简单著称。Go 编译后生成的是静态链接的单一二进制文件，不依赖外部运行时环境（不像 Java 需要 JVM、Python 需要解释器），这使得部署极为简便——只需将一个文件复制到服务器即可运行。Go 的 goroutine 机制对于 API 网关场景尤其适合：每个 goroutine 仅占用约 2-8KB 的栈内存（相比操作系统线程的 1-8MB），这意味着单个 Go 进程可以轻松维持数万个并发连接——对于需要同时处理大量流式长连接的 LLM 网关来说，这是一个关键优势。这种特性在容器化场景中优势明显，也是 Docker、Kubernetes、Terraform 等云原生基础设施工具选择 Go 的重要原因。One API 继承了这一优势，Docker 镜像体积小（通常在 50-100MB 级别）、启动速度快（秒级冷启动）、内存占用低（空载约 30-50MB），单实例即可处理相当高的并发请求量。

部署过程非常简单：

docker run -d --name one-api \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v /home/ubuntu/data/one-api:/data \
  justsong/one-api

启动后访问 http://localhost:3000 即可进入管理后台。默认使用 SQLite 存储数据，无需额外安装数据库。SQLite 是一个嵌入式数据库引擎，数据存储在单个文件中，无需独立的数据库服务进程，非常适合中小规模部署和快速验证场景。SQLite 虽然轻量，但其性能并不弱——在读多写少的场景下，单机 QPS 可达数万。然而 SQLite 的写入采用文件级锁，在高并发写入场景（如大量用户同时调用 API 产生日志记录）下可能成为瓶颈。因此生产环境也支持切换到 MySQL 或 PostgreSQL，通过环境变量 SQL_DSN 指定连接字符串即可完成迁移，真正做到了开箱即用。

部署完成后的基本配置流程：

1. 添加渠道：在后台填入各家大模型的 API Key，选择对应的服务商类型
2. 创建令牌：为自己或团队成员生成访问令牌，设置额度和有效期
3. 接入应用：将 One API 的地址和令牌填入你的应用或工具中，替换原来的 OpenAI API 地址即可

关于流式响应的技术说明

值得一提的是，大模型 API 的一个重要特性是支持流式响应（Streaming），即模型生成的文本不是等全部完成后一次性返回，而是逐 Token 实时推送给客户端。这种机制基于 Server-Sent Events（SSE） 协议实现——服务端通过 HTTP 长连接持续发送 data: 前缀的事件流，客户端逐行解析并实时渲染。SSE 是 HTML5 规范的一部分，与 WebSocket 相比，它是单向的（仅服务端向客户端推送）、基于标准 HTTP 协议、天然支持断线重连，非常适合大模型这种「请求一次、持续输出」的交互模式。在 OpenAI 的实现中，每个流式数据块是一个 JSON 对象，包含 choices[0].delta.content 字段携带增量文本，最后以 data: [DONE] 标记流结束。

流式响应对用户体验至关重要：一个 GPT-4 级别的长回答可能需要 10-30 秒才能完整生成，如果等待全部完成再显示，用户体验会非常糟糕。流式输出让用户在首个 Token 生成后（通常 0.5-2 秒内）就能看到响应开始出现，这个指标被称为 TTFT（Time To First Token），是衡量大模型服务响应速度的关键指标之一。

One API 作为中间层需要正确处理 SSE 的透传，包括保持长连接不被中间代理（如 Nginx）意外断开、正确转发各家不同格式的流式数据块、以及在流式模式下准确统计 Token 消耗量。流式模式下的 Token 统计是一个技术难点：由于文本是逐块到达的，One API 需要在流结束后汇总所有块的内容来计算实际 Token 消耗，或者依赖上游 API 在最后一个数据块中返回的 usage 字段（并非所有服务商都支持）。如果你在部署时使用了 Nginx 反向代理，需要注意添加 proxy_buffering off、chunked_transfer_encoding on 和适当的超时配置（建议 proxy_read_timeout 设为 300 秒以上），以确保流式响应正常工作。

典型应用场景

企业内部 AI 平台

企业 IT 部门可以将 One API 部署为内部 AI 网关，统一采购和管理各家大模型的 API Key，为不同业务部门分配独立令牌和额度。这样既能实现成本可控、用量可追溯，又能避免 API Key 散落在各个项目中带来的安全隐患。在实际企业场景中，API Key 泄露是一个高频安全事件——开发者不小心将 Key 提交到 GitHub 公开仓库、写入前端代码或在 Slack 中明文传递的情况屡见不鲜。通过 One API 的令牌机制，真实的上游 API Key 只存储在 One API 服务端，分发给各团队的是 One API 生成的二级令牌，即使泄露也可以随时吊销且不影响其他用户，大幅降低了密钥管理的风险面。

API 转售与分发平台

对于 AI 服务中间商来说，One API 提供了现成的多租户管理和计费基础设施，可以快速搭建 API 分发平台，支持预付费额度模式，省去了从零开发管理后台的大量工作。这类平台的商业模式通常是批量采购上游 API 额度获取折扣，再以略高于成本的价格零售给中小开发者，赚取中间差价的同时为用户提供更便捷的接入体验和更灵活的付费方式。

开发者个人聚合使用

个人开发者可以将多个平台的免费试用额度或低价渠道聚合到 One API 中，通过自动故障转移和负载均衡机制，用较低的成本获得更稳定的大模型 API 服务体验。例如，可以同时配置 DeepSeek（性价比高但偶尔限流）、阿里通义千问（有免费额度）和 OpenAI（质量最高但价格贵）三个渠道，设置 DeepSeek 为最高优先级、通义千问为次优先级、OpenAI 为兜底，实现成本和质量的最优平衡。

社区生态与项目活跃度

32,800+ Star 的数据充分说明了社区对这个项目的认可。One API 由 songquanpeng 主导开发，社区贡献者众多，Issue 和 PR 响应较为及时。围绕 One API 还衍生出了多个增强版本（如 new-api、one-api-plus 等），形成了一个活跃的小型生态。

这种 Fork-and-Enhance 的模式在开源社区中非常常见（类似于 Nextcloud 之于 ownCloud、MariaDB 之于 MySQL），既推动了功能创新，也通过竞争促进了原版项目的持续改进。其中 new-api 是最知名的衍生项目之一，在原版基础上增加了更美观的 UI 界面（基于 Material Design 风格重构）、更细粒度的模型定价配置（支持按模型单独设置倍率）、Midjourney 绘图接口支持、以及数据看板等功能。围绕 One API 生态，还出现了专门的监控面板（如基于 Grafana 的用量可视化方案）、用量分析工具、以及与企业微信/钉钉集成的通知插件等周边项目，进一步丰富了其在企业场景中的实用性。

不过也需要留意，作为开源项目，One API 在企业级场景下可能需要额外考虑以下几点：

• 高可用部署：默认单实例部署，生产环境建议配合外部数据库和负载均衡器，必要时可部署多个 One API 实例并通过 Nginx 或云厂商的 SLB（Server Load Balancer）进行流量分发。由于 One API 本身是无状态的（状态存储在外部数据库中），水平扩展相对简单，但需要注意会话一致性和缓存同步的问题
• 安全审计：涉及 API Key 存储和转发，建议部署在内网或配合 HTTPS 和访问控制。API Key 在数据库中的存储方式（是否加密、加密算法的强度）、传输过程中的 TLS 保护、以及管理后台的访问权限控制都需要重点关注。建议启用 One API 的 IP 白名单功能，并定期轮换上游 API Key
• 合规性：部分行业（如金融、医疗）对数据流转路径有严格要求，需评估通过中间层转发 API 请求是否符合相关数据安全和隐私保护规定。特别是在涉及个人隐私数据（如患者病历、用户对话记录）的场景中，需要确认 One API 是否会在本地持久化请求/响应内容，以及数据经过中间层转发是否违反数据本地化（Data Residency）要求

总结：谁适合用 One API

One API 精准地解决了大模型时代 API 碎片化管理的核心痛点。它以极低的部署门槛、广泛的模型兼容性和实用的 Key 管理功能，成为了连接应用层与大模型服务层的关键基础设施。

如果你属于以下情况，One API 值得认真考虑：

• 同时使用两家以上的 LLM 服务商，需要统一管理 API Key
• 希望为团队成员分配独立的 API 额度和权限
• 正在搭建 AI 应用，希望保留随时切换底层模型的灵活性
• 需要一个轻量级的大模型 API 网关，不想引入重量级的商业方案

一行 Docker 命令就能跑起来，不妨先试试看。

核心要点

• One API 通过统一的 OpenAI 兼容接口适配 30+ 主流大模型服务商，消除多平台 API 对接的复杂性
• 提供完整的 Key 管理、额度控制和二次分发能力，支持多租户场景
• 单可执行文件 + Docker 镜像的轻量化部署方案，开箱即用
• GitHub 32,800+ Star，是目前最受欢迎的开源 LLM API 网关方案
• 适用于企业内部 AI 平台、API 转售分发、个人开发者多渠道聚合等典型场景