Concorrenza nelle API di IA: come controllare code, quote e latenza

Perché un’integrazione funzionante può saturarsi

Un’integrazione con un modello può funzionare correttamente con il traffico abituale e, nonostante ciò, degradarsi quando arrivano molte richieste tutte insieme. Se l’applicazione invia ogni richiesta immediatamente, senza controllare quante sono già in corso né quante sono in attesa, un picco può accumulare lavoro più rapidamente di quanto il servizio riesca a completarlo. I risultati visibili possono essere una latenza maggiore, richieste che non sono più utili quando vengono completate, risposte che segnalano il raggiungimento di un limite o una fattura diversa da quella prevista.

La concorrenza è importante perché una richiesta non occupa risorse per un intervallo di tempo fisso. La generazione può durare di più o di meno a seconda dell’attività, delle dimensioni dell’input e della quantità di output richiesta. Perciò, il solo conteggio delle richieste al secondo non descrive tutta la pressione esercitata da un’integrazione. Due carichi con la stessa frequenza di richieste possono avere tempi di servizio e consumi diversi.

L’obiettivo del controllo del carico non è mantenere occupata ogni capacità possibile a qualsiasi costo. È proteggere gli obiettivi dell’applicazione: completare lavoro utile, rispettare le priorità, limitare le attese ed evitare che una domanda temporaneamente elevata trasformi il sistema in una coda senza fine. Le scelte progettuali che seguono sono raccomandazioni generali: non descrivono un limite universale e non sostituiscono le condizioni documentate per ciascuna API, modello o modalità di accesso.

È utile distinguere due problemi che spesso vengono confusi. L’ammissione decide, prima dell’invio di una richiesta, se l’applicazione accetta il lavoro, lo tiene brevemente in attesa oppure lo rifiuta. La politica di retry interviene dopo un errore o un esito incerto. Questa guida si occupa soprattutto della prima decisione e dell’attesa controllata: riprovare automaticamente non corregge un’ammissione che lascia entrare più lavoro di quanto il sistema possa gestire.

Cosa misurare prima di fissare i limiti

Inizia osservando un carico rappresentativo, invece di scegliere a intuito un numero di richieste concorrenti. Registra la frequenza di arrivo e il numero di richieste simultanee, ma aggiungi anche le dimensioni dell’input e dell’output prodotto quando sono disponibili. Al momento di decidere l’ammissione prima dell’invio, l’output non è ancora noto: puoi misurarlo in seguito per migliorare le stime, ma non trattarlo come un dato futuro esatto.

Misura la latenza end-to-end e, se puoi strumentare separatamente le fasi, distingui il tempo trascorso in coda da quello tra l’invio e la risposta. Per le risposte generate progressivamente, registra anche il tempo al primo frammento e la durata complessiva. Un buon tempo al primo frammento non implica che l’intera attività sia terminata rapidamente; allo stesso modo, una durata complessiva elevata non dimostra da sola che la causa sia la coda.

Usa percentili come p95 e p99 insieme alle medie. La media riassume una tendenza, ma può nascondere una minoranza di richieste che attende molto più a lungo. Affianca a queste misure il numero di richieste completate, annullate, scadute e rifiutate; gli errori restituiti dal provider; l’uso dei token, quando disponibile; e il costo per attività completata, se il sistema è in grado di calcolarlo in modo affidabile.

La relazione di Little offre un modo per verificare la coerenza tra il numero medio di unità presenti in un sistema, la frequenza media di arrivo e il tempo medio trascorso al suo interno: L = λW. Applicata con attenzione, aiuta a capire perché, se la frequenza di arrivo resta costante e aumenta il tempo di permanenza, può crescere anche il numero medio di attività presenti. Non è una formula che, da sola, prevede percentili, picchi, costi o il limite di un’API: descrive una relazione tra medie nelle condizioni pertinenti.

Quando è rilevante per la tua configurazione, suddividi le misurazioni per modello, endpoint, provider, regione o progetto. Non mescolare in un’unica serie attività brevi e lunghe se così facendo nascondi i problemi di una categoria. Separa inoltre il carico di produzione dai test e annota i cambiamenti di configurazione, così da poter collegare una variazione della latenza a una causa plausibile.

Non confondere frequenza, concorrenza, token e capacità propria

