In che modo il batching dell’IA domestica scambia la latenza con il throughput?
Il batching dell’IA domestica migliora il throughput complessivo combinando attività compatibili, ma ogni richiesta potrebbe dover attendere più a lungo o condividere iterazioni più lente con altri utenti.
Un singolo prompt può accedere immediatamente a un acceleratore inattivo, mentre un server familiare spesso riceve chat sovrapposte, prompt per documenti, richieste vocali e processi in background. Il runtime può trattenere brevemente una richiesta per creare un batch, aggiungere nuove sequenze tra le iterazioni di decodifica oppure suddividere i prefill lunghi in blocchi più piccoli. Queste scelte mantengono l’acceleratore più occupato, ma modificano anche il tempo al primo token, il ritardo tra i token e l’equità. Le sezioni seguenti spiegano quando il batching è utile e quando i guadagni di throughput smettono di migliorare l’esperienza interattiva.
Il batching trasforma la capacità inutilizzata dell’acceleratore in lavoro condiviso
Una singola richiesta potrebbe non utilizzare in modo efficiente ogni unità di esecuzione parallela, soprattutto durante operazioni su matrici di piccole dimensioni o con sequenze brevi. Combinare più richieste crea operazioni tensoriali più grandi, che possono sfruttare l’acceleratore in modo più efficace.
Orca ha introdotto lo scheduling a livello di iterazione, consentendo alle richieste di unirsi e uscire tra un’iterazione di generazione e l’altra, invece di obbligare un singolo batch fisso a rimanere insieme finché tutte le sequenze non sono terminate.
Il guadagno si misura in token o richieste completati per unità di tempo. Non garantisce che un singolo utente riceva prima un token.
Una finestra di batching aggiunge tempo di attesa prima dell’inizio del calcolo
Un runtime che attende altre richieste può creare un batch più grande ed efficiente, ma la prima richiesta deve pagare quel tempo di attesa anche quando l’acceleratore era disponibile.
Il compromesso tra throughput e latenza diventa evidente quando batch più grandi migliorano l’efficienza del dispositivo, estendendo però i tempi di accodamento o di iterazione.
L’IA domestica interattiva richiede solitamente una finestra di batching breve o adattiva. Gli embedding in background possono tollerare più attesa, perché l’obiettivo è completare il lavoro, non rispondere in modo conversazionale.
I prefill lunghi possono bloccare il lavoro di decodifica breve
L’elaborazione del prompt esegue un prefill intensivo dal punto di vista computazionale, mentre le conversazioni attive restituiscono ripetutamente risultati attraverso fasi di decodifica vincolate dalla memoria. Mescolarle nello stesso batch può far attendere una piccola decodifica interattiva dietro a un lungo prompt documentale.
DistServe isola l’interferenza tra prefill e decodifica, perché le due fasi hanno caratteristiche diverse in termini di risorse e latenza.
Il prefill suddiviso in blocchi è un compromesso: divide un prompt lungo affinché le richieste di decodifica possano essere eseguite tra un blocco e l’altro, ma il documento richiede più cicli di scheduling per essere completato.
L’impostazione migliore dipende dal fatto che il server dia priorità a un’unica analisi lunga o a diversi utenti che stanno già ricevendo risposte in streaming.
Le lunghezze miste delle sequenze rendono ogni batch irregolare
Le richieste differiscono per lunghezza del prompt, lunghezza dell’output, condizioni di arresto e funzionalità del modello. Alcune terminano rapidamente, mentre altre rimangono attive, quindi la composizione del batch cambia continuamente.
vLLM utilizza il batching continuo con cache KV paginata per accettare nuove richieste quando la capacità diventa disponibile, invece di attendere un confine fisso del batch.
Anche con una gestione efficiente della memoria, una risposta molto lunga consuma gli slot di decodifica e la cache KV per molte iterazioni. La dimensione del batch dovrebbe quindi essere espressa in budget di token e memoria, non solo nel numero di richieste.
I batch più grandi possono ridurre il tasso di token per utente
Il numero totale di token al secondo può aumentare mentre ogni utente riceve una quota inferiore di iterazioni di decodifica. Un pannello che mostra un throughput aggregato più elevato può coesistere con uno streaming visibile più lento.
La guida di ZimaSpace alla concorrenza familiare spiega perché i benchmark con un solo utente non prevedono la latenza di diverse conversazioni sovrapposte.
Misura il tempo al primo token, il tempo tra i token e il tempo di completamento per richiesta insieme al throughput aggregato. Altrimenti il batching potrebbe essere ottimizzato per una metrica che gli utenti non sperimentano mai direttamente.
Imposta criteri di batching diversi per il lavoro interattivo e in background
Riserva finestre di accodamento brevi, concorrenza limitata e priorità più alta a voce e chat. Consenti batch più grandi e priorità più bassa per embedding, indicizzazione, riepiloghi e trasformazioni offline.
La ricerca sul serving equo degli LLM utilizza l’equità basata sui token, così l’input o l’output lungo di una richiesta non occupa indefinitamente una quota sproporzionata.
Esegui i test con un carico familiare rappresentativo, non solo con la dimensione massima del batch. La configurazione utile è quella che offre il throughput più elevato continuando a rispettare gli obiettivi di tempo al primo token e latenza dello streaming per il percorso interattivo.
Quando un singolo acceleratore non riesce a soddisfare entrambe le classi, worker o pianificazioni separati possono essere più semplici di un’unica politica di batching universale.
Domande frequenti
Il batching aumenta sempre la latenza?
No. Un batching efficiente può ridurre il tempo complessivo necessario a svuotare la coda e prevenire il sovraccarico, ma attendere la formazione di un batch e condividere iterazioni più lunghe può aumentare la latenza di una singola richiesta.
La dimensione del batch corrisponde al numero di utenti?
Non esattamente. I runtime possono definire il budget in base alle sequenze attive, ai token, ai blocchi KV o al lavoro complessivo, e un singolo utente può generare diverse richieste simultanee.
Le richieste vocali dovrebbero essere inserite nello stesso batch degli embedding?
Di solito no, se sottoposte alla stessa politica di latenza. La voce è interattiva, mentre i processi di embedding possono attendere e utilizzare batch più grandi durante i periodi di capacità inutilizzata.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Perché le previsioni della casa intelligente diventano meno accurate dopo i cambiamenti stagionali delle abitudini?
Le routine stagionali cambiano il rapporto tra tempo, sensori, presenza e azioni desiderate, rendendo obsoleto un modello addestrato su abitudini precedenti.
Perché un NVR domestico perde gli eventi brevi quando il rilevamento degli oggetti è attivato?
Il tracciamento necessita di un numero sufficiente di rilevamenti per avviare e confermare una traiettoria, quindi un oggetto che compare solo per poco tempo...
Perché le etichette delle foto generate dall’IA cambiano dopo un aggiornamento del modello?
Un aggiornamento del modello modifica la rappresentazione e la classificazione utilizzate per assegnare le etichette, quindi la stessa foto può oltrepassare confini semantici o...
