Portkey（現PRISMA AIRS AI Gateway）で複数LLMを扱うときは、同じ対象へ再送する再試行と、別の対象へ切り替えるfallbackを分けて設計します。対象状態、試行回数、全体の待ち時間、費用、出力形式、送信先の情報取扱いを決め、合成入力で確認してから適用範囲を広げてください。失敗が減っても、別modelの回答が業務要件を満たすとは限りません。
ここでは現行の公式config説明を参照した設計・検証手順を示します。API呼出し、provider登録、key取得、config変更や課金を伴う試験は実施していません。例のprovider/modelは説明用の置換値で、そのまま利用できる設定ではありません。契約と利用中の提供方式に対応する仕様を確認してください。
目次
一回の業務実行とLLM試行を区別する
一つの質問が、アプリ側再試行、gateway 再試行、fallback、toolの再実行へ広がると、試行数が想定以上になります。まず親の実行ID、LLM呼出し、gateway configの版、provider/model、後続toolを分けます。アプリやSDK側で再試行が有効かを確認し、各層が独立に最大回数まで繰り返さないようにします。
確認する運用条件は、利用者が待てる総時間、一実行の費用上限の考え方、失敗時に返す内容、切替可能なprovider、データ送信が許可される範囲です。gatewayの機能名だけで、これらが自動的にすべて強制されると考えないでください。必要な制御をどの層で担うかを明記します。
再試行する状態と回数を小さく定める
Automatic Retriesの公式仕様（新しいタブで開く）は、最大5回の再試行、指数backoff、対象状態の指定を案内しています。on_status_codesを指定すると、その集合がdefaultに追加されるのではなく、指定した状態だけが対象になります。古い例に合わせてdefaultの集合を固定せず、使う版の仕様を確認します。
説明用の再試行部分は次のように分けられます。これは完成したgateway configではなく、provider/model等を含む利用中の設定へ組み込む前に確認する断片です。
{
"retry": {
"attempts": 1,
"on_status_codes": [429, 503],
"use_retry_after_headers": true
}
}
この例は429と503を対象にする設計例です。入力不正や認証失敗まで回数で解決しようとしません。attemptsと初回を含む総呼出し回数を混同せず、実際に何回呼ばれるかを確認します。上限が5回だからといって、すべての用途で5回にする必要はありません。
同仕様ではproviderのRetry-After系headerを尊重する設定と、累積再試行待ち時間60秒の上限が説明されています。これは接続・推論・fallback等を含む業務全体が必ず60秒以内に終わる保証ではありません。アプリの期限とproviderの待ち時間を両方確認し、利用者の要求が終了した後も処理が続く場合の扱いを決めます。
fallbackは許可済みの送信先だけを並べる
Fallbacksの公式仕様（新しいタブで開く）は、strategy.modeをfallbackにし、targetsへ優先順に対象を並べる形を示しています。対象状態も指定できます。たとえば次は429と503でbackupへ進む構造の例です。登録済みのproviderと対応modelへ置換し、入力を送ってよい条件を確認する必要があります。
{
"strategy": { "mode": "fallback", "on_status_codes": [429, 503] },
"targets": [
{ "override_params": { "model": "@PRIMARY_PROVIDER/MODEL_NAME" } },
{ "override_params": { "model": "@BACKUP_PROVIDER/MODEL_NAME" } }
]
}
modelを変えると、入力長、画像等の対応、tool calling、出力schema、言語、latency、価格が変わり得ます。primaryで通った入力をbackupも同じ意味で処理できるか、代表的な合成入力で確認します。provider名を並べただけでデータの地域要件や保持条件を満たすとは判断しません。
成功応答でも業務の完了条件を検査する
表は横にスクロールできます
| ケース | 確認すること | 停止・確認へ回す条件 |
|---|---|---|
| 通常応答 | 許可した対象、出力形式、必要内容 | schemaや意味が要件外 |
| 再試行対象の失敗 | 設定した状態と回数、待ち時間 | 予算・期限を超える、対象外状態 |
| primary失敗 | backupへ進む順序と送信先 | 未許可provider、非対応入力 |
| 全対象失敗 | エラーの返し方と未完状態 | 成功文を生成して隠さない |
| toolを伴う実行 | 外部操作がすでに行われたか | 結果不明の書込みを自動再実行しない |
200応答でも、必要なJSON fieldが欠ける、引用がない、回答が拒否されるなど、業務では使えない場合があります。逆にtimeoutでは、providerが処理していないと断定できないこともあります。LLMの再呼出しと、注文・送信・更新等のtool実行を分離し、外部操作の重複防止や状態照会はアプリ側でも設計します。
再試行とfallbackのlogを同じものと考えない
公式再試行資料は、再試行試行が個別のlogとして残らず、応答時間が一つのlogへまとめられる扱いを示しています。一方、fallback資料はchain内のrequestをConfig IDやTrace IDで追う方法を案内しています。画面のlog件数だけで試行数を推定せず、利用可能なheaderやtraceと対応させて確認してください。
記録には親実行ID、config版、対象、状態、待ち時間、最終結果、検証した出力条件、残る不明点を置きます。prompt全文やkeyを調査用に追加保存せず、必要なmetadataで追えるかを先に見ます。実測していない成功率や節約額は、設定例から計算して成果として示しません。
設定変更後に問題が出たら、どの版からかを特定し、検証済みのconfigへ戻すか、該当routeを止める判断を担当者が行います。結果不明の業務操作を再開する前には、外部の状態を照合します。再試行とfallbackを採用する条件は、呼出しが成功するだけでなく、同じ業務の要求・情報管理・復旧手順を守れることです。