Un limite di frequenza controlla quante richieste, o quante unità contabilizzate, possono essere presentate in un determinato periodo. Un limite di concorrenza restringe il numero di operazioni che l’applicazione mantiene attive contemporaneamente. Un limite basato sui token riguarda il volume di testo elaborato o richiesto secondo le regole del servizio. Un limite dell’applicazione è una scelta aggiuntiva: per esempio, quanti lavori ammettere nella coda locale o per quanto tempo consentire l’attesa.

Questi vincoli risolvono problemi diversi. Un sistema può rispettare una frequenza media e accumulare comunque un picco di breve durata; può avere poche richieste simultanee ma di lunga durata; oppure ricevere poche richieste che comportano input molto estesi. L’applicazione deve conoscere i vincoli pubblicati per la modalità di accesso che usa e, in aggiunta, definire controlli locali che proteggano l’esperienza degli utenti.

Non trasferire quote da un prodotto all’altro per analogia. La documentazione di Vertex AI descrive quote e limiti il cui ambito può dipendere dal servizio, dal progetto e dalla regione. Il riferimento dell’API di OpenAI include intestazioni di risposta relative ai limiti di richieste e token. Questi esempi mostrano perché è necessario consultare la documentazione applicabile allo specifico account e alla configurazione in uso; non definiscono valori condivisi né una regola unica per tutti gli endpoint.

Una risposta 429 non identifica sempre una sola causa o un’unica soluzione. La documentazione di Vertex AI distingue situazioni legate alla capacità condivisa e alla capacità provisionata. Registra quindi il tipo di risposta e consulta la documentazione pertinente prima di interpretarne il significato. In particolare, non trasformare ogni risposta 429 in un ordine di riprovare immediatamente: questa è una decisione successiva all’errore e può aumentare la pressione se l’ammissione resta aperta.

Progetta l’ammissione: accettare, attendere o rifiutare

Una politica di ammissione dovrebbe prevedere esplicitamente tre esiti. Accettare significa che la richiesta può iniziare nel rispetto dei limiti locali e delle quote note. Attendere significa conservarla temporaneamente in una coda con capacità e scadenza definite. Rifiutare significa che il sistema non promette di elaborarla in quel momento e restituisce una risposta che consente all’applicazione client di decidere come procedere.

Una coda senza limite non è una soluzione sicura: può trasformare una saturazione visibile in attese sempre più lunghe e in lavoro accumulato che arriva troppo tardi per essere utile. Definisci un numero massimo di elementi, un budget di attesa e una condizione di scadenza. Se la coda raggiunge il limite, rifiuta il nuovo lavoro oppure applica una regola di sostituzione giustificata dal prodotto; non nascondere il problema aggiungendo spazio di archiviazione senza un limite operativo.

La risposta di rifiuto deve essere coerente con l’interfaccia del servizio. Spiega che l’attività non è stata ammessa o indica che la capacità è temporaneamente occupata, senza affermare che il modello l’abbia elaborata. Se l’applicazione può riprovare più tardi, fornisci un’indicazione chiara e documentata affinché il client possa decidere cosa fare. Evita di promettere un tempo di attesa preciso se non puoi sostenerlo con le misurazioni.

L’ammissione può combinare più condizioni: capacità di concorrenza disponibile, coda al di sotto del limite massimo, quota per utente e budget di attesa residuo. Valuta le condizioni prima di riservare risorse e libera la prenotazione quando l’attività viene completata, annullata o scade. Se il client annulla una richiesta ma questa continua a occupare uno slot locale, la misura della concorrenza non rappresenta più il lavoro effettivamente attivo.

Definisci esplicitamente l’ordine delle priorità. Per esempio, puoi riservare una parte della capacità alle attività interattive e limitare quelle batch, purché queste categorie esistano nel prodotto e la politica non lasci indefinitamente senza servizio la categoria meno prioritaria. L’obiettivo non è inventare una priorità universale, ma rispecchiare il valore e la scadenza di ciascuna classe di lavoro.

Pondera il lavoro senza fingere di conoscerne il costo esatto

Contare le richieste è una regola semplice, ma tratta allo stesso modo attività che possono essere molto diverse. Un’alternativa consiste nell’assegnare a ciascuna richiesta un peso stimato, usando segnali disponibili prima dell’invio: token di input stimati, lunghezza prevista dell’output, classe dell’attività oppure misure storiche della durata per quel tipo di operazione. Il peso può servire a stabilire priorità, limitare i budget o decidere se un’attività può entrare in coda.

