v2.0 / 自托管 AI 网关 / MIT

一个入口,
接管所有
渠道与凭据

二十个渠道、几十个凭据、四种客户端协议,全都收在一个基础 URL 后面。调度、重试、冷却、用量核算在网关里做完,应用只需配置基础 URL 和访问密钥。

你的应用1 个基础 URL1 个 AccessKey认证GPT-LOAD调度 / 重试 / 冷却会话亲和 / 日志 / 用量官方 API4 个渠道云平台3 个渠道模型服务8 个渠道订阅账号4 个渠道图 1 — 路由已路由 → 官方 API0 次请求
20
内置渠道
4
客户端协议
1
Go 二进制
2
接入配置
SQLite / MySQL / PostgreSQL凭据本地加密落盘 · 请求发往所选上游
01支持

这个项目由他们支持

GPT-Load 以 MIT 协议开源。服务器、模型额度和开发时间,来自下面这些赞助方。

02能力

它替你处理的六件事

这些事本来要在每个应用里各写一遍,或者干脆不写、出问题再说。放进网关之后,写一次,所有客户端都受益。

01

一套调度,两种凭据

API 密钥和订阅账号(Codex、Claude、Antigravity、Grok)进同一个池子,共用同一套调度、重试、冷却与健康隔离,不用为订阅账号单开一套运维。

02

客户端不改协议

OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini 原生,四种协议原样透传。已有的 SDK、CLI、桌面客户端通常只需修改基础 URL 和访问密钥。

03

坏了自己切走

加权轮转、会话亲和、失败重试、过热冷却、连续报错自动拉黑。单个凭据限流或失效,不会拖垮整条链路,也不需要你半夜起来改配置。

04

每一次调用都看得见

健康状态、路由检查、请求日志、用量汇总、按模型的成本估算。哪个凭据在扛量、哪个在冷却、钱花在哪个模型上,都能查到具体那一条。

05

一个二进制,数据在你手里

管理台内嵌在同一个 Go 二进制里,SQLite 默认起步,也可以接 MySQL 或 PostgreSQL。渠道凭据在本地加密落盘,不经过任何第三方。

06

二十个渠道开箱可用

官方 API、云平台、模型服务、订阅账号都已内置,再加一个自定义渠道兜住任意 OpenAI 兼容中转。添加渠道是填表,不是写适配器。

03渠道与协议

四种协议进来,二十个渠道出去

客户端用什么协议进来、请求最终发到哪个上游,两件事都在网关里解决,应用不用关心。

按这些协议进来
OpenAI Chat Completions
POST /v1/chat/completions
最通用的入口,绝大多数兼容客户端走这条
OpenAI Responses
/v1/responses/**
按命名空间边界透传,支持有状态请求
Anthropic Messages
POST /v1/messages
Claude Code 等客户端的原生入口
Gemini
/v1beta/models/…
含 generateContent 与流式变体
发往这些上游
官方 API4
  • OpenAI
  • Anthropic
  • Gemini
  • xAI
云平台3
  • Azure OpenAI
  • AWS Bedrock
  • Google Vertex AI
模型服务8
  • DeepSeek
  • Moonshot AI
  • SiliconFlow
  • 智谱 AI
  • 阿里云
  • 火山引擎
  • OpenRouter
  • Groq
订阅账号4
  • Codex
  • Claude
  • Antigravity
  • Grok
+ 自定义渠道 — 任意 OpenAI 兼容中转渠道与协议文档 →
04接入

三步配完,之后不用再动

要管的只有两样东西:分组朝上游,访问密钥朝应用。中间的调度、重试、计费统计,网关自己完成。

01

建一个分组

选一个上游渠道,把 API 密钥粘进去。Codex、Claude 这类订阅账号则走 OAuth 授权,之后共用同一套调度。

分组 → 渠道 + 凭据池
02

选开放的模型

勾选这个分组对外提供哪些模型,可以从上游自动发现。顺手还能调权重、超时、重试这些运行策略。

分组 → 模型 + 策略
03

发一把访问密钥

指定它能用哪些分组、哪些客户端协议,设好限流和成本上限,把生成的密钥交给应用。这是应用唯一需要知道的东西。

访问密钥 → 授权 + 限额
05上手

一条命令起服务,客户端改两行

不需要数据库、不需要单独部署前端。管理台内嵌在同一个二进制里。

① 起服务Docker Compose
git clone --depth 1 --branch v2 \
  https://github.com/tbphp/gpt-load.git
cd gpt-load && cp .env.example .env
docker compose up -d

# 取出首次生成的管理密钥
docker compose exec gpt-load \
  sh -c 'cat /app/data/auth.key'
② 接客户端Python — OpenAI SDK
client = OpenAI(
    base_url="http://127.0.0.1:3001/v1",   # 改这行
    api_key="sk-gl-••••a5df",               # 改这行
)

# Anthropic 客户端走 /v1/messages
# Gemini 客户端走 /v1beta/models/…

认证方式按各客户端原本的习惯来:Authorization: Bearer · x-api-key · x-goog-api-key · Gemini key 查询参数都支持。

原生二进制

五个构建目标

Linux 与 macOS 各有 amd64、arm64,Windows 为 amd64。下载后先用随附的 SHA256SUMS 校验,再直接运行;Windows 另有可装成服务的安装包。

数据库

SQLite 起步,随时可换

留空 DATABASE_DSN 使用受管 SQLite;填入 DSN 即可切到外部 SQLite、MySQL 或 PostgreSQL。

备份

密钥和数据库要一起备

encryption.key 用于解密渠道凭据。密钥丢失或被替换后,已加密的凭据无法恢复,本版本不支持主密钥轮换。

完整步骤与更多客户端配置快速开始 →
06管理台

配置和观测在同一个地方

管理台随二进制一起分发,不需要另外部署前端。打开浏览器就能配渠道、看健康、查日志、算成本。

FIG. 2 — 订阅账号额度窗口 · 状态 · 诊断

订阅账号的额度窗口、重置时间、可用与冷却状态一屏看完。额度信息只作展示,真正触发切换的是上游的限流响应。

FIG. 3 — 用量与成本请求 · Token · 估算

请求量与成败趋势、缓存命中、Token 分类明细、成本估算,以及用量数据本身的完整度——缺了多少条、哪些模型还没有价格。

07边界

上生产之前,先看这三条

成本

用量与成本是估算

依据上游返回值推算,用于运营分析和容量规划,不等于服务商账单,也不能作为财务对账依据。价格变更不回算历史数据。

规模

面向单应用实例

2.0 只保证单实例正确性。实例之间不共享状态,不支持水平扩展。需要更大规模时,按业务维度拆成多个独立部署。

升级

1.x 不能原地升级

2.0 是完全重写,无法打开、导入或迁移 1.x 数据。请用独立的数据库、DATA_DIR、端口和卷部署,验证通过后再切流量。

网络边界

服务默认只监听 127.0.0.1,不对公网开放。需要远程访问时,请通过受控网络或 TLS 反向代理暴露,并配置好 ACL 与防火墙规则。AUTH_KEY 与 ENCRYPTION_KEY 请妥善保管,不要提交到仓库、日志、截图或公开 issue 中。

GPT-Load — 自托管 AI 网关