AI API ゲートウェイでの推論-労力ルーティング: プロバイダー全体のトークン、レイテンシー、コストの制御思考

推論の深さは、もはや単純なモデルのオプションではありません。一部のプロバイダーは enum スタイルのエフォート レベルを公開しています。他のものは、トークンバジェット、動的思考、または思考を完全に無効にすることができないモデルファミリーを公開します。目に見える答えは短い場合がありますが、隠された推論は請求可能な出力トークンを消費します。すべてのアプリケーション チームがこれらの制御を直接設定すると、コスト、レイテンシ、品質を説明するのが難しくなります。

実際的な解決策は、推論労力の制御を API ゲートウェイに移行することです。ゲートウェイは、ワークロードを分類し、プロバイダー固有の推論制御にマッピングし、テナントの予算を適用し、実際の推論の使用状況を記録し、ダウングレードの決定を分析で表示する必要があります。モデル ID、サービス層、最大出力、および推論の深さは、別個のポリシーの次元である必要があります。

読者の問題: 単純なリクエストは深い推論の代償を支払っている

推論可能なモデルを採用するチームは、通常、難しいタスクの品質を向上させるという合理的な目標から始めます。この問題は、抽出、短い要約、書式設定、および分類に同じデフォルトが再利用されるときに後で発生します。これらのリクエストには高価なテスト時のコンピューティングは必要ありませんが、それでもトリガーされる可能性があります。

これにより、次の 3 つの運用上の障害が発生します。

• コストの不透明さ: ユーザーには短い答えが表示されますが、台帳には隠された推論トークンまたはプロバイダー固有の同等のものが含まれています。
• レイテンシ ドリフト: 同じモデルの背後で推論の労力が増加するため、インタラクティブに見えたワークフローが遅くなります。
• ポリシーの断片化: 各製品チームは、異なるプロバイダー パラメーターを学習し、異なる上限を適用します。

ゲートウェイ レベルの推論ポリシーにより、制御の問題が請求問題になる前に解決されます。

事実: プロバイダーの推論制御は同等ではありません

以下は実装の事実であり、推奨事項ではありません。

• OpenAI推論対応 API は、none、minimal、low、medium、high、xhigh などの努力値を含む、サポートされているモデルの reasoning オブジェクトを公開します。労力を軽減すると、推論トークンが減り、応答速度が向上します。
• OpenAI のドキュメントには、max_output_tokens により、推論トークンと最終出力トークンの両方を含む、生成されるトークンの合計を制限できると記載されています。
• 人間的拡張思考は、budget_tokens 値で有効にできます。思考トークンは出力トークンとして課金され、表示される応答テキストとともに max_tokens にカウントされます。
• Anthropic のドキュメントでは、内部の思考トークンは完全に表示されない場合でも課金される可能性があるため、課金される出力トークンの数が表示される応答トークンの数と一致しない可能性があることにも言及しています。
• Gemini の思考のドキュメントでは、応答の価格設定には出力トークンと思考トークンの両方を含めることができ、思考トークンと出力を分離する使用フィールドがあると記載されています。
• Gemini 2.5 スタイルのコントロールには、サポートされているモデルでの動的思考と一部のモデル ファミリでのゼロバジェット無効化を備えた ThinkingBudget が含まれています。一部のモデルは思考を無効にできません。
• 新しい Gemini ガイダンスでは、Gemini 3.x スタイルのモデルに対して、生の数値予算ではなく、minimal、low、medium、high などの Thinking_level 値を推奨しています。

コア アーキテクチャの意味は単純です。プロバイダー ネイティブの推論制御を唯一の契約として公開しないことです。これらは、十分な安定性、十分な移植性、またはマルチプロバイダーのガバナンスにとって十分な比較性を備えていません。

推奨事項: プロバイダー中立の推論プロファイルを作成する

製品チームがすべてのプロバイダー API リファレンスを読まなくても理解できる、小さな内部語彙を定義します。ほとんどのゲートウェイでは、次の 5 つのプロファイルで十分です。

プロファイルはアプリケーション側のコントラクトです。プロバイダーのパラメーターはアダプターの詳細になります。これにより、クライアント コードの移植性が維持され、プラットフォーム所有者はプロバイダー API の変更に応じてマッピングを更新できるようになります。

プロバイダーをマッピングする前にワークロード クラスをマッピングする

推論作業は、個人の好みやモデルの人気ではなく、ワークロードの意図に基づいて選択する必要があります。 workload_class などのゲートウェイ フィールドを、クライアントによって指定されるか、承認されたルート設定から推測されて追加します。

サンプル ワークロード ポリシー

