基本概念

二層だけ§

多くのゲートウェイでは、「プロバイダー」「キー」「ルーティングルール」を別々に管理します。GPT-Load はこれらを2層に集約します：

• Group — 接続先のサービス、認証情報、公開モデル、実行ポリシーなど、アップストリーム接続に関するすべてを管理します。
• AccessKey — アプリケーションに渡すキーで、利用可能なGroup、プロトコル、上限を定義します。

要約すると、Groupはアップストリームに接続し、AccessKeyはアプリケーションを認可します。その間のスケジューリング、リトライ、クールダウン、使用量集計はゲートウェイが処理します。

Group：アップストリームに向かう側§

1つのGroupは5つのことを結びつけます：

1. チャネル — 20の組み込みアップストリームから1つを選び、リクエストの最終送信先を決めます。
2. 接続方式 — APIキーまたはサブスクリプションアカウント認可を選びます。
3. 認証情報プール — 1つ以上のキーまたはアカウントをまとめ、ゲートウェイがそれらを切り替えます。
4. 使用可能なモデル — このGroupが外部に公開するモデルです。
5. 運用ポリシー — ウェイト、タイムアウト、リトライ回数、クールダウンしきい値、アウトバウンドプロキシです。

クリックして表示

Groupの設定は、「認証情報プール」「モデルとエイリアス」「実行ポリシー」の3つのタブにまとまっています。

チャネルは個別に作成されない§

プロバイダーを変えると、認証情報、利用可能なモデル、レート制限の特性もまとめて変わることが一般的です。1つのGroupを1つのアップストリームサービスに対応させることで、3か所を個別に変更せずに済みます。

二種類の接続方法、同じスケジューリング§

Groupを作成するときは、認証情報の種類を決める接続方式を選びます：

• APIキー — 1つ以上のキーを貼り付ける最も一般的な方式です。
• サブスクリプションアカウント — Codex、Claude、Antigravity、Grok などのサブスクリプション型アカウントを OAuth で認可します。

どちらも同じスケジューリング、リトライ、クールダウン、健全性分離の仕組みを共有します。サブスクリプションアカウント専用の運用ロジックは不要で、ゲートウェイから見れば同じ認証情報プールの一部です。認可の詳細はサブスクリプションアカウントを参照してください。

AccessKey：アプリ側の半分§

AccessKeyはアプリケーションに渡す文字列です。アップストリームに直接紐づかず、次の3点だけを定義します：

• 使用可能なGroup — 複数選択できます。ゲートウェイがモデルと健全性に基づいて実際のGroupを選びます。
• 使用可能なプロトコル — OpenAI Chat Completions、Responses、Anthropic Messages、Gemini
• 制限額 —— 毎分リクエスト数と、コスト上限（リセットされない総額か、周期ごとにリセットされる額）

この分離により、テスト環境、本番環境、利用者ごとに別のキーを発行できます。各キーの上限と失効は独立しており、互いに影響しません。詳細はAccessKeyを参照してください。

URLにはGroupが表示されません§

つまり、アップストリームの切り替えはアプリケーションに対して完全に透過的です。Group設定の変更、認証情報の追加・削除、プロバイダーの変更を行っても、アプリケーション側のエンドポイントとキーは変わりません。

作成するGroupの数§

一律の答えはありませんが、次の2つが実用的な基準になります：

• アップストリーム別に分ける — これは必須条件で、1つのGroupは1つのチャネルにだけ接続できます。
• ポリシー別に分ける — 同じプロバイダーでも、キーの優先度、フォールバック用途、タイムアウト、リトライポリシーが異なる場合はGroupを分けます。

一方、同じプロバイダーの複数のキーをGroupに分ける必要はありません。同じ認証情報プールにまとめれば、ゲートウェイがローテーションと障害回避を行います。