核心概念
管理台里只有两个需要你操心的东西：分组和访问密钥。搞清它们各管什么，其余文档都好读了。
只有两层§
很多网关会让你分别管理「服务商」「密钥」「路由规则」。GPT-Load 把它们压成了两层：
- 分组——对接上游的一切：用哪个服务、拿哪些凭据、开放哪些模型、按什么策略跑
- 访问密钥——发给应用的东西：能用哪些分组、能用哪些协议、限额多少
一句话概括：分组朝上游，访问密钥朝应用。中间的调度、重试、冷却、计费统计， 网关自己完成，两边都不用管。
分组：朝上游的那一半§
一个分组把五件事绑在一起：
- 渠道——从内置的二十个上游里选一个，决定请求最终发到哪
- 接入方式——用 API 密钥，还是用订阅账号授权
- 凭据池——一个或多个密钥／账号，网关在它们之间轮转
- 可用模型——这个分组对外开放哪些模型
- 运行策略——权重、超时、重试次数、冷却阈值、出站代理
一个分组的全部内容就在这三个标签页里：凭据池、模型与别名、运行策略。
渠道不是单独建的§
管理台里没有「渠道」这个菜单。渠道是在「导入渠道凭据」的新建分组页中选择的—— 常用渠道直接显示为按钮，其余渠道在「其他渠道」里。选完 OpenAI 或 Anthropic， 这个分组就固定对接那个上游了。 想接两个不同的服务商，就建两个分组。
这么设计是因为：换服务商往往意味着凭据、可用模型、限流特征全都变了， 与其让你在三个地方分别改，不如让一个分组从头到尾对应一个上游。
两种接入方式，同一套调度§
建分组时要选接入方式，它决定凭据长什么样：
- API 密钥——粘贴一串或多串密钥，最常见的方式
- 订阅账号——走 OAuth 授权，用于 Codex、Claude、Antigravity、Grok 这类按订阅计费的账号
两者共用同一套调度、重试、冷却和健康隔离。也就是说， 你不需要为订阅账号单独维护一套运维逻辑，它们在网关眼里都只是「一池凭据」。 订阅账号的授权细节见 订阅账号。
访问密钥：朝应用的那一半§
访问密钥是你交给应用的那串字符。它不直接绑定任何上游， 只声明三件事：
- 能用哪些分组——可以选多个，网关按模型和健康状况决定实际走哪个
- 能用哪些协议——OpenAI Chat Completions、Responses、Anthropic Messages、Gemini
- 限额——每分钟请求数，以及成本上限（可以是不重置的总额度， 也可以是按周期重置的额度）
因为这层隔离，给不同应用发不同的密钥就变得很自然： 测试环境一把、生产一把、给同事一把，各自限额、各自吊销，互不影响。 细节见 访问密钥。
分组不出现在 URL 里§
1.x 需要把分组名拼进请求地址。2.0 不需要——应用只认一个固定的基础 URL， 用哪个分组由访问密钥的授权范围和请求里的模型名共同决定。
这意味着切换上游对应用是完全无感的：你在管理台里改分组配置、 增删凭据、甚至换一家服务商，应用那边的地址和密钥都不用动。
该建几个分组§
没有标准答案，但有两条实用的判断：
- 按上游分——这是硬性的，一个分组只能对接一个渠道
- 按策略分——同一个服务商，如果你想让一批密钥走高优先级、另一批做兜底， 或者两批密钥的超时和重试要求不同，那就拆成两个分组
反过来，同一个服务商的多把密钥不需要拆分组—— 直接扔进同一个凭据池，网关会自己轮转和避让。