Condividi tramite

Limiti e quote delle API del modello di base

Questa pagina descrive i limiti e le quote per i carichi di lavoro delle API modello di Databricks Foundation.

Le API del modello di Databricks Foundation applicano limiti di frequenza per garantire prestazioni affidabili e allocazioni equa delle risorse in tutti gli utenti. Questi limiti variano in base al livello della piattaforma dell'area di lavoro, al tipo di modello di base e alla modalità di distribuzione del modello di base.

Limiti di frequenza degli endpoint con pagamento in base al token

Gli endpoint con pagamento in base al token sono regolati dai limiti di frequenza basati su token e basati su query. I limiti di frequenza basati su token controllano il numero massimo di token che possono essere elaborati al minuto e vengono applicati separatamente per i token di input e di output.

  • Token di input al minuto (ITPM): numero massimo di token di input (dalle richieste) che possono essere elaborati all'interno di una finestra di 60 secondi. Un limite di velocità ITPM controlla la velocità effettiva del token di input di un endpoint.
  • Token di output al minuto (OTPM): numero massimo di token di output (dalle risposte del modello) che possono essere generati in una finestra di 60 secondi. Un limite di velocità OTPM controlla la velocità effettiva del token di output di un endpoint.
  • Query all'ora: numero massimo di query o richieste che possono essere elaborate entro un intervallo di 60 minuti. Per le applicazioni di produzione con modelli di utilizzo sostenuti, Databricks consiglia gli endpoint di velocità effettiva di cui è stato effettuato il provisioning, che offrono capacità garantita.

Modalità di rilevamento e applicazione dei limiti

Il limite di velocità più restrittivo (ITPM, OTPM, QPH) si applica in qualsiasi momento. Ad esempio, anche se non è stato raggiunto il limite ITPM, è comunque possibile limitare la frequenza se si supera il limite QPH o OTPM. Quando viene raggiunto il limite ITPM o OTPM, le richieste successive ricevono un errore 429 che indica che sono state ricevute troppe richieste. Questo messaggio persiste fino a quando non viene reimpostata la finestra del limite di velocità.

Databricks tiene traccia e applica i limiti di frequenza dei token al minuto (TPM) usando le funzionalità seguenti:

Caratteristica / Funzionalità Dettagli
Verifica della contabilità dei token e dei controlli di pre-ammissione
  • Conteggio dei token di input: i token di input vengono conteggiati dal prompt effettivo in fase di richiesta.
  • Stima del token di output: se si specifica max_tokens nella richiesta, Databricks usa questo valore per stimare e riservare la capacità del token di output prima che la richiesta venga ammessa per l'elaborazione.
  • Convalida preliminare: Databricks verifica se la richiesta supera i limiti ITPM o OTPM prima dell'inizio dell'elaborazione. Se max_tokens si superano i limiti DI OTPM, Databricks rifiuta immediatamente la richiesta con un errore 429.
  • Output effettivo e stimato: dopo la generazione della risposta, vengono conteggiati i token di output effettivi. Importante, se l'utilizzo effettivo del token è inferiore a quello riservato max_tokens, Databricks accredita la differenza rispetto al limite di velocità, rendendo immediatamente disponibili tali token per altre richieste.
  • Nessun max_tokens specificato: se non si specifica max_tokens, Databricks usa una prenotazione predefinita e il numero effettivo di token viene riconciliato dopo la generazione. Nota: Claude Sonnet 4 usa in modo specifico 1.000 token di output quando max_tokens non è impostato, restituendo il motivo di fine "length" quando viene raggiunto. Questa non è la lunghezza massima del contesto del modello. Claude 3.7 Sonnet non ha questa impostazione predefinita.
Capacità di burst e smussamento
  • Buffer burst: il limite di velocità include un buffer ridotto per supportare brevi picchi di traffico al di sopra della velocità nominale.
  • Finestra temporale scorrevole: il consumo di token viene monitorato usando un algoritmo di finestra scorrevole che fornisce una limitazione della velocità più fluida rispetto ai limiti rigidi al minuto.
  • Algoritmo del bucket di token: Databricks usa un'implementazione del bucket di token che consente una capacità burst mantenendo il limite medio di velocità nel tempo.

Di seguito è riportato un esempio di funzionamento del controllo pre-ammissione e del comportamento di credit-back.

# 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

Limiti di frequenza per modello

Le tabelle seguenti riepilogano i limiti di frequenza ITPM, OTPM e QPH per gli endpoint DELL'API modello di base con pagamento in base al token per le aree di lavoro del livello Enterprise:

Annotazioni

A partire dal 15 febbraio 2026, Meta-Llama-3.1-405B-Instruct verrà ritirato. Per informazioni su come eseguire la migrazione durante la deprecazione, vedere Modelli ritirati per il modello di sostituzione consigliato.

Modelli linguistici di grandi dimensioni Limite ITPM Limite OTPM Limite QPH Note
Qwen3-Next 80B A3B Instruct (Beta) 200,000 10,000 LLM per utilizzo generico
GPT OSS 120B 200,000 10,000 LLM per utilizzo generico
GPT OSS 20B 200,000 10,000 Variante GPT più piccola
Gemma 3 12B 200,000 10,000 7,200 Modello Gemma di Google
Llama 4 Maverick 200,000 10,000 2,400 Versione più recente di Llama
Llama 3.3 70B Istruzioni 200,000 10,000 2,400 Modello Llama di medie dimensioni
Llama 3.1 8B Istruzioni 200,000 10,000 7,200 Modello Llama leggero
Llama 3.1 405B Istruzioni 5,000 500 1,200
  • Modello llama più grande - limiti ridotti a causa delle dimensioni
