基盤モデルAPIでプロビジョニングされたthroughputを予約する
このページでは、基盤モデル APIs の予約済みプロビジョニング throughput について説明します。概要、使用するタイミング、予約サイズの決定方法、およびそれを使用する Endpoint の作成と管理方法について解説します。
予約済みのプロビジョニング済みthroughputとは何ですか？
予約済みのプロビジョニング済みthroughputは、Databricks 基盤モデルAPIsの容量オプションです。共有のキャパシティプールを利用する従量課金（per-token）の提供形態ではなく、一定期間にわたって専用のキャパシティを固定量で予約します。このキャパシティは モデルユニット 単位で測定され、Databricksが予約期間中保持します。
容量は事前に専用かつ予約されているため、共有のトークン単位の従量課金に対する全体的な需要が高い場合でも、その容量のthroughputとレイテンシは一貫した状態に保たれます。予約容量を超えるトラフィックはレート制限の対象となり、トークン単位の従量課金で自動的に処理されることはありません。そのオーバーフローを拒否せずにトークン単位の従量課金に送信するには、Endpoint の前にあるモデルサービスで fallback を構成します。予約容量を超えるトラフィックの処理を参照してください。
予約済みのプロビジョニング済み throughput を使用するタイミング
予約済みのプロビジョニング済み throughput は、共有プールへのベストエフォート型アクセスではなく、確実な容量を必要とするワークロード向けに設計されています。Databricksでは、次のような場合に推奨します。
- ビジネスクリティカルなアプリケーションやエージェントを稼働させている場合、モデルに依存する本番運用機能があり、共有容量をめぐって他のトラフィックと競合することができません。
- 共有のトークン単位の従量課金よりも一貫した可用性と稼働時間が必要になるため、共有プールに対する高負荷がthroughputに与える影響を軽減できます。
- 予測可能なトラフィックのボリュームが大量である場合や継続的に高い場合、またはトークン単位の従量課金や優先トークン単位の従量課金で容量やレート制限の制約に達している場合にスケーリングを行います。
トラフィックが試験目的や低ボリュームである場合は、トークン単位の従量課金または優先トークン単位の従量課金を参照してください。
サポートされているモデル
予約済みのプロビジョニング済みthroughputは、サポートされている基盤モデルで利用可能です。Databricks はモデルごとに適格性を管理しており、作成フローには予約可能なモデルのみが表示されます。
予約済みプロビジョニング throughput は、以下のモデルで利用可能です：
プロバイダー | モデル | エンドポイント名 |
|---|---|---|
Zhipu AI |
| |
Zhipu AI |
| |
Zhipu AI |
| |
Moonshot AI |
| |
DeepSeek |
| |
Alibaba Cloud |
|
Qwen3.5 122B A10B はパブリックプレビュー中です。有効化については、Databricksアカウントチームにお問い合わせください。
予約済みのプロビジョニングされた throughput の仕組み
容量は モデルユニット 単位で予約します。モデルユニットとは、Endpointが1分あたりに処理できる作業量を設定する、プロビジョニングされたthroughputの単位です。モデルユニット数が多いほど、確保される throughput が大きくなります。モデルユニットは、最小50から50単位で予約します。
予約するモデルユニットの数と期間（ term ）を選択して、 予約 を作成します。Databricksは、全期間にわたってその専用容量をプロビジョニングします。Endpointは一度に複数の予約を保持でき、その総予約容量は有効な予約全体のモデルユニットの合計になります。
予約済みプロビジョニング済み throughput Endpoint の構成要素については、以下の用語で説明します。
期間 | 意味 |
|---|---|
モデルユニット | プロビジョニング済み容量の単位。モデルユニット数が増えると、予約済みthroughputが増加します。モデルユニット見積もりツールを使用して、予想されるトラフィックからプールのサイズを決定します。 |
予約 | Endpointにおけるモデルユニットの前払い分と期間の付与。Endpointでは、それぞれ独自のモデルユニットと期間終了日を持つ複数の予約を同時に保持できます。 |
期間 | 予約期間：1か月または3か月。期間が長いほど、ユニットあたりの料金は低くなります。 |
カバレッジ | Endpointのアクティブな予約の合計となるモデルユニット数。 |
フォールバック | カバレッジを超えるトラフィックに対してモデルサービスで設定するバックアップの送信先。Databricks は、トークン単位の従量課金に対してトラフィックを自動的にルーティングしません。fallbackがない場合、カバー範囲を超えるトラフィックにはレート制限が適用されます。予約済み容量を超えるトラフィックの処理を参照してください。 |
予約する量を決定する
予約するモデルユニットの数はユーザーが自由に決定できます。すべてのワークロードを専用容量に割り当てることも、容量を少なめにしてオーバーフローを fallback 付きでトークン単位の従量課金に送信することもできます（予約容量を超えるトラフィックの処理を参照してください）。
- ベースラインを予約し、ピークをfallbackに送信します。 安定した日常的なトラフィックをカバーするのに十分なモデルユニットを予約し、そのベースラインを超えるバーストがトークン単位の従量課金で実行されるように fallback を構成します。より少ない容量をcommitし、オーバーフロー分に対してのみトークン単位の従量課金で支払います。代わりに、それらのバーストに対してベストエフォート型の共有容量を利用できます。
- ピーク時に備えて予約します。 ワークロード全体が専用容量で実行されるように、予想される最も繁雑な負荷をカバーするのに十分なモデルユニットを予約してください。これにより、より大きなコミットメントと引き換えに、最も一貫した動作が得られます。
いずれの方法でも、作成フロー内の組み込みの Estimate model units ツールを使用して、ワークロードをモデルユニットに変換します。想定されるリクエストの形状を入力すると、estimator が必要なモデルユニットを返します。
- 想定される1分あたりのリクエスト数。
- リクエストあたりの入力トークンの平均数。
- リクエストあたりの平均出力トークン数。
- 想定されるキャッシュヒット率です。
ベースラインの規模を見積もるには、通常のトラフィックを入力します。ピーク時に備えて予約するには、最もトラフィックが多いと予想される時間帯を入力します。commitする前であれば、estimatorを何度でもランできます。
トークン単位の従量課金と比較した予約済みプロビジョニングthroughput
予約済みプロビジョニング済みthroughputとトークン単位の従量課金は、二者択一ではなく補完的な関係にあります。コアトラフィック用に専用容量を予約し、予約済みプールを超えるトラフィックについてはトークン単位の従量課金へのfallbackを設定できます。次の表は、各オプションが適している用途を示しています。
機能 | トークンごとの従量課金制 | 予約済みのプロビジョニング済みthroughput |
|---|---|---|
価格体系 | トークン単位（使用量に応じた課金） | 予約済み容量（全期間分を請求） |
容量 | 共有プール、ベストエフォート | 専用プール（お客様専用に予約済み） |
高負荷時のレイテンシー | 共有された需要によって変動する可能性があります | 予約済み容量に対して一貫性があります |
予約 | なし | 1か月または3か月 |
どのようなタスクにベストなのか | スパイクの多いトラフィック、内部トラフィック、または探索的トラフィック | 本番運用における外部のビジネス重要アプリケーションまたはエージェント |
価格の仕組み
予約済みプロビジョニング済み throughput は、送信したリクエスト数ではなく、予約した容量に基づいて課金されます。予約済み容量の使用の有無にかかわらず、予約期間全体に対して課金されます。
何が起こるか | 請求方法 |
|---|---|
予約済み容量内のトラフィック | 期間全体にわたり、予約済み容量として請求されます。 |
予約済み容量を超えるトラフィック、fallbackの設定あり | オーバーフロー時のトークン単位の従量課金のみ。fallbackの宛先によって課金されます。 |
予約済み容量を超えるトラフィック（fallbackなし） | レート制限されますが、課金はされません。 |
予約の有効期限が切れた後のトラフィック | 予約済み容量を超える他のトラフィックと同様に処理されます。fallbackを設定している場合はトークン単位の従量課金となり、それ以外の場合はレート制限されます。 |
- 期間が長いほど、短い期間よりも単位あたりの料金が低くなります。
- Endpointが異なる期間の予約を同時に保持している場合、それぞれの予約は個別の料金で独立して価格設定されます。
- 具体的な料金は、モデルおよび期間によって異なります。
始める前に
要件 | 詳細 |
|---|---|
モデルの権限 | Unity Catalog内の基盤モデル（ |
対象モデル | 予約済みのプロビジョニング済みthroughputは、対象となるモデルでのみ作成できます。サポートされているモデルを参照してください。 |
予約済みのプロビジョニング済み throughput Endpoint を作成する
Unity Gatewayから予約済みのプロビジョニング済みthroughputを作成します。
-
Unity Gatewayで、 + Model を選択します。
-
モデルサービスに名前を付けます。
-
Destination でプロビジョニング済みthroughputを選択し、Linkを選択してワークスペース内に新しいサービングEndpointを作成します。 Set up a プロビジョニングされた throughput Endpoint ダイアログが開きます。
-
対象となる基盤モデルを選択します。
-
モデルユニットを50単位ずつ設定します。 プールをサイジングするには、 [モデルユニットを見積もる] を選択し、想定されるワークロード（1分あたりのリクエスト数、リクエストごとの平均入力・出力トークン数、想定されるキャッシュヒット率）を入力します。すると、見積もりツールに必要なモデルユニットが表示されます。予約量の決定方法をご覧ください。
-
予約期間 を選択してください：1か月または3か月。期間が長いほど、単価が低くなります。
-
モデルユニットと期間を確認し、Endpointを作成します。Databricks が専用容量をプロビジョニングします。
Endpointの容量タイプは、作成時に固定されます。既存のEndpointを後から予約済みのthroughputに変換することはできません。代わりに、新しい予約済みプロビジョニング済みthroughput Endpointを作成してください。
表示と監視
The Endpoint詳細ページには、 予約済みプロビジョニング throughput という見出しの アクティブな構成 セクションが表示され、予約済みのモデルユニットと各予約の期間、有効期限、ステータスが一覧表示されます。Endpointがスケールアップやアップグレードによる複数の予約を保持している場合、それらはリストとして表示されます。
メトリクス タブには、1分あたりのリクエスト数、エラー数、レイテンシ（p50、p90、p95、p99）、トークン数、Time-to-First-Token（TTFT）など、通常のサービングテレメトリが表示されるため、使用状況を監視してスケーリングのタイミングを判断できます。
容量のスケールアップ
容量を追加するには、 [Edit] ＞ [Add capacity] を開き、追加するモデルユニットの数（50単位）を入力して、期間を選択します。これにより、既存の予約の上に新しい予約が積み重ねられます。既存の環境を変更または中断することはありません。その後、詳細ページに各予約がリストされ、それぞれのスケジュールで有効期限が切れます。
![[サービングEndpointの編集]ページの[容量の追加] tab で、新しい予約期間にモデルユニットを追加します。](/aws/ja/assets/images/reserved-pt-add-capacity-f2d05f094500bf592b1c30f008b08fc9.png)
有効期限
- 有効期限が切れると、予約されたプールは失効します。その後、トラフィックは予約容量を超える他のトラフィックと同様に処理されます。つまり、構成されたトークン単位の従量課金の fallback に送信されるか、fallback がない場合はレート制限されます。予約容量を超えるトラフィックの処理を参照してください。
- 期間終了後も予約済み容量を維持するには、現在の予約の有効期限が切れる前に新しい予約を作成してください。「容量のスケールアップ」を参照してください。
- 期限切れの予約は 期限切れ バッジ付きで表示されたままとなり、削除されずに保持されます。
予約済み容量を超えるトラフィックの処理
予約済みプロビジョニングthroughputEndpointは、予約済み容量からのトラフィックのみを処理します。Databricks は、オーバーフローをトークン単位の従量課金に自動的にルーティングしません。バーストが原因であるか、予約の有効期限が切れたことが原因であるかに関わらず、トラフィックが予約済み容量を超過した場合、それらのリクエストはレート制限エラーで拒否されます。
そのオーバーフローのサービングを維持するには、Endpointの前段にある Unity Gateway モデルサービスにfallbackを設定します。予約済みプロビジョニングthroughput Endpointをプライマリ宛先として設定し、トークン単位の従量課金または優先トークン単位の従量課金 Endpointをfallbackとして設定します。予約済みEndpointがレート制限エラーを返した場合、モデルサービスはfallback宛先に対してリクエストを再試行するため、ワークロードの実行が継続され、オーバーフロー分に対してのみトークン単位の従量課金が発生します。
セットアップのステップについては、モデルのルーティングと fallback の構成を参照してください。
制限事項
- 現在のリリースでは、モデルごと、ワークスペースごとに 1 つの予約済みプロビジョニング throughput Endpoint を作成できます。
- 予約は前払いであり、期間満了まで実行されます。予約を途中でキャンセルすることはできません。
- アクティブな予約があるEndpointは、予約が終了するまで削除できません。
- モデルに対する
MANAGEを持たないユーザーには、読み取り専用ビューが表示されます。
基盤モデル APIs のその他の制限については、基盤モデル APIs の制限とクォータを参照してください。