之前写过类似文章,请参考LLM系列之API聚合平台:OpenRouter、TogetherAI、LiteLLM。
本文继续汇总几个开源API统一管控平台。
one-api
官网,开源(GitHub,30.1K Star,5.8K Fork)平台,旨在解决多API并行模式的问题:
- 接口差异大,代码重复且脆弱
- 每个平台的API协议、参数格式、认证方式、错误码甚至响应结构都不尽相同。
- 开发者需为每个平台单独编写适配层,一旦某家平台升级接口,多处代码需同步修改,极易出错。
- API Key分散管理,安全风险高
- 开发人员各自持有不同平台的Token,密钥硬编码在代码或配置文件中,容易泄露。
- 无法统一控制用量、权限和生命周期,离职员工仍可能保留访问权限。
- 调试与测试成本高
- 切换模型需修改代码或配置,无法快速对比不同模型效果。
- 缺乏统一日志、监控和计费视图,难以评估各平台性价比。
- 上线后难以灵活调度
- 无法根据成本、性能或可用性动态切换后端模型。
- 某个平台限流或故障时,缺乏自动降级或故障转移机制。
开源大模型API聚合网关,通过提供标准化的OpenAI兼容接口,屏蔽底层平台差异,实现一次接入,多端兼容。
浏览器打开http://localhost:3000开始体验,输入用户名密码root/123456。
优势:
- 完全屏蔽各平台的技术差异
- 所有后端模型均通过统一的
/v1/chat/completions接口被调用 - 请求/响应格式严格遵循OpenAI API规范,前端或业务代码无需感知后端是GPT、Qwen、Llama3。
- 自动处理各平台特有的字段映射(如
max_tokens、max_output_tokens)、认证头、错误码转换等细节。
- 所有后端模型均通过统一的
- 集中管理所有平台的Token与权限
- 所有第三方平台的API Key仅由one-api后台管理员配置,普通开发者无需接触原始密钥
- 为每个开发者或应用分配独立的访问令牌,具备:
- 使用额度限制,按Token数或请求次数
- 可用模型白名单,如仅允许调用
qwen-turbo - IP白名单、速率限制、QPS控制
- 支持密钥轮换、禁用、审计日志,大幅提升安全性与合规性。
- 提升开发效率与系统灵活性
- 快速切换模型:只需在请求中更改
model字段,即可对比不同模型效果,无需改代码。 - 支持自定义模型别名:如将
gpt-4映射到qwen-max,实现无缝迁移。 - 本地模型无缝集成:通过Ollama、FastChat等提供OpenAI兼容接口,可将私有模型纳入统一调度体系。
- 快速切换模型:只需在请求中更改
- 增强生产环境的可靠性与可观测性
- 多渠道负载均衡:为同一模型配置多个供应商(如多个OpenAI账号),自动分摊请求。
- 故障自动转移:当首选渠道失败(如配额耗尽、网络超时),自动尝试备用渠道。
- 完整请求日志与用量统计:记录每次调用的模型、耗时、Token消耗、费用估算,便于成本分析与优化。
- Web管理界面:可视化管理用户、渠道、模型、配额,降低运维门槛。
配置文件示例:
yaml
ai:
openai:
api-key: xxx
base-url: http://ip:3000/
chat:
options:
model: qwen3-max
embedding:
options:
model: text-embedding-3-large
dimensions: 1024
new-api
官网,开源(GitHub,19.2K Star,3.7K Fork)LLM API Key统一管理平台,把各种LLM Provider的API入口、Key、渠道、配额、模型映射、审计统一管理:对外提供稳定的兼容接口,对内做鉴权、分发、路由、限流、日志脱敏、密钥加密存储、监控与成本控制。让客户端保持稳定接口,把复杂度留在网关层解决。
问题:
- 多Provider分裂:OpenAI、Anthropic、Gemini、本地模型......接口差异带来维护成本
- Key管理混乱:密钥散落在各服务里,轮换、权限、审计都很难
- 配额与成本不可控:没有统一的限流、计费与监控,超支和滥用很常见
- 模型命名不统一:同名不同能力、不同名同能力,客户端适配非常痛苦
- 稳定性问题:单一渠道故障会直接影响业务,需要路由与容灾
功能:
- 渠道与Key管理(Distribution):面向团队/多租户的常见能力:
- 管理多个渠道(不同Provider/不同Key组)
- 做分发、配额与访问控制,降低Key滥用、泄露等风险
- 模型映射与兼容层(Model Mapping),解耦前端命名和后端路由:
- 支持模型映射/重命名
- 更容易做灰度、替换与统一接入
- 路由与稳定性(负载均衡/容灾)面向生产实践的关键能力:
- 支持负载均衡与故障切换思路(按项目说明为准)
- 多家Provider做成稳定服务出口
亮点:
- 网关/控制面思路成熟:把权限、配额、路由、模型管理集中处理,客户端更简单
- 更适合团队化使用:多租户与分发能力,不仅是反代,而是平台层
- 可部署可自建:提供Docker等部署方式,适合内网/自托管场景
UniAPI
Chrome搜索UniAPI,可找到好几个不同的项目:
- uniapi.ai:
- uniapi.top:文档托管在GitHub
GitHub上也能搜到好几个不同的项目:
- yym68686:1.2K Star,152 Fork
- zhangtyzzz:87 Star,34 Fork,项目已归档;已部署在Vercel
- LiuLucian:30 Star,6 Fork
zhangtyzzz
功能列表
- 支持OpenAI及兼容OpenAI协议的服务,包括Azure OpenAI、Claude等
- 将不同厂商的API统一转换为OpenAI格式,简化调用流程
- 支持模型映射,用统一模型名调用不同厂商的实际模型
- 提供模型择优机制,根据72小时成功率和首token响应时间选择最佳服务
- 内置断路器机制,服务连续失败后自动暂停请求,保护系统稳定性
- 优化流式输出,把大块响应拆成小块,提升视觉效果
- 支持自定义API密钥、BaseURL和模型列表,灵活配置
- 通过Vercel部署,提供管理面板和安全认证
Sub2API
功能强大的开源(GitHub,3.4K Star,597 Fork)AI API网关平台,旨在解决AI订阅服务的统一接入、配额分发和成本管理问题。体验地址,用户名密码:admin@sub2api.com/admin123。
允许将多个上游AI服务的订阅接入平台,然后通过平台生成统一的API Key分发给不同的用户。
当用户使用这些Key调用AI服务时,Sub2API负责处理鉴权、计费、负载均衡和请求转发。这一切都在一个统一的管理后台中清晰可见,让复杂的订阅管理变得简单高效。
核心功能
- 多账号管理:支持多种类型的上游账号,包括OAuth认证和传统的API Key模式;
- API Key分发:为不同的用户生成和管理独立的API Key,并设置不同的权限和额度;
- 精确计费:用量追踪精确到Token级别,成本计算一目了然;
- 智能调度:当有多个可用账号时,系统能智能选择,并支持粘性会话以保证对话的连续性;
- 并发控制:可对用户和上游账号设置并发请求限制,防止滥用;
- 速率限制:可灵活配置请求速率和Token速率,保障服务稳定;
- 管理后台:提供现代化Web界面,用于实时监控和管理所有资源。
技术栈
- 后端:Go 1.25.7、Gin、Ent
- 前端:Vue 3.4+、Vite 5+、TailwindCSS
安装
bash
curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/install.sh | sudo bash
sudo systemctl start sub2api
sudo systemctl enable sub2api
# 升级docker-compose.yml
docker-compose -f docker-compose.local.yml pull
# 源码
git clone https://github.com/Wei-Shaw/sub2api.git
cd sub2api
# 2. 编译前端
cd frontend
pnpm install
pnpm run build
# 3. 编译后端(嵌入前端)
cd ../backend
go build -tags embed -o sub2api ./cmd/server
# 4. 配置并运行
cp ../deploy/config.example.yaml ./config.yaml
nano config.yaml
./sub2api
解读:编译后端时使用-tags embed 参数会将前端静态资源打包进二进制文件,实现单文件部署。
使用模式:环境变量RUN_MODE=simple
Quotio
官网,专门为解决多API Key账号管理痛点而生的开源(GitHub,3.9K Star,244 Fork)工具,显示各个AI账号的剩余额度。
功能:
- 在本地启动一个代理服务,只需要把编程工具的Base URL指向代理服务地址;
- 检测到当前使用的Key爆出
Rate Limit或余额不足的错误时,自动切换到下一个可用的Key,重试请求。在后台默默调度资源。 - API路由器:通过配置规则,可灵活地分配策略:让不重要请求走便宜的API通道,核心逻辑走高质量通道。

