项目详情
GPT-Load
把 API Key 和订阅账号收进同一个入口——自托管 AI 网关，多渠道多凭据统一调度
更新于 2026-09-30 · v2.0.0-rc.38
← 返回汇总
项目速览
一句话定位
应用只配一个地址和一个 AccessKey，其余全部进网关
自托管 AI 网关。统一管理服务商、账号、凭据、模型与路由策略：官方 API、云平台、模型服务、兼容中转，以及 Codex / Claude / Grok 等订阅账号，全部共享同一套调度、容错、日志与用量体系。2025 年 6 月开源，16 个月做到 7k stars。
项目速览
核心数据
数据截至 2026-09-30。当前版本 v2.0.0-rc.38（2026-09-30 发布），RC 阶段保持数日一版的发布节奏；获 OpenAI 平台支持、LINUX DO 社区支持、DigitalOcean 基础设施支持。
为什么存在
多渠道多凭据的四个痛点
API Key 散落各处
N 家服务商 = N 个 Key、N 个 base URL，应用配置爆炸，轮换一次动全身。
订阅账号进不了程序
ChatGPT Plus / Claude Pro 的订阅额度无法被 API 调用直接使用，付了月费却只能手动用。
单个凭据故障拖垮全量
限流、封号、欠费时没有调度与冷却机制，重试只会反复砸向同一个坏凭据。
用量与成本是黑盒
调用分散在多个入口，无法统一看请求趋势、token 消耗与成本估算。
核心理念
一个入口，保留原生协议
应用（一个 URL + 一个 AccessKey）
→
Group（可用模型 + 运行策略）
→
Channel（上游服务商）
→
Credentials（Key/账号池）
- 客户端零改造：继续使用 OpenAI、Anthropic、Gemini 原生接口，协议转换在网关内完成
- 策略全在管理界面：服务商、账号、模型、路由策略不进应用代码，改配置不改代码
- AccessKey 即边界：每个 AccessKey 可设置允许访问的 Group 与客户端协议，交给谁用就发谁
架构
三层结构 + 两个开源底座
Layer 1 · 客户端协议层
OpenAI / Anthropic / Gemini 原生入口
Chat Completions、Responses、Images、Embeddings、Rerank、Mistral 原生（OCR/Audio）、Anthropic Messages、Gemini 及其 Embeddings，共 9 类客户端协议
Layer 2 · 核心调度层（GPT-Load 自研）
凭据存储 · 账号选择 · 调度 · 重试 · 健康 · 亲和 · 日志 · 用量策略
internal/ 下 37 个模块：scheduler、affinity、health、ratelimit、rpm、accessquota、requestlog、requestaudit、usagecost、pricing、outboundproxy、parameteroverride、webui…
Layer 3 · 上游渠道层
官方云平台 · 模型服务 · 订阅渠道 · 自定义中转
内置 30 个渠道模板：OpenAI / Anthropic / Gemini / xAI / Azure / Bedrock / Vertex、DeepSeek / Moonshot / SiliconFlow / 智谱…、Codex / Claude / Antigravity / Grok、OpenAI Compatible
开源底座：Bifrost Core（Apache-2.0，认证 / 请求响应转换 / 流式与用量归一化）· CLIProxyAPI（MIT，订阅渠道 OAuth 与执行适配）· Lobe Icons（界面图标）。调度、健康、亲和、日志与用量策略由 GPT-Load 自持。
核心机制
API Key 与订阅账号同一套体系
API Key 渠道
- 粘贴一个或多个 Key 即用
- 官方 API、云平台、模型服务、兼容中转
- 按 Key 计费，额度即余额
订阅渠道
- Codex、Claude、Antigravity、Grok
- OAuth 授权流或凭据导入接入
- 固定回调端口 1455 / 54545 / 51121（上游客户端决定）
关键在「统一」：两类凭据共享同一套调度、权重、重试、冷却、黑名单、会话亲和与健康体系——订阅账号被当成一等公民凭据参与流量分配，这是它区别于普通 API 网关的定位。
核心机制
调度与故障隔离
请求进入
→
按权重选凭据
→
失败 → 冷却
→
连续失败 → 拉黑
→
流量切到健康凭据
- 多凭据调度：可配置权重，按渠道容量分配流量
- 重试 / 冷却 / 黑名单：失败凭据先冷却，反复失败拉黑，避免砸向已知坏点
- 会话亲和：同一会话粘滞同一凭据，保住上游缓存命中与上下文连续性
- RPM 与配额限制：per-credential 速率与配额控制（ratelimit / rpm / accessquota 模块）
- 健康监测：分组总览页直接看凭据数量、流量与健康状态
支持范围
9 类客户端协议
| 协议 | 主要入口 |
|---|
| OpenAI Chat Completions | POST /v1/chat/completions |
| OpenAI Responses | /v1/responses 及其资源路径 |
| OpenAI Images / Embeddings | POST /v1/images/... · /v1/embeddings |
| Rerank | POST /v1/rerank |
| Mistral 原生 | /v1/ocr · /v1/audio/... |
| Anthropic Messages | POST /v1/messages |
| Gemini | /v1beta/models/... |
| Gemini Embeddings | :embedContent / :batchEmbedContents |
客户端用什么协议就接什么协议，网关负责转换到任意上游渠道——OpenAI SDK 的应用可以无感调用 Anthropic 订阅账号。
支持范围
协议转换与参数覆盖
- 覆盖先于转换：分组参数覆盖在协议转换前应用，按客户端协议填写普通参数（如 Responses 的 max_output_tokens 由 SDK 转成 Anthropic 的 max_tokens）
- Bifrost 负责对话转换：明确设置但 SDK 请求结构未定义的顶层字段作为扩展参数交给 SDK，不开启任意字段透传
- 语义安全：客户端自行附加的未知字段不因此获得透传能力，缓存标记保持原有行为
示例：Anthropic 分组中为 Responses 请求设置顶层缓存参数
[
{
"match": { "protocol": "openai-responses" },
"set": { "cache_control": { "type": "ephemeral" } }
}
]
传递缓存配置，不保证上游实际缓存命中。
支持范围
内置 30 个渠道模板
官方与云平台 ×7
OpenAI · Anthropic · Gemini · xAI · Azure OpenAI · AWS Bedrock · Google Vertex AI
模型服务 ×18
DeepSeek · Moonshot · SiliconFlow · 智谱 · Alibaba · Volcengine · OpenRouter · Groq · Cerebras · Mistral · Cohere · Hugging Face 等
订阅渠道 ×4
Codex · Claude · Antigravity · Grok——OAuth 接入订阅账号额度
自定义 ×1
OpenAI Compatible——任意兼容中转都能挂进来
另有 Models.dev 模型目录自动同步（MODELS_DEV_AUTO_SYNC_ENABLED），新模型信息保持最新。
核心能力
可观测与成本核算
- 用量统计：请求趋势、缓存命中率、Token 分类（输入 / 输出 / 缓存）与成本估算，管理界面开箱即用
- 请求日志：全量请求留痕，按凭据 / 分组回溯（requestlog 模块）
- 审计与脱敏：requestaudit / requestredact 模块支撑审计与敏感信息处理
- 成本估算体系：usagecost + pricing 模块，按牌价折算各渠道成本
- 数据自持：全部数据落在自己的 SQLite / MySQL / PostgreSQL，不经过第三方统计服务
快速上手
五分钟跑起来
# 启动服务（需 Docker）
git clone --depth 1 https://github.com/tbphp/gpt-load.git
cd gpt-load && cp .env.example .env
docker compose up -d
# 确认健康 + 读取首启管理密钥
curl --fail http://127.0.0.1:3001/health
docker compose exec gpt-load \
sh -c 'cat /app/data/auth.key'
- 第一步 · 添加渠道：选上游服务，填 API Key；订阅渠道走 OAuth 或凭据导入
- 第二步 · 创建 Group：选渠道，配置可用模型与运行策略
- 第三步 · 创建 AccessKey：设置允许的 Group 与客户端协议，交给应用
默认只监听 127.0.0.1，不暴露公网；也可在 .env 里显式指定 AUTH_KEY。
部署与数据
单二进制 · 三种数据库 · 五平台
- 单个 Go 二进制内嵌管理界面，无外部依赖即可跑；官方镜像 ghcr.io/tbphp/gpt-load:2
- 数据库随需切换：默认应用托管 SQLite（具名卷 gpt-load-data）；DATABASE_DSN 一行切换 MySQL / PostgreSQL
- 数据三件套：数据库 + auth.key + encryption.key 必须一起备份——密钥丢失后加密凭据无法恢复
- 五平台便携构建：Linux / macOS amd64 / arm64 / Windows 前台与安装器双形态
- Windows 服务化：setup 安装器注册低权限服务 + 开机自启 + 桌面快捷方式，卸载保留数据
- 合规供应链：每个 Release 附 CycloneDX SBOM，第三方声明与许可证全文入库
安全设计
凭据安全与暴露面控制
- 默认环回监听：HOST 默认 127.0.0.1，服务不直接暴露公网，要暴露自己显式配
- 管理面 / 数据面分离：AUTH_KEY 是管理界面 Bearer 密钥，AccessKey 才是给应用的数据面凭据，两者不混用
- 本地凭据加密：ENCRYPTION_KEY 加密渠道凭据后入库，明文不落盘
- 三级代理隔离：凭据 / Group / 全局各自可配出站代理（outboundproxy），环境代理仅兜底——不同上游可走不同出口 IP
- OAuth 回调端口可控：固定回调端口只发布在 HOST 指定地址上，SSH 远程场景复制完整回调 URL 即可完成授权
升级须知
2.0 是完整重写，不迁 1.x 数据
- 硬断代：2.0 不能打开、导入或原地迁移 1.x 数据，需独立数据库 / DATA_DIR / 端口 / 卷并行部署
- 迁移 SOP：验证完成再切业务流量，回滚窗口关闭前保留原 1.x 部署；1.4.x 维护线文档仍在官方文档站
- 镜像标签策略：:2 跟随已验证 2.x（GA 前含 Beta/RC），:2.0-beta 是 Beta 通道，:latest 继续留在 1.x
- 当前状态：v2.0.0-rc.38，GA 在即但尚未宣布稳定
评估
适合谁用 & 需要警惕
适合
- 同时持有多个 API Key 与多份订阅、想把额度榨满的个人 / 小团队
- Codex / Claude Code CLI 用户，想把订阅额度分享给团队或接入自建应用
- 多 Provider 应用需要统一入口 + 自动容错，又不想改造客户端代码
- 有数据自持要求：日志、用量、凭据全部留在自己机器上
警惕
- 2.0 尚在 RC：功能仍数日一迭代，生产采用需自担节奏
- 密钥不可恢复：encryption.key 丢失即凭据报废，且暂不支持主密钥轮换
- 单机单实例：OAuth 固定回调端口限制同机只能跑一个默认 Compose 实例
- ToS 灰区：订阅账号经 OAuth 中转属于上游服务条款灰色地带，商用需自查风险
- 网关自身单点：入口收敛后网关的高可用需要自己解决
在线体验
亲手玩一遍凭据调度器
搭一个 4 凭据的渠道池：调权重、调故障率、狂发请求，实时看加权选路、失败冷却、连败拉黑与会话亲和如何联动——把 GPT-Load 最核心的调度容错机制在浏览器里跑通。
▶ 打开凭据调度 Playground
潜力评估
未来空间
AI 网关赛道拥挤（LiteLLM、one-api、new-api），但「订阅账号与 API Key 同池调度」是 GPT-Load 最锐利的差异点——Claude Code / Codex CLI 的爆发让订阅额度整合成为真实刚需。7k stars、数日一版 RC、OpenAI 平台背书，GA 之后有机会成为自托管网关的主流选项之一。