Foundation Model API の制限とクォータ

このページでは、Databricks Foundation Model API ワークロードの制限とクォータについて説明します。

Databricks Foundation Model API では、すべてのユーザーに対して信頼性の高いパフォーマンスと公平なリソース割り当てを確保するために、レート制限が適用されます。 これらの制限は、 ワークスペース プラットフォームレベル、基礎モデルの種類、および基盤モデルのデプロイ方法によって異なります。

トークンごとの支払いエンドポイントレートの制限

トークンごとの支払いエンドポイントは、トークンベースとクエリベースのレート制限によって管理されます。 トークン ベースのレート制限は、1 分あたりに処理できるトークンの最大数を制御し、入力トークンと出力トークンに対して個別に適用されます。

• 1 分あたりの入力トークン数 (ITPM):60 秒のウィンドウ内で処理できる (プロンプトからの) 入力トークンの最大数。 ITPM レート制限は、エンドポイントの入力トークンのスループットを制御します。
• 1 分あたりの出力トークン数 (OTPM): 60 秒の期間内に生成できる (モデルの応答からの) 出力トークンの最大数。 OTPM レート制限は、エンドポイントの出力トークンのスループットを制御します。
• 1 時間あたりのクエリ数: 60 分以内に処理できるクエリまたは要求の最大数。 継続的な使用パターンを持つ運用アプリケーションの場合、Databricks では、保証された容量を提供するプロビジョニング済みスループット エンドポイントが推奨されます。

制限の追跡と適用方法

最も制限の厳しいレート制限 (ITPM、OTPM、QPH) は、いつでも適用されます。 たとえば、ITPM の制限に達していない場合でも、QPH または OTPM の制限を超えた場合でもレート制限が発生します。 ITPM または OTPM の制限に達すると、後続の要求は、受信された要求が多すぎることを示す 429 エラーを受け取ります。 このメッセージは、レート制限ウィンドウがリセットされるまで保持されます。

Databricks は、次の機能を使用して、1 分あたりのトークン (TPM) レート制限を追跡して適用します。

入学前チェックとクレジットバック動作のしくみの例を次に示します。

# 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

モデル別のレート制限

次の表は、 Enterprise レベルワークスペースのトークンごとの支払い基盤モデル API エンドポイントの ITPM、OTPM、QPH レートの制限をまとめたものです。

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を設定する: 既定の 1,000 トークン制限を回避するには、常に Claude Sonnet 4 を使用するときに 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: 推奨される待機時間 (秒単位)

一般的な問題と解決策

プロビジョニングされたスループットの制限

より高い制限を必要とする運用環境のワークロードの場合、プロビジョニングされたスループット エンドポイントは次の機能を提供します。

• TPM の制限なし: プロビジョニングされたリソースに基づく処理能力
• レート制限の引き上げ: ワークスペースあたり 1 秒あたり最大 200 クエリ
• 予測可能なパフォーマンス: 専用リソースによって一貫した待機時間が確保される

出力トークンの制限

次の表は、サポートされている各モデルの出力トークンの制限をまとめたものです。

追加の制限

プロビジョニングされたスループット ワークロードの制限事項を次に示します。

• Unity カタログの system.ai から Meta Llama モデルをデプロイするには、該当する Instruct バージョンを選択する必要があります。 Meta Llama モデルの基本バージョンは、Unity カタログからのデプロイではサポートされていません。 プロビジョニング済みスループット エンドポイントのデプロイに関する説明を参照してください。
• Llama 4 Maverick を使用するプロビジョニング済みスループット ワークロードの場合:
  • プロビジョニングされたスループット ワークロードでのこのモデルのサポートは、 パブリック プレビュー段階です。
  • 自動スケールはサポートされていません。
  • メトリック パネルはサポートされていません。
  • Llama 4 Maverick にサービスを提供するエンドポイントでは、トラフィックの分割はサポートされていません。 Llama 4 Maverick にサービスを提供するエンドポイントで複数のモデルを提供することはできません。

リージョンの可用性とデータ処理

Databricks でホストされる基盤モデルのリージョンの可用性については、「 Foundation Model の概要」を参照してください。

データ処理と所在地の詳細については、 データ処理と常駐を参照してください。

その他のリソース

• Foundation Model API の概要
• プロビジョニングされたスループット エンドポイントをデプロイする
• モデル サービスの制限とリージョン
• API リファレンス