Gränser och kvoter för API:er för grundmodell

Den här sidan beskriver gränserna och kvoterna för Api:er för Databricks Foundation-modell.

Databricks Foundation-modell-API:er tillämpar hastighetsgränser för att säkerställa tillförlitlig prestanda och rättvis resursallokering för alla användare. Dessa gränser varierar beroende på arbetsytans plattformsnivå, grundmodelltyp och hur du distribuerar din grundmodell.

Gränser för slutpunktsfrekvens för betala per token

Slutpunkter för betala per token styrs av tokenbaserade och frågebaserade hastighetsgränser. Tokenbaserade hastighetsgränser styr det maximala antalet token som kan bearbetas per minut och tillämpas separat för indata- och utdatatoken.

• Indatatoken per minut (ITPM): Det maximala antalet indatatoken (från dina frågor) som kan bearbetas inom ett 60-sekundersfönster. En ITPM-hastighetsgräns styr dataflödet för indatatoken för en slutpunkt.
• Utdatatoken per minut (OTPM) : Det maximala antalet utdatatoken (från modellens svar) som kan genereras inom ett 60-sekundersfönster. En OTPM-hastighetsgräns styr utdatatokens dataflöde för en slutpunkt.
• Frågor per timme: Det maximala antalet frågor eller begäranden som kan bearbetas inom ett fönster på 60 minuter. För produktionsprogram med varaktiga användningsmönster rekommenderar Databricks etablerade dataflödesslutpunkter som ger garanterad kapacitet.

Hur gränser spåras och framtvingas

Den mest restriktiva hastighetsgränsen (ITPM, OTPM, QPH) gäller vid en viss tidpunkt. Även om du till exempel inte har nått itpm-gränsen är du fortfarande hastighetsbegränsad om du överskrider gränsen för QPH eller OTPM. När gränsen för ITPM eller OTPM nås får efterföljande begäranden ett 429-fel som anger att för många begäranden har tagits emot. Det här meddelandet kvarstår tills hastighetsbegränsningsfönstret återställs.

Databricks spårar och tillämpar hastighetsbegränsningar för token per minut (TPM) med hjälp av följande funktioner:

Följande är ett exempel på hur förintagningskontroll och kredituppföljningsbeteende fungerar.

# 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

Hastighetsbegränsningar per modell

I följande tabeller sammanfattas ITPM-, OTPM- och QPH-hastighetsgränserna för API-slutpunkter för foundation-modell för betala per token för arbetsytor på Enterprise-nivå:

Metodtips för att hantera TPM-hastighetsbegränsningar

Steg 1. Övervaka tokenanvändning

Spåra både antal in- och utdatatoken separat i dina program:

# 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

Steg 2. Implementera logik för återförsök

Lägg till exponentiell backoff när du stöter på hastighetsbegränsningsfel:

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")

Steg 3. Optimera tokenanvändning

• Minimera promptens längd: Använd koncisa, välstrukturerade prompter
• Kontrollutdatalängd: Använd max_tokens parameter för att begränsa svarsstorleken
• Ange max_tokens explicit för Claude Sonnet 4: Ange max_tokens alltid när du använder Claude Sonnet 4 för att undvika standardgränsen på 1 000 token
• Batch effektivt: Gruppera relaterade begäranden när det är möjligt medan du håller dig inom gränserna

Steg 4. Överväg att välja modell

• Mindre modeller för uppgifter med stora volymer: Använd modeller som Llama 3.1 8B för uppgifter som kräver högre dataflöde
• Stora modeller för komplexa uppgifter: Reservera Llama 3.1 405B för uppgifter som kräver maximal kapacitet

Övervaka och felsöka

Övervaka användningsmönstren för token för att optimera prestanda:

# 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")

Hantera hastighetsbegränsningsfel

När du överskrider hastighetsgränserna returnerar API:et ett 429 Too Many Requests fel:

{
  "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
  }
}

Felsvaret innehåller:

• limit_type: Vilken specifik gräns har överskridits (ITPM, OTPM, QPS eller QPH)
• limit: Det konfigurerade gränsvärdet
• current: Din aktuella användning
• retry_after: Föreslagen väntetid i sekunder

Vanliga problem och lösningar

Etablerade dataflödesgränser

För produktionsarbetsbelastningar som kräver högre gränser erbjuder etablerade slutpunkter för dataflöde:

• Inga TPM-begränsningar: Bearbeta kapacitet baserat på etablerade resurser
• Högre hastighetsgränser: Upp till 200 frågor per sekund per arbetsyta
• Förutsägbar prestanda: Dedikerade resurser säkerställer konsekvent svarstid

Begränsningar för utdata-token

I följande tabell sammanfattas utdatatokens gränser för varje modell som stöds:

Ytterligare gränser

Följande är begränsningar för etablerade dataflödesarbetsbelastningar:

• Om du vill distribuera en Meta Llama-modell från system.ai i Unity-katalogen måste du välja tillämplig Instruktion-version . Basversioner av Meta Llama-modellerna stöds inte för distribution från Unity Catalog. Se Distribuera etablerade dataflödesslutpunkter.
• För etablerade dataflödesarbetsbelastningar som använder Llama 4 Maverick:
  • Stöd för den här modellen för etablerade dataflödesarbetsbelastningar finns i offentlig förhandsversion.
  • Autoskalning stöds inte.
  • Måttpaneler stöds inte.
  • Trafikdelning stöds inte på en slutpunkt som hanterar Llama 4 Maverick. Du kan inte hantera flera modeller på en slutpunkt som hanterar Llama 4 Maverick.

Regional tillgänglighet och databehandling

Information om tillgänglighet för Databricks-värdbaserade basmodellregioner finns i Översikt över Foundation Model.

Information om databehandling och uppehållstillstånd finns i Databearbetning och residens.

Ytterligare resurser

• Översikt över API:er för Foundation Model
• Distribuera etablerade dataflödesslutpunkter
• Gränser och regioner för modellservering
• API-referens