Cos'è il continuous batching negli LLM?

Il continuous batching (o in-flight batching) è la tecnica di scheduling con cui un motore di inferenza per LLM raggruppa più richieste sullo stesso hardware liberando lo slot di ognuna appena finisce di generare la sua risposta, invece di aspettare che finiscano tutte le richieste del gruppo iniziale. Nel batching statico, l'approccio precedente, un blocco di richieste viene processato insieme e lo slot resta occupato fino al completamento di tutte, anche quando una richiesta è molto più corta delle altre: quella capacità resta sprecata in attesa, senza servire nessuno. Qui il termine "batching" riguarda lo scheduling delle richieste di inferenza in produzione, un problema distinto dal batch processing nell'ETL dei dati, che descrive l'elaborazione offline dei dati secondo una pianificazione a blocchi: sono due concetti con lo stesso nome ma domini completamente diversi. Il continuous batching nasce nel paper Orca (OSDI 2022), è stato reso mainstream da vLLM nel 2023 e poi da DeepSpeed-FastGen all'inizio del 2024, oggi lo standard implicito di quasi ogni motore self-hosted.

Come funziona lo scheduling a livello di iterazione

Il motore ricalcola la composizione del batch a ogni singolo passo di decodifica (token per token), non una volta sola all'inizio. Appena una sequenza raggiunge il token di fine risposta, il suo posto viene riassegnato immediatamente a una richiesta in coda, senza aspettare il resto del gruppo. Questo funziona solo se la memoria della KV cache di ogni richiesta può essere allocata e liberata in modo dinamico invece che riservata in blocco all'inizio: è esattamente il compito di PagedAttention, che gestisce quella memoria a pagine assegnate appena servono, con uno spreco sotto il 4% come riportato nel paper di vLLM, contro le decine di punti percentuali dell'allocazione statica, ed è la ragione per cui vLLM ha reso il continuous batching praticabile su larga scala.

Perché il throughput aumenta senza cambiare hardware

Il vantaggio non viene da GPU più potenti, ma da GPU meno inattive: nel batching statico ogni slot libero durante l'attesa delle richieste più lunghe è capacità di calcolo pagata e non usata. Il continuous batching riempie quei vuoti in tempo reale, il che si traduce in più richieste servite per secondo a parità di scheda video. Il paper DeepSpeed-FastGen e la letteratura successiva a Orca documentano guadagni di throughput di un ordine di grandezza rispetto al batching statico nelle stesse condizioni di latenza, e vLLM ha reso questo comportamento lo standard de facto dell'ecosistema open source.

Un esempio enterprise

Un servizio di assistenza clienti che risponde sia a "qual è il mio saldo" (poche parole) sia a "riassumi questo contratto di dieci pagine e segnala le clausole a rischio" (migliaia di token) è il caso da manuale. Con il batching statico, ogni richiesta breve resterebbe bloccata nello stesso slot fino a quando anche la richiesta più lunga del gruppo non termina, sprecando capacità GPU per l'intera differenza di durata. Con il continuous batching, la richiesta breve libera lo slot in pochi secondi e quello slot passa immediatamente al prossimo utente in coda, mentre la richiesta lunga continua a girare sul proprio slot indipendentemente dalle altre.

Perché conta per chi decide

Per un'azienda che valuta un motore di inference self-hosted, il continuous batching è spesso la singola ottimizzazione con il miglior rapporto costo-beneficio: non richiede né hardware aggiuntivo né un modello diverso, e nella pratica corrente vLLM, TensorRT-LLM (che lo chiama "in-flight batching") e SGLang lo implementano di default. Il punto da verificare in fase di scelta non è se una piattaforma lo supporta, ma quanto bene gestisce i casi con lunghezze di risposta molto variabili, che è esattamente lo scenario in cui questa tecnica fa la differenza economica maggiore.