{
  "ワークロードポリシー": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "なし",
      "max_reasoning_profile": "低",
      「最大出力トークン」: 800
    }、
    "classify_support_ticket": {
      "default_reasoning_profile": "なし",
      "max_reasoning_profile": "低",
      「最大出力トークン」: 300
    }、
    "draft_customer_reply": {
      "default_reasoning_profile": "低",
      "max_reasoning_profile": "標準",
      「最大出力トークン」: 1200
    }、
    "コードレビュー": {
      "default_reasoning_profile": "標準",
      "max_reasoning_profile": "深い",
      「max_output_tokens」: 4000
    }、
    "セキュリティレビュー": {
      "default_reasoning_profile": "深い",
      "max_reasoning_profile": "キャップ付きディープ",
      「最大出力トークン」: 6000
    }、
    "エージェントプラン": {
      "default_reasoning_profile": "標準",
      "max_reasoning_profile": "深い",
      「max_output_tokens」: 5000
    }
  }
}

このポリシーは 2 つの便利な機能を果たします。まず、単純なエンドポイントがコストのかかるデフォルトを継承するのを防ぎます。次に、管理者に具体的な検討対象を提供します。つまり、どのワークフローが詳細な推論をリクエストできるのか、またその上限は何ですか?

互換性マトリックスの構築

ゲートウェイ アダプターは、すべてのプロバイダーとモデル ファミリのマトリックスを維持する必要があります。少なくとも、推論、列挙型の労力、数値予算、動的思考、サポートされる最大予算、および推論トークンの使用フィールドの無効化をモデルがサポートするかどうかを保存します。

行列の形状の例

{
  「プロバイダー」: {
    "プロバイダー_a": {
      "モデルファミリー_x": {
        "supports_reasoning": true、
        "control_type": "effort_enum",
        "allowed_values": ["なし"、"最小"、"低"、"中"、"高"、"x高"]、
        "can_disable": true、
        "reports_reasoning_tokens": true
      }
    }、
    "プロバイダ_b": {
      "モデルファミリー_y": {
        "supports_reasoning": true、
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024、
        "max_budget_tokens": 32000、
        "can_disable": false、
        "reports_reasoning_tokens": true
      }
    }、
    "プロバイダー_c": {
      "モデルファミリー_z": {
        "supports_reasoning": true、
        "control_type": "思考レベル",
        "allowed_values": ["最小"、"低"、"中"、"高"]、
        "can_disable": false、
        "reports_reasoning_tokens": true
      }
    }
  }
}

互換性マトリックスは人間専用のドキュメントではありません。実行可能なポリシーである必要があります。リクエスト ルーターはディスパッチ前にこれを使用し、請求台帳は決済中にそれを使用する必要があります。

内部プロファイルをプロバイダー パラメータに変換する

プロバイダー マッピングは明示的でバージョン管理されている必要があります。 「より賢明な推論を使用する」などの曖昧な言葉に頼らないでください。ゲートウェイは、どのプロバイダ パラメータが送信されたかを正確に把握している必要があります。

マッピングの例

{
  "reasoning_profile_mappings": {
    "なし": {
      "effort_enum": "なし",
      「budget_tokens」: 0、
      "思考レベル": "最小限"
    }、
    「低」: {
      "effort_enum": "低",
      "budget_tokens": 2048、
      "思考レベル": "低"
    }、
    「標準」: {
      "effort_enum": "中",
      "budget_tokens": 8192、"思考レベル": "中"
    }、
    「深い」: {
      "effort_enum": "高",
      "budget_tokens": 20000、
      "思考レベル": "高い"
    }、
    "キャップ付きディープ": {
      "effort_enum": "高",
      「budget_tokens」: 12000、
      "思考レベル": "高い"
    }
  }
}

これらの数値は例であり、普遍的なデフォルトではありません。適切な予算は、モデル ファミリ、価格設定、レイテンシ要件、評価結果によって異なります。実装の重要な詳細は、ゲートウェイがマッピングを所有し、リクエストごとに解決されたプロバイダー パラメーターを記録することです。

マッピングが安全でない場合はフェール クローズする

サポートされていない推論コントロールが、黙ってプロバイダーのデフォルトになるべきではありません。デフォルトは高価であり、時間の経過とともに変更される可能性があります。

要求されたプロファイルを安全にマッピングできない場合は、次の 3 つの結果のいずれかを使用します。

• 許可: プロバイダー/モデルは要求されたプロファイルをサポートし、テナント ポリシーで許可されます。
• ダウングレード: 要求されたプロファイルはポリシーを上回るため、ゲートウェイは最も承認されたプロファイルを適用し、 downgrade.
• 拒否: プロファイルを安全に表現できない、テナントに厳密な動作が必要、またはダウングレードは製品の期待に違反する可能性があります。

