Perché l’elaborazione dei prompt può superare la generazione locale di token AI?

Il processamento del prompt può superare la generazione dei token perché un acceleratore valuta molti token di input in parallelo, mentre deve decodificare i token di output in sequenza.

Una dashboard AI domestica può indicare centinaia o migliaia di token del prompt al secondo, mentre l’output trasmesso in streaming arriva a una velocità molto inferiore. Questi numeri descrivono fasi di esecuzione diverse, non misurazioni contraddittorie. Il prefill elabora il contesto fornito come un blocco e costruisce lo stato di attenzione, mentre il decode esegue ripetutamente il modello per accettare un nuovo token alla volta. Il divario dipende dalla lunghezza del prompt, dalle dimensioni del modello, dalla larghezza di banda della memoria, dal batching, dall’organizzazione della cache e dall’eventuale condivisione dello stesso acceleratore con richieste in background.

Prefill e decode risolvono problemi computazionali diversi

Il processamento del prompt, spesso chiamato prefill, valuta la sequenza di input e crea lo stato KV necessario per la generazione successiva. Il decode inizia solo dopo che questo stato iniziale è disponibile ed estende la sequenza un token alla volta.

La ricerca sul serving degli LLM descrive il prefill limitato dal calcolo e il decode limitato dalla larghezza di banda della memoria come fasi distinte, caratterizzate da comportamenti hardware diversi.

Lo stesso modello può quindi produrre un valore elevato di throughput del prefill e un valore molto più basso per i token di output senza che ci sia alcun malfunzionamento. Ogni metrica conta i token che attraversano un percorso di esecuzione diverso.

I token del prompt possono essere valutati in grandi matrici parallele

Durante il prefill, molte posizioni delle query sono disponibili contemporaneamente. Le moltiplicazioni di matrici possono combinare il lavoro lungo la sequenza, il batch, le teste di attenzione e le dimensioni nascoste, fornendo all’acceleratore un numero sufficiente di operazioni parallele per mantenerlo occupato.

FlashAttention riduce il sovraccarico dell’attenzione tramite il calcolo dell’attenzione a blocchi, evitando di materializzare ripetutamente l’intera matrice di attenzione nella lenta memoria del dispositivo.

I prompt più lunghi aumentano il lavoro totale del prefill, ma possono anche migliorare l’utilizzo delle risorse di calcolo finché la capacità della memoria, i limiti dei kernel o la complessità dell’attenzione non diventano il fattore dominante.

Si tratta del throughput sull’intero blocco di input, non dell’indicazione che il server potrebbe emettere ogni secondo lo stesso numero di token di output indipendenti.

Il decode non può finalizzare il token successivo prima di quello corrente

La generazione autoregressiva campiona o seleziona un token, lo aggiunge alla sequenza e poi esegue un altro passaggio del modello condizionato sul risultato accettato. Il token successivo accettato non è noto in anticipo.

DistServe separa le due fasi perché le iterazioni di decode accedono ripetutamente ai pesi del modello e allo stato KV attivo, producendo al contempo solo una piccola quantità di nuovo output per sequenza.

Il batching di più utenti può parallelizzare diverse sequenze di decode, ma una singola conversazione procede comunque attraverso una catena di decisioni sui token dipendenti l’una dall’altra.

Il decode speculativo può verificare insieme diverse ipotesi generate in anticipo, ma il decode ordinario rimane seriale quando nessun candidato viene accettato in anticipo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Un throughput elevato del prompt può comunque comportare una lunga attesa prima del primo token

I token al secondo si calcolano dividendo il lavoro completato sul prompt per le dimensioni del prompt. Un contesto molto lungo può avere un throughput impressionante e richiedere comunque diversi secondi prima che compaia il primo token generato.

ZimaSpace separa il caricamento, la valutazione del prompt e la generazione nella sua analisi delle fasi della latenza AI. Un modello già caricato elimina il ritardo dovuto al ricaricamento, ma non il costo della valutazione di un prompt di grandi dimensioni.

Il tempo al primo token è quindi la misura interattiva più indicata per il prefill. I token del prompt al secondo sono utili per confrontare l’efficienza con cui il runtime elabora input di lunghezze diverse.

I prefill lunghi possono rallentare gli utenti che stanno già effettuando il decode

Un prompt documentale impegnativo dal punto di vista computazionale può utilizzare lo stesso acceleratore mentre un altro utente riceve token in streaming. Se il runtime combina entrambi i carichi di lavoro senza un controllo adeguato, il prefill di grandi dimensioni può allungare le iterazioni di decode.

DistServe segnala una forte interferenza tra prefill e decode quando le due fasi vengono collocate ed eseguite insieme.

Il server può comunque mostrare un utilizzo aggregato elevato, mentre la chat attiva sperimenta intervalli più lunghi tra un token e l’altro. Il throughput e la fluidità percepita dall’utente possono quindi muoversi in direzioni opposte.

Worker separati, pianificazione consapevole della fase o opportunità di decode riservate possono proteggere l’output interattivo quando l’hardware e il runtime li supportano.

Il chunking sacrifica parte dell’efficienza del prefill per migliorare la reattività

Un runtime può suddividere un prompt lungo in blocchi più piccoli e alternare questi blocchi al lavoro di decode. Il prompt richiede più turni di pianificazione, ma nessun singolo prefill monopolizza una singola iterazione molto lunga.

Sarathi-Serve utilizza i prefill suddivisi in blocchi per ridurre l’interferenza mantenendo al contempo utili opportunità di batching.

La dimensione ottimale dei blocchi dipende dalla lunghezza dei prompt, dall’architettura del modello, dalla capacità dell’acceleratore e dall’obiettivo di latenza per le conversazioni attive.

Misura separatamente il tempo di processamento del prompt, il tempo al primo token, il tempo tra i token e i token di output al secondo. La fase con il throughput nominale più basso non è automaticamente quella che causa l’attesa più lunga per l’utente.