One Hub 上手体验：2.8k 星的 OpenAI 接口管理分发系统，多模型一站搞定

用 AI 大模型的团队应该都有过这个烦恼：公司里不同项目要用不同的模型——有的用 GPT-4，有的用 Claude，有的用国产的通义千问或者文心一言。每个模型都有自己的 API 格式、密钥管理、计费方式，维护起来头都大了。

更头疼的是，有的项目用量大，有的项目用量小，怎么合理分配额度? 怎么监控每个项目的调用情况? 怎么在模型之间做 failover，某个模型挂了自动切到备用?

One Hub 就是来解决这些问题的。2.8k 星，Go 语言写的， fork 自 songquanpeng/one-api，在这个基础上做了很多增强。部署试用了一段时间，来分享下体验。

它解决了什么问题

核心定位：把多个 AI 模型的 API 统一成一个 OpenAI 兼容的接口，让调用方只需要对接一套标准。

具体场景：

• 团队内部多个项目共用 AI 能力，但各项目技术栈不同
• 需要同时使用 OpenAI、Anthropic、Google、国产大模型等多个供应商
• 想按项目/用户分配 API 配额，控制成本
• 需要统计每个模型的调用量、耗时、成功率
• 某个模型服务不稳定时，自动切换到备用模型

核心功能

多模型统一接入 支持接入的模型供应商非常全：OpenAI、Anthropic Claude、Google Gemini、Azure OpenAI、百度文心、阿里通义、讯飞星火、智谱 ChatGLM、MiniMax、Moonshot 等等。基本上国内国外主流的模型都能接。

接入之后，所有模型都通过统一的 OpenAI 标准 API 对外提供服务。你的应用只需要按照 OpenAI 的格式调用，One Hub 在背后自动路由到对应的模型供应商。这个体验对于已经基于 OpenAI API 开发的项目特别友好——几乎零迁移成本就能用上其他模型。

渠道管理 每个模型供应商可以配置为独立的”渠道”，支持：

• 多个密钥轮询（负载均衡 + 故障转移）
• 渠道优先级设置
• 按渠道设置速率限制
• 渠道的启用/禁用开关

我配置了 OpenAI 和 Claude 两个渠道，OpenAI 为主、Claude 为备用。OpenAI 偶尔 429 的时候，请求会自动落到 Claude 上，业务端完全无感知。

用户和令牌管理 可以创建多个用户，每个用户分配独立的 API token 和额度。支持：

• 按用户设置月度/总量配额
• token 级别的权限控制
• 用户分组管理

这个对于多租户场景或者按项目分账特别实用。给每个项目发一个 token，月底看统计就知道各项目用了多少。

统计面板 内置了比较完善的统计功能：

• 各模型的调用量、token 消耗、成功率
• 按用户/渠道的用量排行
• 响应时间分布
• 错误类型统计

统计面板的粒度够细，能看出哪个模型性价比最高、哪个项目的调用量异常。对于成本控制来说，这些数据是决策基础。

函数调用增强 原版 one-api 对非 OpenAI 模型的函数调用支持不完善。One Hub 在这方面做了增强，让 Claude、Gemini 等模型也能支持 OpenAI 格式的 function calling。对于依赖 function call 的应用来说，这意味着可以无缝切换模型而不改代码。

价格设置 支持自定义各模型的计费单价。如果某个渠道是通过代理或者自建部署获取的，成本结构和官方不同，可以在这里设置实际价格，统计出来的费用就更准确。

快速上手

# 推荐 Docker 部署
docker run -d -p 3000:3000 \
  -e SQL_DSN="root:password@tcp(localhost:3306)/onehub" \
  -e SESSION_SECRET="your-secret-key" \
  --name one-hub \
  martialbe/one-hub:latest

# 访问 http://localhost:3000
# 默认管理员账号: root / 123456
# 首次登录后务必修改密码

# 或者 docker-compose 部署（推荐）
git clone https://github.com/MartialBE/one-hub.git
cd one-hub/docker-compose
# 编辑 docker-compose.yml 配置数据库信息
docker-compose up -d

环境要求：

• MySQL 5.7+ 或 PostgreSQL
• Redis（可选，用于缓存和限流）
• 2GB+ 内存

实际使用场景

场景一：团队 AI 中台 公司内部的 AI 能力中台，统一接入各种模型，对外提供标准 OpenAI 接口。各业务线按需申请 token，按量计费。运维统一管理渠道，业务方只关心 prompt 和结果。

场景二：模型 A/B 测试 同一个业务场景，想测试 GPT-4 和 Claude 哪个效果更好。通过 One Hub 配置两个渠道，用同一套代码分别调用，对比输出质量、响应速度和成本。

场景三：成本控制 高峰期用便宜模型处理简单请求，复杂请求才用贵模型。One Hub 支持按关键词或请求内容做路由规则（需要配合外部逻辑），实现智能降级。

场景四：国产模型过渡 项目原本基于 OpenAI API 开发，由于合规或成本原因需要切到国产模型。通过 One Hub 接入通义或文心，业务代码几乎不用改，只需要换 endpoint 和 token。

优点和槽点

真香的点：

• 多模型统一接入，极大降低了维护成本
• 兼容 OpenAI API 格式，迁移成本低
• 统计面板实用，成本控制有数据支撑
• Go 语言性能好，单机能扛不小的并发量
• 函数调用增强让非 OpenAI 模型也能 function call
• Docker 部署简单，配置不复杂
• 开源免费，可以二次开发

想吐槽的地方：

• 文档还不够完善，部分高级功能需要自己看源码理解
• UI 界面比较朴素，离”产品级”还有距离
• 渠道配置出错时的错误提示不够友好
• 非 OpenAI 模型的 function call 兼容性还在完善中，复杂场景可能有问题
• 没有内置的 prompt 管理和版本控制
• 社区规模相对小，遇到问题搜解决方案不如 one-api 方便

和 one-api 怎么选

特性	One Hub	one-api
多模型支持	更多模型	主流模型都有
函数调用	增强版	基础版
统计面板	更完善	基础统计
社区规模	较小(2.8k)	较大(20k+)
文档	一般	更完善
维护状态	活跃	活跃

如果你需要函数调用增强或者更完善的统计，选 One Hub。如果只是基础的多模型接入，one-api 的社区支持更好。

总结

One Hub 这类工具解决的是一个很实际的工程问题：在多模型时代，怎么统一管理各种 AI API。2.8k 星说明有这个需求的团队不在少数。

它的价值不在于技术创新，而在于把碎片化的模型接入体验统一化。对于已经深度绑定 OpenAI API 格式的团队来说，One Hub 让切换和扩展模型供应商变得几乎无痛。

不过也要看到它的局限：它只是一个 API 路由层，不解决 prompt 工程、模型微调、输出质量控制等更上层的问题。把它当作 AI 基础设施的一个组件来用比较合适，而不是期望它解决所有问题。

对于需要同时使用多个 AI 模型、且希望统一管理的团队，One Hub 是一个值得试用的方案。部署成本低，迁移风险小，用好了能省不少维护精力。

---

关于作者

柳钉鱼，全栈开发者，GitHub 重度用户。过去 3 年 Star 了 900+ 仓库，这里只写我真正用过或深度调研过的工具。

📧 发现好工具想推荐？发邮件到 [email protected]