OpenAI Router
GitHub,轻量级、持久化、零配置OpenAI API统一网关。
功能
| 特性 | 描述 |
|---|---|
| 统一入口 | /chat/completions、/embeddings、/images/generations...所有OpenAI兼容接口都能转发 |
| 多后端支持 | vLLM、SGLang、lmdeploy、Ollama...任意组合 |
| 零配置持久化 | 内置SQLite存储,路由配置自动保存,关机重启不丢失,告别繁琐配置文件 |
| 实时流式 | SSE&Chunked Transfer全双工支持,流式输出体验,和直连原生服务一样 |
| 开箱即用WebUI | 自带Gradio管理面板,开发者友好 |
| 完美兼容OpenAI | 现有的OpenAI SDK、LangChain、LlamaIndex代码,不改一行,只需更换base_url |
安装
bash
uv add openai-router -U
# 或
pip install openai-router -U
openai-router --host localhost --port 8000
浏览器打开http://localhost:8000,文档参考http://localhost:8000/docs。
示例:
py
from openai import OpenAI
# 唯一改变,base_url指向路由器
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="xxx"
)
resp = client.chat.completions.create(
model="gpt-4",
messages=[{"role":"user", "content":"hello"}],
stream=True
)
for chunk in resp:
print(chunk.choices[0].delta.content or"", end="")