Cos'è il batching continuo e quando è importante per un server AI domestico?
Il batching continuo pianifica le sequenze attive a ogni iterazione di decodifica, consentendo alle nuove richieste di unirsi e a quelle completate di uscire senza attendere un batch fisso.
Una famiglia può inviare a un unico modello locale una richiesta vocale, una domanda su un documento e un prompt di programmazione nell'arco di pochi secondi. La lunghezza dei prompt e degli output varia, quindi un batch fisso spreca slot mentre le risposte più brevi attendono quella più lunga. Il batching continuo ricostruisce continuamente il lavoro utile attorno al modello, ma è vantaggioso solo quando le richieste si sovrappongono e il server dispone di memoria e margine di pianificazione sufficienti.
La pianificazione a livello di iterazione è l'idea fondamentale
La decodifica autoregressiva fa avanzare ogni sequenza attiva di circa un token per iterazione del modello. Uno scheduler continuo seleziona le sequenze eseguibili per l'iterazione successiva, accetta nuove richieste quando si libera capacità e rimuove immediatamente le sequenze al completamento.
Il paper Orca ha introdotto la pianificazione a livello di iterazione alla granularità delle iterazioni del modello, anziché delle richieste complete. Il batching selettivo raggruppa quindi le operazioni compatibili, lasciando separato il lavoro specifico di ciascuna richiesta. Questa distinzione resta visibile durante i successivi test domestici.
Non è la stessa cosa dello streaming dei token verso un utente. Lo streaming modifica il momento in cui viene consegnato l'output; il batching continuo modifica il modo in cui diverse richieste condividono internamente l'esecuzione del modello. Il risultato intermedio deve restare ispezionabile prima che l'automazione proceda.
Differisce dal batching statico e da quello basato su finestre di arrivo
Il batching statico blocca insieme un gruppo fisso e spesso aggiunge padding alle sequenze più brevi finché non termina quella più lunga. Il batching basato su una finestra di arrivo, o batching dinamico, attende brevemente per raccogliere le richieste, ma può comunque eseguire il gruppo risultante come un'unica unità. Il batching continuo riconsidera la composizione a ogni iterazione.
Il paper vLLM abbina la pianificazione a livello di iterazione alla gestione paginata della KV cache, così i set di sequenze variabili non richiedono prenotazioni contigue rigide. La pianificazione e la gestione della memoria sono funzionalità complementari, non intercambiabili. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.
Un numero maggiore di sequenze attive ammortizza le letture dei pesi e può migliorare il throughput, ma ogni richiesta compete per la memoria KV e per le risorse di calcolo. Un batch attivo più grande non è automaticamente migliore per latenza o imparzialità. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.
È la concorrenza, non solo la dimensione del modello, a creare il vantaggio
Un singolo utente interattivo può ottenere pochi vantaggi, perché non è disponibile una seconda richiesta per sfruttare la capacità inutilizzata. I benefici emergono con utenti domestici sovrapposti, rami di agenti, riepiloghi in background o diverse applicazioni che condividono un modello residente.
Sarathi-Serve analizza come l'interferenza del prefill possa compromettere la latenza della decodifica e utilizza prefill suddivisi in blocchi per rendere più prevedibile la pianificazione mista. Il risultato mostra che la politica di ammissione è importante quanto l'etichetta di batching continuo. Questa dipendenza dovrebbe restare esplicita nell'interfaccia finale.
Il limite critico è rappresentato dalla pressione sulla memoria o da un'ammissione aggressiva che fa aumentare il tempo per token di output e la latenza di coda. Quando la cache KV si riempie, il preemption, lo swapping o il ricalcolo possono annullare i guadagni di throughput e rendere instabile il servizio interattivo.
Determina se la domanda concorrente lo giustifica
Riproduci una, due, quattro e otto richieste sovrapposte con lunghezze realistiche di prompt e output. Registra il throughput, il tempo al primo token, il tempo per token di output, il tempo di completamento p95, l'utilizzo della KV, i preemption e l'imparzialità per classe di richiesta.
Confronta il comportamento con i divari del batching continuo. Ripeti il test con il batching continuo disabilitato o con una configurazione di riferimento a batch fisso, mantenendo invariati modello, quantizzazione, limiti di contesto e hardware. Il risultato deve quindi essere verificato rispetto alle evidenze originali.
Utilizza il batching continuo quando la sovrapposizione produce aumenti sostanziali di throughput o capacità senza violare la latenza di coda interattiva. Se le richieste si sovrappongono raramente, dai priorità alla permanenza del modello in memoria e alla latenza di avvio prima di aggiungere complessità allo scheduler. Questa distinzione resta visibile durante i successivi test domestici.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Che cos’è la deriva degli embedding e quando è necessario ricostruire un indice di ricerca privato?
Decodifica il modello, il preprocessing, il corpus e il drift delle query; distingui il monitoraggio dall'incompatibilità e decidi quando è necessario ricostruire un indice...
Che cos'è la compatibilità dei tokenizzatori e perché può compromettere il passaggio da un modello all'altro?
Decodifica l'identità del vocabolario, la semantica dei token speciali, i modelli di chat, i token memorizzati nella cache, gli adattatori e i controlli di...
Che cos'è la permanenza del modello e quando un servizio di IA locale dovrebbe mantenere i pesi caricati?
Comprendi la permanenza dei pesi, i livelli della cache, gli avvii a freddo, l'espulsione, il multiplexing, la pressione sulla memoria e quando un servizio...
