API统一管控平台:new-api、one-api、UniAPI、

之前写过类似文章,请参考LLM系列之API聚合平台:OpenRouter、TogetherAI、LiteLLM

本文继续汇总几个开源API统一管控平台。

one-api

官网,开源(GitHub,30.1K Star,5.8K Fork)平台,旨在解决多API并行模式的问题:

  1. 接口差异大,代码重复且脆弱
    • 每个平台的API协议、参数格式、认证方式、错误码甚至响应结构都不尽相同。
    • 开发者需为每个平台单独编写适配层,一旦某家平台升级接口,多处代码需同步修改,极易出错。
  2. API Key分散管理,安全风险高
    • 开发人员各自持有不同平台的Token,密钥硬编码在代码或配置文件中,容易泄露。
    • 无法统一控制用量、权限和生命周期,离职员工仍可能保留访问权限。
  3. 调试与测试成本高
    • 切换模型需修改代码或配置,无法快速对比不同模型效果。
    • 缺乏统一日志、监控和计费视图,难以评估各平台性价比。
  4. 上线后难以灵活调度
    • 无法根据成本、性能或可用性动态切换后端模型。
    • 某个平台限流或故障时,缺乏自动降级或故障转移机制。

开源大模型API聚合网关,通过提供标准化的OpenAI兼容接口,屏蔽底层平台差异,实现一次接入,多端兼容。

浏览器打开http://localhost:3000开始体验,输入用户名密码root/123456

优势:

  • 完全屏蔽各平台的技术差异
    • 所有后端模型均通过统一的/v1/chat/completions接口被调用
    • 请求/响应格式严格遵循OpenAI API规范,前端或业务代码无需感知后端是GPT、Qwen、Llama3。
    • 自动处理各平台特有的字段映射(如max_tokensmax_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管理混乱:密钥散落在各服务里,轮换、权限、审计都很难
  • 配额与成本不可控:没有统一的限流、计费与监控,超支和滥用很常见
  • 模型命名不统一:同名不同能力、不同名同能力,客户端适配非常痛苦
  • 稳定性问题:单一渠道故障会直接影响业务,需要路由与容灾

功能:

  1. 渠道与Key管理(Distribution):面向团队/多租户的常见能力:
    • 管理多个渠道(不同Provider/不同Key组)
    • 做分发、配额与访问控制,降低Key滥用、泄露等风险
  2. 模型映射与兼容层(Model Mapping),解耦前端命名和后端路由:
    • 支持模型映射/重命名
    • 更容易做灰度、替换与统一接入
  3. 路由与稳定性(负载均衡/容灾)面向生产实践的关键能力:
    • 支持负载均衡与故障切换思路(按项目说明为准)
    • 多家Provider做成稳定服务出口

亮点:

  • 网关/控制面思路成熟:把权限、配额、路由、模型管理集中处理,客户端更简单
  • 更适合团队化使用:多租户与分发能力,不仅是反代,而是平台层
  • 可部署可自建:提供Docker等部署方式,适合内网/自托管场景

UniAPI

Chrome搜索UniAPI,可找到好几个不同的项目:

GitHub上也能搜到好几个不同的项目:

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="")
相关推荐
青苔猿猿8 个月前
OpenAI API(1)补全Responses(Chat Completions)API和记忆Assistants API对比分析
openai api·responses api·assistants api·chatcompletions
营赢盈英1 年前
OpenAI GPT-3 API: What is the difference between davinci and text-davinci-003?
ai·gpt-3·openai·openai api
营赢盈英1 年前
OpenAI converting API code from GPT-3 to chatGPT-3.5
人工智能·chatgpt·gpt-3·php·openai api
营赢盈英1 年前
how can I train a OpenAI fine tuned model with more prompts
人工智能·深度学习·ai·openai api
营赢盈英1 年前
Why is OpenAI image generation Api returning 400 bad request in Unity?
ai·json·openai api·post·unitywebrequest·unitygameengine
营赢盈英1 年前
Azure OpenAI and token limit
ai·chatgpt·asp.net·azure·openai api
营赢盈英1 年前
TypeError: expected string or buffer - Langchain, OpenAI Embeddings
langchain·azure·embeddings·openai api·rag
营赢盈英1 年前
Trying to install openai in chaquopy in android studio but getting build failed
android·ide·ai·android studio·openai api·chaquopy
营赢盈英1 年前
Azure web app has no access to openai private endpoint in virtual network
azure·openai api·web app·webapp·webapps·virtual network