当你同时用上五家大模型，真正拖垮工程的不是模型，而是那五套互不兼容的接口
OpenAI、Anthropic Claude、Google Gemini、DeepSeek、通义千问、智谱 GLM……每一家都有自己的鉴权方式、请求体与错误码。把业务代码和某一家死死绑定时，换模型就像给行驶中的汽车换引擎。One API 想做的，是把这堆碎片收拢成「一个端点、一种格式、一套密钥」——你只管对着标准 OpenAI 接口发请求，它替你去翻译、去路由、去算账。
- 开源 LLM 网关
- OpenAI 兼容
- 多模型统一
- 密钥二次分发
- 额度配额
- MIT 协议
一句话认识它：One API 是开发者 songquanpeng（社区昵称 JustSong）维护的开源 LLM 接口管理与密钥分发系统，核心能力是把 OpenAI、Azure、Anthropic Claude、Google Gemini、DeepSeek、字节豆包、ChatGLM、文心一言、讯飞星火、通义千问、腾讯混元等三十余家供应商的协议，统一翻译成一套 OpenAI 兼容接口，在此之上提供多密钥负载均衡、自动故障转移、按用户额度配额、令牌计数与用量看板，并以 MIT 协议开源、单二进制加 Docker 镜像「开箱即用」。它既是个人开发者整合多模型的「瑞士军刀」，也是团队搭建内部大模型中台、对外做二次分发的底层基座。
一条演进时间线：从「每家 SDK 各写一遍」到「一个端点通吃」
理解 One API 为什么存在，先要看大模型接入这件事是怎么一步步变复杂的。下面这条时间线，串起的是「调用方视角」的演进，而非某个项目内部的提交记录——它解释了统一网关这个类目为何会成为今天 AI 工程里绕不开的一层。
ChatGPT 走红之后，OpenAI 的 /v1 请求格式（messages、model、stream）成了开发者最熟悉的调用范式，大量 SDK、客户端、开源工具默认就按这套格式写。一个统一网关只要「伪装成 OpenAI」，就能零改造接入海量既有生态。
文心一言、通义千问、智谱 GLM、讯飞星火、DeepSeek 等国内供应商，以及 Claude、Gemini 等海外模型，在 2023 年前后陆续开放接口。问题来了：每家鉴权不同、请求体不同、错误码不同，业务侧若要「哪个便宜用哪个、哪个强用哪个」，就要为每家单独写适配层。
One API 用 Go 后端把各家协议翻成 OpenAI 格式，对外只暴露标准 /v1。部署后，任何原本面向 OpenAI 写的工具都能不改代码直接打到它上面，再由它去分发到真实供应商。这层抽象让「换模型 = 改一处配置」成为现实。
当网关被团队用起来，需求从「转发成功」升级为「稳定、可控、可计量」。One API 逐步补齐多密钥轮询、权重分流、故障自动切换、失败重试、按用户配额、令牌计数与用量分析看板，让它从个人玩具变成可对外分发的中台。
由于 One API 采用宽松的 MIT 协议，社区在其基础上衍生出 New API 等分叉版本，继续扩展模型适配、管理界面与运营能力。One API 因此可被视为这类「自托管 LLM 分发面板」谱系的前身与母体。
六块能力拆解：它到底替你干了哪些活
把 One API 从「一个转发代理」拆开看，真正值钱的是下面这六块能力。它们单独看都不稀奇，合在一起才构成「中台级」的体验。
用 Go 后端把各家原生协议收敛成 OpenAI 兼容格式，业务侧只需对着标准 /v1 发请求。Claude、Gemini、DeepSeek、文心一言、通义千问等三十余家供应商共享同一套调用范式。
同一模型可挂多个渠道密钥，按权重轮询分发流量，避免单 key 触发速率限制或额度耗尽，把「一家的上限」变成「多家之和」。
某渠道报错、超时或余额不足时，自动切到同模型的下一个健康渠道并重试，配合优先级与权重规则实现「主用廉价、备用优质」的路由逻辑。
支持用户分组、令牌额度限制、渠道倍率计费、IP 白名单与模型调用权限隔离，给团队内部或对外分发时做「控流控费」的硬约束。
按用户、渠道、模型维度统计请求量、消耗与成本拆解，后台可视化看板实时呈现调用量与在线状态，让每一分钱花在哪都看得见。
单可执行文件或 Docker 一键拉起，默认 SQLite 免装即可跑，也可切 MySQL/PostgreSQL；支持自定义 LOGO、首页文案、页脚与中英文界面。
三个真实落地场景：它替谁省了事
- 痛点：想横向对比 Claude、Gemini、DeepSeek 的同一道题表现，却要在三家各申请 key、各写一套请求代码。
- 解法：把三家渠道都接进 One API，应用里只改 base_url 和 model 字段，就能在同一套代码里切换对比，省掉大量胶水代码。
- 痛点：公司多团队共用一批供应商 key，谁超支了、哪个模型最常被调，财务和负责人都说不清。
- 解法：统一收敛到 One API，按用户/分组下配额、记令牌，看板把成本拆到人和模型，对账从「拍脑袋」变成「有据可查」。
- 痛点：想做面向客户的 API 服务，却不想把上游供应商 key 直接暴露，还要自己解决充值、配额、兑换码。
- 解法：利用令牌体系、兑换码与倍率计费，把上游额度包装成自有服务对外分发，密钥分级、权限隔离都在后台配好。
它和「裸调官方 SDK」「其他网关」到底差在哪
| 维度 | 直连各家官方 SDK | One API 统一网关 | 纯托管网关（如 OpenRouter） |
|---|---|---|---|
| 接入改造成本 | 每加一家重写适配层 | 配一次渠道，代码零改 | 同样零改，但依赖第三方 |
| 数据与控制权 | 直连供应商，无中间层 | 自托管，数据留在自己服务器 | 流量过第三方，受服务条款约束 |
| 多密钥容灾 | 需自己实现 | 内置轮询/权重/故障转移 | 平台侧提供，不可自定义 |
| 配额与计量 | 无，需自建 | 按用户/模型配额与看板 | 平台计费，规则不透明 |
| 国内模型覆盖 | 各自支持 | 对国内供应商支持尤为广泛 | 覆盖较泛，国内模型参差 |
| 协议与费用 | 免费，但有速率天花板 | MIT 开源，自有算力成本 | 平台抽成或加价 |
一句话总结：要极致简单又不在乎把流量交给别人，用托管网关；要数据自持、要对外分发、要深度定制，One API 这类自托管方案更对路。它和 LiteLLM、Portkey 等同类工具同台竞争，差异点在于对国内供应商的广度、单二进制 Docker 的轻部署，以及 MIT 协议毫无使用限制。
三步上手：从零到跑通第一个请求
- 拉起服务：最省事是 docker run -d --name one-api -p 3000:3000 -v /data/one-api:/data justsong/one-api；想用 MySQL 就补 SQL_DSN 环境变量。容器起来后访问 http://IP:3000。
- 改密码加渠道：默认管理员账号 root / 123456，上线第一件事就是改密码。随后在后台「渠道」里填入各家 key 与模型映射，One API 会自动把不同供应商归一。
- 发令牌调接口：在「令牌」里生成用户 token，把应用里的 base_url 指向你的 One API 地址、api_key 换成该 token，原有 OpenAI 风格代码无需改写即可开始调用。
三个最容易踩的坑
常见问答
One API 和直接调用官方 SDK 最大的区别是什么？
官方 SDK 每家一套，换模型要改代码、重写适配；One API 把三十余家供应商统一成 OpenAI 兼容接口，业务侧只维护一套调用逻辑，模型的增删换只在后台配置里完成，应用代码几乎不动。
它支持哪些大模型供应商？
覆盖 OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini、Mistral、DeepSeek、字节豆包、ChatGLM、文心一言、讯飞星火、通义千问、360 智脑、腾讯混元，以及 Ollama、vLLM、LocalAI 等本地推理与 Amazon Bedrock、Together、Groq 等云平台，总数三十余家并持续增加。
已经有 OpenAI 风格代码，要改很多吗？
基本不用改。把请求地址的 base_url 指向你的 One API 实例、api_key 换成它下发的令牌即可，消息体、流式、函数调用、视觉等多模态能力在兼容供应商上都能沿用原有写法。
New API 和 One API 是什么关系？
New API 是在 One API 基础上的社区分叉（fork）后续版本，沿用了其 MIT 协议与整体架构思路，并在模型适配、管理界面与运营能力上继续演进；One API 可视为这一自托管分发面板谱系的前身。
用它做对外分发合规吗，数据安全吗？
One API 以 MIT 协议开源，可自行部署、修改与商用；自托管意味着流量与密钥数据留在你自己的服务器，不经由第三方。但对外分发涉及的上游供应商条款、实名与合规责任仍由运营方承担，敏感数据请按合规要求评估。
部署复杂吗，小机器能跑吗？
非常轻量。单二进制或 Docker 一行命令即可拉起，默认 SQLite 免装数据库，资源占用低、启动快，个人 VPS 就能稳定运行；需要横向扩展时再切 MySQL 并配合 Redis 做分布式限流。
和 LiteLLM、OpenRouter 比该怎么选？
OpenRouter 是托管服务、零运维但流量过第三方且计费不透明；LiteLLM 偏 Python 代理、能力也不错；One API 胜在国内供应商覆盖广、带完整管理后台与配额体系、MIT 无限制且可完全自托管，适合要数据自持和对外分发的团队。
相似工具推荐
参考资料
- 来源：One API 官方 GitHub 仓库（项目定位、支持供应商清单、MIT 协议、Docker 与二进制部署说明）：https://github.com/songquanpeng/one-api
- 来源：One API 官方 README 文档（渠道配置、多机部署、环境变量与令牌/配额机制）：https://github.com/songquanpeng/one-api#readme
- 来源：The Agent Times — Open-Source LLM Gateway Crosses 29K GitHub Stars（社区规模、MIT 协议、30+ 供应商支持与架构概述）：https://theagenttimes.com/agents/article/open-source-llm-gateway-crosses-29k-github-stars-unifying-30-e813ab43
- 来源：CSDN 技术博客 — 开源神器 One API 一键统一整合全网大模型接口（渠道调度、额度管控、轻量部署实操）：https://blog.csdn.net/weixin_43400476/article/details/161310303
- 来源：TokRepo — One API Unified LLM Gateway（架构、负载均衡、配额管理、与 LiteLLM/OpenRouter 对比）：https://tokrepo.com/en/workflows/asset-1039cfd7
- 来源：New API 官方 GitHub（One API 社区分叉的后续演进版本，印证其谱系前身地位）：https://github.com/QuantumAI-Org/New-API
- 来源：OpenAI 官方文档 — API Reference（/v1 接口格式，One API 兼容对齐的目标规范）：https://platform.openai.com/docs/api-reference