新しいテナントを受け入れる前に AI API 容量台帳を構築する
プロバイダーの割り当て、プロジェクトの制限、地域の TPM プール、支出上限を、販売可能な AI API の容量、テナントの予約、より安全なオンボーディングの決定に変えるための実用的なアーキテクチャ。
新しい顧客に対応できないことがライブトラフィックによって判明するのを待たないでください。ランタイム スロットルは、「このリクエストは今すぐ実行すべきか?」という狭い質問に答えます。オンボーディング前に重要な商業的な質問には答えていません。つまり、このプロバイダー アカウント、プロジェクト、ワークスペース、リージョン、モデル ファミリー、および支出エンベロープは、販売しようとしているテナントをサポートできますか?
AI API 容量台帳は、その質問に具体的な答えを与えます。上流の制限を内部供給に変換し、予約を減算し、ヘッドルームを適用し、約束されたワークロードに信頼できる裏付け容量がない場合、プランの作成またはテナントのアクティブ化をブロックします。
容量台帳で制御される内容
容量台帳は、実行時のレート制限、請求、またはインシデント対応に代わるものではありません。これは、販売、プラン設計、テナント プロビジョニング、モデル プロファイルの割り当て、アップグレードといったライフサイクルの早い段階にあります。
読者の問題は特有です。AI API 再販業者と SaaS チームは、上流のプロバイダーが割り当てを承認、公開、維持するよりも早くアクセスを販売できます。顧客は、関連するアップストリーム プールが存在するかどうかを誰かが確認する前に、モデル、リージョン、レイテンシー層、または月間ボリュームを約束してプランを購入する場合があります。結果は予測可能です: 429 エラー、アップグレードのブロック、緊急割り当てリクエスト、強制フォールバック モデル、気まずい顧客コミュニケーション。
台帳は次のような質問に答える必要があります:
- 予約されたエンタープライズ容量を消費せずに、このモデル ファミリーでこのテナントをアクティブ化できますか?
- 再販業者は、特定の地域で毎月 2,000 万トークンを約束するプランを作成できますか?
- このお客様はバースト可能なアクセスから確約容量にアップグレードできますか?
- どのプロバイダー プールがその約束を支持しますか?その前提はいつ見直す必要がありますか?
- プロバイダーの制限が最近調整されていない場合はどうなりますか?
これは、AI API 販売代理店プラットフォームにとって特に重要です。このプラットフォームでは、上流の割り当てが少数のプロバイダー アカウントに集中している一方で、下流のポータルがパッケージ化されたアクセスを多くの顧客に販売する可能性があります。
基礎となる事実
以下はプロバイダーのドキュメントからの事実上の制約であり、設計を形作る必要があります。
- OpenAI は、組織およびプロジェクト レベルでの API レート制限を文書化します。制限はモデルによって異なり、モデル ファミリ間で共有される場合があり、応答ヘッダーを通じて検査できます。
- OpenAI では、レート制限とは別に毎月の支出管理について説明します。ハードな支出制限を強制すると 429 エラーが返される可能性があり、強制は即座に行われない可能性があります。
- OpenAI Admin API は、プロジェクト管理、API キー管理、支出制限、アラート、監査ログ、レート制限操作などの組織のワークフローをサポートします。
- Anthropic には、構成された組織とワークスペースの制限を照会するための管理者 API レート制限 API が文書化されています。
- Anthropic API 応答には、適用された制限、現在の使用量、リセットのタイミングを示すレート制限ヘッダーが含まれます。
- Azure OpenAI の割り当ては、サブスクリプション、リージョン、モデル、デプロイメント タイプごとに、1 分あたりのトークン数単位で割り当てられます。デプロイメントは、使用可能な割り当てプールから消費します。
- Azure ドキュメントでは、サブスクリプション全体で利用可能な割り当てを表示するための最小限のアクセスとして、Cognitive Services の使用状況閲覧者ロールを推奨しています。
- Google クラウド割り当ては、プロジェクトが使用できるリソースの量を制限し、多くの場合調整でき、クラウド割り当てを通じて監視されます。システム制限は固定されています。
これらの事実は設計要件を暗示しています。台帳は容量を単一のグローバル番号としてモデル化できません。正規化されたアドミッション決定を独自の製品とパートナー API.
に公開しながら、プロバイダー固有のディメンションを保持する必要があります。推奨される台帳モデル
ファーストクラスのコントロールプレーンオブジェクトとしてアップストリーム容量をモデル化します。有用な容量プール レコードには通常、次のフィールドが必要です:
- プロバイダ: openai、anthropic、azure_openai、gemini、または別の上流。
- provider_account_id: 割り当てを所有する組織、サブスクリプション、請求先アカウント、またはテナント。
- スコープ: 組織、プロジェクト、ワークスペース、クラウド プロジェクト、リージョン、デプロイメント、またはサービス アカウント。
- region: は、Azure および居住地に依存するワークロードに必要です。制限が地域に限定されないプロバイダーの場合はオプションまたはグローバルです。
- model_family: 正確なプロバイダ モデル文字列だけでなく、正規化された内部ファミリー。
- deployment_type: 標準、プロビジョニング、バッチ、優先、リアルタイム、または別の容量クラス。
- rpm_limit: リクエスト/分 (可能な場合)。
- tpm_limit: トークン/分、または同等のトークンレート容量。
- batch_queue_limit: キューに入れられたジョブ、キューに入れられたトークン、ファイル サイズ、またはプロバイダー固有の非同期容量。
- monthly_spend_cap: ハードまたは設定された上流予算の境界。
- sellable_fraction: 商用契約に許可される測定容量の割合。
- effective_from と effective_until: のため、一時的な割り当ての増加が永続的な想定にはなりません。
- ソース: API、コンソールの証拠、アカウント マネージャーの承認、手動オーバーライド、またはヘッダーから推測されます。
- last_reconciled_at:: 古いデータの警告と承認ゲート。
次に、これらのプールから消費する予約レコードを追加します:
- tenant_id または reseller_customer_id: 顧客または下流テナント。
- reservation_class: コミット済み、バースト可能、内部、バッチ、free_trial、または緊急。
- model_profile_id: モデルとフォールバックの製品向けバンドル。
- required_rpm および required_tpm: 入場見積もり。
- monthly_volume_commitment: 予想される月間トークン量または支出。
- region_policy: 必須、優先、または制限なし。
- ステータス: 保留中、アクティブ、機能低下、期限切れ、拒否、または awaiting_provider_quota.
- approved_by および approval_reason: は商用例外です。
- review_at: 容量を再度確認する必要がある場合。
重要なのは、すべてのトークンを完全に予測することではありません。重要なのは、顧客が依存する前に、販売とオンボーディングに関する決定を十分に明確にし、監査、異議申し立て、更新ができるようにすることです。
アドミッション コントロールはランタイム スロットリングとは異なります
ランタイムスロットルはリクエストレベルの保護です。ライブリクエストのプレッシャーを推定または測定し、ディスパッチするか、遅延するか、低下させるか、または拒否するかを決定します。これは必要ですが、反応的なものです。
アドミッションコントロールは供給側の計画です。テナント、リセラー プラン、モデル プロファイル、またはアップグレードの存在を許可するかどうかを決定します。強力な実装により、キャパシティ チェックが パートナー API 自動化、プランの検証、顧客のオンボーディング、管理者の承認に接続されます。
たとえば、計画が次のことを約束している場合、計画の作成は検証に失敗する必要があります:
- マッピングされたプロバイダー プールを持たないモデル ファミリ;
- 割り当てが存在しないリージョン;
- ベストエフォート型の容量のみによって裏付けられたレイテンシー層;
- 販売可能なヘッドルームを超えるコミットされたトークンの量;
- キュー制限が不明なバッチ層;
- プロバイダー アカウントをハードキャップに近づける費用コミットメント。
これは顧客向けの調整ではありません。それは製品の完全性です。ゲートウェイが、プロバイダーの割り当てによって裏付けられないプランをリセラーに宣伝させる場合、実行時コードは、守れない約束を継承することになります。
余裕のある販売可能容量を計算する
上流の番号を 100% 販売しないでください。プロバイダーの制限が変動する可能性があり、モデル ファミリがプールを共有する可能性があり、再試行により余分なクォータが消費され、顧客のトラフィックが均等に到着しないことがあります。実際的なポリシーでは、測定された容量の一部のみが販売可能として公開されます。
始めるには簡単な数式で十分です:
sellable_tpm = provider_tpm_limit * sellable_fraction
available_tpm = sellable_tpm - active_reserved_tpm - pending_reserved_tpm
プロバイダー プールが 1,000,000 TPM を公開し、ポリシーが 70 パーセントを販売する場合、コミットメントに利用できるのは 700,000 TPM のみです。アクティブなテナントが 500,000 TPM を予約し、保留中の承認済み取引が 100,000 TPM を予約している場合、残りの利用可能な TPM は 100,000 です。
販売可能な割合はプールのタイプによって異なります:
- 安定した大容量プール: 調整が完了した後は、70 ～ 80% が妥当である可能性があります。
- 新しいプロバイダ アカウント: 実際のトラフィックで動作が確認されるまでは、50 ～ 60% の方が安全です。
- 共有モデル ファミリー プール: 関連のないモデル エイリアスが競合する可能性があるため、販売可能容量が減少します。
- 手動または古い証拠: 販売可能な容量を削減するか、新しい契約をブロックします。
- 緊急フォールバック プール: 通常の容量として販売しないでください。
支出上限にも同様の処理が必要です。プロバイダーのハード支出制限は予算のバックストップであり、製品容量計画ではありません。アップストリームのハードキャップが月額 50,000 ドルの場合、ゲートウェイは計画された使用量に対して低い内部しきい値を予約し、ハード制限によって運用トラフィックが中断される前に警告する必要があります。
リクエストごとの予約の代わりに予約クラスを使用する
受付中に考えられるすべてのリクエストに対してプロバイダーの容量を予約しないでください。これはランタイムスロットリングに属します。キャパシティ アドミッションは予約クラスを使用するとより適切に機能します。
熱心な顧客
熱心な顧客は明示的な容量予約を取得します。計画では、必要なモデル ファミリ、リージョン、サービス レベル、トークン レートの仮定、レビュー日を指定する必要があります。アイドル状態の予約は使用率を低下させますが、約束を信頼できるものにします。
バースト可能な顧客
バースト可能な顧客は共有プールから引き込みます。利用可能な場合は容量を使用できますが、コミットされたオンボーディングをブロックしないでください。計画言語、API ステータス、および機能低下の動作は明確でなければなりません。
内部ワークロード
内部評価、サポート ツール、分析ジョブ、および管理自動化には、独自の予約クラスが必要です。そうしないと、営業が利用可能であると信じている容量を内部トラフィックが黙って消費する可能性があります。
バッチジョブ
バッチ容量は、RPM と TPM だけではなく、キュー サイズ、ジョブ数、エンキューされたトークン、ファイル制限、またはターンアラウンド コミットメントによって制御される可能性があるため、個別のモデリングが必要です。
無料トライアル
無料トライアルでは、意図的に制限されたプールを使用する必要があります。無料トライアルは、意図的な市場投入決定の一部でない限り、希少な地域または優先容量を消費するべきではありません。
スケジュールに従ってプロバイダーのキャパシティを調整する
元帳は、調整によって提供される場合にのみ役立ちます。プロバイダーのコントロール プレーンはゲートウェイの外で変更されます。管理者はプロジェクト、ワークスペース、デプロイメント、支出上限、キー、リージョン、モデルの可用性を調整します。既知の管理者の変更後に、スケジュールされたプルとイベント駆動型のチェックを構築します。
実際の調整ループは次のようになります:
- API が存在するプロバイダーに表示される制限を取得します。
- ディメンションを容量プール レコードに正規化します。
- 新しい値を前の台帳スナップショットと比較します。
- 容量が減少または消滅した場合、予約を危険にさらしているとマークします。
- 証拠期間が終了すると、一時的な増加の期限が切れます。
- 古いプールにまだアクティブなコミットメントが残っている場合は、アラートを生成します。
- すべての変更を監査ログに記録します。
一部の容量の証拠は不完全です。プロバイダーは、API、クラウド クォータ コンソール、応答ヘッダー、またはアカウントを代表するワークフローを通じて制限を公開する場合があります。これらすべてをさまざまな証拠タイプとしてサポートします。台帳は、すべてのプロバイダーが同じコントロール プレーン データを発行しているかのように見せるのではなく、信頼性と最新性を示す必要があります。
これは、より広範な AI API 割り当て管理と重複しますが、容量台帳の目的はより狭く、トラフィックが到着する前に何を安全に販売またはアクティブ化できるかを決定することです。
製品に入れるための入場小切手
キャパシティアドミッションは、Promise が作成されるワークフローの一部である必要があります。通常、最も役立つチェックは次のとおりです。
計画作成チェック
管理者が販売パートナー プランを作成するときは、宣伝されているモデル ファミリー、サービス レベル、地域別のコミットメント、月間ボリューム、バーストの想定、およびフォールバック ポリシーを検証します。ヘッドルームのあるプランをサポートできるプロバイダー プールがない場合、プランはドラフトのままにするか、オーバーライドを必要とする必要があります。
テナントのアクティブ化チェック
顧客がプロビジョニングされたら、関連する容量クラスを予約します。アクティベーション応答では、アクティブ、保留中のクォータ承認、フォールバックへの低下、ブロックなどのステータスを公開する必要があります。
アップグレードチェック
テナントのプランを増やす前に、ターゲットの予約に対して同じ入場料の計算を実行します。容量が不十分な場合、アップグレードはプロバイダー割り当てワークフローに関連付けられた保留中のリクエストになります。
モデル プロファイル チェック
モデルのエイリアスまたはプロファイルが変更された場合は、予約を再計算します。無害に見えるエイリアス プロモーションにより、テナントをあるプロバイダー プールから別のプロバイダー プールに移動し、供給モデルを破壊する可能性があります。
地域ポリシーの確認
Azure および居住地に依存するワークロードの場合は、リージョンを明示的に検証します。別のリージョンの同等のモデルは、顧客ポリシーでフォールバックが許可されていない限り、常駐の約束を満たしません。
実装の詳細: 入学決定の形式
入院結果を機械で読み取り可能な状態に保ちます。パートナー API、再販業者ポータル、または内部管理 UI は人間によるメモを解析する必要はありません。
{
"decision": "approved",
"tenant_id": "tenant_123",
"model_profile_id": "profile_support_fast",
"reservation_class": "committed",
"backing_pool_id": "pool_azure_eastus_gpt4_standard",
"required_tpm": 120000,
"required_rpm": 600,
"sellable_tpm_before": 700000,
"reserved_tpm_before": 520000,
"available_tpm_after": 60000,
"headroom_policy": "standard_70_percent",
"evidence_freshness": "fresh",
"review_at": "2026-11-01T00:00:00Z"
}
拒否の場合は、製品ワークフローが動作できる理由を返します:
{
"decision": "blocked",
"reason_code": "insufficient_regional_tpm",
"required_region": "eastus",
"required_tpm": 300000,
"available_tpm": 90000,
"recommended_action": "request_provider_quota_increase",
"fallback_options": [
"standard_global_pool",
"lower_volume_plan",
"pending_activation"
]
}
「容量なし」のみを返すことは避けてください。呼び出し元は、問題が地域割り当て、モデルの可用性、古い証拠、支出上限の露出、デプロイメントの不足、またはポリシーの競合であるかどうかを知る必要があります。
商業上の決定を監査する
すべての容量に関する決定は監査可能である必要があります。レコード:
- テナント、プラン、またはアップグレードをリクエストした人;
- 決定を承認または無効にしたのは誰か;
- どのプロバイダー プールが約束を裏付けたのか;
- どのヘッドルーム ポリシーが適用されたか;
- どの証拠ソースが使用されたか;
- 予約の有効期限が切れたとき、または予約の確認が必要なとき;
- テナントが機能低下した場合、または別のプールに移動された場合の変更点。
これはインシデント発生時に重要です。プールが割り当てを使い果たした場合、チームは問題の原因が予期せぬトラフィック、プロバイダーの古い証拠、上書き、モデル プロファイルの移行、またはアクティブ化すべきではなかった販売計画によるものなのかを知る必要があります。
トレードオフ
容量台帳により、運用上のオーバーヘッドが追加されます。また、上流の割り当てが確認されるまで収益を拒否することもできます。それはイライラしますが、負荷がかかると失敗するプランを販売するよりは望ましいです。
ハード予約により、価値の高いテナントの予測可能性が向上しますが、顧客がアイドル状態の場合は使用率が低下します。ソフト予約により使用率は向上しますが、より強力な実行時制御と、顧客向けのより明確な劣化ルールが必要です。
リージョン モデリングは Azure および居住地に依存するワークロードに必要ですが、フォールバック ルーティングが複雑になります。あるリージョンで利用可能なモデルは、データを別のリージョンに保持する必要があるテナントを満足させられない可能性があります。
手動による証拠が避けられない場合があります。リスクは、手動による証拠が存在することではありません。リスクは、それを API から派生した新鮮な真実のように扱うことです。古いデータの警告、有効期限、承認要件を使用します。
プロバイダーのハード支出制限は便利なバックストップですが、429 で本番トラフィックが中断される可能性があります。ゲートウェイは、アップストリームのハードキャップが強制メカニズムになる前に、内部でアラートと予約を行う必要があります。
推奨事項と予測とは何ですか?
推奨事項: 台帳オブジェクトとして容量をモデル化し、プロバイダーの制限を調整し、ヘッドルームを適用し、テナント クラスごとに予約し、アドミッション チェックをプランとテナントのワークフローに接続し、すべての決定を監査します。
予測: 再販業者のポータル、代理店のサービス、SaaS テナントのオンボーディングがより自動化されるにつれて、キャパシティ アドミッションの重要性がさらに高まるでしょう。顧客は即時アクティベーションを期待するでしょうが、プロバイダーのクォータの承認と地域のキャパシティは不均一なままです。コントロール プレーンで供給を明示するチームは、ランタイム スロットルのみに依存するチームよりも緊急エスカレーションが少なくなります。
事実: 上記のプロバイダー固有のステートメントは、現在の公開ドキュメントの事実として扱われるべきですが、プロバイダーの API とクォータのセマンティクスは変更される可能性があります。調整コードとドキュメントのリンクをレビュー中のままにしておきます。
実用的な結論
価値の高い 1 つのワークフローから始めます。新しいプロバイダー プールが要求されたモデル ファミリー、リージョン、レート、ヘッドルーム後の支出エンベロープをサポートできない限り、コミットされたテナントのアクティベーションをブロックします。次に、プランの検証、アップグレード チェック、古い証拠のアラート、パートナー API ステータス フィールドを追加します。
最小の有用なバージョンは小さいものです: 容量プール テーブル、予約テーブル、調整ジョブ、ヘッドルーム ポリシー、およびアドミッション決定 API。これは、部族の知識から製品コントロール プレーンにキャパシティを移行するのに十分です。そこでは、販売、サポート、運用、および下流の再販業者のポータルが、約束が実際に供給に裏付けられているかどうかを確認できます。