Foundryモデルにおけるプロビジョニングされたスループットとは何ですか？

現在表示中:Foundry ポータルの新しいバージョン - クラシック Foundry ポータルのバージョンに切り替える

プロビジョニング済みスループットは、Microsoft Foundry のデプロイの種類であり、デプロイに専用のモデル処理スループットを提供します。 推論容量が顧客間で共有され、スループットが需要によって異なる標準のデプロイとは異なり、プロビジョニングされたデプロイでは、要求が行われているかどうかにかかわらず、デプロイの使用に対してのみ固定量の処理容量が保持されます。

この記事では、プロビジョニングされたスループットの背後にある主要な概念について説明します。その概要、使用するタイミング、容量の測定と課金方法、デプロイ前のクォータと容量について知っておくべきこと。

デプロイ カテゴリの比較

標準デプロイ、バッチ デプロイ、優先順位処理、プロビジョニングスループットは、Microsoft Foundry にモデルをデプロイする方法です。 適切な選択は、待機時間の要件、トラフィック パターン、コスト許容度によって異なります。

プロビジョニング済みスループットを使用するタイミング

プロビジョニング済みスループットは、アプリケーションに次の項目がある場合に適した選択肢です。

• 予測可能なトラフィック パターン: 1 分あたりの要求数とトークン 量が妥当に見積もられます。
• 待機時間に依存する要件: ユーザーまたはダウンストリーム システムには、一貫性のある低待機時間の応答が必要です。
• 運用規模のボリューム: トークンごとの課金が高価になる高スループットのユース ケース。
• リアルタイムまたは対話型のシナリオ: 応答時間が可変でユーザー エクスペリエンスが低下するチャット アプリケーション、副操縦、またはエージェント。

標準デプロイは、開発、テスト、少量の利用、またはトラフィックの変動が大きく事前にデプロイ規模を見積もるのが難しいケースに、引き続きより適しています。

設定済みのスループット ユニット

プロビジョニング済みスループットユニット (PTU) は、プロビジョニングされたスループットの測定単位です。 PTU は、一定量のモデル処理能力を表します。 プロビジョニングされたデプロイを作成するときは、割り当てる PTU の数を指定します。 Foundry は、その量のコンピューティングを予約し、デプロイ用に保持します。

PTU の主な特性:

• モデルに依存しない: 同じ PTU クォータを使用して 、サポートされている任意のモデルをデプロイできます。 特定のモデルの PTU は購入しません。
• リージョン固有: PTU クォータは、サブスクリプションごと、リージョンごと、 デプロイの種類ごとに付与されます。 米国東部のクオータは、西ヨーロッパには繰り越されません。
• スループットはモデルによって異なります。特定の数の PTU が提供する 1 分あたりのトークン (TPM) は、モデルによって異なります。 より重いモデルでは、より軽いモデルと同じTPMを処理するには、より多くのPTUが必要です。 モデルごとの PTU と TPM の比率については、 モデルごとのスループット パラメーターに関するページを参照してください。
• 最小デプロイ サイズが適用されます。各モデルには、デプロイを作成するために必要な最小 PTU 数があります。 最小値はモデルによって異なり、「 デプロイ パラメーター」と「モデル別のスループット値」に記載されています。

クォータと容量

PTU クォータと容量は関連しますが、デプロイを作成できるかどうかに影響する個別の概念です。 このセクションでは、それぞれが何であるか、追加のクォータを要求する方法、およびリージョンで容量が使用可能かどうかを確認する方法について説明します。

PTU クォータとは?

PTU クォータは、サブスクリプションごと、リージョンごと、デプロイの種類ごとにデプロイできる PTU の最大数です。 クォータは、Azureによって適用されるポリシー制限であり、関連するコストはありません。 クォータは、オファリング単位（Global Provisioned、Data Zone Provisioned、Regional Provisioned はそれぞれ別個のクォータ プールです）およびリージョン単位で管理されます（たとえば、米国東部のクォータは西ヨーロッパには適用されません）。

