Microsoft Foundry Models のクォータと制限

この記事では、Azure によって直接販売される Foundry Models のクォータと制限のクイック リファレンスと詳細な説明を提供します。 Foundry モデルの Azure OpenAI に固有のクォータと制限については、「Quotas と Azure OpenAI の制限」を参照してください。

2025 年 5 月 6 日以降のクォータ管理の更新

Microsoft Foundry では、デプロイ全体でクォータを管理する方法の一貫性と予測可能性を実現するために、クォータ管理の更新プログラムが導入されています。 Realtime Translate と Realtime ささやき以降、デプロイのクォータは、リソースまたはリージョンごとに個別に割り当てられるのではなく、すべてのリソースとリージョンで共有されるサブスクリプション レベルで追跡されます。

この変更により、クォータが共有プールに統合されます。

• グローバル標準: 同じモデルとバージョンのデプロイは、サブスクリプション内のすべてのリージョンで 1 つのクォータ プールを共有します。
• データ ゾーン標準: 同じモデルとバージョンのデプロイは、データ ゾーン (米国や EU など) ごとに 1 つのクォータ プールを共有します。

何が変わりますか?

新しいクォータ管理システムがオンボードされているモデルの場合:

• サブスクリプションの下にある同じモデルとバージョンのすべてのグローバル標準デプロイは、すべてのリージョンで 1 つの共有クォータ プールから引き出されるようになりました。
• サブスクリプションの下にある同じモデルとバージョンのすべての Data Zone Standard デプロイは、各データ ゾーン内の共有クォータ プールから引き出されるようになりました。
• 既存の承認済みクォータは保持され、サブスクリプション レベルで自動的に適用されます。アクションは必要ありません。

この統合により、Microsoft Foundry では、リソースまたはリージョン間でのクォータの分散方法に関係なく、すべての Foundry リージョンでサポートされているモデルを一貫して提供できます。

クォータと制限のリファレンス

次のセクションでは、Foundry モデルに適用される既定のクォータと制限に関するクイック ガイドを提供します。 クォータと制限は、テナント レベルでは適用されません。 代わりに、クォータ制限の最上位レベルは、Azure サブスクリプション レベルでスコープ設定されます。 トークン/分 (TPM) と 1 分あたりの要求数 (RPM) の制限は、リージョンごと、サブスクリプションごと、モデルまたはデプロイの種類ごとに定義されます。

リソース制限 (Azure サブスクリプションごと、リージョンごと)

レート制限

次の表に、以下のレートに対する Foundry Models の制限を示します。

• 1 分あたりのトークン数
• 1 分あたりの要求数
• 同時要求

割り当てを増やすには:

• Azure OpenAI の場合は、Foundry Service: クォータの引き上げ要求 を使用して要求を送信します。
• その他のモデルについては、 既定の制限への要求の増加に関するページを参照してください。

需要が高いため、制限の引き上げ要求は個別に評価されます。

その他の制限

¹ つの現在の API では、パイプラインが通過して返すカスタム ヘッダーを最大 10 個使用できます。 このヘッダー数を超えると、要求によって HTTP 431 エラーが発生します。 このエラーを解決するには、ヘッダー ボリュームを減らします。 今後の API バージョンでは、カスタム ヘッダーは渡されません。 今後のシステム アーキテクチャでは、カスタム ヘッダーに依存しないでください。

使用量レベル

グローバル標準デプロイでは、Azureのグローバル インフラストラクチャを使用して、顧客の推論要求に最適な可用性を備えたデータ センターに顧客トラフィックを動的にルーティングします。 このインフラストラクチャにより、トラフィックレベルが低から中程度の顧客に対して一貫した待機時間が実現します。 使用率が高い継続的なレベルの顧客には、応答の待機時間の変動が増える可能性があります。

[使用制限] は、応答待ち時間の変動が大きくなる可能性がある使用量の上限を決定します。 顧客の使用状況はモデルごとに定義され、特定のテナントのすべてのリージョンのすべてのサブスクリプションのすべてのデプロイで使用されるトークンの合計です。

既定の制限の引き上げを要求する

quota の増加要求フォームを送信して、Azure、Azure OpenAI モデル、およびAnthropic モデルによって直接販売されるファンドリー モデルのクォータの引き上げを要求します。 Anthropicモデルを除き、パートナーやコミュニティのモデルはクォータの引き上げをサポートしていません。

クォータの引き上げ要求は受け取った順序で処理され、優先度は既存のクォータ割り当てを積極的に使用している顧客に適用されます。 この条件を満たしていない要求は拒否される可能性があります。

レート制限内を維持するための一般的なベスト プラクティス

レート制限に関連する問題を最小限に抑えるには、次の手法を使用します。

• アプリケーションに再試行ロジックを実装します。
• ワークロードの急激な変更を避けます。 ワークロードを徐々に増やします。
• さまざまな負荷増加パターンをテストします。
• デプロイメントに割り当てられているクォータを増やす。 必要に応じて、別のデプロイからクォータを移動します。

クライアント側のタイムアウトの設定

次のガイダンスに基づいて、クライアント側のタイムアウトを明示的に設定します。

• 推論モデル (要約された応答を生成する前に中間推論トークンを生成するモデル): 最大 29 分。
• 非推論モデル:
  • ストリーミングの場合、最大 60 秒。
  • ストリーミング以外の要求の場合は、最大 29 分です。

ここで 29 分は、すべての要求が 29 分かかるという意味ではなく、コンテキスト トークン、生成されたトークン、キャッシュ ヒット率に応じて、要求に最大 29 分かかる場合があります。

トラフィック パターンに合わせて、これらの値より小さいタイムアウトを設定します。

ストリーミング要求を含む推論モデルでは、すべての推論トークンが最初に生成され、その後、最初の応答トークンがユーザーに送信される前に要約されます。

推論作業パラメーターを変更して、プロセスで生成される推論トークンの数を制御できます。

トラブルシューティング

関連コンテンツ

• Foundry モデルで使用可能なモデル
• Foundry リソースのクォータを管理および増やす
• Azure OpenAI のクォータと制限