プロビジョンドスループットとは？従量課金との違い・損益分岐

結論：安定したピーク負荷とSLA要件があるときに比較する

プロビジョンドスループットの採用条件は、月間トークンが多いことだけではありません。毎日のピーク時間と入出力構成を予測でき、必要な容量を一定期間使い切れ、従量課金の共有容量では遅延や429が事業上の損失になる場合に比較します。需要が読めない新機能、短時間だけ跳ねるキャンペーン、モデルを頻繁に替える検証環境では、未使用容量と契約拘束が重くなります。

導入判断は二段階です。まず、対象モデルとリージョンでピークQPS、入力・出力tokens、cache hit率、p95・p99遅延を測り、必要なPTU・MU・GSUを公式calculatorまたは負荷試験で求めます。次に、予約容量の月間固定費と、同じリクエストを従量課金で処理した実績額を比較します。費用上の損益分岐を超えていても、ピークを処理できない小さな予約は採用できません。

結論として、本番の基幹機能、常時稼働する社内AI、一定量の文書処理には候補になります。一方、平均利用率だけを根拠に長期契約するのは危険です。最初は従量課金で実測し、短い契約または時間課金で容量を検証し、需要の下限が固まってから長期割引へ移します。

仕組み：トークン単価ではなく、モデルの処理容量へ課金する

従量課金は、実際に処理した入力・出力tokensへ料金を掛けます。プロビジョンドスループットは、一定時間に処理できる容量を先に割り当て、使わない時間も課金します。Microsoftは単位をPTU、AWSはMU、Google CloudはGSUと呼びます。いずれも単純なtokens/分ではなく、モデル、入力・出力、cache、batch sizeなどを重み付けして消費容量へ換算します。

特に出力tokensは入力より演算負荷が高く、同じ総token数でも長い回答を出す処理は多くの容量を使う場合があります。Google Cloudは入力・出力へモデル別のburndown rateを掛け、QPSと合わせてGSU需要を計算します。AWSのMUもモデルごとに1分当たりの入出力token能力が定義されます。単位名だけを見て、1 PTU＝1 MU＝1 GSUとは比較できません。

固定容量を使い切った後の動作も重要です。Google Cloudは既定で超過分を従量課金へ流せます。Azure OpenAIは対応モデルでStandard deploymentへのspilloverを構成できます。AWSは購入したMUの範囲を前提に設計し、追加容量は別途購入します。超過経路がない場合、スロットリングや待ち時間が顧客影響になります。

この節の一次情報：Microsoft公式｜Provisioned throughput ／ AWS公式｜Provisioned Throughput ／ Google Cloud公式｜Measure Provisioned Throughput

Azure PTU・AWS MU・Google GSUの違い

3社とも固定容量ですが、契約の柔軟性は同じではありません。Azureはhourly deploymentを作成し、必要に応じて1か月または1年のReservationを重ねて割引します。Reservationは金銭上の割引であり、容量を確保する権利ではありません。先にdeploymentを作り、稼働を確認してから予約する順番です。

Amazon BedrockはモデルごとのMUを、契約なし、1か月、6か月で購入します。custom modelの利用にはProvisioned Throughputが必要です。Google CloudはGSUを1週間、1か月、3か月、1年で契約し、未使用容量は翌時間へ繰り越せません。契約途中の取消はできず、増量は契約中でも可能ですが、減量は更新時に行います。

この節の一次情報：Microsoft公式｜Provisioned billing ／ AWS公式｜Provisioned Throughput ／ Google Cloud公式｜Purchase Provisioned Throughput

料金と契約条件：公開価格だけで月額を決めない

2026年11月9日に確認したGoogle CloudのGlobal価格は、1 GSU当たり1週間が7.14ドル/時、1か月が3.698630137ドル/時、3か月が3.287671233ドル/時、1年が2.739726027ドル/時です。公式例では1 GSUを1か月使うと月2,700ドル、1年契約は月換算2,000ドルです。RegionalなどGlobal以外は10%高くなります。必要GSU数を掛け、超過分の従量課金と税を加えます。

AWSの料金表には一部モデルのMU価格が掲載されています。例としてCohere Commandは1 MU当たり契約なし49.50ドル/時、1か月39.60ドル/時、6か月23.77ドル/時です。Command Lightは8.56ドル、6.85ドル、4.11ドルです。同じMUでもモデルごとに価格と処理能力が違うため、この例を別モデルへ流用できません。詳細はアカウント担当への確認が必要です。

AzureのPTU価格はdeployment type、リージョン、通貨、予約条件で変わります。公式pricing calculatorまたはAzure portalで対象条件を選びます。hourly PTUはdeploymentを削除するまで課金され、停止機能はありません。縮小で解放した容量は再取得できない可能性があります。3社とも表示単価だけでなく、容量承認、超過料金、契約終了後の更新、削除手順まで見積書へ入れてください。

この節の一次情報：Google Cloud公式｜Generative AI pricing ／ AWS公式｜Amazon Bedrock pricing ／ Microsoft公式｜Provisioned onboarding

損益分岐：固定費÷従量課金の実効単価で求める