既定のクォータ量は、複数のリージョンの対象となるサブスクリプションに割り当てられます。

容量とは

容量は、デプロイ可能なモデル バージョンごとの実際の PTU の量です。 容量はデプロイ時に割り当てられ、デプロイの有効期間にわたって保持されます。

容量は有限で動的に変化するリソースであるため、

• 容量の可用性は、すべてのリージョンとモデルの顧客の需要に基づいて、1 日を通して変化します。
• デプロイを削除またはスケールダウンすると、その容量 がリージョン プールに戻されます。 後でデプロイを再作成またはスケールアップしても、同じ容量を使用できる保証はありません。

クォータを取得する方法

グローバル、データ ゾーン、およびリージョンプロビジョニング済みクォータの既定の量は、複数のリージョンの対象となるサブスクリプションに割り当てられます。 クォータ要求フォームを送信することで、より多くのクォータまたは容量を 要求できます。 フォームは、 Foundry ポータルの [クォータ] ページでも使用できます。

承認にはクォータの可用性に基づいて数日かかる場合があり、要求が承認されると電子メール通知を受け取ります。

使用可能な容量を確認する方法

リアルタイムの容量の可用性を確認するには:

• Foundry ポータルのデプロイ エクスペリエンスを使用します。これは、デプロイを作成しようとしたときに容量が使用可能かどうかを示し、ターゲット リージョンに十分でない場合は、使用可能な容量を持つ代替リージョンを一覧表示します。
• モデル容量 API を使用して、特定のモデルとリージョンのデプロイ可能な最大 PTU 数をプログラムで照会します。

ターゲット リージョンに使用可能な容量がない場合:

• クォータ要求 フォーム を送信して、より多くのクォータまたは容量を要求します。
• 少ない PTU でデプロイしてみてください。
• 容量の可用性が 1 日を通じて動的に変化する場合は、後で再試行してください。

プロビジョニングされたデプロイの作成と容量の制約の処理に関する詳細なガイダンスについては、「 プロビジョニングされたデプロイの概要」を参照してください。

PTU のサイズ設定

プロビジョニングされたデプロイを作成する前に、ワークロードに必要な PTU の数を見積もります。 次の 3 つの要因が計算を推進します。

• 要求の形状: 予想される 1 分あたりの要求数 (RPM)、平均プロンプト サイズ (入力トークン)、平均応答サイズ (出力トークン)。
• 出力と入力の比率: 出力トークンには、入力トークンよりも多くの処理能力が必要です。 各モデルには、容量の目的で 1 つの出力トークンが等しい入力トークンの数を表す比率があります。 GPT-4.1 以降Azure OpenAI モデルの場合、この比率は、出力トークンと入力トークンの間のモデルのグローバル標準価格比と一致します。 この比率の詳細については、「 モデル別のデプロイ パラメーターとスループット値」を参照してください。
• キャッシュ レート: プロンプト キャッシュから提供される入力トークンの割合。 キャッシュされたトークンは PTU 容量を消費しないため、キャッシュ レートが高いほど、必要な PTU が減少します。

サイズ設定の計算では、これらの要因を使用して、予想されるトークン ボリュームを 1 つの 正規化された TPM の数値に変換し、モデルの PTU ごとの入力 TPM 値で除算して、必要な PTU 数に到達します。

数式とモデルごとの値を使用して手動でサイズを設定することも、Foundry ポータルの 容量計算ツール を使用してガイド付き見積もりを行うこともできます。

数式、作業例、容量計算ツールのリファレンスなど、完全なサイズ設定手法については、 ワークロードの PTU サイズ設定の決定に関するページを参照してください。

プロビジョンドスループットのデプロイタイプ

プロビジョニングされたスループットは、3 種類のデプロイとして使用できます。 これらはすべて、デプロイ後に専用の容量と予測可能な待機時間を提供します。 違いは、推論トラフィックが処理される場所です。

標準、バッチ、プロビジョニングを含むすべての Foundry デプロイの種類の完全な比較については、Microsoft Foundry Models の展開の種類を参照してください。

