GPT-Load 实测评估：一个把订阅账号和 API 密钥统一调度的自托管网关
Self-hosted AI gateway for multi-channel, multi-credential setups — API keys and subscription accounts, scheduling, failover, request logs and usage. 自托管 AI 网关：多渠道多凭据统一接入，含密钥与订阅账号、调度容错、日志与用量。
秒懂
- 它是什么？
- GPT-Load 是一个面向多渠道、多凭据场景的自托管 AI 网关，用统一入口管理 API 密钥和订阅账号。它的核心价值在于调度与容错，但 2.0 版本无法迁移 1.x 数据，部署前需要确认这一点。
- 适合谁用？
- GPT-Load 适合那些拥有多个上游渠道、多个 API 密钥或订阅账号，并且希望用一个统一入口管理调度、容错和用量的团队或个人开发者。它尤其适合使用 Codex、Claude、Antigravity 等订阅账号的场景，因为这些账号的凭据管理和健康检查被集成到了同一套机制中。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是凭据混乱，不是模型转发
很多团队卡在同一个问题上：应用要接 OpenAI、Anthropic、Gemini，每个上游又有多个密钥或订阅账号，某个密钥超限、某个账号被封，代码里就得写一堆重试逻辑。GPT-Load 把这一层抽出来，应用只需要一个 base URL 和一个 AccessKey。上游渠道、账号、凭据、模型和路由策略全部在管理界面里配。它的重点不是把请求转发到某个模型，而是让多个凭据在同一个调度机制下工作。订阅账号和 API 密钥走同一套凭据管理、调度和健康处理，这是它区别于普通反向代理的地方。对个人开发者来说，这可能只是省了几个环境变量；对需要稳定输出的小团队来说，这是把故障处理从业务代码里移出去的一种方式。
调度与容错的具体机制
README 列出了几个关键行为：多凭据调度、可配置权重、重试、冷却、黑名单和会话亲和。权重决定流量如何分配到不同账号或密钥，冷却让失败的凭据暂时休息，黑名单把反复出错的凭据踢出候选池，会话亲和则保证同一会话的请求尽量落在同一个凭据上。这些机制组合起来的效果是，某个上游过载或凭据失效时，网关能自动把流量切到其他可用凭据，而不是让应用层感知每一次抖动。需要指出的是，README 没有给出调度算法的细节，比如权重是轮询还是随机、冷却时间如何计算、黑名单是永久还是有时效。这些参数是否可调、默认值是多少，文档里没有展开。实际效果只能通过部署后观察日志和健康状态来验证。
部署与初始配置的真实步骤
官方推荐的启动方式是 Docker Compose。命令序列很直接：先克隆仓库，复制 .env.example 为 .env，然后 docker compose up -d。健康检查用 curl --fail http://127.0.0.1:3001/health。首次启动会生成一个管理密钥，存放在容器内的 /app/data/auth.key，你需要读取并妥善保存。也可以在 .env 里显式设置 AUTH_KEY。默认服务只监听回环地址，不暴露到公网，这对自托管是合理的安全默认。初始配置分三步：添加渠道，选择上游服务并填入 API 密钥或完成订阅账号的 OAuth 流程；创建组，从渠道中选择模型并配置运行策略；创建 AccessKey，指定该密钥可用的组和客户端协议。整个流程围绕管理界面展开，没有需要手写配置文件的地方。
订阅账号的 OAuth 回调端口是个硬约束
订阅渠道的 OAuth 客户端使用固定回调端口。Compose 默认在 HOST 配置的地址上发布这些端口，HOST 默认是 127.0.0.1。这意味着如果你在一台主机上运行多个默认 Compose 实例，端口会冲突，只能同时跑一个。若通过 SSH 或远程浏览器访问，浏览器里的 localhost 可能无法到达 GPT-Load，你需要把完整的回调 URL 粘贴到授权对话框里才能完成流程。这个限制不是 bug，而是上游客户端固定端口导致的。部署前必须确认主机上没有其他服务占用这些端口，并且远程访问场景下要准备好手动粘贴回调 URL 的流程。对于只用 API 密钥、不用订阅账号的用户，这个约束不适用，但 README 没有明确区分哪些渠道受影响，只提到 Codex、Claude 和 Antigravity 的 OAuth 客户端使用固定端口。
支持哪些客户端协议，边界在哪里
协议支持列表是判断适用范围的关键。README 列出了 OpenAI Chat Completions 的 POST /v1/chat/completions、OpenAI Responses 的 /v1/responses 及其资源路径、OpenAI Images 的 POST /v1/images/...、OpenAI Embeddings 的 POST /v1/embeddings，以及 Rerank 的 POST /v1/rerank。列表在 README 中被截断，后面可能还有更多条目，但无法确认。这意味着如果你依赖某个特定端点，比如 Assistants API 或微调接口，需要自行查阅最新文档。另外，客户端协议和上游协议是两回事。网关对外提供这些原生接口，但上游可以是官方 API、云平台、模型服务或兼容中继。这种设计让客户端无需改动即可切换上游，但上游是否支持某个模型或参数，网关不一定能感知。
可观测性：日志、用量与成本估算的呈现方式
管理界面内置了健康检查、路由、日志、用量和成本估算的视图。截图显示有分组总览、订阅账号状态、AccessKey 只读主页以及用量成本页。订阅账号页面可以查看可用性、配额窗口、重置时间和运行时诊断。用量成本页展示请求趋势、缓存命中率、token 分类和成本估算。AccessKey 只读主页允许用 AccessKey 登录后查看自己所属的组、模型、请求、用量和费用额度。这意味着你可以把 AccessKey 分发给应用所有者，让他们自查消耗，而不必暴露管理端。不过，成本估算的具体算法没有说明，比如价格表从哪里来、是否支持自定义单价。对于只关心请求量不关心费用的用户，这个功能可能多余，但对预算敏感的小团队来说，估算的准确性直接影响决策。
存储与加密：SQLite、MySQL 或 PostgreSQL 的选择
数据存储支持 SQLite、MySQL 或 PostgreSQL，凭据在本地加密。SQLite 适合单机部署，MySQL 或 PostgreSQL 适合需要多实例或集中管理的场景。README 没有详细说明加密实现，比如使用什么算法、密钥如何派生、是否依赖环境变量。本地加密意味着即使数据库文件泄露，凭据也不会直接明文暴露，但加密密钥本身必须妥善管理。如果密钥丢失，你可能无法恢复已保存的凭据。另一个实际问题是，2.0 版本无法打开、导入或迁移 1.x 数据。如果你已经在用 1.x，升级到 2.0 意味着需要重新添加渠道、创建组和 AccessKey。这不是平滑升级，而是重新配置。在决定采用 2.0 之前，必须确认这一点可以接受。
与同类方案的差异：不是又一个 OpenAI 代理
市面上有不少 AI 网关项目，但多数只处理 API 密钥的负载均衡。GPT-Load 的差异在于把订阅账号也纳入同一套调度体系。订阅账号通常有配额窗口和重置时间，这比 API 密钥的按量计费更复杂。README 提到订阅账号页面可以查看配额窗口和重置时间，说明网关不只是转发请求，还追踪账号的状态。另一个差异是会话亲和，这适合对话类应用，避免同一用户的请求被分散到不同账号导致上下文丢失。相比之下，一些更简单的代理只做轮询或随机分发，不考虑会话连续性。如果你只用 API 密钥且不需要会话亲和，更轻量的方案可能足够。但如果你依赖订阅账号，或者需要细粒度的冷却和黑名单控制，GPT-Load 的设计更贴合。
编辑结论
GPT-Load 适合那些拥有多个上游渠道、多个 API 密钥或订阅账号，并且希望用一个统一入口管理调度、容错和用量的团队或个人开发者。它尤其适合使用 Codex、Claude、Antigravity 等订阅账号的场景，因为这些账号的凭据管理和健康检查被集成到了同一套机制中。不适合的人群包括：只需要单一上游、单一密钥的简单代理用户，以及已经深度依赖 1.x 版本且无法接受重新配置成本的现有用户，因为 2.0 无法打开、导入或就地迁移 1.x 数据。在采用之前，你需要验证三件事：第一，确认你需要的上游协议在支持列表中，例如 OpenAI Responses、Images、Embeddings、Rerank 等是否覆盖你的调用方式；第二，检查订阅账号的 OAuth 回调端口是否与你的主机环境冲突，因为固定端口意味着同一台主机只能运行一个默认 Compose 实例；第三，明确你的存储后端选择，SQLite、MySQL 或 PostgreSQL 各有运维要求，且本地凭据加密机制需要你妥善管理加密密钥。如果你能接受这些前提，GPT-Load 的调度权重、冷却、黑名单和会话亲和机制值得实际测试。
社区笔记