AI API ゲートウェイのサービス層ルーティング: ハードコーディング プロバイダーを使用しない、高速、標準、プロビジョニング済み、およびバッチ
プロバイダーに依存しない AI ワークロード層をゲートウェイで公開し、テナント制御、分析、請求レコードを使用して、各リクエストを高速、標準、プロビジョニングされた、またはバッチのキャパシティにマッピングするための実用的なアーキテクチャです。
サービス層ルーティングは、AI リクエストがプレミアム低遅延容量、通常のオンデマンド容量、予約されたスループット、または割引された非同期処理に値するかどうかを決定するポリシー層です。この層がないと、アプリケーション チームは通常、プロバイダー固有のフラグ、デプロイメント名、バッチ エンドポイントを製品コードに直接エンコードします。そのため、レイテンシ、コスト、割り当て、テナントの請求動作を管理することが困難になります。
ゲートウェイは、プロバイダーの仕組みではなく、ワークロードの意図を公開する必要があります。製品チームは、「これはインタラクティブなサポートの返信です」または「これは夜間のエンリッチメント ジョブです」と言える必要があります。一方、ゲートウェイはその意図を適切な上流のキャパシティ オプションにマッピングし、実際に何が起こったかを記録します。
読者の問題: 容量クラスがアプリケーション ロジックになりつつある
複数のモデル プロバイダーを使用するチームは、多くの場合、単純なモデル ルーティングから開始します。つまり、このモデル ID をこのプロバイダーに送信します。プロバイダーがさまざまな容量クラスを公開すると、ルーティングが難しくなります。
- ユーザー向けパスに対するプレミアムな低遅延リクエスト処理
- 通常の同期トラフィックの標準共有容量。
- 予測可能なスループットを実現する専用またはプロビジョニングされた容量
- レイテンシ耐性のあるワークロード向けのバッチ API または非同期 API。
- 予約容量が使い果たされた場合のスピルオーバー動作
すべてのアプリケーションがこれらの選択を自ら処理する場合、組織は 4 つのことを制御できなくなります。つまり、プレミアム キャパシティを誰が使用できるか、そのコストはいくらか、キャパシティが利用できない場合はどうなるか、選択した階層が支出を正当化できるほど製品を改善したかどうかです。
実際的なパターンは、AI API ゲートウェイ内にプロバイダー中立の QoS レイヤーを配置することです。
基礎となる事実
詳細はプロバイダーによって異なりますが、いくつかの観察可能な事実がゲートウェイ レベルの設計を裏付けています。
- 事実: 一部のプロバイダは、プレミアム処理のためにリクエストごとのサービス層を公開しています。 OpenAI は、高速モードを
service_tierパラメーターを使用したリクエストごとのオプションとして説明し、標準処理に比べて割増料金で請求されると述べています。 OpenAI はまた、優先処理の名前が 2026 年 7 月 30 日に高速モードに変更され、service_tier=priorityとservice_tier=fastの両方が API リクエストに対して受け入れられると述べています。 - 事実: プレミアム リクエストの処理は、個別のクォータ ユニバースではない場合があります。 OpenAI は、高速モードのレート制限は他のサービス層と共有されており、トラフィックの急激な増加によりランレート動作が引き起こされ、一部のトラフィックが代わりに標準処理に送信される可能性があると述べています。
- 事実: サービス層は、レポートおよび請求のディメンションとなる可能性があります。 OpenAI によると、API の顧客はサービス層と品目ごとに使用状況ダッシュボードのデータをグループ化できるという。 Anthropic は、API 使用状況レポートのサービス階層値として
standard、priority、batchを文書化します。 - 事実: バッチ API により、非同期作業のコストを大幅に削減できます。 Anthropic の価格ドキュメントには、Batch API が入力および出力トークンの 50% 割引で非同期大量処理をサポートしていると記載されています。 Google の Gemini Batch API ドキュメントでは、大規模な非同期ワークロードを標準コストの 50% で実行できると説明していますが、一部の大量ジョブの場合は最大 24 時間などの所要時間のトレードオフがあります。
- 事実: プロビジョニングされたスループットは別の容量モデルです。 Microsoft は、Azure OpenAI でプロビジョニングされたスループットを専用の容量として文書化しています。これは、容量が共有され、スループットが需要に応じて変化する標準的な展開とは対照的です。 Microsoft は、プロビジョニングされたデプロイメントから同じ Azure OpenAI リソース内の標準デプロイメントへの波及についても文書化しています。
アプリケーション コード内のすべてのプロバイダー用語をミラーリングしないことをお勧めします。これらのメカニズムをビジネス指向のゲートウェイ層に正規化することをお勧めします。
プロバイダー中立のゲートウェイ層を定義する
ベンダーの用語ではなく、ワークロードの動作に応じて層に名前を付けることから始めます。有用な最初の分類法は次のとおりです。
<テーブル> <頭>interactive_fastinteractive_standardreserved_capacity背景_割引emergency_fallbackこの階層リストは意図的に小さくなっています。 20 層を作成すると、開発者はシステムをバイパスします。ゲートウェイは、内部的に 1 つのニュートラル層を複数のプロバイダー固有のメカニズムにマッピングできます。
要求された階層を選択された階層から分離します
呼び出し元は要求された層を送信する必要がありますが、ゲートウェイは要求された層と実際に選択された層の両方を記録する必要があります。これらは常に同じとは限りません。
リクエスト メタデータの例:
{
"モデル": "サポートチャットデフォルト",
「メッセージ」: [...],
「メタデータ」: {
"ワークフロー": "customer_support_reply",
"テナントID": "テナント_123",
"requested_gateway_tier": "interactive_fast",
"end_user_id": "u_789"
}
}ディスパッチレコードの例:
{
"request_id": "req_abc",
"テナントID": "テナント_123",
"api_key_id": "key_live_456",
"ワークフロー": "customer_support_reply",
"model_alias": "サポートチャットデフォルト",
"requested_gateway_tier": "interactive_fast",
"選択されたプロバイダ": "プロバイダ_a",
"selected_provider_tier": "高速",
"tier_outcome": "selected_as_requested",
"downgrade_reason": null、
「入力トークン」: 1840、
「出力トークン」: 420、
「latency_ms」: 1420、
"推定コスト_米ドル": "0.0312",
"settled_cost_usd": "0.0308"
}ランプ制限またはテナント予算ルールのためにプレミアム リクエストが標準処理に送信される場合、それが表示される必要があります。
{
"requested_gateway_tier": "interactive_fast",
"selected_provider_tier": "標準",
"tier_outcome": "ダウングレード",
"downgrade_reason": "tenant_premium_budget_exhausted"
}この区別により、誤解を招く分析が防止されます。ダッシュボードに発信者が要求した内容のみが表示される場合、財務部門にはプレミアムの意図は表示されますが、プレミアムの実行は表示されません。ダッシュボードに上流の結果のみが表示される場合、製品チームは、レイテンシの影響を受けやすいワークフローがいつプレミアム キャパシティーを拒否されたのかを知ることができません。
ルーティングの前に機能マトリックスを作成する
サービス層ルーターには機能マトリックスが必要です。このマトリックスは、特定のモデル、リージョン、テナント、ワークフローに対して、どのキャパシティ メカニズムが利用可能か?
という答えを導き出す必要があります。最小フィールド:
プロバイダモデルまたはデプロイメントリージョンsupports_syncsupports_batchsupports_premium_tiersupports_provisioned_capacityspillover をサポートprovider_tier_valuesbilling_line_items既知のダウングレード動作テナント_許可リスト
簡略化した例:
gateway_tier_map:
インタラクティブ_ファースト:
好ましい：
- プロバイダー: openai
request_params:
サービス層: 高速
- プロバイダー: anthropic
request_params:
サービス層: 優先度
フォールバック:
- ゲートウェイ層: インタラクティブ_標準
allowed_when:policy.allows_standard_downgrade
背景_割引:
好ましい：
- プロバイダー: anthropic
モード: バッチ
- プロバイダー: ジェミニ
モード: バッチ
フォールバック:
- キュー: 遅延再試行
allowed_when: true
予約済み容量:
好ましい：
- プロバイダー: azure_openai
デプロイメントクラス: プロビジョニング済み
フォールバック:
- プロバイダー: azure_openai
デプロイメントクラス: 標準
allowed_when:policy.allows_spilloverこのマトリックスは分散コードではなく構成である必要があります。プロバイダーの名前の変更、利用可能な地域、および請求の処理は時間の経過とともに変更されます。ゲートウェイ ポリシーを更新することは、API を呼び出すすべてのアプリケーションを再デプロイするよりも安全です。
容量を選択する前にワークロードを分類する
最も難しい部分はプロバイダーのマッピングではありません。どのリクエストがどのレベルに値するかを決定することになります。
interactive_fast の適切な候補
- 遅延により会話が中断される音声アシスタント
- 価値の高いコンバージョンまたは維持パスに関する顧客対応のチャット
- エージェントがアクティブに待機している人間参加型のオペレーション
- レイテンシが軽減に直接影響する本番環境のインシデント
interactive_standard の適切な候補
- 社内副操縦士。
- 人間が通常の応答時間を許容できるドラフトをサポートする
- 応答時間が重要ではあるが重要ではない製品の機能
background_discount の候補者
- 夜の要約。
- 大規模なドキュメントの強化
- オフライン評価。
- 埋め込みの一括更新。
- 分析のラベル付けとレポートの生成
reserved_capacity の適切な候補
- 安定した大量の本番環境のワークロード
- 予測可能なスループットコミットメントを備えた契約済みの顧客ワークロード
- ノイズの多い近隣変動を許容できず、専用容量を正当化するのに十分な使用率があるトラフィック
簡単なポリシー ルールは、発信者が速度を優先するという理由だけでプレミアム容量を選択することを許可しないことです。宣言されたワークフロー、テナントの許可、予算封筒が必要です。
テナントと API キーの権限を強制する
すべてのテナントと API キーには、許可された階層セットが必要です。新しいキーは、デフォルトでプレミアム ティアではなく、スタンダード ティアとバックグラウンド ティアに設定される必要があります。
テナント ポリシーの例:
{
"テナントID": "テナント_123",
"allowed_gateway_tiers": [
"インタラクティブ_スタンダード",
「背景_割引」
]、
"プレミアム層": {
"有効": false、
"monthly_budget_usd": "0.00",
"承認_必須": true
}、
"予約容量": {
"有効": true、
"deployment_pool": "support-prod-ptu",
"allow_spillover_to_standard": true、
"spillover_monthly_budget_usd": "500.00"
}
}キーレベルのオーバーライドの例:
{
"api_key_id": "key_voice_prod",
"allowed_gateway_tiers": ["interactive_fast"],
"workflow_allowlist": ["voice_control_loop"],
"premium_daily_budget_usd": "75.00",
「max_premium_traffic_percent」: 15
}キーレベルのポリシーにより、偶発的な拡張が防止されます。開発者は、ワークフローも許可されていない限り、音声トラフィック用のキーを取得して、それを一括要約スクリプトに使用することはできません。
ダウングレードと波及動作を明示的に設計する
ダウングレード動作は、インフラストラクチャの決定だけでなく、製品の決定でもあります。プレミアムまたはプロビジョニングされた容量が利用できない場合、ゲートウェイは 4 つのパスのいずれかを選択する必要があります。
- 標準に従う: レイテンシの一貫性よりも可用性が重要な場合に役立ちます。
- キュー: バックグラウンド ジョブやバッチ ワークロードに役立ちます。
- フェイルファスト: タイトなリアルタイム ループなど、応答が遅い方が応答がないよりも悪い場合に役立ちます。
- 呼び出し元に再試行を依頼する: クライアントがバックオフと保存された冪等性キーを使用して安全に再試行できる場合に便利です。
ポリシーの例:
downgrade_policy:
音声制御ループ:
requested_tier: インタラクティブ_ファースト
if_fast_unavailable: フェイルファースト
エラーコード: tier_capacity_unavailable
customer_support_reply:
requested_tier: インタラクティブ_ファースト
if_fast_unavailable: continue_on_standard
Record_outcome: ダウングレード
nightly_document_enrichment:
requested_tier: 背景_割引
if_batch_unavailable: キュー
最大キュー遅延時間: 24
契約済み_API_顧客:
requested_tier: 予約容量
if_reserved_exhausted: 標準への波及
require_spillover_budget: trueこぼれを隠さないでください。スピルオーバーにより可用性は向上しますが、コストと SLO の解釈が変わります。請求書と分析には、予約容量のリクエスト、波及イベント、実際に使用された標準容量、およびその理由が示される必要があります。
サービス層ルーティングを請求に接続する
階層の選択が台帳に含まれていない場合、ゲートウェイはプレミアム支出を制御できません。リクエストまたはジョブごとに次のフィールドを保存します。
- リクエストされたゲートウェイ層。
- 選択したプロバイダー層または容量クラス。
- 階層の結果: 選択、ダウングレード、アップグレード、キューに登録、スピルオーバー、拒否
- 結果の理由
- テナント、API キー、ユーザー、ワークフロー識別子
- モデルのエイリアスと上流のモデルまたはデプロイメント
- 発送前の見積もり費用
- プロバイダの使用量が判明した後の精算費用
- 同期リクエストのレイテンシと再試行回数
- 非同期ジョブのバッチ送信時間、完了時間、結果取り込みステータス
これらのフィールドを使用すると、ゲートウェイは財務とエンジニアリングが尋ねる質問に答えることができます。
- 今週プレミアム容量を使用したテナントはどれですか?
- 最も多くのプレミアム支出を引き起こしたワークフローはどれですか?
- プレミアム リクエストはどのくらいの頻度でスタンダードにダウングレードされましたか?
interactive_fastは、プレミアムを正当化できるほど p95 レイテンシーを改善しましたか?- バックグラウンド バッチ処理は、同期標準処理と比較してどれくらい節約できましたか?
- プロビジョニングされた容量によってどの程度の標準波及効果が生じましたか?
重要な推奨事項: 実際に使用された階層を請求すると同時に、運用コンテキストで要求された階層も表示します。そうしないと、テナントはコストに驚いたり、サービスの品質について誤解したりすることになります。
プレミアムがデフォルトにならないようにガードレールを追加します
チームは、より高速な階層を発見すると、それを過剰に使用する可能性があります。広範囲に展開する前に、ゲートウェイに制限を設けます。
- テナントごとのプレミアム予算: 毎月および毎日の上限が厳しい。
- ワークフローの承認: プレミアムは名前付きワークフローにのみ許可されます。
- トラフィック シェアの上限: たとえば、承認なしに
interactive_fastを使用できるのは、テナントの同期リクエストの 10% 未満です。 - スタンダードからプレミアムへのアラート: 通常はスタンダードを使用するワークフローがアップグレードされたときにアラートを送信します。
- プレミアムバーンレートアラート: 予測支出が承認された範囲を超えた場合にアラートを送信します。
- 自動有効期限: 一時的な緊急オーバーライドは手動でクリーンアップせずに有効期限が切れます。
- バッチ適格性チェック: バッチ基準を満たした場合、同期プレミアム層からの一括ジョブをブロックします。
ガードレールはリバーシブルである必要があります。インシデント発生中、認可されたオペレータは、一時的な保険料の上書きを許可する必要がある場合があります。このオーバーライドには理由、承認者、予算、有効期限、監査記録が必要です。
実装シーケンス
安全なロールアウトは、どこでもプレミアム ルーティングを有効にすることで始まるわけではありません。まずは測定から始めましょう。
1.シャドウ層分類を追加
各リクエストを提案されたゲートウェイ層に分類しますが、ルーティングはまだ変更しないでください。既存のレイテンシー、コスト、ワークフローのメタデータの隣に、提案された層を記録します。これにより、ポリシーが適用された場合にプレミアム、バッチ、または予約容量に移動するトラフィックの量が明らかになります。
2.機能マトリックスの作成
プロバイダーのメカニズム、サポートされているモデル、リージョン、制限、レポートフィールド、および既知のダウングレード動作をリストします。未知のダウングレード動作は、テストされるまでリスクとして扱います。
3.予行演習モードでテナント権限を強制する
各リクエストが許可されるか、ダウングレードされるか、キューに入れられるか、または拒否されるかをログに記録します。施行前に結果をプロダクト所有者と共有してください。
4. 1 つのコホートに対して 1 つの階層を有効にする
ライブ サポートの返信パスや夜間の要約ジョブなど、狭いワークフローを選択します。小規模なテナント コホートに対して関連するゲートウェイ層を有効にします。可能な場合は、p50 レイテンシ、p95 レイテンシ、コスト、ダウングレード率、エラー率、およびユーザー向けのビジネス指標を測定します。
5.データがサポートする場合にのみ拡張します
プレミアム レベルによってレイテンシーは改善されるものの、製品の成果は改善されない場合は、制限を限定してください。バッチ処理によって製品の動作に悪影響を与えることなくコストが削減される場合は、バッチ処理を拡張してください。プロビジョニングされた容量がアイドル状態になっている場合は、コミットメントを再検討するか、より予測可能なトラフィックをコミットメントにルーティングします。
明示すべきトレードオフ
- プレミアム低レイテンシー層は応答性を向上させることができますが、レート制限が共有されたり、ランプ制約がトリガーされたりする可能性があります。これらはレート制限の形成に代わるものではありません。
- プロビジョニングされた容量により予測可能性が向上しますが、使用率が低い場合はコストが無駄になる可能性があります。標準容量またはバッチ容量は、スパイクの多いトラフィックやレイテンシを許容するトラフィックに適している可能性があります。
- バッチ処理はトークンのコストを削減できますが、応答が非同期であり、かなり遅く到着する可能性があるため、製品の動作が変わります。
- プロバイダーに依存しない階層名によりアプリケーション コードが簡素化されますが、プロバイダーは異なる名前、制限、請求明細、ダウングレード動作を使用するため、ゲートウェイは最新の機能マトリックスを維持する必要があります。
- 自動ダウングレードにより可用性が向上しますが、ゲートウェイが実際に使用されている階層を記録しない限り、SLO と請求の期待が曖昧になる可能性があります。
- 厳格なテナント制御により予期せぬ出費を防ぎますが、過度に厳格なポリシーは、制御されたオーバーライド パスがない限り、緊急の本番ワークフローをブロックする可能性があります。
予測: サービス層は第一級のルーティング ディメンションになる
予測: モデル API が成熟するにつれて、サービス層はモデルの選択、リージョン、コンテキスト ウィンドウと同じくらい AI ルーティングにとって重要になります。チームは、「どのモデルがこれに答える必要があるか?」ということだけを尋ねることはありません。彼らは、「どのモデル、どの容量クラス、どのテナント予算、どのダウングレード ポリシーを使用しますか?」と尋ねます。
推奨事項: アプリケーション コードを変更せずに新しいプロバイダー キャパシティ クラスを追加できるように、今すぐゲートウェイ レジャーとポリシー モデルを設計します。標準とバッチのみから始める場合でも、最初から requested_gateway_tier、selected_provider_tier、tier_outcome などのフィールドを使用します。
実行可能なチェックリスト
- プロバイダー中立のゲートウェイ階層は 5 つまで定義します。
- 各 API キーに、使用できる層とワークフローを宣言するよう要求します。
- プレミアム、スタンダード、プロビジョニング、バッチ、スピルオーバー動作のプロバイダー機能マトリックスを作成する
- リクエストされた階層、選択された階層、ダウングレードまたはスピルオーバーの結果、レイテンシ、使用量、精算コストを記録する
- 新しいキーをデフォルトで標準階層またはバックグラウンド階層に設定します。
- プレミアム予算、トラフィックシェアの上限、アラートを追加します。
- ワークフローごとにダウングレード動作を明示する
- 適用前にシャドウ メトリクスから始めます。
- プレミアム キャパシティまたはプロビジョニングされたキャパシティを最初に小規模なコホートに展開する
- 遅延、信頼性、ビジネス指標がコストに見合った場合にのみ拡張してください。
結論
サービス層ルーティングは、横断的なポリシー決定であるため、AI API ゲートウェイに属します。これは、レイテンシー、コスト、クォータ、テナントの権限、請求書、および運用上の期待に影響します。アプリケーション チームは、ワークロードの緊急性を表現するためだけに、プロバイダー固有の階層名やデプロイメント クラスをハードコーディングしないでください。
実用的なゲートウェイは、interactive_fast、interactive_standard、reserved_capacity、background_discount などの中立層を公開します。これらの層をプロバイダー固有のメカニズムにマッピングし、テナントのアクセス許可を強制し、実際の結果を記録し、プレミアム キャパシティをデフォルト パスではなく意図的な例外にします。