Rate limit delle API LLM: 13 provider, 2 SDK non ritentano i 429
Indice
- Cosa significano RPM, TPM e gli altri limiti?
- Su quali dimensioni le API LLM applicano i rate limit?
- Quali token vengono conteggiati nel limite?
- Quali header restituisce ogni provider?
- Cosa significa un 429 e quando va ritentato?
- Come gestisce un 429 lo SDK?
- In che modo un gateway cambia la situazione?
- FAQ
Delle tredici API LLM analizzate (dieci vendor più Bedrock, Vertex AI e Azure OpenAI), quattro indicano il budget residuo in ogni risposta. Mistral invia un solo contatore residuo, mentre le altre otto non comunicano nulla finché la richiesta non fallisce. Un “429” può indicare quattro situazioni diverse: un throttle da ritentare, un acceleration limit che richiede di rallentare, una quota o un limite di spesa per cui non va fatto alcun retry, oppure un sovraccarico segnalato come 429, 503 o 529 a seconda del vendor. Il comportamento dipende però dal client più che dal vendor: gli SDK di OpenAI, Anthropic e Groq ritentano due volte un 429 e rinunciano se Retry-After supera 60 o 120 secondi, mentre gli SDK Google GenAI e Mistral hanno i retry disattivati per impostazione predefinita. Questo articolo è un riferimento cross-vendor, ricavato direttamente dal codice sorgente: dimensioni dei limiti, token conteggiati, header, significato dei 429 e comportamento di ogni SDK ufficiale.
TL;DR
- Quasi tutte le API LLM applicano limiti alle richieste e ai token al minuto. Anthropic separa input e output, mentre DeepSeek limita soltanto la concorrenza.
- OpenAI, Azure e Bedrock addebitano subito
max_tokens; Anthropic esclude le letture dalla cache; xAI conteggia il reasoning; Bedrock consuma 10 token di quota per ogni token di output di Claude 5. - OpenAI, Anthropic, Groq e Azure restituiscono gli header con valori residui e tempi di reset in ogni risposta 200. Otto API non ne documentano alcuno.
- Gli SDK google-genai e Mistral non ritentano un 429 per impostazione predefinita. OpenAI, Anthropic e Groq effettuano due retry e fissano a 60 o 120 secondi il limite massimo per Retry-After.
Cosa significano RPM, TPM e gli altri limiti?
Sono tutti tetti alla quantità di traffico inviabile in una finestra temporale. Ogni provider adotta una combinazione diversa:
| Gruppo | Termini | Significato e provider che li usano |
|---|---|---|
| Contatori di richieste | RPM, RPD, RPS, concorrenza | Richieste al minuto o al giorno, una per chiamata indipendentemente dalle dimensioni. In genere RPS equivale a RPM diviso 60 e funge da protezione contro i picchi (xAI, Alibaba, Mistral, Azure). La concorrenza misura le richieste in corso anziché quelle effettuate in una finestra ed è l’unico limite applicato da DeepSeek |
| Contatori di token | TPM, TPD, ITPM, OTPM, burndown rate | Token al minuto o al giorno. Alcuni provider li separano in input (ITPM) e output (OTPM). Il burndown rate moltiplica i token di output prima di addebitarli alla quota (Bedrock). Il provider decide quali token conteggiare, come spiegato nella sezione successiva |
| Contatori per altre unità | IPM, secondi audio, pagine OCR | Immagini al minuto per i modelli di immagini (OpenAI, Gemini), secondi audio all’ora o al giorno (Groq, Mistral), pagine al minuto per l’OCR dei documenti (Mistral) |
| Applicazione della finestra | Token bucket, acceleration limit | Un token bucket si ricarica continuamente anziché azzerarsi ogni minuto. Un picco può quindi svuotarlo pur restando entro il totale al minuto (Anthropic; Alibaba e Azure descrivono lo stesso effetto). Un acceleration limit controlla separatamente la velocità di crescita del traffico e può scattare in caso di aumento improvviso anche senza superare il limite (Anthropic, slow_down di OpenAI) |
| Fattori che determinano i limiti | Tier, limite di spesa o quota, capacità riservata | Il tier definisce i contatori precedenti e aumenta in base all’utilizzo a pagamento o allo storico, non alle ricariche di credito. Un limite di spesa o una quota giornaliera impone un tetto economico o di volume, non di velocità: aspettare un minuto non serve. La capacità riservata è throughput dedicato, fatturato per unità e per ora (Bedrock e Vertex AI Provisioned Throughput, Azure PTU). In questo caso un 429 indica che la capacità riservata è satura, non che la quota è esaurita |
Il valore indicato è un tetto per la finestra, non una quantità garantita. Anthropic precisa che 60 RPM “potrebbero essere applicati come 1 richiesta al secondo”, mentre Azure segnala che “un picco in una finestra di 1 o 10 secondi può generare un 429 anche se il totale al minuto resta entro il limite”.
Su quali dimensioni le API LLM applicano i rate limit?
Quasi sempre su richieste e token al minuto. I tre cloud, però, non si limitano a inoltrare le regole dei vendor. Le definizioni seguenti provengono direttamente dai provider e dalle pagine collegate, consultate il 2026-09-03 e il 2026-09-04.
| Provider | Dimensioni | Come aumentano i limiti | Fonte |
|---|---|---|---|
| OpenAI | RPM, RPD, TPM, TPD, IPM, minuti audio al minuto; coda Batch API misurata in token di input accodati | Tier da 1 a 5 in base ai pagamenti cumulativi | rate limit |
| Anthropic | RPM, ITPM e OTPM per classe di modello; token bucket; acceleration limit | Tier Start, Build e Scale in base allo storico di utilizzo | rate limit |
| Google Gemini | RPM, TPM (input), RPD; IPM sui modelli di immagini | Piano gratuito, poi Tier da 1 a 3 con limiti di spesa ogni 10 minuti | rate limit |
| xAI | RPS (RPM / 60) e TPM per modello | Tier da 0 a 4 più Enterprise | rate limit |
| Alibaba Model Studio | RPM e TPM per modello, con RPS = RPM / 60 e TPS = TPM / 60 come protezioni contro i picchi | Per modello; batch esente per alcuni modelli | rate limit |
| DeepSeek | Solo concorrenza: 500 connessioni su V4 Pro, 2,500 su V4 Flash | Fisso per modello | rate limit |
| Mistral | RPS, token al minuto e token al mese, per modello e workspace | Tier da 1 a 4 in base alla fatturazione cumulativa; “L’aggiunta di credito non aumenta i rate limit” | utilizzo e limiti, centro assistenza |
| MiniMax | RPM e TPM per modello; MiniMax M3 a 200 RPM e 10M TPM | Contattare il reparto vendite | rate limit |
| Moonshot Kimi | Concorrenza, RPM, TPM, TPD; il Tier 0 offre 1 richiesta concorrente e 3 RPM, il Tier 5 offre 100 e 300 | Sei tier in base alle ricariche cumulative, da $1 a $3,000 | limiti |
| Groq | RPM, RPD, TPM, TPD, ITPM, OTPM, secondi audio all’ora e al giorno | Per modello | rate limit |
| Amazon Bedrock | RPM, TPM, TPD per modello e regione; il valore predefinito di TPD è TPM x 1,440 | Service Quotas, aumentabili su richiesta; i nuovi account partono con valori ridotti | quote |
| Google Vertex AI | Nessun valore per progetto nel piano pay-as-you-go: un pool condiviso in cui “la spesa storica dell’organizzazione determina Usage Tier e throughput di base (TPM)”, con picchi gestiti in modalità best effort | Usage tier basato sulla spesa; Provisioned Throughput “garantisce l’isolamento dal pool PayGo condiviso” | blog di Google Cloud |
| Azure OpenAI | TPM assegnato per deployment, da cui deriva RPM (6 RPM ogni 1,000 TPM sui modelli precedenti, 1 RPM ogni 1,000 TPM sui modelli attuali); i deployment PTU sono limitati dall’utilizzo | Tier di quota da 0 a 6, con upgrade automatico | quote e limiti, gestione delle quote |
Due righe non descrivono affatto finestre al minuto. DeepSeek limita le connessioni aperte e, quando è sotto carico, mantiene aperta una richiesta inviando righe vuote (oppure commenti : keep-alive in streaming) per un massimo di 10 minuti anziché rifiutarla. Vertex AI in modalità pay-as-you-go non espone una quota da consultare: un 429 indica che in quel momento il pool condiviso non aveva capacità sufficiente.
Quali token vengono conteggiati nel limite?
Non sono necessariamente gli stessi token fatturati. Questa differenza può ridurre la capacità effettiva a una frazione del valore dichiarato oppure moltiplicarla:
| Provider | Token conteggiati nel limite | Conseguenza |
|---|---|---|
| OpenAI | Il valore maggiore tra max_tokens e una stima ricavata dal prompt, addebitato all’arrivo: “Se imposti max_tokens su un valore troppo alto, l’utilizzo può essere sovrastimato anche quando la risposta effettiva è molto più breve” (cookbook) | Un max_tokens di 4,000 per una risposta da 50 token consuma 4,000 TPM |
| Azure OpenAI | Una stima basata su “testo e quantità del prompt, impostazione del parametro max_tokens, impostazione del parametro best_of”, calcolata in parte sul numero di caratteri; nei deployment PTU “i token in cache ricevono uno sconto del 100%” (guida alle quote) | “Un rate limit può scattare prima del previsto”; se max_tokens non è impostato, viene stimato automaticamente |
| Amazon Bedrock | ”Token di input totali + max_tokens” detratti all’inizio, poi corretti alla fine in InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate), con le letture dalla cache escluse. Il burndown è 5x su Claude 4.7 e precedenti, 10x su Sonnet 5, Opus 5, Fable 5.1 e sui modelli GPT-5.6, 15x su Claude 4.8 (conteggio dei token) | Nell’esempio documentato, 1,000 token di input e 100 di output su un modello 5x consumano 1,500 token di quota e ne fatturano 1,100 |
| Anthropic | ITPM conteggia input_tokens e cache_creation_input_tokens; cache_read_input_tokens “NON viene conteggiato in ITPM”. OTPM considera l’output effettivo; “max_tokens non influisce su OTPM” (documentazione) | Nell’esempio documentato, 2M ITPM con un cache hit rate dell’80% gestiscono 10M token di input al minuto |
| xAI | ”Tutti i token consumati da una richiesta vengono conteggiati nel limite TPM: token del prompt (testo, immagini e audio), token di completamento, token di reasoning (sui modelli di reasoning), token del prompt in cache” | Il reasoning consuma TPM per token non visibili; la cache non aumenta il throughput |
| Google Gemini | Token di input | La lunghezza dell’output non riduce il limite disponibile |
| Alibaba, Mistral, MiniMax | Input più output | |
| Kimi, Groq, DeepSeek, Vertex AI | Non dichiarato | Groq misura ITPM e OTPM separatamente; DeepSeek non applica limiti sui token; Vertex AI pubblica soltanto un valore di base legato allo usage tier |
La stessa richiesta pesa in modo diverso per ogni limite, da 800 a 6,000 token nell’esempio precedente. Un router che distribuisce lo stesso workload tra più vendor deve quindi mantenere un contatore separato per ciascuno.
Quali header restituisce ogni provider?
Quattro API includono lo stato dei limiti in ogni risposta, Mistral invia un solo campo e le altre otto obbligano il client a tenere il conteggio.
| Provider | Header in una risposta normale | Note sul formato |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens, più la terna -project-tokens | Reset indica “il tempo mancante all’azzeramento del rate limit”; Retry-After sui 429 |
| Azure OpenAI | Gli stessi sei nomi x-ratelimit-* in ogni chiamata; retry-after-ms e retry-after sui 429 | Un x-ratelimit-limit-tokens inferiore al TPM configurato indica che è attiva una “modifica temporanea del rate limit” |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}, la stessa terna per tokens, input-tokens e output-tokens, più anthropic-priority-* e anthropic-fast-* dove si applicano questi tier | Reset in RFC 3339; valore residuo arrotondato al migliaio più vicino; la terna tokens-* mostra “il limite più restrittivo attualmente in vigore” |
| Groq | x-ratelimit-limit-requests (giornaliero), x-ratelimit-limit-tokens (al minuto), x-ratelimit-remaining-*, x-ratelimit-reset-*; “sempre inclusi” | Reset espresso come durata, "2m59.56s", "7.66s"; retry-after in secondi, solo sui 429 |
| Mistral | X-RateLimit-Remaining | |
| Gemini, xAI, Alibaba, DeepSeek, MiniMax, Kimi, Bedrock, Vertex AI | Nessuno documentato | Gemini, Alibaba e Bedrock indicano il motivo nel body dell’errore; Kimi documenta Retry-After in caso di sovraccarico; gli SDK AWS leggono x-amz-retry-after in millisecondi quando il servizio lo invia |
Il problema pratico è che uno stesso campo usa tre formati: la durata di OpenAI, il timestamp di Anthropic e il valore 2m59.56s di Groq richiedono tre parser. Anche per questo gli SDK leggono soltanto retry-after. Il 2026-09-03 sono stati misurati due intermediari, con una richiesta ciascuno. Un grande aggregatore multi-provider non ha restituito alcun header di rate limit su una risposta 200, riservandoli ai 429. Il gateway Synthorai ha restituito x-ratelimit-remaining-requests e x-ratelimit-reset-requests insieme al costo della richiesta.
Cosa significa un 429 e quando va ritentato?
Può indicare quattro situazioni diverse. Solo due giustificano un retry:
| Significato | Retry? | Come viene indicato dai provider |
|---|---|---|
| Throttle: è stato superato un limite | Sì, dopo Retry-After o un backoff | OpenAI e Anthropic 429 rate_limit_error, Anthropic con retry-after; Gemini e Vertex AI 429 RESOURCE_EXHAUSTED, che su Vertex AI indica capacità insufficiente nel pool condiviso; Kimi rate_limit_reached_error; Bedrock ThrottlingException, più ModelNotReadyException ritentato dallo SDK fino a 5 volte; Azure “Rate limit is exceeded”; xAI RateLimitError; Alibaba “Requests rate limit exceeded”; DeepSeek e Mistral 429 |
| Accelerazione: il traffico è cresciuto troppo rapidamente | Ridurre la velocità di crescita, poi ritentare | OpenAI slow_down; “acceleration limits” di Anthropic; Alibaba “Request rate increased too quickly”; Azure, un picco in una finestra di 1 o 10 secondi |
| Quota o limite di spesa: aspettare non libera capacità | No; correggere la fatturazione o attendere la data di reset | OpenAI insufficient_quota, credit_balance_exhausted, organization_spend_limit_exceeded; Anthropic enforced_spend_limit_reached senza retry-after, mentre un limite di spesa impostato dall’utente produce un 400; Gemini quota_exceeded (giornaliero); Kimi exceeded_current_quota_error; Bedrock 400 ServiceQuotaExceededException; aggregatore e DeepSeek 402. Su Azure la quota viene assegnata durante il deployment, quindi il suo esaurimento non produce un 429 |
| Sovraccarico: è satura la capacità del provider, non quella del client | Sì, con backoff | OpenAI 503 server_is_overloaded; Anthropic 529 overloaded_error; Gemini 503 UNAVAILABLE; Kimi 429 engine_overloaded_error con Retry-After; Bedrock 503 ServiceUnavailableException e 529 overloaded_error; Azure “System is experiencing high demand”, una “temporary rate limit adjustment” del pool condiviso oppure PTU al 100% di utilizzo con retry-after-ms; DeepSeek 503 |
Il problema è nella terza riga. Il 429 per limite di spesa di Anthropic ha lo stesso tipo rate_limit_error di un throttle e la documentazione avverte: “I retry, compresi quelli automatici degli SDK, falliscono finché l’accesso non viene ripristinato.” Anche insufficient_quota di OpenAI è un 429. Un client che decide solo in base allo status code ritenta entrambi, proprio come fanno tutti gli SDK ufficiali, come mostra la sezione successiva. La decisione deve basarsi sull’error code. Un 429 senza Retry-After suggerisce inoltre che attendere non servirà.
La quarta riga evidenzia le differenze tra i cloud. La guida alla risoluzione dei problemi di Azure è esplicita: “Molti clienti interpretano erroneamente i 429 dovuti alla capacità come problemi di quota, scegliendo quindi una soluzione sbagliata.” Su Azure, un 429 con x-ratelimit-limit-tokens inferiore al limite configurato indica che il pool condiviso si sta proteggendo. Su Vertex AI, ogni 429 pay-as-you-go ha questo significato. Su Bedrock la stessa condizione produce un 503 o 529, mai un ThrottlingException. Attraverso un aggregatore, l’informazione compare nel body: durante la misurazione degli header, un 429 è arrivato incapsulato come provider_error_code: insufficient_quota, limit_source: upstream_provider_shared_pool. Lo status indicava throttle, il body la quota di qualcun altro.
Come gestisce un 429 lo SDK?
Dipende dallo SDK e due tra i più usati non fanno nulla. I comportamenti seguenti sono stati ricavati dal codice sorgente di ogni client ufficiale il 2026-09-04, non dalla documentazione:
| SDK | Retry predefiniti | Status ritentati | Backoff | Gestione di Retry-After |
|---|---|---|---|---|
| openai-python (anche Azure OpenAI) | 2 | 408, 409, 429, 5xx o quanto indicato da x-should-retry | min(0.5 × 2^n, 8) s con jitter | Legge retry-after-ms, poi retry-after come secondi o data; oltre 120 s non ritenta affatto |
| anthropic-sdk-python, groq-python | 2 | gli stessi | lo stesso | Stesso parsing; oltre 60 s l’header viene ignorato e si usa la formula di backoff |
| openai-node, anthropic-sdk-typescript | 2 | gli stessi | lo stesso | Stesso comportamento; oltre 60 s usa il backoff predefinito |
| google-genai (Python, Gemini API e Vertex AI) | 0: retry_options ha valore predefinito None, che corrisponde a un solo tentativo | Se abilitato: 408, 429, 500, 502, 503, 504 | Se abilitato: 5 tentativi, da 1 s raddoppiando fino a 60 s con jitter | Non legge Retry-After |
| mistralai (Python) | 0: retry_config non è impostato per impostazione predefinita | Se configurato: 429, 500, 502, 503, 504 | Se configurato: 500 ms × 1.5^n fino a 60 s, 1 h totale | Rispetta qualsiasi Retry-After, espresso in secondi o come data |
| boto3 (Bedrock) | Modalità legacy: 5 tentativi incluso il primo; modalità standard: 3 | ThrottlingException e simili, 429, 5xx | Fattore base 2, massimo 20 s in modalità standard. Il comportamento 2026, attivabile con AWS_NEW_RETRIES_2026=true, usa full jitter, una base di 1,000 ms per il throttling e un retry token bucket | Nessun Retry-After; il comportamento 2026 legge x-amz-retry-after in millisecondi, limitandolo al backoff più 5 s |
| xai-sdk (Python, gRPC) | 5 tentativi, solo per UNAVAILABLE | RESOURCE_EXHAUSTED, cioè il 429 gRPC, non viene ritentato | Da 0.1 s raddoppiando fino a 1 s | n/a |
| dashscope (Alibaba) | 0 in base allo status HTTP; un solo reinvio se una connessione del pool cade prima dell’arrivo di qualsiasi byte | |||
| DeepSeek, Kimi, MiniMax | Nessuno SDK chat proprietario; la documentazione DeepSeek suggerisce di “usare lo SDK OpenAI/Anthropic” con un base URL diverso |
Ne derivano tre considerazioni. Primo, un 429 di Gemini, Vertex AI o Mistral arriva al codice applicativo già al primo evento, a meno che non siano state specificate le opzioni di retry. Il commento nel sorgente di google-genai secondo cui il client “ritenterà 4 volte” descrive la configurazione abilitata, non quella predefinita. Secondo, i limiti imposti a Retry-After sono incompatibili con le attese lunghe richieste dai vendor: se Anthropic chiede di attendere 90 secondi, lo SDK ignora l’header e riprova entro 8; se OpenAI ne chiede 150, lo SDK non ritenta. Terzo, gli SDK generati da Stainless, il code generator usato dai client OpenAI, Anthropic e Groq, rispettano un header x-should-retry non documentato prima di controllare lo status code e leggono retry-after-ms prima di retry-after. Un vendor o un gateway può quindi controllare i retry senza modificare lo status code.
Nessuno distingue un 429 dovuto al limite di spesa da un throttle. Due retry di una risposta insufficient_quota costano pochi secondi ciascuno, ma se li effettua un’intera flotta su larga scala si crea un picco inutile.
In che modo un gateway cambia la situazione?
Il gateway è l’unico punto in cui gestire tutto una volta sola. Verso upstream legge gli header specifici di ogni vendor, assorbendo la complessità dei tre formati di reset e dei quattro significati di 429 invece di scaricarla su ogni client. Verso downstream espone un unico set di header e un solo formato di errore, come mostrano gli header Synthorai misurati in precedenza. Il gateway non può però cambiare la contabilizzazione del vendor: con OpenAI il valore max_tokens del client continua a consumare TPM in anticipo; con Bedrock ogni token di output Claude continua a consumarne dieci. Inoltre, un gateway che aggrega molti client su una sola chiave del vendor raggiunge l’acceleration limit prima di qualsiasi singolo client. Servono quindi bucket per chiave, non un unico contatore condiviso.
FAQ
max_tokens viene conteggiato nel rate limit?
Sì, su OpenAI, Azure OpenAI e Bedrock. max_tokens viene addebitato all’arrivo della richiesta, quindi un valore sovradimensionato spreca TPM anche se la risposta è breve. Bedrock corregge la detrazione al termine della risposta. Su Anthropic no: OTPM conteggia i token effettivamente generati e max_tokens “non influisce” sul valore.
I token in cache vengono conteggiati nel rate limit?
Non su Anthropic, Bedrock o nei deployment Azure PTU, dove le letture dalla cache sono escluse. Su xAI vengono conteggiati per intero. OpenAI e Gemini non lo dichiarano.
Retry-After viene sempre inviato con un 429?
No. OpenAI, Azure (come retry-after-ms) e Groq lo inviano in caso di throttle; Anthropic lo invia per i throttle ma non per il limite di spesa; Kimi e Bedrock solo in caso di sovraccarico. Gemini, Vertex AI, xAI, Alibaba, DeepSeek e MiniMax non ne documentano l’uso, quindi il client deve implementare un backoff proprio.
Perché lo SDK non ha ritentato un 429?
Negli SDK Python di Google GenAI e Mistral, i retry sono disattivati per impostazione predefinita: occorre passare retry_options o un RetryConfig. Lo SDK Python di OpenAI non ritenta se il server richiede un’attesa superiore a 120 secondi. Se il 429 indica una quota o un limite di spesa, non ritentare è il comportamento corretto.
Articoli correlati: guida alle unità di fatturazione, fasce di prezzo per contesti lunghi, anatomia dell’utilizzo dei token, audit della cache del gateway.