Limity i przydziały API modelu fundamentowego

Na tej stronie opisano limity i kwoty przydziału dla obciążeń interfejsów API modelu usługi Databricks Foundation.

Interfejsy API modelu usługi Databricks Foundation wymuszają limity szybkości w celu zapewnienia niezawodnej wydajności i sprawiedliwej alokacji zasobów dla wszystkich użytkowników. Te limity różnią się w zależności od warstwy platformy obszaru roboczego, typu modelu podstawowego i sposobu wdrażania modelu podstawowego.

Limity stawek punktów końcowych z płatnością za token

Punkty końcowe płatności za token podlegają limitom szybkości opartym na tokenach i zapytaniach. Limity szybkości oparte na tokenach kontrolują maksymalną liczbę tokenów, które mogą być przetwarzane na minutę i są wymuszane oddzielnie dla tokenów wejściowych i wyjściowych.

• Tokeny wejściowe na minutę (ITPM): maksymalna liczba tokenów wejściowych (z monitów), które mogą być przetwarzane w 60-sekundowym oknie. Limit szybkości itpm kontroluje przepływność tokenu wejściowego punktu końcowego.
• Tokeny wyjściowe na minutę (OTPM): maksymalna liczba tokenów wyjściowych (z odpowiedzi modelu), które można wygenerować w 60-sekundowym oknie. Limit szybkości OTPM kontroluje przepływność tokenu wyjściowego punktu końcowego.
• Zapytania na godzinę: maksymalna liczba zapytań lub żądań, które można przetworzyć w ciągu 60 minut. W przypadku aplikacji produkcyjnych ze stałymi wzorcami użycia, Databricks zaleca korzystanie z punktów końcowych o aprowizowanej przepustowości, które zapewniają gwarantowaną pojemność.

Jak są śledzone i wymuszane limity

Najbardziej restrykcyjny limit szybkości (ITPM, OTPM, QPH) ma zastosowanie w danym momencie. Na przykład, nawet jeśli nie osiągniesz limitu ITPM, możesz nadal być ograniczony czasowo, jeśli przekroczysz limit QPH lub OTPM. Po osiągnięciu limitu ITPM lub OTPM kolejne żądania otrzymają błąd 429, który wskazuje, że odebrano zbyt wiele żądań. Ten komunikat będzie się powtarzać do momentu zresetowania okna limitu szybkości.

Usługa Databricks śledzi i wymusza limity szybkości tokenów na minutę (TPM), korzystając z następujących funkcji:

Poniżej przedstawiono przykład działania sprawdzania przed przyjęciem i zachowania zwrotu środków.

# 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 system credits back 150 tokens (500 - 350) to your OTPM allowance
# These 150 tokens are immediately available for other requests

Maksymalna liczba tokenów wyjściowych

Każdy otwarty model ma maksymalną liczbę tokenów wyjściowych, które może wygenerować w jednej odpowiedzi. Poniższa tabela przedstawia maksymalną wartość dla każdego modelu dostępnego w Twojej chmurze.

Limity szybkości według modelu

Poniższe tabele podsumowują limity stawek ITPM, OTPM i QPH dla endpointów API modelu Foundation rozliczanych pay-per-token dla przestrzeni roboczych w warstwie platformy obszaru roboczego Enterprise:

Poziomy kwot tokenów modelu partnerskiego

Drabinka kwotowa tokenów modelu partnerskiego składa się z trzech numerowanych poziomów. Modele partnerskie domyślnie mają Tier 1, chyba że specyficzne dla modelu ograniczenie zdolności dostawcy wymaga niższego limitu. Te poziomy kwotowe są oddzielne od poziomu platformy Workspace.

Limity niestandardowych tokenów wymagają przeglądu pojemności przez Databricks i znajdują się poza tymi trzema poziomami. Poziomy kwot tokenów zmieniają jedynie limity ITPM i OTPM; Limity RPS, QPS, RPH i QPH pozostają specyficzne dla modelu. Model partnerski zachowuje niższą wartość domyślną tylko dla specyficznego dla modelu ograniczenia pojemności dostawcy. Modele otwarte zachowują domyślne wartości pokazane w poniższych tabelach.

Najlepsze rozwiązania dotyczące zarządzania limitami szybkości modułu TPM

Krok 1. Monitorowanie użycia tokenu

Śledź zarówno liczbę tokenów wejściowych, jak i wyjściowych oddzielnie w aplikacjach:

# 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

Krok 2. Implementuj logikę ponawiania

Dodaj wycofywanie wykładnicze, gdy wystąpią błędy limitu szybkości:

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

Krok 3. Optymalizowanie użycia tokenu

• Minimalizuj długość monitu: używaj zwięzłych, dobrze ustrukturyzowanych monitów
• Długość danych wyjściowych kontrolki: użyj max_tokens parametru, aby ograniczyć rozmiar odpowiedzi
• Efektywne wsadowe przetwarzanie: Grupuj powiązane żądania, jeśli to możliwe, nie przekraczając limitów

