AI API ゲートウェイのサービス層ルーティング: ハードコーディング プロバイダーを使用しない、高速、標準、プロビジョニング済み、およびバッチ

サービス層ルーティングは、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 の価格ドキュメントには、そのバッチ API が入力トークンと出力トークンの 50% 割引で非同期大量処理をサポートしていると記載されています。 Google の Gemini バッチ API のドキュメントでは、大規模な非同期ワークロードを標準コストの 50% で説明していますが、一部の大量ジョブでは最大 24 時間などの所要時間のトレードオフがあります。
• 事実: プロビジョニングされたスループットは別の容量モデルです。 Microsoft では、Azure OpenAI のプロビジョニングされたスループットを専用の容量として文書化しています。これは、容量が共有され、スループットが需要に応じて変化する標準的な展開とは対照的です。 Microsoft は、同じ Azure OpenAI リソース内のプロビジョニングされたデプロイメントから標準デプロイメントへの波及についても文書化しています。

アプリケーション コード内のすべてのプロバイダー用語をミラーリングしないことをお勧めします。これらのメカニズムをビジネス指向のゲートウェイ層に正規化することをお勧めします。

プロバイダーに依存しないゲートウェイ階層を定義する

ベンダーの用語ではなく、ワークロードの動作に応じて層に名前を付けることから始めます。有用な最初の分類法は次のとおりです:

ゲートウェイ層	一般的なワークロード	待ち時間の予想	コスト姿勢	デフォルトのダウングレード動作
interactive_fast	音声ループ、ライブチャット、価値の高いユーザーアクション	実用的な最小レイテンシー	プレミアムは許可されています	ワークフローに応じて、標準で続行するかフェイルファストで続行します
interactive_standard	通常のチャット、製図のサポート、社内副操縦士	同期	デフォルトの費用	再試行、フォールバック、または制御されたエラーを返す
reserved_capacity	安定した使用率による予測可能な本番トラフィック	予測可能なスループット	プリペイドまたは確約された容量	ポリシーで許可されている場合にのみスピルオーバー
background_discount	評価、強化、要約、埋め込み、レポート	非同期	割引優先	バッチ パスが使用可能になるまでキューに入れます
emergency_fallback	インシデント対応または一時的な顧客エスカレーション	ポリシーに依存する	制御された例外	承認期間後に自動的に期限切れになる

この階層リストは意図的に小さくなっています。 20 層を作成すると、開発者はシステムをバイパスします。ゲートウェイは引き続き、1 つのニュートラル層を複数のプロバイダー固有のメカニズムに内部的にマッピングできます。

リクエストされた階層を選択された階層から分離します

呼び出し元はリクエストされた層を送信する必要がありますが、ゲートウェイはリクエストされた層と実際に選択された層の両方を記録する必要があります。これらは常に同じであるとは限りません。

リクエストのメタデータの例:

{
  "model": "support-chat-default",
  "messages": [...],
  "metadata": {
    "workflow": "customer_support_reply",
    "tenant_id": "tenant_123",
    "requested_gateway_tier": "interactive_fast",
    "end_user_id": "u_789"
  }
}

ディスパッチレコードの例:

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "api_key_id": "key_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "fast",
  "tier_outcome": "selected_as_requested",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0.0312",
  "settled_cost_usd": "0.0308"
}

ランプ制限またはテナント予算ルールのためにプレミアム リクエストが標準処理に送信される場合、それが表示される必要があります:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "downgraded",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

この区別により、誤解を招く分析が防止されます。ダッシュボードに発信者が要求した内容のみが表示される場合、財務部門にはプレミアムの意図は表示されますが、プレミアムの実行は表示されません。ダッシュボードに上流の結果のみが表示される場合、製品チームは、レイテンシの影響を受けやすいワークフローがいつプレミアム キャパシティーを拒否されたのかを知ることができません。

ルーティングの前に機能マトリックスを作成する

サービス層ルーターには機能マトリックスが必要です。このマトリックスは、特定のモデル、リージョン、テナント、ワークフローに対して、どの容量メカニズムが利用可能か?

という答えを返す必要があります。

最小フィールド:

• provider
• model_or_deployment
• regions
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

単純化した例:

gateway_tier_map:
  interactive_fast:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_when: policy.allows_spillover

このマトリックスは分散コードではなく構成である必要があります。プロバイダーの名前の変更、利用可能な地域、および請求の処理は時間の経過とともに変更されます。ゲートウェイ ポリシーの更新は、API.

を呼び出すすべてのアプリケーションを再デプロイするより安全です。

容量を選択する前にワークロードを分類

最も難しい部分はプロバイダーのマッピングではありません。どのリクエストがどの階層に値するかを決定しています。

interactive_fast

に適した候補者

• 遅延により会話が中断される音声アシスタント。
• 価値の高いコンバージョンまたは維持パスに関する顧客対応のチャット。
• エージェントがアクティブに待機している人間参加型のオペレーション。
• 遅延が軽減に直接影響する本番環境のインシデント。

interactive_standard

に適した候補者

• 社内副操縦士。
• 人間が通常の応答時間を許容できるドラフトをサポートします。
• 応答時間が重要ではあるが重要ではない製品機能。

background_discount

に適した候補者

• 夜の要約。
• 大規模なドキュメントの強化。
• オフライン評価。
• 埋め込みを一括更新します。
• 分析のラベル付けとレポートの生成。

reserved_capacity

に適した候補者

• 安定した大容量本番ワークロード。
• 予測可能なスループットコミットメントを備えた契約済みの顧客ワークロード。
• ノイズの多い近隣変動を許容できず、専用容量を正当化するのに十分な使用率があるトラフィック。

簡単なポリシー ルールは、発信者が速度を優先するという理由だけでプレミアム容量を選択することを許可しないことです。宣言されたワークフロー、テナントの許可、予算枠が必要です。

テナントと API キーの権限を強制する

すべてのテナントと API キーには、許可された階層セットが必要です。新しいキーは、デフォルトでプレミアム ティアではなく、スタンダード ティアとバックグラウンド ティアに設定される必要があります。

テナント ポリシーの例:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": 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:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    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 などの中立層を公開します。これらの層をプロバイダー固有のメカニズムにマッピングし、テナントの権限を強制し、実際の結果を記録し、プレミアム容量をデフォルトのパスではなく意図的な例外にします。

関連資料

• プロバイダー 429 前のレート制限シェーピング
• 非同期の耐久性のあるゲートウェイ パターンバッチジョブ
• 見積、予約、決済、調整のための請求台帳