Spiegazione dei limiti di velocità e del throughput dell'API

Cos'è in realtà un limite di velocità

UN limite di tariffa è un limite alla velocità con cui puoi utilizzare un'API. I fornitori li impongono per mantenere il servizio giusto e stabile: senza di essi, un singolo loop di bug o un picco di traffico da parte di un cliente potrebbe affamare tutti gli altri, quindi i limiti proteggono la capacità, applicano livelli di piano e attenuano gli abusi e gli attacchi denial-of-service. Quando superi un limite, l'API smette di servirti per un momento e restituisce un HTTP 429 "Troppe richieste" risposta invece di fare il lavoro.

I limiti sono disponibili in alcune unità comuni e puoi prima raggiungerne uno qualsiasi:

Sulle API LLM i due che mordono più spesso sono giri al minuto E TPM, e sono indipendenti. Cinquanta minuscole chiamate di classificazione possono superare l'RPM toccando a malapena il TPM; un riepilogo di documenti da 100.000 token può superare il TPM in un'unica richiesta. Progetta in base al limite raggiunto per primo dal carico di lavoro.

Trasformare un limite TPM in "quanti utenti posso servire?"

La pianificazione della capacità è solo aritmetica. Partiamo dai gettoni uno l'utente consuma al minuto, quindi dividi il limite per esso.

• Gettoni per richiesta = token di input (prompt + messaggio di sistema + contesto) più token di output generati dal modello. Entrambi contano contro il TPM.
• Richieste per utente al minuto = quanto è loquace un utente attivo.
• Token per utente al minuto = token per richiesta × richieste per utente al minuto.

Esempio: ogni turno di chat utilizza ~1.500 input + ~500 output = 2.000 gettonie un utente attivo invia ~1,5 giri al minuto → 3.000 token/utente/minuto. Con a 300.000 TPM limite che puoi servire all'incirca 300.000 ÷ 3.000 = 100 utenti attivi simultanei. Fai la stessa divisione rispetto al limite RPM e prendi il più piccolo delle due risposte: questo è il tuo vero limite. Nota "attivo" significa invio attivo; un prodotto con 100 utenti simultanei di solito ha migliaia di account registrati.

Livelli: spendere di più aumenta i tuoi limiti

La maggior parte dei fornitori funziona livelli di utilizzo. I nuovi account iniziano con RPM/TPM/RPD bassi; man mano che spendi di più e il tuo account invecchia, vieni automaticamente promosso a livelli più alti con massimali molto più grandi, a volte 10× o 100× i numeri iniziali. Se stai raggiungendo i limiti, le prime domande sono: a quale livello mi trovo e mi qualifico per quello successivo? Gli accordi aziendali e di spesa impegnata possono aumentare ulteriormente i limiti o aggiungere capacità dedicata.

Tecniche che aumentano la produttività effettiva

• Batch - combinare molti elementi in meno richieste più grandi per allentare la pressione dell'RPM. Anche le API batch dedicate dei fornitori vengono eseguite con uno sconto per lavori non urgenti.
• Streaming — Lo streaming dei token non aumenta il budget dei token, ma riduce la latenza percepita e libera le risorse del client prima, quindi le richieste sovrapposte vengono cancellate più velocemente.
• Backoff e ritmo - Distribuire le chiamate in modo uniforme nel corso del minuto invece di spararle tutte in una volta ti mantiene sotto soffitti esplosivi che altrimenti inciamperesti.
• Token di taglio — Prompt più brevi, memorizzazione nella cache dei prompt e limiti di output rigorosi aumentano direttamente il numero di richieste che rientrano in un budget TPM fisso.

Gestione dei 429: backoff, tentativi e code

Raggiungere un limite è normale: la domanda è se la tua app si ripristina correttamente. Il modello standard è backoff esponenziale con jitter: su un 429 attendere un breve ritardo e riprovare; se fallisce di nuovo, raddoppia all'incirca il ritardo ogni volta (ad esempio 1s, 2s, 4s, 8s) e aggiungi un piccolo offset casuale in modo che molti client non riprovino contemporaneamente. Rispettare sempre a Riprova dopo intestazione se il provider ne invia una: ti dice esattamente quanto tempo aspettare.

Limite rigido rispetto a limite morbido/burst

UN limite rigido è un limite assoluto: superalo e ogni richiesta verrà rifiutata fino al ripristino della finestra. UN limite soft o burst consente brevi picchi al di sopra della velocità costante (spesso tramite un secchio di gettoni che si ricarica nel tempo), quindi passano brevi raffiche ma il sovraccarico prolungato viene comunque limitato. Sapere cosa devi affrontare cambia la tua strategia: i limiti di burst premiano il traffico uniforme oltre la finestra; i limiti rigidi richiedono un reale coda che i contatori richiedono a una tariffa sicura.

• Lavori non urgenti in coda quindi si scarica a un ritmo controllato invece di martellare l'API.
• Distribuire il carico in modo uniforme anziché scoppiare all'inizio di ogni minuto.
• Limita i tentativi totali quindi una richiesta destinata a fallire fallisce in modo pulito invece di ripetersi per sempre.

L'aspetto dei costi: i limiti modellano l'architettura, non la bolletta

I limiti tariffari non comportano un costo diretto in denaro: non ti viene mai addebitato un 429. Ma influenzano fortemente il modo in cui costruisci e tali scelte Fare hanno un costo. Quando una singola chiave non è in grado di fornire il throughput necessario, i team in genere cercano una chiave catena di ripiego (failover su un secondo modello o provider quando il primario subisce limitazioni), più chiavi o fornitori alla capacità del pool e a API batch per spingere i lavori non urgenti su corsie più economiche e con limiti più alti. Ciascuno aggiunge resilienza e margine di manovra, ma anche complessità di integrazione e talvolta prezzi per token più elevati in caso di fallback. L’approccio più salutare è aumentare prima il tuo livello e ridurre i token, quindi aggiungere la ridondanza solo dove un limite rigido ti blocca davvero.

Continua ad imparare

Domande frequenti

Qual è la differenza tra RPM e TPM?

L'RPM (richieste al minuto) limita il numero di chiamate API che puoi effettuare ogni minuto, mentre il TPM (token al minuto) limita la quantità di testo che tali chiamate possono spostare. Puoi raggiungere prima uno dei due limiti: molte chiamate di piccole dimensioni esauriscono l'RPM, mentre alcune chiamate di contesto più ampio esauriscono il TPM.

Come posso trasformare un limite TPM nel numero di utenti che posso servire?

Stimare i token consumati da un utente al minuto (token per richiesta moltiplicati per le richieste per utente al minuto, conteggiando sia l'input che l'output), quindi dividere il limite TPM per tale cifra. Se un utente ha bisogno di 3.000 token/minuto e il tuo limite è 300.000 TPM, puoi servire circa 100 utenti attivi simultanei.

Come devo gestire l'errore 429 Too Many Requests?

Riprova con backoff e jitter esponenziali: attendi progressivamente più a lungo tra un tentativo e l'altro e rispetta qualsiasi intestazione Retry-After restituita dal provider. Metti in coda il lavoro non urgente, distribuisci il carico in modo uniforme anziché in modo eccessivo e limita il numero totale di tentativi in ​​modo che una richiesta alla fine fallisca in modo pulito anziché ripetersi all'infinito.