このプロジェクトを支えるパートナー
GPT-Load は MIT ライセンスのオープンソースです。インフラ、モデルクレジット、開発時間はスポンサーの支援によって成り立っています。
ゲートウェイが代わりに処理する 6 つのこと
本来なら各アプリケーションが個別に実装するか、障害が起きるまで後回しにしがちな処理です。ゲートウェイに一度実装すれば、すべてのクライアントが恩恵を受けます。
一つのスケジューラー、二種類の認証情報
API キーと Codex、Claude、Antigravity、Grok のサブスクリプションアカウントを同じプールに入れ、スケジューリング、リトライ、クールダウン、健全性分離を共通化します。
クライアントはネイティブプロトコルのまま
OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini ネイティブの 4 プロトコルをそのまま通します。既存の SDK、CLI、デスクトップクライアントは通常、Base URL と AccessKey を変更するだけです。
障害を自動的に切り離す
重み付きローテーション、セッションアフィニティ、リトライ、クールダウン、自動ブラックリストにより、制限中または無効な認証情報の影響を経路全体から分離します。
すべての呼び出しを観測可能
健全性、ルート検査、リクエストログ、使用量集計、モデル別コスト概算を、実際に処理した認証情報まで追跡できます。
一つのバイナリ、データは自分で管理
管理画面は Go バイナリに組み込まれています。SQLite で始め、必要に応じて MySQL または PostgreSQL を使用できます。上流認証情報はローカルで暗号化され、第三者を経由しません。
20 チャネルをすぐに利用可能
公式 API、クラウド基盤、モデルサービス、サブスクリプションを内蔵し、任意の OpenAI 互換中継向けカスタムチャネルも用意しています。アダプターを書く代わりにフォームへ入力するだけです。
4 プロトコルから 20 チャネルへ
クライアントが使用するプロトコルと、最終的にリクエストを受け取る上流の両方をゲートウェイが処理します。アプリケーションはルーティングの詳細を意識しません。
- OpenAI
- Anthropic
- Gemini
- xAI
- Azure OpenAI
- AWS Bedrock
- Google Vertex AI
- DeepSeek
- Moonshot AI
- SiliconFlow
- Zhipu AI
- Alibaba Cloud
- Volcengine
- OpenRouter
- Groq
- Codex
- Claude
- Antigravity
- Grok
3 ステップで設定完了
管理する対象は二つだけです。Group は上流向け、AccessKey はアプリケーション向けです。その間のスケジューリング、リトライ、使用量集計はゲートウェイが処理します。
Group を作成
上流チャネルを選び、API キーを登録します。Codex や Claude などのサブスクリプションアカウントは OAuth 認可後、同じスケジューラーに入ります。
公開モデルを選択
この Group が公開するモデルを選び、上流から自動検出します。必要に応じてウェイト、タイムアウト、リトライなどの実行ポリシーも調整できます。
AccessKey を発行
利用可能な Group とクライアントプロトコルを指定し、レートやコスト上限を設定して、生成されたキーをアプリケーションへ渡します。アプリ側で必要なのはこれだけです。
1 コマンドで起動、クライアントは 2 項目だけ変更
外部データベースもフロントエンドの個別デプロイも不要です。管理画面は同じバイナリに組み込まれています。
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'
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 クエリパラメーター。
5 つのビルド対象
Linux と macOS はそれぞれ amd64 と arm64、Windows は amd64。ダウンロードしたバイナリは付属の SHA256SUMS で検証してから実行してください。Windows にはサービスとして登録できるインストーラーもあります。
SQLite で始め、必要に応じて変更
DATABASE_DSN を空にすると管理対象 SQLite を使用し、DSN を設定すると外部 SQLite、MySQL、PostgreSQL を使用できます。
キーとデータベースを一緒に保管
encryption.key はチャネル認証情報の復号に必要です。紛失または置換すると暗号化済み認証情報は復元できず、このバージョンではマスターキーのローテーションをサポートしません。
設定と可観測性を一か所に
管理画面はバイナリと一緒に配布されます。ブラウザーからチャネル設定、健全性とログの確認、使用量とコスト概算の確認ができます。
クォータ期間、リセット時刻、可用性、クールダウンを一画面で確認できます。クォータ情報は表示専用で、実際のルート切替は上流のレート制限応答によって行われます。
リクエストの成否傾向、キャッシュヒット、トークン分類、コスト概算に加え、欠落データや価格未設定モデルなど使用量データ自体の品質も確認できます。
本番利用前に確認する 3 点
使用量とコストは概算
上流応答から算出した運用分析・容量計画向けの値です。プロバイダー請求書ではなく、会計照合には使用できません。価格変更時も過去データは再計算されません。
単一アプリケーションインスタンス向け
2.0 は単一インスタンス内の正しさを保証します。インスタンス間で状態を共有せず、水平スケールはサポートしません。大規模な場合は業務単位で独立したデプロイに分割してください。
1.x からのインプレース更新は不可
2.0 は完全な再実装で、1.x データを開く、インポートする、その場で移行することはできません。別のデータベース、DATA_DIR、ポート、ボリュームでデプロイし、検証後にトラフィックを切り替えてください。
サービスは既定で 127.0.0.1 のみを待ち受け、公開ネットワークには露出しません。リモートアクセスには、適切な ACL とファイアウォールを設定した管理ネットワークまたは TLS リバースプロキシを使用してください。AUTH_KEY と ENCRYPTION_KEY をリポジトリ、ログ、スクリーンショット、公開 issue に記載しないでください。