信頼性の高い LLM API ルーティング: セマンティック リグレッションのないタイムアウト、再試行、モデル フォールバック
LLM API の障害を分類し、1 つのレイテンシ バジェットを適用し、互換性のあるフォールバック モデルを選択し、副作用を保護し、受け入れられたすべての応答を検証するための実用的なアーキテクチャ。
別のモデルが HTTP 200 を返しただけでは、フォールバック リクエストは成功しません。置換によって、元のレイテンシ バジェットを超えたり、必要な JSON フィールドが省略されたり、別のツールが呼び出されたり、実質的に異なるセマンティクスで応答が生成されたりする可能性があります。したがって、信頼性の高い LLM API ルーティングには、順序付けされたモデルのリスト以上のものが必要です。コントラクト、失敗分類子、制限付き試行ポリシー、および受け入れ前の検証が必要です。
中心的なルールは単純です。失敗が一時的であると考えられる場合にのみ再試行し、次のルートが元のリクエスト コントラクトをまだ満たせる場合にのみフォールバックします。
モデルを選択する前にルーティング コントラクトを定義してください
まず、成功した応答が何を提供する必要があるかを説明します。このルーティング コントラクトは、機械で読み取り可能であり、各ワークロードまたはリクエスト クラスに添付される必要があります。
{
"ワークロード": "請求書抽出",
"モダリティ": ["テキスト", "画像"],
"max_input_tokens": 50000、
"requires_tools": false、
"構造化出力": {
「必須」: true、
"schema_id": "請求書-v3",
「厳密」: true
}、
"allowed_model_classes": ["ドキュメント抽出"],
"max_cost_usd": 0.08、
「デッドライン_ミリ秒」: 8000
}契約には、必要なモダリティ、コンテキスト容量、ツールのサポート、構造化された出力動作、許容可能なモデル クラス、最大コスト、およびエンドツーエンドの期限が含まれている必要があります。必要に応じて、許可される領域、最小出力長、または必要な終了理由など、アプリケーション固有の制約を追加します。
推奨事項: プレーン テキスト、スキーマに制約された出力、ツールの使用、ビジョン、および長いコンテキストのリクエストに対して、テスト済みの別個のルート グループを維持します。許容可能なテキスト フォールバックであるモデルは、自動的にツール呼び出しや画像入力に対して許容可能なフォールバックにはなりません。
アクションを起こす前に障害を分類する
認証エラー、不正な形式のリクエスト、レート制限、サーバー障害には、異なる応答が必要です。成功しないすべての応答を再試行可能なものとして扱うと、容量が無駄になり、欠陥が隠蔽される可能性があります。
<テーブル>事実: 失敗したレート制限リクエストは依然としてプロバイダーの制限にカウントされる可能性があります。したがって、積極的な即時再試行は、スロットリングを解決するのではなく、さらに深くする可能性があります。再試行は停止中に追加の容量も消費し、複数のアプリケーション層での再試行ポリシーにより負荷が倍増する可能性があります。
推奨: 1 つのレイヤーがモデル生成の再試行を所有するようにします。一般的なアーキテクチャでは、AI API ゲートウェイがルートの健全性、試行履歴、レイテンシー、コストを確認するため、適切な所有者となります。可能であれば、下位レベルのクライアントでの自動再試行を無効にするか、同じ試行バジェット内で明示的にカウントします。
エンドツーエンドのレイテンシ バジェットを 1 つ費やす
試行ごとのタイムアウトが不十分です。 5 秒のタイムアウトで 3 回試行すると、バックオフと検証が含まれる前に、意図した 5 秒の操作が 15 秒の応答に変わる可能性があります。
リクエストがゲートウェイに入るときの絶対期限を記録します。試行するたびに、残り時間を計算します。
残り = 期限 - 現在の時刻
必須 = 接続許可 + 生成許可 + 検証許可
残っている場合 < 必要な場合:
stop_without_launching_another_attempt8 秒の期限の場合、妥当な初期割り当てでは、ゲートウェイの作業と最終検証に 300 ミリ秒を予約し、プライマリ ルートに最大 4.5 秒を許可し、1 つのフォールバックに約 3.2 秒を保持します。これらの値は一例であり、ベンチマークではありません。これらは、実際のプロバイダー、モデル、リージョン、出力サイズについて測定されたレイテンシー分布から導き出す必要があります。
一時的な再試行には、ジッターを伴う上限付き指数バックオフを使用します。
遅延 = ランダム(0, min(cap, Base * 2^retry_index))プロバイダーの再試行ヒント (retry-after 値など) は、残りの期限内に収まる場合に優先されます。少数の試行後に停止します。共通のポリシーは、1 回のプライマリ試行と 1 回のフォールバックであり、課金対象の出力を生成できなかった初期の接続障害に対してのみ、オプションで同じルートの再試行が行われます。
トレードオフ: 順次フォールバックにより可用性は向上しますが、テール レイテンシが増加します。並列リクエストまたはヘッジリクエストにより、速度低下時のレイテンシを短縮できますが、より多くの容量を消費し、成功した複数の世代に対して料金が発生する可能性があります。ヘッジは、キャンセルとコスト管理を備えた、遅延が重要で副作用のないワークロードに限定する必要があります。
ランクではなく能力によってフォールバックを選択する
フォールバック テーブルは、グローバルな優先順位ではなく互換性をエンコードする必要があります。健全性、遅延、価格を考慮する前に、契約に照らして候補ルートをフィルタリングします。
候補 = ルート
.filter(supports_required_modalities)
.filter(context_limit >=estimated_input_size)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(allowed_model_classes のmodel_class)
.filter(推定コスト <= 残りのコスト予算)
.filter(一時的に抑制されていない)
selected = ランク(候補、ヘルス、レイテンシ、コスト)構造化出力のサポートには明示的なテストが必要です。 2 つのルートがスキーマ制約のある生成をアドバタイズする場合でも、異なる JSON スキーマ サブセットをサポートしたり、エッジ ケースを異なる方法で解釈したりする場合があります。ツール対応モデルも同様に、ツールの選択、引数の構築、並列呼び出しの動作が異なる場合があります。
事実: モデル ファミリを切り替えると、スタイル、推論品質、安全動作、トークン化、ツール選択を変更しながら、トランスポートの可用性を維持できます。 HTTP の成功は、意味上の同等性の証拠ではありません。
予測: モデル カタログが拡大するにつれて、実稼働ルーティング ポリシーでは、静的なモデル リストの代わりに、バージョン管理された機能プロファイルとワークロード固有の受け入れテストを使用することが増えます。これはプロバイダの動作を保証するものではなく、設計の方向性として扱ってください。
応答を受け入れる前に検証する
プライマリ レスポンスを含むすべてのレスポンスを同じ受け入れパイプラインを通じて実行します。検証は、結果がキャッシュされる前、成功として内部的に請求される前、またはツール実行者に渡される前に行われる必要があります。
<オル>請求書抽出の場合、セマンティック チェックでは、負でない合計、サポートされている通貨コード、および明示的に定義された許容範囲内の明細合計が必要になる場合があります。分類するには、許可されたセットからのラベルを必要とします。コード生成には、解析またはコンパイルが適切な場合があります。これらのチェックは品質を証明するものではありませんが、予測可能な契約違反が成功として扱われるのを防ぎます。
不正な応答をすべて黙って修復しないでください。無害な周囲の空白を削除するなど、決定的な正規化は許容される場合があります。財務フィールドが欠落していると推測したり、ツールの引数を書き換えたりすると、モデルの意味が変わるため、拒否または人間によるレビューが引き起こされるはずです。
生成の再試行を副作用から分離する
LLM リクエストは通常、本質的に冪等ではない HTTP POST を使用します。さらに重要なのは、モデル応答は、支払い方法への請求、メッセージの送信、チケットの作成、インフラストラクチャの変更などの外部アクションを開始する可能性があることです。生成を再試行することと、そのアクションを再実行することは、別個の決定です。
アプリケーション境界で操作 ID を割り当て、すべてのモデル呼び出しに試行 ID を割り当てます。次のような決定論的なキーに対してツールの実行状態を保持します。
実行キー = 操作 ID + ツール名 + canonical_arguments_hashツールを実行する前に、そのキーが保留中、完了、または失敗したかどうかを確認してください。完了した実行を再度実行するのではなく、保存された結果を返します。引数が正当に変更される可能性があるオペレーションの場合は、アプリケーション レベルの承認または新しいオペレーション ID が必要です。
あいまいなタイムアウトには特別な処理が必要です。リクエストの送信後に接続が失敗した場合、ゲートウェイは生成が発生したかどうかを認識できない可能性があります。プロバイダーがサポートする冪等性キーが利用可能な場合は役に立ちます。それ以外の場合は、結果を不明としてログに記録し、何も起こらなかったと仮定するのではなく、ワークロード固有の再生ポリシーを適用します。
不健全なルートを抑制し、すべての試行を公開します
サーキット ブレーカーまたは一時的なヘルス抑制により、新しいリクエストごとに同じ障害が発生したルートが再検出されなくなります。定義されたエラー率または連続障害しきい値の後に回路を開き、その後、半開状態で制限されたプローブを許可します。ルートと障害クラスごとにしきい値を調整して、不正なクライアント リクエストによって正常なモデルが利用できないように見えることがないようにしてください。
リクエストレベルのイベントを 1 つと、試行ごとに 1 つのイベントを記録します。有用なフィールドには、操作 ID、試行 ID、選択したプロバイダーとモデル、失敗クラス、ステータス コード、待ち時間、トークン数、推定コスト、フォールバック理由、検証結果、回線状態、および最終結果が含まれます。機密性と保持の要件に従って、プロンプト、出力、ツールの引数を編集またはハッシュします。
有用な運用指標には、フォールバック率、完了したリクエストあたりの試行回数、期限切れ率、検証拒否率、あいまいな結果、受け入れられた応答あたりのコスト、最終ルート別のレイテンシなどがあります。 HTTP 成功率の上昇と検証拒否率の上昇は、トランスポートの可用性がコントラクトの失敗を隠しているという警告です。
本番展開チェックリスト
- ワークロード クラスごとにバージョン管理されたルーティング コントラクトを定義します。
- プロバイダーのエラーを永続的、一時的、互換性がない、無効な応答、あいまいなカテゴリに分類する
- 再試行の所有者を 1 人選択し、合計試行回数を制限します。
- ゲートウェイ、プロバイダ クライアント、検証、ツールの実行を通じて絶対期限を伝達する
- 1 つのグローバル モデル チェーンではなく、機能がテストされたフォールバック グループを構築する
- スキーマ、ツール呼び出し、終了理由、ドメインの不変条件を検証する
- 操作キーと実行キーを使用して副作用を重複排除します。
- 境界付きハーフオープン プローブによるルート抑制を追加します。
- 試行レベルのレイテンシ、トークン、コスト、失敗、承認結果をログに記録します。
- 挿入タイムアウト、429 秒、選択された 5xx エラー、不正な形式の JSON、コンテキスト オーバーフロー、ステージングの成功が遅い
単一の低リスク ワークロードに対して、プライマリ ルートと 1 つの互換性のあるフォールバックから始めます。ポリシーを拡張する前に、受け入れられた応答の品質、レイテンシ、コストを比較します。目標は、可能な限り高いフォールバック率ではありません。これは、元の契約を満たす応答を返すか、重複作業やセマンティックな損傷を引き起こす前に明らかに失敗する、制限されたシステムです。