グループルーティングで LLM API コストを下げる方法

結論から言うと、ゲートウェイでは同じモデルでも、キーがどのグループを使うかによって料金が変わります。そして適切なグループを選ぶほうが、安いモデルに乗り換えるよりも節約効果が大きいことがよくあります。HopBase のグループはサービス品質と価格のバランスで分かれています。安定型は複数ソースの冗長化とリクエスト単位の自動フェイルオーバーを備えた標準料金、高速型は初回トークンのレイテンシを優先するやや高めの料金、低価格型は最安料金ですがピーク時に待ちが発生する場合があります。同じモデルを提供する 2 つのグループは 1 本のキーに同居できないため、ティアごとにキーを分け、キーを差し替えるかコンソールでキーのグループを編集して切り替えます。コードの変更は不要です。個人開発者ならコーディングは安定型、テストやバッチスクリプトは低価格型。チームなら本番は安定型、CI は低価格型。大量のコンテンツ処理はオフピークに低価格型で回せます。最適化の順番は、まずプロンプトキャッシュによる節約を確保し、次に適切なグループを選び、モデルの変更を検討するのはその後です。

LLM API のコストを最適化しようとすると、多くの人がまず「もっと安いモデルを選ぼう」と考えます。しかし私たちが実際の請求データを見る限り、大きな節約は「同じモデルで、ルーティング経路を変える」ことから生まれる場合がほとんどです。本記事では、グループルーティングの仕組みと、利用パターンに合ったコスト削減設定の詰め方を解説します。

グループとは？

ゲートウェイは、モデルへのアクセスを「サービス品質 × 価格」でグループに整理しています。同じモデルでも、どのグループのキーを使うかで料金が変わります。下表は代表的な 3 種類のグループで、コンソール上の実際のグループ名はこれとは異なります。

1 本のキーには 1 つ以上のグループを含められますが、同じモデルを提供する 2 つのグループは同じキーに入れられません。そのため、同じモデルの異なるティアは別々のキーで管理します。ティアの切り替えにコード変更は不要で、使うキーを差し替えるか、コンソールでキーのグループを変更するだけです。

自動フェイルオーバーとは？

安定型グループは冗長化された経路で動いています。ある経路がレート制限を受けたり不安定になったりすると、ゲートウェイがリクエスト単位で自動的に切り替えます。呼び出し側から見えるのは「今の 1 回は少し遅かった」程度で、5xx エラーは返りません。リトライ処理やサーキットブレーカー、複数ベンダー向けのアダプターを自前で書く必要はありません。それこそがゲートウェイを使う意味です。

3 つのタイプ別のおすすめ設定

1. 個人開発者：コーディング用に安定型のキーを 1 本、テスト実行やバッチスクリプト用に低価格型のキーをもう 1 本。キー 2 本で請求の内訳が分かれ、コストの内訳が一目瞭然です。
2. 小規模チーム：役割（フロントエンド、CI、本番）ごとにキーを配布します。本番は安定型、CI は低価格型。CI ではキャッシュ割引を最大限に受けられるため、請求額がほぼ無視できる水準まで下がることもよくあります。
3. コンテンツ／データの大量処理：すべて低価格型経由にし、バッチ実行をオフピークの時間帯に組みます。時間的にシビアな最終検証だけ安定型に回します。

コスト最適化の順番

第一に、キャッシュ割引を確保する（プロンプトの書き換えだけで、コストはゼロ）。第二に、適切なグループを選ぶ（アーキテクチャ上の判断で、設定は一度きり）。第三に、モデルの変更を検討する（品質とのトレードオフがあるので慎重に）。この順番で進めれば、品質を犠牲にせずにほとんどの請求額がはっきり下がります。使用記録のページは嘘をつきません。