Microsoft Foundry Models のクォータと制限

この記事では、Azure で販売される Foundry Models のクォータと制限の概要と詳細な説明を提供します。 Foundry モデルの Azure OpenAI に固有のクォータと制限については、「Quotas と Azure OpenAI の制限」を参照してください。

サブスクリプション単位のクォータ管理

Realtime Translate と Realtime Transcribe から始まり、すぐにすべてのモデルで、Foundry はリソースごとまたはリージョンごとではなく、サブスクリプション レベルでデプロイのクォータを追跡します。 この方法では、サブスクリプション内のすべてのリソースとリージョンが同じクォータ プールを共有するため、デプロイ間でのクォータの管理方法に一貫性と予測可能性がもたらされます。

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

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

クォータ管理スコープを確認する

Foundry ポータルの [クォータ] ページに移動すると、特定のモデルに適用される クォータ 管理システムを見つけることができます。 特定のモデルの [スコープ] 列の値は、Foundry がそのモデルのクォータを管理する方法を示します。 スコープ値は次のとおりです。

• グローバル または データ ゾーンは、サブスクリプション レベルのクォータ管理を示します。
• リージョン (米国東部や米国西部など) は、そのサブスクリプションとモデルのリージョンごとのクォータ管理を示します。

導入済みモデルの変更

サブスクリプション レベルのクォータ管理システムにオンボードされているモデルの場合:

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

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

モデルのアップグレード時のクォータ制限

既存のモデルをアップグレードすると、新しいグローバルまたはデータ ゾーンのクォータ制限が次の値に設定されます。

• 該当するレベルの制限。
• クォータ スコープ内でそのモデルのすべての既存のデプロイに割り当てられたクォータの合計。

たとえば、モデルに 5 つのリージョンにまたがる Global Standard デプロイがある場合、新しいグローバル クォータ制限は、その合計がレベルの制限を超えた場合、それらのデプロイの合計クォータと等しくなります。 それ以外の場合は、レベルの制限が適用されます。

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

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

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

レート制限

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

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

クォータを増やすには、Microsoft Foundry Service: クォータの引き上げ要求を使用して要求を送信します。 需要が高いため、クォータの引き上げ要求は個別に評価されます。 クォータの引き上げ要求の詳細については、 要求の既定の制限への引き上げに関するページを参照してください。

その他の制限

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

使用量レベル

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

使用上限は、これを超えると顧客において応答レイテンシのばらつきが大きくなる可能性がある使用量の水準を示します。 顧客の使用状況はモデルごとに定義され、特定のテナントのすべてのリージョンのすべてのサブスクリプションのすべてのデプロイで使用されるトークンの合計です。

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

クォータ引き上げ要求フォームを送信して、Azure で販売される Foundry Models、Azure OpenAI モデル、および Anthropic モデルのクォータ引き上げを申請します。 Anthropicモデルを除き、パートナーやコミュニティのモデルはクォータの引き上げをサポートしていません。

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

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

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

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

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

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

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

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

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

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

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

トラブルシューティング

関連コンテンツ

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