サポートされているモデル

プロビジョニングされたスループットをサポートする Foundry モデルの完全な一覧 (各モデルでサポートされるデプロイの種類やリージョンの可用性など) については、「Azure によって直接販売される Foundry Models のRegion availability」を参照してください。

波及

スピルオーバーは、同じ Foundry リソース内の対応する標準デプロイにオーバーフロー要求を自動的にルーティングすることで、プロビジョニングされたデプロイのトラフィック変動を管理するためのオプションの構成です。 プロビジョニングされたデプロイが完全に利用され、200 以外の応答 (PTU が使い果たされたときの 429 など) が返されると、スピルオーバーによってこれらの要求が標準デプロイにリダイレクトされ、トラフィックバースト中の中断を減らすことができます。

プロビジョニングされたスループットをサポートする Foundry モデルのすべての Azure OpenAI もスピルオーバーをサポートします。 他のプロバイダー (deepSeek、Meta Llama Azure) の Foundry モデルは現在、スピルオーバーをサポートしていません。

スピルオーバーは、デプロイ上のすべての要求に対して構成することも、 x-ms-spillover-deployment 要求ヘッダーを使用して要求ごとに制御することもできます。 構成手順については、 プロビジョニングされたデプロイのスピルオーバーによるトラフィックの管理に関するページを参照してください。

時間単位の課金とAzure予約

プロビジョニングされたデプロイでは、hourly billing の 2 つの課金モードがサポートされ、柔軟で短期的な使用が可能です。また、Azure Reservations は、継続的な運用ワークロードを割引料金で利用できます。

時間単位の課金

すべてのプロビジョニング済みデプロイの種類は、使用されたトークンの数に関係なく、デプロイされた PTU の数に基づいて時間単位の料金 ($/PTU/時間) で課金されます。 メーターはデプロイの作成時に開始され、削除されると停止します。

時間単位の課金は、新しいモデルのベンチマークやハッカソンなどのイベントの一時的なスケールアップなどの短期的なシナリオに適しています。 ただし、次の理由から、時間単位課金のままにするために、トラフィックに応じてプロビジョニング済みデプロイをスケールアップまたはスケールダウンしないでください。

• スケールアップが必要な場合は、容量を使用できない場合があります。

• 使用率の高い継続的な時間単位の課金は、通常、予約価格を超えています。

時間単位の課金とプロビジョニングされたデプロイのスケーリングに関する完全なガイダンスについては、「 時間単位の課金」を参照してください。

Azure の予約

Azure Reservations は、個々のデプロイメントではなく、PTU 課金メーター（Azure が課金対象とする時間単位の使用量カウンター）に適用される料金上の割引です。 1 か月または 1 年間のコミットメントと引き換えに、有効な $/PTU/hr 料金が割引されます。 予約に関して注意すべき重要な点は次のとおりです。

• 予約はデプロイの種類 (グローバル、データ ゾーン、またはリージョン) ごとに購入され、1 つ以上のサブスクリプションまたはリソース グループに対応するようにスコープを設定できます。

• 予約とデプロイは疎結合されています。つまり、デプロイと予約を個別に作成します。

• 予約では容量は保証されません。 最初にデプロイを作成して容量が使用可能であることを確認してから、予約を購入して割引料金をロックします。

予約のサイズ設定、購入、管理に関する完全なガイダンスについては、「Azure プロビジョニング済みスループットの予約を参照してください。

PTU のコストと課金を追跡する方法

Microsoft Cost Managementを使用して、PTU の使用状況と予約コストを追跡および分析します。

関連コンテンツ

• プロビジョニング済みデプロイを使ってみる
• PTU のコストと課金
• プロビジョニングされたデプロイのスピルオーバーを使用してトラフィックを管理する
• Microsoft Foundry モデルの優先度処理を有効
• Microsoft Foundry のプロビジョニングされたスループットの予約でコストを削減
• Foundry Models のクォータと制限