基盤モデル APIの制限とクォータ
このページでは、Databricks基盤モデルAPIワークロードの制限とクォータについて説明します。
Databricks 基盤モデル API レート制限を適用して、すべてのユーザー間で信頼性の高いパフォーマンスと公平なリソース割り当てを確保します。 これらの制限は、 ワークスペース プラットフォームの層、基盤モデルの種類、および基盤モデルの展開方法によって異なります。
トークン単位の従量課金 エンドポイントのレート制限
トークン単位の従量課金エンドポイントは、トークンベースおよびクエリベースのレート制限によって管理されます。 トークンベースのレート制限は、1 分間に処理できるトークンの最大数を制御し、入力トークンと出力トークンに別々に適用されます。
- 入力トークン/分 (ITPM): 60 秒以内に処理できる入力トークンの最大数 (プロンプトから)。ITPM レート制限は、エンドポイントの入力トークンのスループットを制御します。
- 出力トークン/分 (OTPM) : 60 秒以内に生成できる出力トークン (モデルの応答から) の最大数。 OTPM レート制限は、エンドポイントの出力トークンのスループットを制御します。
- 時間あたりのクエリ 数: 60 分以内に処理できるクエリまたは要求の最大数。本番運用 持続的な使用パターンを持つアプリケーションの場合、 Databricks は、容量が保証されているプロビジョニング スループット エンドポイントをお勧めします。
制限の追跡と適用方法
最も制限の厳しいレート制限 (ITPM、OTPM、QPH) は、いつでも適用されます。たとえば、ITPM 制限に達していない場合でも、QPH または OTPM 制限を超えるとレート制限が適用される可能性があります。ITPM または OTPM の制限に達すると、後続の要求は、受信した要求が多すぎることを示す 429 エラーを受け取ります。このメッセージは、レート制限ウィンドウがリセットされるまで続きます。
Databricks では、次の機能を使用して、トークン/分 (TPM) のレート制限を追跡し、適用します。
機能 | 詳細 |
|---|---|
トークンアカウンティングと事前入場チェック |
手記： Claude Sonnet 4 は、 |
バースト容量とスムージング |
|
以下は、入学前チェックとクレジットバック動作の仕組みの例です。
# Request with max_tokens specified
request = {
"prompt": "Write a story about...", # 10 input tokens
"max_tokens": 500 # System reserves 500 output tokens
}
# Pre-admission check:
# - Verifies 10 tokens against ITPM limit
# - Reserves 500 tokens against OTPM limit
# - If either would exceed limits, returns 429 immediately
# If admitted, actual response uses only 350 tokens
# The systen credits back 150 tokens (500 - 350) to your OTPM allowance
# These 150 tokens are immediately available for other requests
モデル別のレート制限
次の表は、 エンタープライズ層 ワークスペースのトークン単位の従量課金基盤モデルAPIエンドポイントの ITPM、OTPM、および QPH レート制限をまとめたものです。
大規模言語モデル（LLM） | ITPM 制限 | OTPM 制限 | QPH 制限 | 注 |
|---|---|---|---|---|
GPT OSS 120B | 200,000 | 10,000 | 7,200 | 汎用LLM |
GPT OSS 20B | 200,000 | 10,000 | 7,200 | より小さなGPTバリアント |
Gemma 3 12B | 200,000 | 10,000 | 7,200 | Google の Gemma モデル |
Llama 4 Maverick | 200,000 | 10,000 | 2,400 | 最新の Llama リリース |
Llama 3.3 70B Instruct | 200,000 | 10,000 | 2,400 | 中型 Llama モデル |
Llama 3.1 8B Instruct | 200,000 | 10,000 | 7,200 | 軽量 Llama モデル |
Llama 3.1 405B Instruct | 5,000 | 500 | 1,200 | 最大の Llama モデル - サイズによる制限の削減 |
Anthropic Claudeモデル | ITPM 制限 | OTPM 制限 | QPH 制限 | 注 |
|---|---|---|---|---|
Claude 3.7 Sonnet | 50,000 | 5,000 | 2,400 | バランスが取られたClaudeモデル |
Claude Sonnet 4 | 50,000 | 5,000 | 60 | ソネットの最新バージョン |
Claude Opus 4 | 50,000 | 5,000 | 600 | 最も有能なクロードモデル |
埋め込みモデル | ITPM 制限 | OTPM 制限 | QPH 制限 | 注 |
|---|---|---|---|---|
GTE Large (En) | N/A | N/A | 540,000 | テキスト埋め込みモデル - 正規化された埋め込みを生成しません |
BGE Large (En) | N/A | N/A | 2,160,000 | テキスト埋め込みモデル |
TPM レート制限のベスト プラクティスを管理する
ステップ 1.トークンの使用状況を監視する
アプリケーションで入力トークン数と出力トークン数の両方を個別に追跡します。
# Example: Track token usage
response = model.generate(prompt)
input_tokens = response.usage.prompt_tokens
output_tokens = response.usage.completion_tokens
total_tokens = response.usage.total_tokens
# Check against limits
if input_tokens > ITPM_LIMIT or output_tokens > OTPM_LIMIT:
# Implement backoff strategy
pass
ステップ 2.再試行ロジックを実装する
レート制限エラーが発生した場合に指数バックオフを追加します。
import time
import random
def retry_with_exponential_backoff(
func,
initial_delay: float = 1,
exponential_base: float = 2,
jitter: bool = True,
max_retries: int = 10,
):
"""Retry a function with exponential backoff."""
num_retries = 0
delay = initial_delay
while num_retries < max_retries:
try:
return func()
except Exception as e:
if "rate_limit" in str(e) or "429" in str(e):
num_retries += 1
if jitter:
delay *= exponential_base * (1 + random.random())
else:
delay *= exponential_base
time.sleep(delay)
else:
raise e
raise Exception(f"Maximum retries {max_retries} exceeded")
ステップ 3.トークンの使用を最適化する
- プロンプトの長さを最小限に抑える : 簡潔で構造化されたプロンプトを使用する
- 出力長の制御 :
max_tokensパラメーターを使用して応答サイズを制限します - Claude Sonnet 4 に明示的にmax_tokensを設定する: Claude Sonnet 4 を使用するときは、デフォルトの 1,000 トークン制限を回避するために、常に
max_tokensを指定します。 - 効率的なバッチ処理 : 制限内に収まりながら、可能な場合は関連する要求をグループ化します
ステップ 4.モデル選択を検討する
- 大量のタスク用の小規模なモデル : より高いスループットを必要とするタスクには、Llama 3.1 8B などのモデルを使用します
- 複雑なタスク用の大規模モデル : Llama 3.1 405B は、最大限の能力を必要とするタスク用に予約します。
モニタリングとトラブルシューティング
トークンの使用パターンを監視して、パフォーマンスを最適化します。
# Example: Log token usage for monitoring
import logging
logger = logging.getLogger(__name__)
def log_token_usage(response):
usage = response.usage
logger.info(f"Input tokens: {usage.prompt_tokens}")
logger.info(f"Output tokens: {usage.completion_tokens}")
logger.info(f"Total tokens: {usage.total_tokens}")
# Alert if approaching limits
if usage.prompt_tokens > ITPM_LIMIT * 0.8:
logger.warning("Approaching ITPM limit")
if usage.completion_tokens > OTPM_LIMIT * 0.8:
logger.warning("Approaching OTPM limit")
レート制限エラーの処理
レート制限を超えると、API は 429 Too Many Requests エラーを返します。
{
"error": {
"message": "Rate limit exceeded: ITPM limit of 200,000 tokens reached",
"type": "rate_limit_exceeded",
"code": 429,
"limit_type": "input_tokens_per_minute",
"limit": 200000,
"current": 200150,
"retry_after": 15
}
}
エラー応答には次のものが含まれます。
limit_type: どの特定の制限を超えたか (ITPM、OTPM、QPS、または QPH)limit:設定された制限値current:現在の使用状況retry_after: 推奨待ち時間 (秒単位)
一般的な問題とソリューション
問題 | ソリューション |
|---|---|
頻繁な 429 エラー | 指数バックオフの実装、要求レートの削減、より高いレート制限の要求 |
ITPM 制限に達しました | プロンプトの長さを最適化する |
OTPM 制限に達しました |
|
QPH 制限に達しました | 時間の経過とともに要求をより均等に分散する |
プロビジョニングされたスループットの制限
より高い制限を必要とする本番運用ワークロードの場合、プロビジョニング スループット エンドポイントは以下を提供します。
- TPM 制限なし : プロビジョニングされたリソースに基づく処理容量
- より高いレート制限 : ワークスペースごとに最大 200 クエリ/秒
- 予測可能なパフォーマンス : 専用リソースにより、一貫した待機時間が確保されます
プロビジョニングされたスループットワークロードの制限は次のとおりです。
- GTE Large (En) 埋め込みモデルでは、正規化された埋め込みは生成されません。
- Llama 4 Maverick を使用するプロビジョニングされたスループットワークロードの場合:
- プロビジョニングされたスループット ワークロードでのこのモデルのサポートは、 パブリック プレビュー段階です。
- オートスケールはサポートされていません。
- メトリクスパネルはサポートされていません。
- トラフィック分割は、Llama 4 Maverick にサービスを提供するエンドポイントではサポートされていません。Llama 4 Maverick を提供するエンドポイントで複数のモデルを提供することはできません。
地域別の可用性とデータ処理
Databricksがホストする 基盤モデルのリージョン可用性については、「基盤モデルの概要」を参照してください。
データ処理と常駐の詳細については、「 データ処理と常駐」を参照してください。