Una stima non è una garanzia. La risposta generata può essere più corta o più lunga del previsto; la durata può variare anche tra input di dimensioni simili. Calibra quindi la stima confrontandola con i risultati osservati, mantieni un margine e verifica gli errori di previsione. Se registri l’output effettivo, usalo per migliorare le politiche future, non per presentare come noto un dato che non era disponibile al momento dell’ammissione.

Un’opzione pratica consiste nell’assegnare limiti distinti per classe o nel riservare, per ogni finestra temporale, una quantità prevista di lavoro. Un’altra consiste nell’usare un sistema interno di crediti, in cui ogni richiesta consuma un peso stimato e la capacità viene ripristinata secondo la politica locale. In entrambi i casi, documenta come viene calcolato e corretto il peso e cosa succede quando una richiesta supera le previsioni. Non presentare un conteggio locale dei token come se fosse identico alla quota del provider.

Confronta le politiche usando lo stesso insieme di richieste e lo stesso carico. Se una politica ponderata riduce i picchi di attesa per i lavori brevi, verifica anche cosa accade alle attività più grandi: potrebbero essere continuamente rinviate. Il criterio di successo deve considerare il rendimento complessivo, la latenza per classe e la percentuale di attività completate entro la scadenza, non soltanto una metrica favorevole alle richieste più brevi.

Priorità, equità e protezione dai blocchi

Una sola coda può bastare per un prodotto con attività equivalenti, ma comporta rischi quando combina lavori urgenti e attività lunghe. Un’attività di lunga durata all’inizio della coda può far attendere le altre anche quando sono brevi. Inoltre, se un client genera una quota sproporzionata della domanda, può consumare la capacità condivisa e penalizzare gli altri.

Puoi separare le code per classe di servizio, stabilire quote per utente oppure limitare il numero di attività simultanee per client. Puoi anche riservare capacità al traffico interattivo ed elaborare i lavori batch usando il margine restante. Sono opzioni progettuali, non garanzie di equità: priorità, dimensioni delle riserve e regola di selezione vanno provate con i modelli d’uso reali.

Definisci cosa significa equità nel tuo caso. Potrebbe significare che ogni client ha l’opportunità di avanzare, che le attività interattive rispettano una scadenza o che nessun utente consuma l’intero budget locale. Una quota molto rigida per utente può proteggere dall’accaparramento, ma anche lasciare inutilizzata capacità quando gli altri utenti non sono attivi. Una quota troppo flessibile potrebbe non proteggere i client più piccoli durante un picco.

Per evitare che una priorità bassa venga rinviata indefinitamente, valuta limiti massimi di attesa, l’aumento progressivo della priorità con il tempo o opportunità minime di servizio. Misura il tempo in coda per classe e client, non soltanto la media globale. Se le categorie hanno scadenze diverse, registra quante attività vengono completate in tempo e quante scadono. Una politica che migliora la latenza di una classe a scapito di un’altra, rendendola inutile, deve essere presentata come una scelta esplicita del prodotto.

Budget di attesa, annullamento e scadenza

Ogni attività dovrebbe avere una scadenza utile definita dal prodotto, anche se non viene esposta direttamente all’utente. Se una richiesta resta in coda oltre il momento in cui può ancora offrire valore, conservarla significa soltanto accumulare lavoro in arretrato. Assegna un tempo massimo di attesa e controllalo di nuovo prima di inviare l’attività al provider.

La scadenza in coda e l’annullamento dopo l’invio non sono la stessa cosa. Prima dell’invio, rimuovere un’attività può evitare di avviare lavoro che non serve più. Dopo l’invio, l’effetto dell’annullamento dipende dalle funzionalità dell’integrazione e dal comportamento documentato dell’endpoint. Non presumere che chiudere una connessione arresti l’elaborazione remota o annulli il consumo. Strumenta ciò che il sistema può osservare e descrivine i limiti.

Registra quante richieste scadono prima di iniziare e quante vengono annullate mentre sono in corso. Se molte scadono in coda, rivedi la dimensione della coda, la frequenza di ammissione e il budget di attesa. Se vengono annullate dopo l’invio, valuta se una scadenza anticipata o un’interfaccia che consenta all’utente di ritirare il lavoro ridurrebbero le attività inutili. Non dedurre un risparmio sui costi senza misurazioni che lo confermino.

