LLM フォールバック ルーティングは、プライマリ ルートがリクエストを適切に完了できない場合に、AI API リクエストを代替ルートに送信する方法です。代替ルートは、別のリージョンの同じモデル、別のデプロイメント、別のプロバイダー、セカンダリ API キー、より小さいモデル、プレミアム緊急モデル、または非ストリーミング パスである可能性があります。フォールバック ルーティングをうまく使用すると、すべてのアプリケーション チームがプロバイダー固有の回復ロジックを手動でコーディングする必要がなく、可用性が向上します。
難しいのは、LLM リクエストが通常の HTTP 呼び出しではないことです。失敗した世代でもレート制限容量を消費する可能性があります。ストリーミングされた回答には、すでにコンテンツがユーザーに表示されている場合があります。エージェント ツールの呼び出しを再試行すると、購入、電子メール、チケット、またはデータベースへの書き込みが重複する可能性があります。フォールバック モデルは、タスク コントラクトに違反したり、スキーマを無視したり、ツールのサポートを失ったり、低品質の推論を生成したりしながら、有効な HTTP 200 応答を返す可能性があります。したがって、信頼性の高い LLM API フェイルオーバー設計では、再試行ポリシー、モデルの互換性、レイテンシ バジェット、コスト管理、可観測性、チーム ガバナンスを調整する必要があります。
このガイドでは、運用パターンとして LLM フォールバック ルーティングを設計する方法について説明します。いつ再試行するか、いつフェールオーバーするか、フォールバック モデルの選択方法、再試行ストームを回避する方法、セマンティクスを保持する方法、Model Gate などのマルチモデル ゲートウェイが API アクセス、請求属性、API キー管理、分析、ルーティング決定に関するチーム制御を一元化する方法について説明します。
LLM フォールバック ルーティングの実際の内容means
フォールバック ルーティングは、「モデル A がダウンしている場合はモデル B を試す」よりも広範です。実稼働 AI システムでは、ルートは通常、リクエストされたモデルのエイリアス、解決されたプロバイダー モデル、プロバイダー アカウント、API キー、リージョン、エンドポイント タイプ、ストリーミング モード、クォータ バケット、価格レベル、安全性ポリシー、リクエスト パラメーターなどのいくつかの要素の組み合わせです。フォールバックは、プライマリ ルートが利用できない、過負荷になっている、遅すぎる、予算を超えている、リクエストがサポートされていない、または検証に失敗した場合に、これらの選択肢の 1 つ以上を変更します。
単純なフォールバック チェーンは次のようになります。チャット リクエストをプライマリ モデルに送信し、一時的な 503 で 1 回再試行し、合計期限がまだ許せば互換性のあるセカンダリ モデルに移動します。より成熟したポリシーでは、ヘルス スコアリング、サーキット ブレーカー、テナント レベルの許可リスト、支出制限、試行ごとのタイムアウト、チャット、コード生成、抽出、RAG、エージェント ワークフロー、バッチ ジョブ用の個別のフォールバック グループを使用する場合があります。
目標は、試行回数を最大化することではありません。目標は、定義された信頼性、遅延、コスト、および品質の範囲内でユーザーのリクエストを完了することです。場合によっては、より小さなモデルが最適なフォールバックとなります。場合によってはプレミアムモデルになることもあります。キューに入れられたバッチ パスである場合もあります。場合によっては、フェール クローズして、使用可能な準拠ルートが存在しないことをアプリケーションに通知するのが正しい動作である場合があります。
再試行はフォールバックと同じではありません
再試行とは、通常、同じルートに対する別の試行を意味します。フォールバックとは、ルートを変更することを意味します。再試行とフォールバックは異なる障害モードを解決するため、この区別は重要です。
再試行は、ネットワーク タイムアウト、一時的な過負荷、一部の 408 応答、一部の 429 応答、および一部の 5xx 応答など、同じルートがすぐに成功する可能性が高い一時的な障害に適しています。プロバイダーのガイダンスでは、通常、Retry-After が存在する場合はそれを尊重し、ジッターを伴う指数バックオフを使用し、再試行回数と合計再試行時間の両方を制限することを推奨しています。公式 SDK は対象となる 429 および 503 レスポンスをすでに再試行している可能性があるため、アプリケーション レベルの再試行ではそれを考慮する必要があります。
同じルートがリクエスト期限内に回復する可能性が低い場合、またはリクエストをもう満たすことができない場合は、フォールバックが適切です。例には、地域的な停止、クォータ バケットの枯渇、異常な展開、無効なモデル、プロバイダー インシデント、互換性のない機能、プライマリ ルートを除外するポリシーの決定などがあります。AI モデルのフォールバック ルーティングは、プレミアム容量が制限されている場合に、低リスクの要約タスクをより安価なモデルに移動するなど、制御された低下にも使用できます。
よくある失敗は、予算を共有せずに両方のパターンを組み合わせることです。 SDK が 3 回再試行し、アプリケーションが 3 回再試行し、ゲートウェイが 3 回再試行し、キュー ワーカーがジョブ全体を再試行すると、1 つのユーザー リクエストが数十のアップストリーム呼び出しに変わる可能性があります。これにより、レート制限が悪化してコストが増大し、停止からの回復が困難になる可能性があります。
ハードコーディングされたリストではなく、ルーティング ポリシーから開始します
耐久性のあるモデルのフォールバック戦略は、明示的なポリシー オブジェクトから始まります。ポリシーでは、プライマリ ルート、フォールバック候補、適格性ルール、再試行可能なエラー クラス、合計期限、試行ごとのタイムアウト、最大試行、フォールバック無効化制御、およびロギング要件を定義する必要があります。また、何が成功とみなされるのかも定義する必要があります。構造化された抽出タスクの場合、成功するには有効なスキーマが必要な場合があります。エージェント ワークフローの場合、成功するには、世代の回復とツールの実行を分離する必要がある場合があります。ストリーミング チャット リクエストの場合、成功には最初のトークンのタイミングと、フォールバックがまだ安全かどうかの明確な境界が必要な場合があります。
実際的なポリシーには次のものが含まれます。
- プライマリ ルート: 優先モデル、プロバイダー、リージョン、キークラス、またはモデル エイリアス。
- フォールバック グループ: 同じ機能プロファイルを満たす順序付けされた候補またはスコア付けされた候補。
- 再試行予算: 1リクエスト パス内のすべての再試行とフォールバック試行に対するエンドツーエンドの予算。
- エラー分類: どのエラーが再試行可能で、どのエラーがフォールバックをトリガーし、どのエラーが直ちに失敗する必要があるか。
- 互換性契約: 必要なエンドポイントの形状、コンテキストの長さ、モダリティ、ツールのサポート、構造化出力のサポート、ストリーミング動作、安全性の制約、および応答形式。
- コスト ルール: リクエストがエスカレートする可能性があるかどうか
- ガバナンス ルール: テナント許可リスト、チーム権限、リージョン制限、保持要件、およびキーレベルの予算制約。
- オブザーバビリティ ルール: 試行されたすべてのルートについて記録する必要があるメタデータ。
これらのルールを明示的に維持することで、フォールバック動作をレビュー可能にします。また、すべてのリクエスト タイプに 1 つのグローバル チェーンを強制するのではなく、異なるワークロードに異なるポリシーを適用することも可能になります。
行動する前に障害を分類する
信頼できる LLM API ルーティングは適切なエラー分類に依存します。すべての失敗した応答が再試行に値するわけではなく、すべてのエラーが同じフォールバック ルートを使用する必要があるわけでもありません。
適切な再試行候補
再試行候補は通常、一時的でルートローカルです。これらには、一時的なネットワーク エラー、応答を受信する前の接続リセット、リクエスト タイムアウト、一部の 408 応答、プロバイダーの過負荷、一部の 429 レート制限応答、および 5xx エラーが含まれます。 429 応答の場合、アプリケーションまたはゲートウェイは、Retry-After などのプロバイダーのガイダンスが利用可能な場合には従う必要があります。バックオフにはジッターを含めて、多くのクライアントが同時に再試行しないようにする必要があります。
適切なフォールバック候補
フォールバック候補には、プライマリ プロバイダーの停止、持続的な 5xx レート、割り当てバケットの使い果たし、リージョンの健全性障害、既知の不正な展開、使用不可のモデル、トラフィックの急増、または機能チェックに失敗したルートが含まれます。429 は、制限の有効期間が短い場合は再試行をトリガーするか、割り当てバケットが枯渇し、別の承認されたバケットまたはプロバイダがリクエストを満たすことができる場合はフォールバックをトリガーする可能性があります。
通常は再試行すべきではないエラー
認証の失敗、不正な形式のリクエスト、無効なモデル ID、サポートされていないパラメーター、ポリシーの拒否、クレジットの不足、権限の欠落、コンテキスト オーバーフロー、互換性のないツール スキーマでは、通常、構成またはリクエストの変更が必要です。再試行すると、多くの場合、信頼性は向上せずに余分なコストとノイズが発生します。これらのエラーの一部は、フォールバック ルートが正確なリクエスト コントラクトをサポートすることがわかっており、ポリシーで許可されている場合にのみ、代替ルートをトリガーする可能性があります。
人気ではなく機能に基づいてフォールバック グループを構築する
フォールバック モデルは、利用可能なからといって代替可能ではありません。リクエストの機能プロファイルを満たす必要があります。チャットの場合、これにはシステム メッセージ、長いコンテキスト、JSON モード、ストリーミング、およびツール呼び出しが含まれる場合があります。 RAG の場合、大きなコンテキスト ウィンドウと一貫した引用フォーマットが含まれる場合があります。構造化された抽出の場合、スキーマの遵守と決定論的な出力が含まれる場合があります。ビジョンまたはオーディオの場合は、関連する入力モダリティをサポートする必要があります。規制されたワークロードの場合は、同じ保持、リージョン、安全性の制約が必要になる場合があります。
これは、多くのマルチモデル フォールバック設計が失敗する場所です。彼らは、いくつかの人気のあるモデルをリストに入れ、ゲートウェイが次から次へと移行できると想定しています。実際には、プロバイダーのパラメーターは異なります。サンプリング コントロール、推論コントロール、メッセージ ロール、ツール スキーマ、応答形式、ファイル入力、安全性設定、および請求単位が適切にマッピングされない場合があります。同じ出力スキーマを尊重できないフォールバック モデルは、可用性の問題を正確性の問題に変換する可能性があります。
より良いアプローチは、ワークロードと互換性によってフォールバック グループを作成することです。 1 つのグループは一般的なチャットを提供する場合があります。他の人はコード支援を提供するかもしれません。別のサービスでは、厳密なスキーマを使用した JSON 抽出を提供する場合があります。別のものは視覚入力を提供するかもしれません。各グループ内で、フォールバック候補は実稼働環境で使用する前に適合フィクスチャを使用してテストする必要があります。
1 つのエンドツーエンド期限で遅延を制御
フォールバックは、代替パスの試行により多くの時間を費やすことで可用性を向上させます。同じ余分な時間が、ユーザーの待ち時間の期待に反する可能性があります。答えは、各レイヤーで独立したタイムアウトではなく、リクエスト全体に対して 1 つのエンドツーエンドの期限を使用することです。
たとえば、ユーザー側の SLO が 5 秒の場合、ポリシーでは、十分な時間が残っている場合にのみ 1.5 秒のプライマリ試行、短いバックオフ、および 1 回のフォールバック試行を許可する可能性があります。プライマリ モデルがトークンをストリーミングする場合、ポリシーは最初のトークンまでの時間を最適化し、意味のある出力が出力された後のフォールバックを禁止する可能性があります。リクエストがバックグラウンド バッチ ジョブの場合、ユーザー側のレイテンシーはそれほど重要ではないため、ポリシーではより長いバックオフとより多くの試行が許可される場合があります。
再試行予算には、SDK 回の再試行、ゲートウェイ再試行、キュー再試行、プロバイダ再試行、およびフォールバック試行を含める必要があります。いつ停止するかを定義する必要もあります。すでに期限の大部分を消費しているリクエストは、時間内に完了する可能性が低い高価なフォールバック試行を開始すべきではありません。
ストリーミングと副作用の境界を定義する
ストリーミングにより、フォールバックの問題が変わります。コンテンツが配信される前に、失敗した試行が再試行されるか、別の場所にルーティングされることがよくあります。コンテンツがユーザーに表示された後は、フォールバックが危険になります。同じ生成を再試行すると、重複した出力、矛盾した出力、または混乱を招く出力が作成される可能性があります。一部のシステムでは、ストリーム ヘッダーの前にフォールバックが許可されています。最初のコンテンツ トークンの前にそれを許可するものもあります。ストリーミング ライフサイクルが開始されると、フォールバックを許可しないものもあります。重要な点は、境界を意図的に定義し、部分ストリームを通常の障害とは別にログに記録することです。
エージェント ワークフローには、副作用という別の境界が追加されます。ツール アクションを作成するモデル呼び出しは、多くの場合再試行できます。電子メールの送信、カードへの請求、データベースへの書き込み、サポート チケットの作成、または外部 API の呼び出しを行うツール呼び出しをむやみに繰り返すことはできません。生成の再試行とツールの実行には別の状態が必要です。外界を変更するアクションに関してフォールバック ルーティングが使用される場合、冪等キー、ワークフロー ステート マシン、永続的な実行レコードが不可欠です。
サーキット ブレーカーとヘルス スコアリングを使用する
ヘルス コントロールがなければ、フォールバックは、すでに障害が発生していることがわかっているルートにトラフィックを送信し続ける可能性があります。サーキットブレーカーはそれを防ぎます。失敗が繰り返された場合、タイムアウト率が高い場合、またはプロバイダー インシデント信号が強い場合、ルートは一時的に抑制されます。トラフィックは、クールダウン、ヘルスチェック、または小規模なプローブが成功した後に再開できます。
ヘルス スコアリングでは、最近のエラー率、タイムアウト率、レイテンシー、プロバイダーのステータス、割り当てシグナル、およびワークロードごとに観察された成功を考慮できます。 1 つのモデルまたはリージョンに障害が発生したからといって、すべてのトラフィックをプロバイダーから遠ざけるように盲目的にルーティングすべきではありません。逆に、成功した 1 つのリクエストをルートが完全に正常であることの証拠として扱うべきではありません。スコアリング ウィンドウは、バタつきを避けるのに十分な長さである必要がありますが、実際のインシデントに反応するのに十分な短さである必要があります。
健全性状態については、テナントの認識も必要です。特定の API キー、プロジェクト、クォータ バケット、またはアカウントが使い果たされていても、プロバイダーはグローバルに正常である可能性があります。 LLM API フェイルオーバーでは、プロバイダ レベルの健全性と認証情報レベルの健全性を区別する必要があります。
コストとガバナンスをポリシーの一部にする
フォールバックはコストを変更します。バックアップ ルートは、より安くなったり、より高価になったり、請求方法が異なる場合があります。試行が失敗しても、トークンまたはレート制限容量が消費される可能性があります。部分的なストリーミング応答は課金対象となる場合があります。停止中にフォールバックがエコノミー モデルからプレミアム モデルにエスカレートした場合、ユニットエコノミクスが劇的に変化する間もサービスは利用可能な状態を維持できる可能性があります。
そのため、フォールバックは予算および請求ポリシーと統合する必要があります。一部のテナントでは、プレミアム緊急フォールバックが許可されている場合があります。より安価な劣化ルートを好む人もいるかもしれません。承認された低コストのルートが利用できない場合、一部のワークロードは停止する必要があります。きめ細かい制御が必要なチームは、フォールバックを LLM API キー による支出制限に合わせて調整する必要があります。これにより、セカンダリ ルートがプライマリ ルートを保護した制御をバイパスできなくなります。
最終的な答えによって複数のアップストリーム試行が隠蔽される可能性があるため、統合請求も重要です。クリーンな請求書または使用状況レポートでは、どのモデルがリクエストされたか、どのルートが解決されたか、どの試行が失敗したか、どの試行が成功したか、およびどのコストが決済されたかを説明できる必要があります。 統合 AI API 請求 をサポートするゲートウェイを使用すると、特にフォールバック動作が複数のサプライヤーにまたがる場合に、チームがモデルやプロバイダー全体でコストをより一貫した方法で属性付けることができます。
すべてのリクエストの試行台帳を記録します
来歴のないフォールバックはデバッグが困難です。アプリケーションは最終応答を確認しますが、運用チームは途中で何が起こったのかを知る必要があります。試行台帳には、勝者だけでなく、各ルートの試行も記録する必要があります。
有用なフィールドには、リクエストされたモデルまたはエイリアス、解決されたモデル、プロバイダー、リージョン、資格情報クラス、テナント、チーム、API キー、リクエスト ID、試行番号、開始時間、レイテンシ、タイムアウト、エラー クラス、再試行決定、フォールバック決定、プロンプト トークン、完了トークン、キャッシュされたトークン (該当する場合)、推定コスト、決済コスト、ストリーミング ステータス、
このデータは、インシデント対応、コスト分析、モデル評価、およびカスタマー サポートをサポートします。また、サイレントな品質低下の検出にも役立ちます。ユーザーがより弱い回答を報告した場合、台帳はプロバイダーのインシデント中にユーザーが下位層のフォールバック モデルを受け取っていたかどうかを示すことができます。運用チームは、ルーティングの来歴と AI API 使用状況分析ダッシュボードを組み合わせて、チーム、キー、モデル、またはワークロードごとのフォールバック率、プロバイダーのエラー、支出の変化、レイテンシの変化を確認できます。
マルチモデル ゲートウェイが適した場所
マルチモデル ゲートウェイは、すでにアプリケーションとプロバイダーの間に配置されているため、ルーティング ポリシーを一元管理するのに自然な場所です。 Model Gate は、統合請求、API キー管理、使用状況分析、チーム管理、Telegram 統合、およびプラットフォーム上にサービスを構築するためのパートナー API を備えた OpenAI 互換のマルチモデル API ゲートウェイです。これらの機能は、モデル アクセス、資格情報管理、コスト アトリビューション、使用状況の可視性、チーム レベルのガバナンスなど、フォールバック ルーティングに関する運用環境に直接関連しています。
これは、ここで説明するすべてのフォールバック パターンをすべてのゲートウェイが自動的に実行するという意味ではありません。このコンテキストで Model Gate について考える責任ある方法は、マルチモデル API のアクセスと可観測性の中央制御ポイントとして考えることです。アプリケーション自体がフォールバック ロジックを実装している場合でも、ゲートウェイはモデルへのアクセス、請求記録、キー管理、分析を簡素化できます。フォールバック動作がゲートウェイ層に実装されている場合、同じガバナンスとレポートの問題が引き続き適用されます。つまり、テナント制御を保持し、すべての試行を記録し、有用なメタデータを公開し、不透明なモデル置換を回避します。
OpenAI 互換のインターフェースは、移行の摩擦も軽減できます。アプリケーションは多くの場合、ベース URL とルーティング ポリシーをバックグラウンドで変更しながら、使い慣れた SDK 形状を維持できます。この互換性は貴重ですが、本番環境でフォールバックに依存する前に、プロバイダ固有の動作、ツール呼び出し、スキーマ出力、ストリーミング、レイテンシ、コストをテストする必要性がなくなるわけではありません。
インシデントの前にフォールバックをテストする
最初の実際のプロバイダ インシデントが、フォールバック ルーティングの最初のエンドツーエンド テストであってはなりません。予想される障害モードを実行するテスト ハーネスを構築します。
有用なフィクスチャには、Retry-After の有無にかかわらず 429 レート制限、408 タイムアウト、500 および 503 プロバイダー エラー、不正なプロバイダー応答、サポートされていないパラメーター、無効なモデル ID、コンテキスト オーバーフロー、予算拒否、ポリシー拒否、最初のトークン前のストリーミング中断、部分出力後のストリーミング中断、ツール呼び出しの再試行、クォータが含まれます。疲労と品質検証の失敗。ルーティングの決定と結果のログの両方をテストします。成功しても試行記録が残らないフォールバックは、運用上まだ不完全です。
否定的なケースもテストします。クライアントエラーが不必要に再試行されないことを確認します。ベンチマーク、監査、再現性、および正確なモデルの評価のためにフォールバックを無効にできることを確認します。テナントの許可リスト、チームの権限、リージョンの制限、支出制限が、プライマリ ルートに適用されるのとまったく同じようにフォールバック ルートに適用されることを確認します。
避けるべきよくある間違い
最も一般的な間違いは、フォールバックをバックアップ モデルの単純な順序付きリストとして扱うことです。これにより、機能の互換性、期限、予算、ポリシー、可観測性などの本当の要件が見えなくなります。
もう 1 つの間違いは、エラーが発生するたびに再試行することです。認証、不正な形式のリクエスト、サポートされていないパラメータ、ポリシーの拒否、クレジットの枯渇、および無効なモデル エラーには、通常、構成の変更または別のリクエストが必要です。再試行すると時間が無駄になり、コストが増加する可能性があります。
ネストされた再試行ループも同様に危険です。 SDK、アプリケーション コード、ゲートウェイ、キュー、プロバイダー クライアントはそれぞれ独自の再試行設定を持つことができます。これらが調整されていない場合、1 つのユーザー リクエストが多数のアップストリーム コールに増殖し、レート制限の圧力が高まる可能性があります。
サイレント置換は別のリスクです。フォールバックを完全に非表示にすると、クライアント API がクリーンに見える可能性がありますが、開発者は品質、コンプライアンス、レイテンシ、請求結果を説明するのに十分なメタデータが必要です。適切な透明性のレベルは製品によって異なりますが、ルーティング レイヤは少なくとも内部の出所を保持する必要があります。
最後に、誤った答えが一時的な失敗よりも悪い場合は、低品質のモデルにフォールバックしないでください。法律、財務、医療、セキュリティ、コンプライアンス、および影響の大きい自動化ワークフローでは、フォールバック ルートがプライマリ ルートと同じ基準を満たしていない限り、フェールクローズ動作が必要になることがよくあります。
実用的な設計チェックリスト
- 1 つのグローバル フォールバック チェーンではなく、主要なワークロード タイプに対して個別のルーティング ポリシーを定義します。
- 再試行またはフェイルオーバーの前にエラーを分類します。
- いずれかを使用してください。 SDK、アプリケーション、ゲートウェイ、キュー、プロバイダー層全体にわたるエンドツーエンドの再試行予算。
- モデルの人気度ではなく、機能プロファイルに基づいてフォールバック グループを構築します。
- 明示的なレイテンシー期限と試行ごとのタイムアウトを設定します。
- 運用環境で使用する前にストリーミング フォールバック境界を定義します。
- モデル呼び出しの再試行を外部の副作用から分離します。エージェントのワークフロー。
- 異常なルートにはヘルス スコアリング、クールダウン、サーキット ブレーカーを使用します。
- フォールバック中にテナント、キー、チーム、支出、リージョン、およびモデルのアクセス制御を保持します。
- 分析と請求のために、失敗した試行や破棄された試行を含むすべての試行を記録します。
- 開発者が必要とするフォールバック メタデータを公開します。
- プロバイダーのようなフィクスチャを使用して、成功パスと失敗パスの両方をテストします。
結論
LLM フォールバック ルーティングは、単なる便利な機能ではなく、信頼性とガバナンスのパターンです。これにより、アプリケーションはプロバイダーの過負荷、レート制限、タイムアウト、地域的なインシデント、不健全な展開、クォータ障害などに耐えることができます。ただし、再試行、フェイルオーバー、モデル置換、レイテンシ バジェット、コスト ルール、互換性チェック、オブザーバビリティが一緒に設計されている場合にのみ有効に機能します。
強力な AI API 再試行およびフォールバック戦略は、再試行できるもの、代替できるもの、リクエストの実行時間、コスト、許可されるルート、および記録する必要があるものなどの明示的なポリシーから始まります。複数のモデルやプロバイダーを使用しているチームの場合、Model Gate などのゲートウェイ層は、OpenAI 互換アクセス、API キー管理、請求の帰属、使用状況分析、およびそれらの決定に関するチーム制御のための中心的な場所を提供できます。アプリケーションには依然としてドメイン固有の検証と副作用の安全性が必要ですが、ルーティング基盤の管理、測定、改善が容易になります。