Krok 4. Rozważ wybór modelu

• Mniejsze modele do zadań o dużej liczbie pracy: Używaj modeli takich jak GPT OSS 20B do zadań wymagających większej przepustowości.
• Duże modele dla złożonych zadań: Zarezerwuj GPT OSS 120B dla zadań wymagających maksymalnych możliwości.

Monitorowanie i rozwiązywanie problemów

Monitoruj wzorce użycia tokenów, aby zoptymalizować wydajność:

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

Obsługa błędów limitu szybkości

Po przekroczeniu limitów częstotliwości interfejs API zwraca błąd 429 Too Many Requests:

{
  "error": {
    "message": "Rate limit exceeded: ITPM limit of 1,000,000 tokens reached",
    "type": "rate_limit_exceeded",
    "code": 429,
    "limit_type": "input_tokens_per_minute",
    "limit": 1000000,
    "current": 1000150,
    "retry_after": 15
  }
}

Odpowiedź na błąd obejmuje:

• limit_type: Który określony limit został przekroczony (ITPM, OTPM, QPS lub QPH)
• limit: skonfigurowana wartość limitu
• current: Bieżące użycie
• retry_after: Sugerowany czas oczekiwania w sekundach

Obsługa błędów wydajności usługi

Błąd 429 Too Many Requests oznacza, że Twoje obciążenie pracą przekroczyło limit liczby żądań pod Twoją kontrolą. Błąd 503 Service Unavailable to coś innego: oznacza to, że interfejsy API Foundation Model są chwilowo przeciążone i nie mogą obsłużyć Twojego żądania. Błąd 503 nie liczy się do limitu ani nie wskazuje, że osiągnąłeś własnych limitów żądań.

Traktuj odpowiedzi 503 jako przejściowe i próbuj ponownie z wykładniczym wydłużaniem odstępów, zgodnie z tym samym wzorcem co w Kroku 2. Wdroż logikę powtórek. W przypadku obciążeń produkcyjnych, które wymagają stałej pojemności, należy stosować provisioned throughput, który zapewnia dedykowaną pojemność zamiast współdzielonej przepustowości rozliczanej za token. Zobacz dokumentację dotyczącą zarezerwowanej przepustowości aprowizowanej i aprowizowanej przepustowości na żądanie dla obsługiwanych modeli podstawowych.

Typowe problemy i rozwiązania

Aprowizowane limity przepływności

W przypadku obciążeń produkcyjnych, które wymagają wyższych limitów, punkty końcowe z zarezerwowaną przepustowością oferują:

• Brak ograniczeń modułu TPM: Pojemność przetwarzania na podstawie zaaprowizowanych zasobów
• Wyższe limity szybkości: maksymalnie 200 zapytań na sekundę na obszar roboczy
• Przewidywalna wydajność: Zasoby dedykowane zapewniają spójne opóźnienie

Limity tokenów wyjściowych

W poniższej tabeli podsumowano limity tokenów wyjściowych dla każdego obsługiwanego modelu:

Dodatkowe limity

Poniżej przedstawiono ograniczenia dotyczące obciążeń związanych z przydzieloną przepływnością:

• Aby wdrożyć model Meta Llama z system.ai Unity Catalog, należy wybrać odpowiednią wersję Instruct. Podstawowe wersje modeli Meta Llama nie są obsługiwane do wdrażania z Unity Catalog. Zobacz Wdrażanie przydzielonych punktów końcowych przepustowości.
• W przypadku obciążeń aprowizowanej przepływności korzystających z Llama 4 Maverick:
  • Obsługa tego modelu w przypadku obciążeń zarezerwowanej przepustowości jest dostępna w publicznej wersji zapoznawczej.
  • Skalowanie automatyczne nie jest obsługiwane.
  • Panele metryk nie są obsługiwane.
  • Dzielenie ruchu nie jest obsługiwane w punkcie końcowym, który obsługuje Llama 4 Maverick. Nie można obsługiwać wielu modeli na punkcie końcowym, który obsługuje Llama 4 Maverick.

Dostępność regionalna i przetwarzanie danych

Aby uzyskać informacje o dostępności regionu modelu podstawowego hostowanego w usłudze Databricks, zobacz Omówienie modelu foundation.

Aby uzyskać szczegółowe informacje na temat przetwarzania i rezydencji danych, zobacz Przetwarzanie i rezydencja danych.

Limity zasobów i ładunku dla modeli podstawowych i modeli zewnętrznych

W poniższych tabelach podsumowano limity zasobów i ładunków dla punktów końcowych obsługujących modele podstawowe i modele zewnętrzne.

Limit 30 minut streamingu nie dotyczy starszych modeli Meta Llama 3.1 8B, 70B i 405B. Żądania strumieniowe do tych modeli podlegają limitowi 597 sekund.

Dodatkowe zasoby

• Omówienie interfejsów API modelu foundation
• Wdrażaj przydzielone punkty końcowe przepustowości
• Limity i regiony obsługi modelu
• Dokumentacja interfejsu API