La scadenza aiuta anche a gestire le priorità: un’attività urgente che ha già perso la propria scadenza non dovrebbe continuare a occupare il primo posto solo perché è arrivata prima. Tuttavia, eliminare automaticamente il lavoro può avere conseguenze funzionali. Definisci se la scadenza viene comunicata, se l’attività viene conservata per un’esecuzione successiva o se viene eliminata; il comportamento deve essere prevedibile per chi integra il servizio.

Test di carico riproducibile e gestione operativa

Metti alla prova la politica prima di applicarla su larga scala. Prepara un insieme rappresentativo di attività che includa input e output di lunghezze diverse e le classi di priorità effettivamente usate dal prodotto. Esegui un carico di base, poi aumenta gradualmente la concorrenza e aggiungi picchi controllati. Per confrontare le varianti, mantieni costante l’insieme delle richieste, così che le differenze non dipendano dall’aver provato attività diverse.

Definisci in anticipo i criteri di arresto e di ripristino. Per esempio, puoi interrompere l’aumento se p99 supera l’obiettivo concordato, se aumentano le scadenze o gli errori, oppure se il tempo in coda oltrepassa il budget del prodotto. I valori concreti devono derivare dagli obiettivi, dalle misurazioni e dalle condizioni dell’API, non da una cifra universale. Registra configurazione, data, versione del client e parametri del test, così da poterlo ripetere.

Scomponi la latenza: tempo di attesa locale, tempo alla prima risposta quando pertinente e durata complessiva. Confronta inoltre richieste completate, risposte di limite raggiunto, annullamenti, percentili per classe e costo per attività completata. Se osservi solo il rendimento totale, potresti non accorgerti che una classe sta fallendo; se guardi soltanto una risposta di errore, potresti non rilevare che il problema era una coda locale che aveva iniziato a crescere prima della chiamata al provider.

Durante l’esercizio, controlla le quote pubblicate per la specifica modalità di accesso e monitora le intestazioni o i campi di risposta documentati dal servizio. Questi segnali aiutano a riconoscere i limiti e a informare il sistema di osservabilità, ma disponibilità e significato dipendono dall’API. Non presumere che un’intestazione sia presente in ogni risposta o rimanga invariata. Annota quando hai consultato la documentazione e verifica eventuali cambiamenti prima di aggiornare i controlli.

Un rilascio prudente parte da limiti locali conservativi, osservabilità e una modalità per tornare alla configurazione precedente. In seguito, si aumenta gradualmente l’ammissione se i risultati giustificano la scelta. Se le metriche peggiorano, riduci il flusso in ingresso, accorcia la coda o modifica le classi di lavoro; non reagire automaticamente a una latenza crescente ampliando la coda, perché così potresti nascondere la saturazione e prolungare le attese.

Limiti dell’approccio e criteri pratici

Non esiste un numero di richieste concorrenti che possa essere trasferito in sicurezza a tutte le integrazioni. Quote e condizioni possono variare in base a servizio, modello, progetto, regione e modalità di accesso. Inoltre, le quote possono cambiare e una risposta osservata durante un test non dimostra che la stessa capacità sarà disponibile con un’altra configurazione o in un altro momento. Consulta le fonti ufficiali pertinenti e verifica i limiti prima di trasformarli in regole permanenti.

Non esiste neppure una formula unica che traduca token o richieste al secondo in una latenza garantita. La relazione tra arrivi, permanenza e numero medio di elementi aiuta a ragionare sulla crescita di una coda, ma non sostituisce un test rappresentativo né prevede ogni risposta. Le dimensioni degli output e le durate osservate forniscono informazioni; le stime preventive aiutano ad ammettere il lavoro con prudenza, non a garantirne l’esito esatto.

Prima di approvare una politica, verifica di sapere quante richieste sono in corso e in attesa; che la coda abbia un limite e una scadenza; che l’ammissione consideri le dimensioni di lavoro rilevanti; e che esista una risposta chiara quando un’attività non viene accettata. Assicurati anche che le priorità non privino una classe del servizio, che gli annullamenti siano misurati nello stato corretto e che le metriche distinguano l’attesa locale dall’elaborazione remota.

Infine, mantieni distinta la gestione del carico dal recupero dopo gli errori. L’ammissione decide quanta domanda entra e quanto lavoro resta in attesa. I retry decidono come reagire dopo un errore o un esito incerto. Un sistema robusto necessita di politiche compatibili per entrambe le fasi, ma l’una non sostituisce l’altra: prima evita di accettare più lavoro di quanto tu possa gestire; poi definisci separatamente come reagire agli errori.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.