基本式は「月間固定費 ÷ 従量課金の実効単価 ＝ 損益分岐となる利用量」です。実効単価は、入力・出力tokensの構成、cached input、Batch、priority tier、リージョン割増を本番実績で加重平均します。カタログの入力単価だけを分母にすると、出力が長いアプリでは分岐点を大きく誤ります。

例として、従量課金の実効単価が100万tokens当たり2.50ドル、必要な予約容量が月2万ドルとします。編集部の仮定では、損益分岐は80億tokens/月です。40億tokensなら従量課金は1万ドルで有利、90億tokensなら2万2,500ドルで、予約容量が2,500ドル低くなります。ただし、予約容量がピークQPSを処理でき、超過料金、未使用時間、運用費を含めても成立することが条件です。

これは特定事業者の見積もりではなく計算例です。実務では月平均だけでなく、1分または5分ごとの需要分布で計算します。固定容量の利用率、従量課金へ逃がした比率、スロットリング率を並べ、通常月と繁忙月の両方で比較してください。

向くケース・向かないケース

向くのは、顧客向け検索や要約、コールセンター支援、継続的な文書処理など、曜日別の負荷を予測できる本番です。遅延のp99や処理失敗が契約SLAに直結し、同じモデルを数か月以上使う組織では、容量の優先処理と予算の予測可能性に価値があります。custom modelをBedrockで動かす場合のように、技術要件として予約容量が必要なケースもあります。

向かないのは、PoC、季節イベント、夜間batchだけの短時間利用、モデル比較を続ける環境です。Batch APIや非同期queueで処理時刻をずらせるなら、まず従量課金の割引手段を比較します。また、複数teamの需要を束ねられない組織では、部署ごとに小さな予約を買うより、共通のcapacity poolと利用配賦を設計する方が先です。

導入時の確認事項：ログ、容量、契約を同時に検証する

導入前には、requestごとのモデル、リージョン、入力・出力tokens、cache hit、QPS、TTFT、完了時間、429、再試行を保存します。平均ではなくp50・p95・p99と、最も混む連続5分を確認します。そのログを公式calculatorへ入れ、同じ入力構成で負荷試験します。1種類の短いpromptだけで容量を決めないでください。

契約面では、対象モデル・version・deployment type、最低購入単位、増減の反映時間、途中解約、更新、spillover、超過単価、データ処理地域を確認します。AzureではReservationと実際のdeploymentのscope、region、typeが一致しないと割引が適用されません。Google Cloudではcapacity activationに数分から数週間かかる場合があります。繁忙日の直前購入を前提にしない計画が必要です。

安全な移行は、従量課金を残したまま一部trafficを固定容量へ流し、品質とp99を同じtask IDで比較する方法です。2〜4週間、利用率、超過率、1成功task当たり総原価を測り、容量不足と余剰の両方を確認します。縮小で容量を失う製品では、切り戻し可能性を確認してから変更します。

• ピークQPS、入出力tokens、cache hit率、p95・p99、429を実測したか
• 公式calculatorの容量を代表trafficの負荷試験で再現したか
• 予約のscope・region・deployment typeと実利用が一致しているか
• 超過、spillover、スロットリング時の顧客影響を決めたか
• モデル更新・契約終了・容量縮小時の出口計画があるか
• 固定費、超過費、運用費を成功task単位で配賦できるか

企業の説明と、独立して確認できる事実を分ける

各社は、予約容量によって予測可能な性能、優先処理、安定したthroughputを得られると説明しています。これは製品仕様として確認できますが、自社のprompt構成、同時実行数、リージョンでのp99や必要単位数を保証する第三者benchmarkではありません。公式calculatorも見積もりであり、実トラフィックの負荷試験が必要です。

独立して確認できるのは、請求書の時間数と単価、usageログ、スロットリング、遅延分布、従量課金へ流れた超過量です。導入後はこの観測値を契約前の想定と比較します。『最大throughput』や『安定性』という表現を、そのまま原価削減率やSLA達成率へ置き換えないことが重要です。

FAQ

Q. プロビジョンドスループットは従量課金より安いですか？　A. 必ずではありません。固定容量を継続的に使い切り、長期割引と超過料金を含めた総額が従量課金を下回るときに安くなります。

Q. 月間tokensだけで必要容量を計算できますか？　A. できません。同じ月間量でもピークQPS、入力・出力比、cache hit率、batch sizeで必要容量が変わります。時間帯別ログを使います。

Q. PTU・MU・GSUを単純比較できますか？　A. できません。モデル別の換算、契約期間、超過時の動作が異なります。各社のcalculatorと負荷試験で比較します。

Q. 長期契約から始めてもよいですか？　A. 先に従量課金や短期枠で必要容量を実測する方が安全です。AzureのReservationは容量を保証しないため、deploymentを作成してから購入します。

Q. 予約容量を止めれば請求も止まりますか？　A. 製品ごとに異なります。Azureのhourly PTUはpauseできず削除まで課金、AWSの期間契約は期間中削除不可、Google Cloudのcommitmentは途中解約できません。

Q. cacheやBatchと併用できますか？　A. 対応はモデルと製品次第です。cacheは容量消費を下げる場合がありますが、固定容量の未使用分は返金されません。利用パターン別にcapacity消費を測ってください。