Ultimo aggiornamento: 2026-06-22

Che cos'è la pianificazione dei limiti di frequenza degli LLM

La pianificazione dei limiti di frequenza degli LLM è il processo di determinazione della frequenza di richieste sostenibile, e della concorrenza in corso che ne deriva, che i limiti API di un fornitore consentono per un dato carico di lavoro. Le API di inferenza ospitate limitano la capacità di elaborazione su due assi indipendenti: i token al minuto (TPM, tokens per minute), ossia il numero di token, input più output, che l'account può elaborare ogni minuto, e le richieste al minuto (RPM, requests per minute), ossia il numero di chiamate API consentite ogni minuto indipendentemente dalla loro dimensione. Il tetto raggiunto per primo fissa il limite.

Quale limite è determinante

Un carico di lavoro con un costo medio di token per chiamata traduce il tetto TPM in un tetto di richieste equivalente. Dividendo il budget di token al minuto per i token consumati per richiesta si ottiene il numero di richieste al minuto che il limite dei token consente da solo:

dove $L_t$ è il limite TPM e $n$ sono i token per richiesta. La frequenza sostenibile è il minore tra questo tetto derivato dai token e il tetto RPM esplicito $L_r$:

Se $R_t < L_r$ il limite determinante è quello dei token; se $R_t \ge L_r$ lo è quello delle richieste. Il lavoro a forte componente di token (contesto lungo, completamenti estesi) tende a essere vincolato dai token; le chiamate piccole ad alta frequenza tendono a essere vincolate dalle richieste.

La concorrenza dalla legge di Little

La frequenza sostenibile al secondo è $R_s = R / 60$. La legge di Little, un risultato della teoria delle code secondo cui il numero medio di elementi in un sistema è pari alla frequenza di arrivo moltiplicata per il tempo medio che ciascuno vi trascorre, converte quella frequenza e la latenza media della richiesta $t_L$ nella concorrenza $C$ che deve essere eseguita in parallelo per mantenere saturo il canale:

Esempio svolto

Si consideri un limite TPM di $L_t = 2\,000\,000$, un limite RPM di $L_r = 10\,000$ e una media di n = 2,000 token per richiesta. Il tetto derivato dai token è

Poiché 1,000 < 10,000, il limite determinante è quello dei token: la capacità di elaborazione è limitata a 1.000 richieste al minuto, non alle 10.000 dichiarate. A una latenza media di $t_L = 20$ secondi, la frequenza al secondo è $R_s = 1\,000 / 60 \approx 16.7$, per cui la concorrenza necessaria è

Sostenere la frequenza significa quindi mantenere all'incirca 333 richieste in corso contemporaneamente. Poiché il carico di lavoro è vincolato dai token, aumentare il tetto RPM non aiuterebbe; ridurre i token per richiesta, tramite prompt più brevi, completamenti più piccoli o Calcolatore del risparmio con la cache dei prompt, oppure richiedere un'allocazione TPM più elevata, sì.

Varianti e applicazione

Quando le richieste sono invece vincolate dalle richieste stesse, raggruppare più elementi per chiamata aumenta la capacità di elaborazione effettiva mentre ridurre i token non lo fa. La latenza entra solo attraverso la legge di Little: raddoppiare $t_L$ raddoppia la concorrenza che una frequenza fissa richiede, per cui modelli più veloci alleggeriscono il dimensionamento del pool di connessioni e delle code. La cifra di concorrenza alimenta la configurazione del client, ossia il numero di worker, i limiti dei semafori e i pool di connessioni, e la frequenza sostenibile alimenta le proiezioni di costo tramite Calcolatore del costo mensile di un LLM. Poiché il conteggio dei token varia per richiesta e i fornitori possono accodare o gestire raffiche, le cifre a regime sono una base di pianificazione da convalidare rispetto al traffico reale.