Prefill vs. Decode

Cosa succede in ciascuna fase

Durante il prefill il modello legge l'intero prompt in una volta sola. È un calcolo matrice-matrice grande e fortemente parallelo, che satura le unità di calcolo dell'hardware. Il risultato è la KV cache: le chiavi e i valori di attention per ogni token del prompt, calcolati una volta e riutilizzati per il resto della richiesta. Il prefill termina quando viene prodotto il primo token di output. Per questo è la lunghezza del prompt a determinare il tempo al primo token.

Durante il decode il modello genera un token, lo aggiunge al contesto e ripete. Ogni passo è un'operazione matrice-vettore sottile che riutilizza lo stato in cache, ma per ogni singolo token deve leggere dalla memoria i pesi del modello. Questa fase è memory-bound: a determinare la latenza è la velocità con cui pesi e dati della cache si spostano dalla memoria, non l'aritmetica.

Perché la distinzione è importante

Le due fasi chiedono hardware diverso. Il prefill premia la potenza di calcolo pura, il decode premia la larghezza di banda della memoria e lo spostamento efficiente dei dati. La guida tecnica di Databricks lo dice in termini pratici: la larghezza di banda della memoria prevede la velocità di generazione dei token meglio della potenza di calcolo di picco. Un chip con FLOPS spettacolari può comunque generare token lentamente se resta in attesa della memoria.

È anche per questo che il serving su GPU si affida così tanto al batching: distribuire ogni caricamento dei pesi su molte richieste simultanee recupera utilizzo durante il decode, al prezzo della velocità per utente. Le architetture progettate attorno allo spostamento dei dati, come l'hardware dataflow che usiamo, affrontano invece direttamente il collo di bottiglia del decode e mantengono un utilizzo elevato anche con batch piccoli.

Leggere le metriche con questa lente

Le prestazioni del prefill si vedono nel TTFT, quelle del decode nella latenza inter-token e nei token al secondo di output. La letteratura scientifica aggiunge una precisazione: la divisione tra compute-bound e memory-bound vale per i batch size comuni nel serving, mentre con batch molto grandi anche il decode può diventare compute-bound. La tendenza del settore verso il serving disaggregato, con prefill e decode su pool di hardware separati e specializzati, esiste proprio perché le due fasi sono così diverse.