Modelli di Claude anthropic Limite ITPM Limite OTPM Note
Claude 3.7 Sonnet 50,000 5,000 Modello Claude bilanciato
Claude Sonetto 4 50,000 5,000
Claude Opus 4.1 50,000 5,000
Claude Opus 4.5 200,000 20,000 Ultima versione Opus
Claude Sonnetto 4.5 50,000 5,000 Versione più recente di Sonnet
Claude Haiku 4.5 50,000 5,000 Versione più recente di Haiku
Incorporamento di modelli Limite ITPM Limite OTPM Limite QPH Note
GTE Large (En) N/A N/A 540,000 Modello di incorporamento del testo: non genera incorporamenti normalizzati
BGE Large (En) N/A N/A 2,160,000 Modello di incorporamento del testo

Gestire le procedure consigliate per i limiti di frequenza TPM

Passaggio 1: Monitorare l'utilizzo dei token

Tenere traccia dei conteggi dei token di input e di output separatamente nelle applicazioni:

# 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

Passaggio 2. Implementare la logica di ripetizione dei tentativi

Aggiungere un backoff esponenziale quando si verificano errori di limite di frequenza:

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

Passaggio 3. Ottimizzare l'utilizzo dei token

  • Ridurre al minimo la lunghezza del prompt: usare prompt concisi e ben strutturati
  • Controllare la lunghezza dell'output: usare max_tokens il parametro per limitare le dimensioni della risposta
  • Impostare max_tokens in modo esplicito per Claude Sonnet 4: specificare max_tokens sempre quando si usa Claude Sonnet 4 per evitare il limite predefinito di 1.000 token
  • Batch in modo efficiente: raggruppare le richieste correlate quando possibile mantenendo i limiti

Passaggio 4. Prendere in considerazione la selezione del modello

  • Modelli più piccoli per le attività con volumi elevati: usare modelli come Llama 3.1 8B per le attività che richiedono una velocità effettiva maggiore
  • Modelli di grandi dimensioni per attività complesse: Riserva llama 3.1 405B per le attività che richiedono capacità massima

Monitoraggio e risoluzione dei problemi

Monitorare i modelli di utilizzo dei token per ottimizzare le prestazioni:

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

Gestire gli errori di limite di frequenza

Quando si superano i limiti di frequenza, l'API restituisce un 429 Too Many Requests errore:

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

La risposta di errore include:

  • limit_type: limite specifico superato (ITPM, OTPM, QPS o QPH)
  • limit: valore limite configurato
  • current: utilizzo corrente
  • retry_after: tempo di attesa suggerito in secondi

Problemi e soluzioni comuni

Problema Soluzione
Errori frequenti 429 Implementare backoff esponenziale, ridurre la frequenza delle richieste e richiedere limiti di frequenza più elevati
È stato raggiunto il limite ITPM Ottimizzare la lunghezza del prompt
È stato raggiunto il limite OTPM Usare max_tokens per limitare la lunghezza della risposta
Limite QPH raggiunto Distribuire le richieste in modo più uniforme nel tempo

Limiti di velocità effettiva con provisioning

Per i carichi di lavoro di produzione che richiedono limiti più elevati, gli endpoint di velocità effettiva con provisioning offrono:

  • Nessuna restrizione TPM: capacità di elaborazione basata sulle risorse di cui è stato effettuato il provisioning
  • Limiti di frequenza più elevati: fino a 200 query al secondo per area di lavoro
  • Prestazioni prevedibili: le risorse dedicate garantiscono una latenza coerente

Limiti dei token di output

Annotazioni

A partire dal 15 maggio 2026, Meta-Llama-3.1-405B-Instruct verrà ritirato. Per informazioni su come eseguire la migrazione durante la deprecazione, vedere Modelli ritirati per il modello di sostituzione consigliato.

La tabella seguente riepiloga i limiti dei token di output per ogni modello supportato:

Model Limite di token di output
GPT OSS 120B 25,000
GPT OSS 20B 25,000
Gemma 3 12B 8,192
Llama 4 Maverick 8,192
Llama 3.1 405B 4,096
Llama 3.1 70B 8,192
Llama 3.1 8B 8,192

Limiti aggiuntivi

Di seguito sono riportate le limitazioni per i carichi di lavoro con throughput allocato.

  • Per distribuire un modello Meta Llama da system.ai in Unity Catalog, è necessario scegliere la versione di istruzioni applicabile. Le versioni di base dei modelli Meta Llama non sono supportate per la distribuzione da Unity Catalog. Vedere Distribuire gli endpoint di velocità effettiva con provisioning.
  • Per i carichi di lavoro con velocità effettiva con provisioning che usano Llama 4 Maverick:
    • Il supporto per questo modello nei carichi di lavoro con velocità effettiva con provisioning è disponibile in anteprima pubblica.
    • La scalabilità automatica non è supportata.
    • I pannelli delle metriche non sono supportati.
    • La suddivisione del traffico non è supportata in un endpoint che serve Llama 4 Maverick. Non è possibile gestire più modelli su un endpoint che serve Llama 4 Maverick.

Disponibilità e elaborazione dati a livello di area

Per la disponibilità dell'area del modello di base ospitata da Databricks, vedere Panoramica del modello di base.

Per informazioni dettagliate sull'elaborazione e la residenza dei dati, vedere Elaborazione e residenza dei dati.

Risorse aggiuntive

  • Last updated on