AI API ゲートウェイでの推論-労力ルーティング: プロバイダー全体のトークン、レイテンシー、コストの制御思考
推論可能なモデルは、思考の深さ、トークンの予算、請求、レイテンシーに関するさまざまなコントロールを公開します。推論作業を、各アプリケーション内の緩やかなモデル設定としてではなく、ゲートウェイ内の管理された実行時ポリシーとして扱います。
推論の深さは、単純なモデルのオプションではなくなりました。一部のプロバイダーは enum スタイルのエフォート レベルを公開しています。他のものは、トークンバジェット、動的思考、または思考を完全に無効にすることができないモデルファミリーを公開します。目に見える答えは短い場合がありますが、隠された推論は請求可能な出力トークンを消費します。すべてのアプリケーション チームがこれらの制御を直接設定すると、コスト、遅延、品質を説明するのが難しくなります。
実際的な解決策は、推論労力の制御を API ゲートウェイに移動することです。ゲートウェイは、ワークロードを分類し、プロバイダー固有の推論制御にマッピングし、テナントの予算を適用し、実際の推論の使用状況を記録し、ダウングレードの決定を分析で表示する必要があります。モデル ID、サービス層、最大出力、および推論の深さは、別個のポリシーの次元である必要があります。
読者の問題: 単純なリクエストが深い推論の代償を支払っている
推論可能なモデルを採用するチームは、通常、難しいタスクの品質を向上させるという合理的な目標から始めます。この問題は、抽出、短い要約、書式設定、および分類に同じデフォルトが再利用されるときに後で発生します。これらのリクエストには高価なテスト時のコンピューティングは必要ありませんが、それでもトリガーされる可能性があります。
これにより、3 つの操作上の障害が発生します。
- コストの不透明さ: ユーザーには短い答えが表示されますが、台帳には隠された推論トークンまたはプロバイダー固有の同等のものが含まれています。
- レイテンシー ドリフト: a同じモデル エイリアスの背後で推論の労力が増加するため、インタラクティブに見えるワークフローが遅くなります。
- ポリシーの断片化: 各製品チームは異なるプロバイダ パラメータを学習し、異なる上限を適用します。
ゲートウェイ レベルの推論ポリシーは、課金の問題になる前に制御の問題を解決します。
事実: プロバイダの推論コントロールは同等ではありません
以下は実装の事実であり、推奨事項ではありません。
- OpenAI 推論可能な API は、
none、minimal、low、medium、high、xhighなどのエフォート値を含む、サポートされているモデルのreasoningオブジェクトを公開します。労力を軽減すると、推論トークンが減り、応答速度が向上します。 - OpenAI ドキュメントには、
max_output_tokensが推論トークンと最終出力トークンの両方を含む、生成されるトークンの合計を制限できると記載されています。 - Anthropic 拡張思考は、
budget_tokens値で有効にできます。思考トークンは出力トークンとして課金され、表示される応答テキストとともにmax_tokensにカウントされます。 - Anthropic のドキュメントには、内部思考トークンは完全に表示されない場合でも課金される可能性があるため、課金される出力トークンの数が表示される応答トークンの数と一致しない可能性があることも記載されています。
- Gemini 思考のドキュメントには、応答の価格設定には出力トークンと思考トークンの両方が含まれ、思考を分離する使用フィールドが含まれる可能性があると記載されています。トークンと出力トークン。
- Gemini 2.5 スタイルのコントロールには
thinkingBudgetが含まれており、サポートされているモデルではダイナミックな思考が行われ、一部のモデル ファミリでは予算ゼロで無効化されます。一部のモデルは思考を無効にできません。 - 新しい Gemini ガイダンスでは、Gemini 3.x スタイル モデルに対して、生の数値予算ではなく、
minimal、low、medium、highなどのthinking_level値を推奨しています。
コア アーキテクチャの意味は単純です。プロバイダネイティブの推論制御を唯一の契約として公開しないでください。これらは、十分な安定性、十分な移植性、またはマルチプロバイダーのガバナンスにとって十分な比較性を備えていません。
推奨事項: プロバイダー中立の推論プロファイルを作成する
製品チームがプロバイダー API のリファレンスをすべて読まなくても理解できる小さな内部語彙を定義します。ほとんどのゲートウェイでは、次の 5 つのプロファイルで十分です。
| 内部プロファイル | 目的 | 一般的な使用 | ポリシー姿勢 |
|---|---|---|---|
none | サポートされている場合、隠れた推論を無効にするか最小化する | フォーマット、抽出、タグ付け、ルーティング | 大容量シンプルのデフォルトエンドポイント |
low | 控えめな曖昧さのための軽い推論 | 短いサポート返信、単純な比較、タスクの書き換え | 許可広範囲に |
standard | 日常的なナレッジワークのためのバランスのとれた推論 | 計画、コードレビュー、ポリシー分析、より長い合成 | 混合のデフォルトワークロード |
deep | 難しいタスクにはより大きな労力 | デバッグ、計算、セキュリティレビュー、エージェント計画 | テナント、キー、ワークフロー、および予算 |
capped-deep | 上限が厳しい高い推論 | 暴走コストが容認できないプレミアムタスク | 明示的な上限と分析が必要 |
プロファイルはアプリケーション側です契約。プロバイダーのパラメーターはアダプターの詳細になります。これにより、クライアント コードの移植性が維持され、プラットフォーム所有者はプロバイダ API の変更に応じてマッピングを更新できるようになります。
プロバイダをマッピングする前にワークロード クラスをマッピングする
推論作業は、個人の好みやモデルの人気ではなく、ワークロードの意図に基づいて選択する必要があります。 workload_class などのゲートウェイ フィールドを、クライアントによって指定されるか、承認されたルート構成から推測されて追加します。
ワークロード ポリシーの例
{
"workload_policies": {
"extract_invoice_fields": {
"default_reasoning_profile": "none",
"max_reasoning_profile": "low",
"max_output_tokens": 800
},
"classify_support_ticket": {
"default_reasoning_profile": "none",
"max_reasoning_profile": "low",
"max_output_tokens": 300
},
"draft_customer_reply": {
"default_reasoning_profile": "low",
"max_reasoning_profile": "standard",
"max_output_tokens": 1200
},
"code_review": {
"default_reasoning_profile": "standard",
"max_reasoning_profile": "deep",
"max_output_tokens": 4000
},
"security_review": {
"default_reasoning_profile": "deep",
"max_reasoning_profile": "capped-deep",
"max_output_tokens": 6000
},
"agent_plan": {
"default_reasoning_profile": "standard",
"max_reasoning_profile": "deep",
"max_output_tokens": 5000
}
}
}
このポリシーは 2 つの便利な機能を備えています。まず、単純なエンドポイントがコストのかかるデフォルトを継承するのを防ぎます。次に、管理者に具体的な検討対象を提供します。つまり、どのワークフローが詳細な推論をリクエストできるのか、またその上限は何ですか?
互換性マトリクスを構築する
ゲートウェイ アダプタは、すべてのプロバイダとモデル ファミリのマトリクスを維持する必要があります。少なくとも、推論、列挙作業量、数値予算、動的思考、サポートされる最大予算、推論トークンの使用フィールドの無効化をモデルがサポートするかどうかを保存します。
行列の形状の例
{
"providers": {
"provider_a": {
"model_family_x": {
"supports_reasoning": true,
"control_type": "effort_enum",
"allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
"can_disable": true,
"reports_reasoning_tokens": true
}
},
"provider_b": {
"model_family_y": {
"supports_reasoning": true,
"control_type": "budget_tokens",
"min_budget_tokens": 1024,
"max_budget_tokens": 32000,
"can_disable": false,
"reports_reasoning_tokens": true
}
},
"provider_c": {
"model_family_z": {
"supports_reasoning": true,
"control_type": "thinking_level",
"allowed_values": ["minimal", "low", "medium", "high"],
"can_disable": false,
"reports_reasoning_tokens": true
}
}
}
}
互換性行列は人間専用のドキュメントではありません。実行可能なポリシーである必要があります。リクエスト ルーターはこれをディスパッチ前に使用し、請求台帳は決済中にこれを使用する必要があります。
内部プロファイルをプロバイダ パラメータに変換する
プロバイダ マッピングは明示的であり、バージョン管理されている必要があります。 「より賢明な推論を使用する」などの曖昧な言葉に頼らないでください。ゲートウェイは、どのプロバイダ パラメータが送信されたかを正確に認識している必要があります。
マッピングの例
{
"reasoning_profile_mappings": {
"none": {
"effort_enum": "none",
"budget_tokens": 0,
"thinking_level": "minimal"
},
"low": {
"effort_enum": "low",
"budget_tokens": 2048,
"thinking_level": "low"
},
"standard": {
"effort_enum": "medium",
"budget_tokens": 8192,
"thinking_level": "medium"
},
"deep": {
"effort_enum": "high",
"budget_tokens": 20000,
"thinking_level": "high"
},
"capped-deep": {
"effort_enum": "high",
"budget_tokens": 12000,
"thinking_level": "high"
}
}
}
これらの数値は例であり、普遍的なデフォルトではありません。適切な予算は、モデル ファミリ、価格設定、レイテンシー要件、評価結果によって異なります。実装の重要な詳細は、ゲートウェイがマッピングを所有し、すべてのリクエストに対して解決されたプロバイダ パラメータを記録するということです。
マッピングが安全でない場合のフェール クローズ
サポートされていない推論コントロールが、黙ってプロバイダのデフォルトになるべきではありません。デフォルトは高価であり、時間の経過とともに変更される可能性があります。
要求されたプロファイルを安全にマッピングできない場合は、3 つの結果のいずれかを使用します:
- 許可: プロバイダ/モデルは要求されたプロファイルをサポートしており、テナント ポリシーで許可されています。
- ダウングレード: 要求されたプロファイルはポリシーを超えています。そのため、ゲートウェイは承認された最も高いプロファイルを適用し、ダウングレードを記録します。
- 拒否: プロファイルを安全に表すことができない、テナントは厳密な動作を必要とする、またはダウングレードは製品の期待に反することになります。
決定記録の例
{
"request_id": "req_123",
"tenant_id": "tenant_42",
"api_key_id": "key_abc",
"workflow": "code_review",
"requested_reasoning_profile": "deep",
"applied_reasoning_profile": "standard",
"decision": "downgraded",
"decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
"served_provider": "provider_a",
"served_model": "model_family_x",
"provider_reasoning_param": {
"effort": "medium"
}
}
この決定記録は、サポート、請求に関する紛争、および品質調査の際に役立ちます。また、予算が圧迫された場合の目に見えない品質低下も防ぎます。
予算管理には最大出力トークン以上が必要です
最大出力トークン制限は必要ですが、それだけでは十分ではありません。推論可能なモデルの場合、モデルは限界推論の大部分を費やし、最終的な答えを得る余地が少なすぎる可能性があります。ユーザーは、使用できない切り捨てられた応答に対して料金を支払う可能性があります。
階層化された上限を使用します:
max_reasoning_profileテナント、API キー、ワークフローごとに。max_thinking_budgetまたはプロバイダ/モデルのペアごとに同等。プロバイダがカウントする生成トークンの合計についてはmax_output_tokensdaily_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、およびストリーム完了ステータス。estimated_cost_before_dispatch、reserved_budget、settled_cost、reconciliation_status。policy_decision。許可、ダウングレード、拒否、フォールバックなど。
デフォルトでは生の思考連鎖をログに記録しません。ほとんどのガバナンスと FinOps の作業では、カウントとポリシーの決定で十分です。機密の推論テキストを保存すると、回避可能なプライバシー、コンプライアンス、および保存の問題が発生する可能性があります。
実装フロー
運用ゲートウェイは、確定的なリクエスト パイプラインとして推論労力のルーティングを実装できます。
- リクエストを認証します。 テナント、API キー、ユーザー、チーム、およびworkflow.
- ワークロードを分類します。 可能な場合は、明示的なクライアント フィールドを使用します。既知のエンドポイントの場合は、ルート構成でワークロード クラスをバインドします。
- ポリシーを読み込みます。 グローバル、テナント、キー、およびワークフロー制約を結合します。
- モデル候補を選択します。 推論制御を解決する前に、既存のモデル エイリアスまたはモデル選択ポリシーを使用します。
- 推論を解決するprofile. 要求されたプロファイルから開始し、ワークフローのデフォルトと最大値を適用します。
- 互換性を確認します。 プロバイダーとモデルのペアが選択したプロファイルを安全にサポートしていることを確認します。
- コストを見積もり、予算を確保します。 表示されるものだけでなく、考えられる使用法を含めます
- プロバイダー ネイティブ パラメータを使用してディスパッチします。 アダプタに応じて、列挙型の労力、予算トークン、思考レベル、または推論制御なしを送信します。
- 応答時の使用を正規化します。 個別の入力、表示される出力、推論、キャッシュされたトークン、ツール、および合計トークン
- 解決してアラートを出します。予約コストと実際のコストを調整し、割り当てを更新し、異常信号を発します。
このパイプラインは、推論制御を監査可能に保ちます。また、プロバイダ API が進化したときに、プラットフォーム チームがデフォルトを変更できる単一の場所も提供されます。
デフォルトを変更する前の評価
少数の印象的な例のみに基づいて、高度な推論の努力を促進しないでください。ワークロード クラスのデフォルトを変更する前に評価を実行します。
少なくとも 4 つの結果を測定します:
- タスクの品質: 精度、レビュー担当者の受け入れ、スキーマの妥当性、またはツール呼び出しの成功。
- レイテンシ: 最初のトークンと合計完了までの時間時間。
- コスト: リクエストごとのコストと受け入れられた回答ごとのコスト。
- 障害モード: 切り捨て、拒否、不正な形式の出力、過度のツール呼び出し、またはタイムアウト。
重要な指標は「リクエストごとのトークン」ではありません。検証に失敗した低トークンの回答は、再試行後のコストが高くなる可能性があります。高度な論理的回答は、セキュリティのレビューには正当化されるかもしれませんが、チケットのタグ付けには無駄です。ワークフローによって評価します。
トレードオフ
推論ガバナンスにより制御が追加されますが、無料ではありません。
- 移植性とプロバイダーの機能: 内部プロファイルによりアプリケーション コードの移植性が保たれますが、上級チームはプロバイダー固有の承認されたエスケープ ハッチが必要になる場合があります。
- 予算の確実性と品質: ハードキャップはテナントを無駄な出費から保護しますが、キャップが厳しすぎると、推論トークンがすでに使用された後、有用な答えが切り捨てられる可能性があります。
- 動的思考と予測可能性: プロバイダーの動的な制御は利便性を向上させますが、ゲートウェイが実際のデータを記録しない限り、ディスパッチ前のコスト見積もりを弱めます。
- ダウングレードの可用性と一貫性: 予算が圧迫されている場合のダウングレード推論は可用性を維持しますが、応答はテレメトリでラベル付けされ、品質評価に含まれる必要があります。
- 分析とプライバシー: 推論トークンの指標は便利ですが、生の推論トレースは、
予測: 推論ポリシーが標準のゲートウェイ コントロールになる
これは予測であり、検証された事実ではありません。推論の取り組みは、モデル ルーティング、レート制限、サービス層、トークン バジェットと並んで通常の運用管理になるでしょう。プロバイダーがさまざまな思考制御を公開し続けると、アプリケーション チームはそれらの違いを製品コードにハードコーディングする意欲が減ります。
推論を管理されたランタイム ディメンションとして扱うゲートウェイでは、テナントの請求がより明確になり、移植性が向上し、レイテンシの制御が向上します。これを付随的なモデル パラメータとして扱うゲートウェイは、短い回答が長い回答よりもコストがかかる場合がある理由を説明するのに苦労します。
実用的なチェックリスト
- 内部プロファイルを定義します:
none、low、standard、deep、capped-deep。 - デフォルト プロファイルと最大プロファイルを各ワークロード クラスに割り当てます。
- ビルド推論制御のためのプロバイダ/モデル互換性マトリックス。
- アダプター層でプロファイルをプロバイダネイティブ パラメータに変換します。
- 要求されたプロファイルを安全にマッピングできない場合はフェールクローズします。
- 推論を考慮した見積もりを使用して、ディスパッチ前に予算を予約します。
- 要求されたプロファイル、適用されたプロファイル、プロバイダ パラメータ、推論された使用状況、表示される出力、レイテンシ、およびコスト。
- 大量の単純なワークフローで高い推論トークン比率と深い推論に対する異常アラートを追加します。
- デフォルトの作業量を変更する前に、ワークフロー レベルの評価を実行します。
- デフォルトで生の推論テキストをログに記録することは避けてください。
結論
推論可能なモデルは、難しい問題により多くのコンピューティングを費やすことができるため便利です。同じ機能を無差別に適用すると、コストが高くなります。ゲートウェイは、より深い推論をいつ許可するか、各プロバイダにマッピングする方法、消費できる予算、および結果の測定方法を決定する必要があります。
永続的なパターンは、推論作業をモデル ID から分離することです。ワークロードごとにルーティングし、テナント ポリシーごとに上限を設定し、プロバイダーごとに適応して、実際の使用量を台帳に記録します。これにより、推論が隠れたコスト変数から AI API コスト制御の明示的なコントロール サーフェスに変わります。