レイテンシ、コスト、または出力コントラクトを破ることなく LLM フォールバックを設計する方法
LLM フォールバック ルーティングの実用的なアーキテクチャ。再試行をフォールバックから分離し、プロバイダーのエラーを分類し、構造化された出力コントラクトを保護し、コストを管理し、信頼性の向上を証明するのに十分なテレメトリをチームに提供します。
フォールバックは単なるバックアップ モデル リストではありません。複数の LLM プロバイダを使用しているエンジニアリング チームにとって、フォールバックは、リクエストがあるプロバイダまたはモデルから別のプロバイダまたはモデルにいつ移動するか、何が不変でなければならないか、代替パスによってアプリケーションの信頼性が向上したことをシステムがどのように証明するかを決定するルーティング ポリシーです。
リーダーの問題は通常単純です。出力品質、スキーマの有効性、安全動作、またはコストを黙って変更することなく、失敗したリクエストを減らし、テール レイテンシを下げるということです。この解決策は、「別のプロバイダーを試す」よりも具体的です。信頼性の高い LLM フォールバック戦略には、エラー分類、リクエスト期限、モデル互換性ルール、コスト制限、サーキット ブレーカー、プロバイダーおよびルート レベルでの可観測性が必要です。
コードを再試行するのではなく、フォールバック ポリシーで開始する
再試行とフォールバックにより、さまざまな問題が解決されます。再試行では、一時的な障害の後に同じプロバイダーに同じリクエストを完了するように要求されます。フォールバックは、代わりに別のモデル、プロバイダー、リージョン、またはルートに作業を完了するよう要求します。これらの懸念事項が混在すると、インシデント発生時に推論するのが難しいシステムが作成されます。
事実: クラウド インフラストラクチャ プロバイダによる信頼性に関するガイダンスでは、一般に、制限付き指数バックオフ、ジッター、最大再試行制限、冪等性チェック、および再試行の嵐が過負荷を悪化させる可能性があるため、複数のレイヤでの再試行の回避を推奨しています。主要な LLM プロバイダは、一時的なエラー、レート制限、過負荷応答、タイムアウト、および SDK 再試行動作についても文書化しています。
推奨: リクエスト パスごとに 1 つの再試行レイヤーを実装します。アプリケーション ゲートウェイが再試行する場合、再試行の所有権が明示的でない限り、ダウンストリーム サービスも独立して再試行しないでください。すべての再試行は、新しい無制限のタイムアウトを作成するのではなく、同じ呼び出し元の期限を消費する必要があります。
コードを記述する前に、最小限のポリシーで次の質問に答える必要があります:
- 同じプロバイダーで再試行可能な障害はどれですか?
- 別のプロバイダーまたはモデルへのフォールバックを許可する障害はどれですか?
- 決してトリガーしてはいけない障害はどれですか?フォールバック?
- どの出力コントラクトが同一でなければなりませんか?
- 許容されるコスト増加の最大値はどれくらいですか?
- フォールバックが禁止されるまでに、要求期限のうちどのくらいの時間が費やされる可能性がありますか?
- フォールバックが役に立ったか欠陥を隠したかを証明するテレメトリはどれですか?
ルーティングする前にエラーを分類する
すべての non-200 応答が同じように扱われる場合、フォールバックは危険です。プロバイダーのタイムアウトは、不正な形式のリクエストと同じではありません。レート制限は安全性の拒否と同じではありません。出力検証の失敗は、ネットワークの失敗と同じではありません。
実際の分類には、少なくとも次のクラスが含まれている必要があります:
- 再試行可能なトランスポートの失敗: 接続のリセット、DNS の問題、一時的なネットワーク障害、またはゲートウェイのタイムアウト。
- プロバイダの過負荷: 文書化された過負荷またはサーバー側の一時的失敗。
- レート制限: リクエスト、トークン、アクセラレーション、またはクォータ ペーシング制限。特に Retry-After 値が指定されている場合。
- プロバイダ タイムアウト: プロバイダはリクエストを受け入れましたが、サービス ウィンドウ内に完了しませんでした。
- 無効なリクエスト:不正な形式のペイロード、サポートされていないパラメータ、無効なスキーマ、またはモデルに互換性のないオプション。
- 認証または構成エラー: 不正なキー、無効なアカウント、資格の不足、またはアカウント レベルの割り当ての枯渇。
- 安全性の拒否またはブロック: プロバイダーが安全性に基づいてコンテンツを意図的に拒否またはブロックしているポリシー.
- 出力検証エラー: モデルは応答しましたが、応答はアプリケーション コントラクトを満たしていません。
推奨事項: 呼び出し元のレイテンシ バジェット内で一時的なエラーのみを再試行してください。製品チームとプラットフォーム チームが明示的に承認したエラー クラスに対してのみフォールバックを許可します。製品が特定の代替の安全な動作を定義していない限り、認証エラー、不正な形式のリクエスト、決定論的なスキーマの間違い、または安全性の拒否に頼らないでください。
フォールバックによってバグが隠蔽される可能性があるため、この区別は重要です。スキーマがプライマリ プロバイダーに対して無効であり、フォールバック プロバイダーによってたまたま無視された場合、制約の少ない出力を返しながら、システムはより健全に見える可能性があります。それは信頼性ではありません。これはコントラクト ドリフトです。
タイムアウトだけでなく期限を使用する
テール レイテンシの問題は、多くの場合、技術的には制限されているものの、実際には遅すぎる再試行によって発生します。ユーザー向けの予算が 15 秒のリクエストは、プライマリ ルートでの失敗に 14 秒を費やしてから、時間内に完了できない完全なフォールバック試行を開始するべきではありません。
スタック全体を通過するリクエスト期限を使用してください。各ルーティング決定では、再試行またはフォールバックする前に残り時間を確認する必要があります。例:
request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800
if remaining_deadline_ms < minimum_fallback_budget_ms:
return controlled_failure
正確な数値はワークロードによって異なります。チャット完了ルートでは、1 つの代替モデルに十分な時間を確保できます。バックグラウンド抽出ジョブでは、複数回の試行が許可される場合があります。リアルタイム オートコンプリート パスでは、遅延フォールバック応答よりも高速障害が優先される場合があります。
推奨事項: 遅延バジェットをグローバルではなくルート クラスごとに定義します。低遅延 UI ルート、バッチ分類ルート、および長いコンテキスト分析ルートは、同じ再試行およびフォールバック エンベロープを共有しないでください。
ワークロードごとにモデル クラスを定義する
ベンダー名は、フォールバックの抽象化としては不十分です。アプリケーションは、コンテキストの長さ、推論の深さ、ツールのサポート、構造化された出力動作、レイテンシー、データ処理の制約、コストなどのワークロードのプロパティを考慮します。フォールバック ルートは、これらのプロパティを中心に編成する必要があります。
有用なモデル クラスは次のとおりです。
- 高速ドラフト: 短い応答、低遅延、中程度の品質許容度。
- 構造化抽出: 厳密な JSON 出力、スキーマ検証、形式に対する低い許容度ドリフト。
- 推論: マルチステップ分析、より高い品質要件、より高い許容レイテンシー。
- ロングコンテキスト: 大きなドキュメント、高トークンウィンドウ、慎重な切り捨てルール。
- 低コストのバッチ: に最適化された非同期ジョブまたは非緊急ジョブ。ユニットエコノミクス。
- プレミアム エスカレーション: 高価だが有能なモデルは、ポリシーが許可する場合にのみ使用されます。
クラスごとに、許可されるプライマリ モデル、許可されるフォールバック モデル、および禁止されるダウングレード パスをリストします。ロングコンテキストリクエストは、プロンプトを黙って切り捨てるショートコンテキストモデルにフォールバックすべきではありません。構造化抽出タスクは、スキーマ制約を満たすことができないモデルにフォールバックすべきではありません。プレミアム推論タスクでは、ユーザー エクスペリエンスが劣化した回答を明示的にサポートしない限り、別のプレミアム モデルへのフォールバックは許可されますが、高速ドラフト モデルへのフォールバックは許可されません。
エンタープライズ LLM API を構築しているチームの場合、これらのクラスはアプリケーション サービス全体に分散するのではなく、構成データまたはポリシー データ内に存在する必要があります。これにより、プロバイダーのインシデント時にルーティング動作が監査可能になり、変更が容易になります。
構造化出力コントラクトを保護する
構造化出力フォールバックは、本番環境での微妙なバグが最も発生しやすい場所の 1 つです。プロバイダーは、JSON モード、JSON スキーマ、ツール呼び出し、拒否フィールド、安全性フィードバック、終了理由、およびスキーマ サブセットをサポートする方法が異なります。あるモデルで動作するスキーマが別のモデルに移植できるとは限りません。
事実: 一部のプロバイダーのドキュメントではサポートされているモデルのスキーマの厳密な遵守について説明していますが、他のドキュメントでは JSON スキーマのサブセットのみのサポートについて説明しています。プロバイダーの応答には、拒否フィールド、プロンプト フィードバック、安全性評価、終了理由、またはプロンプトがブロックされている場合や無効な場合の候補が含まれていない場合もあります。
推奨: 出力検証を、オプションの呼び出し元の懸念事項ではなく、ルートの一部として扱います。ゲートウェイは、最終応答をアプリケーションに返す前に検証する必要があります。検証が失敗した場合、ルートは失敗を分類し、フォールバック試行が許可されるかどうかを決定する必要があります。
実行可能なパターンは 2 つあります:
ポータブル スキーマ サブセットを使用する
承認されたフォールバック プロバイダー全体でサポートされている機能の交差部分にスキーマを保持します。これにより、移植性が向上し、操作の複雑さが軽減されます。その代わり、プロバイダ固有の豊富な制約が失われる可能性があります。
プロバイダ固有のスキーマ アダプタを使用する
アプリケーション コントラクトを各プロバイダがサポートするスキーマ形式に変換するアダプタを維持します。これにより、機能は維持されますが、テストとメンテナンスの負担が増加します。また、エンジニアがどのルートが安全にフォールバックできるかを知るための互換性マトリックスも必要です。
基本的な互換性レコードは次のようになります:
{
"route": "invoice_extraction_v3",
"contract": "invoice_json_schema_v3",
"primary": "provider_a.structured_model",
"fallbacks": ["provider_b.extraction_model"],
"disallowed": ["provider_c.fast_model"],
"requires": ["json_schema", "enum", "required_fields"],
"validation": "strict_before_return"
}
推奨事項: 整形式のテキストだからといってフォールバック出力を返すことはありません。プライマリ ルートから期待されるのと同じアプリケーション レベルの契約を満たした場合にのみ、そのルートを返します。
インシデントが発生する前にコストを制御
フォールバックは、多くの場合、トラフィックが増加したりプロバイダーが低下したりしたまさにその瞬間に、トラフィックをより高価なモデルに移行します。コスト管理がなければ、信頼性メカニズムが支出インシデントになる可能性があります。
次のようなフォールバック ルールを設定します。
- ルートごとの最大フォールバック価格乗数。
- 組織、ワークスペース、または環境ごとに許可されるモデル階層。
- 日次または時間別のフォールバック支出予算。
- 個別のポリシーインタラクティブなバッチ ワークロード。
- フォールバックがプロバイダー、リージョン、またはモデル ファミリの境界を越えることができるかどうかに関するルール。
推奨事項: 生のリクエストのコストだけでなく、成功した応答ごとのコストも測定します。重要なルート上でユーザーに見える障害が防止される場合は、より高価なフォールバックが正当化される可能性があります。優先度の低いバッチ作業では、同じフォールバックが受け入れられない可能性があります。
コスト ポリシーも、プラットフォームを使用している組織に表示される必要があります。チームは、開発、テスト、または内部実験のためにそれをブロックしながら、運用カスタマー サポート ワークフローに対してプレミアム フォールバックを許可したい場合があります。これは、単なるルーティングの決定ではなく、ガバナンスの決定です。
プロバイダー、モデル、リージョン、エラー クラスごとにサーキット ブレーカーを追加する
単純なフォールバックは、劣化したプロバイダーに打撃を与える可能性があります。プライマリ リクエストが失敗するたびに、別のプライマリ試行がトリガーされ、次に別のフォールバック試行がトリガーされ、他のサービスでも同様の操作が行われます。サーキット ブレーカーは、繰り返しの圧力を軽減し、配線動作をより予測しやすくします。
サーキット ブレーカーは、過剰反応を避けるために十分に具体的である必要があります。 1 つのリージョン内の 1 つのモデルが構造化出力エラーを返しているため、プロバイダー全体を異常とマークしないでください。可能な場合は、プロバイダー、モデル、リージョン、ルート、エラー クラス別に健全性を追跡します。
多くのチームには、シンプルなサーキット ブレーカー ステート マシンで十分です:
- クローズド: 通常のトラフィックがルートに流れます。
- オープン: ルートは、エラーしきい値を超えた後、一時的に回避されます。超過しました。
- ハーフオープン: 限定されたプローブ トラフィックは、完全なトラフィックが再開される前に回復をテストします。
しきい値はボリュームを考慮する必要があります。 1 分間に 10 回のエラーは、少量のルートでは意味があるかもしれませんが、1 分間に数千のリクエストを処理するルートでは意味がありません。最小サンプル サイズ、ローリング ウィンドウ、およびエラー クラス フィルターを使用します。
推奨事項: サーキット ブレーカーは HTTP 件の障害だけをカウントすべきではありません。また、出力検証の失敗、タイムアウト率、レート制限率、拒否またはブロックのパターンも個別に追跡する必要があります。これらのクラスは、異なる運用上の応答を意味します。
最終的なエラーだけでなく、ルーティングの決定をログに記録します
ユーザー エクスペリエンスを向上させるフォールバックにより、インシデントの診断がさらに困難になる可能性があります。ログに最終的に成功したプロバイダのみが表示される場合、エンジニアはプライマリ プロバイダが失敗していたという証拠を失います。
各リクエストは以下を記録する必要があります:
- 元のプロバイダ、モデル、ルート。
- 使用時のフォールバック プロバイダ、モデル、ルート。
- 再試行またはフォールバックをトリガーしたエラー クラス。
- プロバイダ リクエスト ID利用可能。
- 再試行回数とバックオフ期間。
- 各試行の前に消費される期限。
- 出力検証結果。
- 各試行の推定コストと最終コスト。
- 最終的な答えがプライマリかフォールバックか。
- 組織、ワークスペース、環境、およびアプリケーションのメタデータ
このテレメトリは、エンジニアリングと商業ガバナンスの両方をサポートします。また、さまざまなチーム、製品、または顧客が異なる信頼性と予算ポリシーを持っている場合に、フォールバックの動作を AI API コスト管理に結び付けます。
フォールバックが実際に役に立ったかどうかを測定する
生の成功率では十分ではありません。フォールバック戦略により、最終 200 応答が増加する一方で、p99 レイテンシーが悪化したり、コストが 2 倍になったり、有効な構造化出力が返されなくなったりする可能性があります。
少なくとも次の指標をルート別に測定します:
- 主要な成功率。
- 再試行とフォールバック後の最終成功率。
- p50、p95、およびフォールバック前後の p99 レイテンシ。
- フォールバック呼び出し率。
- 成功応答ごとのコスト。
- 契約有効応答率。
- プロバイダーによる安全性の拒否またはブロック率。
- アプリケーション固有の品質低下シグナル評価。
予測: マルチプロバイダー LLM インフラストラクチャを使用する企業が増えるにつれて、フォールバック ポリシーはアドホックな例外処理ではなく、トラフィック エンジニアリングに近くなるでしょう。チームは、モデルが選択された理由を説明する監査ログとともに、ワークスペース、環境、ワークロード クラスごとのポリシー制御を期待します。
実装チェックリスト
本番ルートでフォールバックを有効にする前に、このチェックリストを使用してください:
- ルートのレイテンシー バジェットとリクエスト期限を定義します。
- プロバイダー エラーを再試行可能、フォールバック対象、ターミナルに分類します。
- どの障害がフォールバックを引き起こしてはならないかを文書化します。
- 承認されたプライマリ モデルとフォールバック モデルをワークロード クラスごとにリストします。
- コンテキストの長さ、ツール サポート、スキーマ サポート、および各フォールバックの安全動作を確認します。
- アプリケーション コントラクトに対してすべての最終応答を検証します。
- 最大再試行回数、バックオフ、ジッター、再試行後の処理。
- プロバイダー、モデル、リージョン、エラー クラスごとにサーキット ブレーカーを構成します。
- コスト乗数とフォールバック費用制限を設定します。
- リクエスト ID、エラー クラス、試行、検証結果、レイテンシ、コストをログに記録します。
- 平均だけでなく、ロールアウト後の p95 および p99 レイテンシを確認します。レイテンシ。
- プロバイダーの停止、レート制限、無効なスキーマ、安全性の拒否、出力検証失敗のシナリオをテストします。
実用的な結論
優れた LLM フォールバック戦略は、管理されたルーティング ポリシーです。これにより、再試行とフォールバックが分離され、失敗が正確に分類され、出力コントラクトが保存され、レイテンシーの期限が尊重され、インシデントが発生する前にコストが可視化されます。
重要な設計原則は不変性です。トラフィックがプライマリ モデルからフォールバックに移行するときに、何が真実のままである必要があるかを決定します。つまり、スキーマの有効性、安全な動作、コンテキストの処理、ツールのサポート、コスト制限、可観測性です。次に、それらの不変条件が保持できる場合にのみフォールバックを許可します。
グローバル フォールバック スイッチではなく、価値の高い 1 つのルートから始めます。エラー分類、互換性のあるフォールバック モデル、検証ルール、サーキット ブレーカー、およびメトリクスを定義します。そのルートに対して障害ドリルを実行します。許容できない p99 遅延、契約有効な応答損失、またはコストの増加がなく、最終的な成功率が向上した場合は、ポリシーを次のワークロード クラスに拡張します。