HopBase結論から言うと、LLM API の高同時実行性は、ゲートウェイがリクエストをどれだけ速く転送できるかの問題ではありません。重なり合う 3 つの制約——希少な上流クォータ(厳格な RPM/TPM 上限)、日常的に起きる上流側エラー(429 や 5xx は事故ではなく毎日の天気のようなもの)、長時間続くリクエスト(ストリームは数十秒、動画ジョブは数分)——の問題です。したがって可用性はスケジューリングから生まれます。冗長なキャパシティ、エラーをスケジューリングのシグナルとして扱うフェイルオーバー、そして負荷がかかってもキャッシュヒットを保つアフィニティです。単にリクエストをプロキシするだけのゲートウェイは、これらの制約をすべて引き継ぎ、そのままアプリケーションに押し付けます。スケジューリングを行うゲートウェイ——冗長なルート間でキャパシティを集約し、分類可能なエラーを別ルートで再試行し、プロンプトキャッシュがヒットし続けるようセッションを固定する——は、それらを吸収します。3 つの仕組みはいずれも契約前に検証でき、再現可能なチェックリストを末尾に掲載しています。
LLM API の同時実行は従来の API の同時実行とは違う
- リクエストの寿命が長い。ストリーミングのチャットは数十秒間コネクションを保持し、動画生成ジョブは数分かかります。キャパシティを消費するのは QPS ではなく、同時に処理中のコネクション数です。
- 上流のクォータが希少なリソース。どのモデル API アカウントにも厳格な RPM/TPM の上限があります。単一アカウントで本番のピークを乗り切ることはできず、実際の同時実行性は集約された冗長キャパシティから生まれます。
- 上流側のエラーは平常運転。レート制限、5xx の断続的な発生、ラッシュアワーの混雑は、どの LLM API にも存在します。ゲートウェイが何もしなければ、すべての呼び出し元がそれをそのまま受け止めることになります。
従来のゲートウェイはスループットで競います。LLM ゲートウェイはスケジューリングで競います。評価すべきはスケジューラーです。
冗長グループ：同時実行性の本当の源泉
HopBase はグループ単位でスケジューリングします。1 本の API キーは冗長キャパシティに支えられたグループに対応するため、スループットは単一アカウントの上限ではなく、グループ全体のキャパシティの合計になります。実務では次のように使います。
- 事業ラインやチームごとにグループを分け、バッチジョブが対話型トラフィックを圧迫しないようにする。
- ピーク時のワークロードには専用グループを割り当て、独立してスケールさせる。
- モデルやルーティングの切り替えはゲートウェイ側で行い、クライアントのコードは一切変更しない。
同じ仕組みはコスト削減にも効きます。詳しくはグループ単位のルーティングをご覧ください。
フェイルオーバー：エラーはスケジューリングのシグナルであり、あなたの問題ではない
多くのゲートウェイは上流のエラーをそのまま返し、再試行をクライアント任せにします。その結果、上流の不安定さがすべての呼び出し元に増幅されて伝わります。私たちのアプローチは次のとおりです。
- 上流のエラーはまずスケジューリングの判定に入ります。5xx だけでなく、分類可能な 4xx レスポンスの大半も別ルートへの自動フェイルオーバーを引き起こします。
- 再試行を使い切った後にはじめて、上流の元のレスポンスをそのまま返します。エラーコードを握りつぶしたりタイムアウトに書き換えたりすることはないため、お客様側のバックオフ処理はそのまま機能します。
- 課金は実際の出力に従います。出力を生成せずに失敗したリクエストは課金されません。出力の生成後に中断したリクエスト(クライアントの切断など)は生成済みの使用量分が課金され、使用量エクスポートに 1 行ずつ明記されます。
プローブとイベントストリーム：ユーザーより先に問題を見つける
- 常駐のヘルスプローブがすべてのルートを継続的にテストします。
- 各ルートはエラー/復旧のイベントストリームを出力し、劣化したルートは自動的に重みを下げられるか外され、復旧後にサービスへ戻ります。
- 生死の判定は感覚ではなく、実際の認証情報を使った直接の A/B テストで行います。
キャッシュアフィニティ：同時実行のためにプロンプトキャッシュを犠牲にしない
プロンプトキャッシュがヒットするには、リクエストが同じバックエンドアカウントに届く必要があります。多数のアカウントにリクエストをばらまく素朴な負荷分散では、ヒット率はゼロに近づき、同時実行性とキャッシュによる節約が設計上両立しなくなります。解決策はアフィニティスケジューリングです。セッションは 1 つのアカウントに固定され、アフィニティのウィンドウは公式のキャッシュ TTL より長く保たれ、スケールアウトしても稼働中のセッションが組み替えられることはありません。キャッシュヒットは二重に効きます。割引されたキャッシュ読み取り料金と、目に見えて短くなる初回トークンまでの時間(TTFT)です。詳しくはプロンプトキャッシュのガイドをご覧ください。
同時実行下でゲートウェイを検証する方法(再現可能)
- 分布を見る負荷テスト：固定のタスクセット、temperature 0、N 並列で実行し、平均ではなく TTFT の P95/P99 を読みます。裾が太ければキューイングが起きています。
- 長文出力の途切れ率：長い出力を要求し、ストリームの途中で黙って切れる割合を測ります。これは最悪の故障モードです。
- エラーのパススルー：意図的にレート制限や不正なパラメータを発生させ、エラーコードを公式の挙動と比較します。
- キャッシュヒット率：同じ長いシステムプロンプトでリクエストを繰り返し、使用量に占めるキャッシュ読み取りの割合を確認します。
- 時間帯を変えて再テスト：ピーク時とオフピーク時の両方で測り、時間帯による劣化を捉えます。
モデルの同一性と品質の検証(すり替えや黙った性能劣化への対策)は別の手法です。忠実度テストをご覧ください。
よくある質問
HopBase はどの程度の同時実行に対応していますか？
キャパシティはワークロードごとに見積もります。バッチパイプライン、共有の開発環境、複数事業のピークが設計上の想定です。導入前にご相談いただければ、負荷に合わせてグループを設計します。
なぜ稼働率のパーセンテージを公開しないのですか？
ランディングページに書かれた数字は、お客様自身では検証できません。私たちは、お客様がご自身でテストできる再現可能な検証方法と、透明なチャネル属性(料金ページに表示)を重視しています。契約上のサービス条件については、担当コンサルタントが対応します。
すべてのルートが失敗したらどうなりますか？
冗長化によって、単一障害点の故障は部分的な劣化に変わります。極端なケースで再試行を使い切った場合、ゲートウェイは上流の元のエラーをそのまま返します。成功を偽装することはなく、出力を生成せずに失敗したリクエストが課金されることもありません。
スケールアウトするとキャッシュヒット率は下がりますか？
下がりません。アフィニティによってセッションはアカウントに固定されます。スケールアウトは新しいセッション向けにキャパシティを追加するだけで、既存のセッションを組み替えることはありません。
エンタープライズ導入や同時実行のキャパシティ見積もりについてはお問い合わせください。接続の詳細はドキュメントをご覧ください。