意思決定記録の例

{
  "request_id": "req_123",
  "テナントID": "テナント_42",
  "api_key_id": "key_abc",
  "ワークフロー": "コードレビュー",
  "requested_reasoning_profile": "深い",
  "applied_reasoning_profile": "標準",
  "決定": "格下げ",
  "決定理由": "テナント月次ディープ合理化予算超過",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    「努力」：「中」
  }
}

この決定記録は、サポート、請求に関する紛争、品質調査の際に役立ちます。また、予算が圧迫された場合の目に見えない品質低下も防ぎます。

予算管理には最大出力トークン以上が必要

最大出力トークン制限は必要ですが、それだけでは十分ではありません。推論可能なモデルの場合、モデルは限界推論の大部分を費やし、最終的な答えを得る余地が少なすぎる可能性があります。その後、ユーザーは、使用できない切り捨てられた応答に対して料金を支払う可能性があります。

階層化された上限を使用します:

• max_reasoning_profile テナント、API キー、ワークフローごと。
• max_ Thinking_budget またはプロバイダ/モデルのペアごとの同等の値。
• max_output_tokens は、プロバイダが生成したトークンの合計です。推論と目に見える出力を一緒にカウントします。
• daily_deep_reasoning_spend テナントまたは再販業者の顧客ごと。
• deep_reasoning_requests_per_hour は、大容量エンドポイントの場合。
• reasoning_token_ratio_threshold は、異常アラートの場合。

予算チェックでは、発送前に起こります。決済ステップでは、プロバイダーの応答が到着した後に実際の使用量を調整する必要があります。プロバイダーが思考トークンを個別に報告する場合は、それらを個別に保存します。合計出力トークンのみをレポートする場合は、利用可能な最適な正規化フィールドを保存し、信頼レベルをマークします。

推論の使用のための台帳フィールド

分析では、表示される回答の長さと支払われた推論の労力との違いを示す必要があります。有用なレジャー行には、

• tenant_id、api_key_id、end_user_id、workflow が含まれている必要があります。
• requested_model、served_model、プロバイダー、およびモデルエイリアス。
• requested_reasoning_profile および applied_reasoning_profile。
• provider_reasoning_param、構造化 JSON として保存されます。
• input_tokens、visible_output_tokens、 reasoning_tokens_or_equivalent、cached_tokens、total_billable_tokens。
• max_output_tokens およびプロバイダー固有の思考バジェット。
• latency_to_first_token_ms、total_latency_ms、およびストリーム完了status。
• estimated_cost_before_dispatch、reserved_budget、settled_cost、reconciliation_status。
• policy_decion（許可、ダウングレード、拒否、フォールバックなど）。

生の思考連鎖をログに記録しないデフォルトでは。ほとんどのガバナンスと FinOps の作業では、カウントとポリシーの決定で十分です。機密の推論テキストを保存すると、回避可能なプライバシー、コンプライアンス、保持の問題が発生する可能性があります。

実装フロー

本番ゲートウェイは、決定論的なリクエスト パイプラインとして推論労力のルーティングを実装できます。

1. リクエストを認証します。 テナント、API キー、ユーザー、チーム、ワークフローを解決します。
2. ワークロード可能な場合は、明示的なクライアント フィールドを使用します。既知のエンドポイントの場合、ルート設定でワークロード クラスをバインドします。
3. ロード ポリシー。 グローバル、テナント、キー、およびワークフロー制約を結合します。
4. モデル候補を選択します。
5. 推論制御を解決する前に、既存のモデル エイリアスまたはモデル選択ポリシーを使用します。
6. 推論プロファイルを解決します。 要求されたプロファイルから開始し、ワークフローのデフォルトを適用し、
7. 互換性を確認します。
8. 互換性を確認します。 プロバイダーとモデルのペアが、選択したプロファイルを安全にサポートしていることを確認します。
9. コストと予算を見積もります。 表示される出力だけでなく、考えられる推論の使用法を含めます。
10. プロバイダー ネイティブのパラメーターを使用して送信します。 列挙型の労力、予算トークン、思考レベル、または推論制御なしを送信します。
11. 応答時の使用を正規化します。
12. 可能な場合、入力、表示される出力、推論、キャッシュされたトークン、ツール、および合計トークンを分離します。
13. 解決とアラート。予約コストと実際のコストを調整し、クォータを更新し、異常シグナルを発します。

このパイプラインは推論制御を監査可能に保ちます。また、プロバイダー API が進化したときに、プラットフォーム チームにデフォルトを変更できる単一の場所が提供されます。

デフォルトを変更する前の評価

いくつかの印象的な例のみに基づいて、より高度な推論の努力を促進しないでください。ワークロード クラスのデフォルトを変更する前に評価を実行します。

少なくとも 4 つの結果を測定します:

• タスクの品質:正確さ、レビュー担当者の受け入れ、スキーマの有効性、またはツール呼び出しの成功。
• レイテンシ:最初のトークンまでの時間と合計完了時間。
• コスト:リクエストあたりのコストと受け入れられたあたりのコスト
• 障害モード: 切り捨て、拒否、不正な出力、過剰なツール呼び出し、またはタイムアウト。

重要な指標は「リクエストあたりのトークン」ではありません。検証に失敗した低トークンの回答は、再試行後のコストが高くなる可能性があります。より論理的な回答は、セキュリティのレビューには正当化されるかもしれませんが、チケットのタグ付けには無駄です。ワークフローによって評価します。

トレードオフ

推論ガバナンスにより制御が追加されますが、無料ではありません。

• 移植性とプロバイダーの機能: 内部プロファイルによりアプリケーション コードの移植性が維持されますが、高度なチームにはプロバイダー固有の制御用に承認された避難口が必要になる場合があります。
• 予算の確実性と品質: ハード キャップがテナントの暴走を防ぎます。
• 動的思考と予測可能性:
• 動的思考と予測可能性:動的プロバイダー制御は利便性を向上させることができますが、ゲートウェイが実際の使用量を記録し、決済制限を強制しない限り、ディスパッチ前のコスト見積もりを弱めます。
• ダウングレード可用性と一貫性:予算のプレッシャーがある中でのダウングレード推論は可用性を維持しますが、応答にはラベルを付ける必要があります。
• 分析とプライバシー: 推論トークンのメトリクスは便利ですが、意図的に承認された保持ポリシーがない限り、生の推論トレースを保存すべきではありません。

予測: 推論ポリシーが標準のゲートウェイ コントロールになる

これは予測であり、検証された事実ではありません: 推論の取り組みは、モデル ルーティング、レートと並んで通常の運用管理になるでしょう。制限、サービス層、トークンの予算。プロバイダーがさまざまな思考制御を公開し続けると、アプリケーション チームはそれらの違いを製品コードにハードコーディングする意欲が減ります。

推論を管理されたランタイム ディメンションとして扱うゲートウェイでは、テナントの請求がより明確になり、移植性が向上し、レイテンシの制御が向上します。これを付随的なモデル パラメータとして扱うゲートウェイは、短い回答が長い回答よりもコストがかかる場合がある理由を説明するのに苦労します。

実用的なチェックリスト

• 内部プロファイルを定義します: none、low、standard、deep、capped-deep。
• それぞれにデフォルト プロファイルと最大プロファイルを割り当てます。ワークロード クラス。
• 推論制御用のプロバイダ/モデルの互換性マトリックスを構築します。
• アダプタ層でプロファイルをプロバイダ ネイティブ パラメータに変換します。
• リクエストされたプロファイルを安全にマッピングできない場合はフェール クローズします。
• 推論を考慮した見積もりを使用して、ディスパッチ前に予算を確保します。
• リクエストされたプロファイル、適用されたプロファイル、プロバイダ パラメータ、推論の使用法、表示される出力、レイテンシ、コストを記録します。
• 追加大量の単純なワークフローにおける高い推論トークン比率と深い推論に対する異常アラート。
• デフォルトの作業量を変更する前に、ワークフロー レベルの評価を実行します。
• デフォルトで生の推論テキストをログに記録することは避けてください。

結論

推論可能なモデルは、難しい問題により多くのコンピューティングを費やすことができるため便利です。同じ機能を無差別に適用すると、コストが高くなります。ゲートウェイは、より深い推論がいつ許可されるか、それが各プロバイダーにどのようにマッピングされるか、消費できる予算の量、および結果の測定方法を決定する必要があります。

永続的なパターンは、推論の労力をモデル ID から分離することです。ワークロードごとにルーティングし、テナント ポリシーごとに上限を設定し、プロバイダーごとに適応して、実際の使用量を台帳に記録します。これにより、推論が隠れたコスト変数から AI API コスト制御の明示的なコントロール サーフェスに変わります。

関連資料

• すべてのモデル呼び出しを予約および決済する請求台帳
• 内部モデルのエイリアスと機能コントラクト
• 最終的な使用量と部分的な使用量のストリーミング トークン アカウンティング応答