Che cos'è la disaggregazione Prefill-Decode e perché cambia la gestione degli LLM?
La disaggregazione di prefill e decode separa l'elaborazione del prompt dalla generazione dei token, così ogni fase dell'LLM può utilizzare worker, pianificazioni e piani di capacità diversi.
Un prompt RAG lungo richiede un grande picco di calcolo prima del primo token, mentre il decoding esegue successivamente molte iterazioni più piccole e sensibili alla larghezza di banda della memoria. Eseguire entrambe le fasi su una sola GPU è semplice, ma consente ai prefill lunghi di interrompere le conversazioni attive. La disaggregazione sposta la richiesta e il relativo stato KV tra pool diversi, scambiando un maggiore costo di coordinamento e trasferimento con un controllo indipendente sulla latenza del primo token e su quella per token.
Prefill e decode hanno profili di risorse diversi
Il prefill elabora tutti i token del prompt in parallelo e crea la cache KV, producendo un picco intensivo in termini di calcolo la cui durata cresce con la lunghezza del prompt. Il decode legge ripetutamente i pesi del modello e lo stato KV accumulato per generare uno o pochi nuovi token.
DistServe identifica l'interferenza tra prefill e decode quando entrambe le fasi condividono le GPU e associa il prefill al tempo fino al primo token, mentre il decode determina il tempo per token generato. Separarle consente allo scheduler di proteggere ciascun obiettivo in modo indipendente. Questa distinzione resta visibile anche durante i successivi test in ambito domestico.
La disaggregazione non è il normale parallelismo del modello. Lo stesso modello può esistere in entrambi i pool, mentre le richieste si spostano tra fasi funzionali anziché tra i layer di un'unica propagazione in avanti. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.
Il trasferimento KV collega i due pool di worker
Dopo il prefill, il sistema deve rendere disponibile la cache KV della richiesta a un worker di decode. Può trasferire i tensori tramite PCIe o una rete fabric, utilizzare la memoria condivisa oppure posizionare i worker in modo da ridurre al minimo il costo dello spostamento.
Splitwise studia il servizio specifico per fase con macchine e pianificazioni dedicate a ciascuna fase, mostrando perché l'allocazione dell'hardware può adattarsi alle diverse caratteristiche computazionali del lavoro sui prompt e sui token. L'accodamento e lo spostamento dello stato diventano parte del percorso di servizio. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.
Il pool di decode non può avviarsi finché non dispone di uno stato KV coerente e dei metadati della richiesta. I contesti estesi aumentano i byte da trasferire, quindi una suddivisione delle fasi nominalmente più veloce può risultare peggiore dell'esecuzione collocata su una piccola rete domestica.
La scalabilità indipendente cambia la pianificazione della capacità
Pool separati possono aggiungere capacità di prefill per i picchi causati da documenti lunghi senza espandere proporzionalmente la capacità di decode, oppure proteggere il decoding vocale mentre la sintesi in background utilizza i worker di prompt. Il controllo degli accessi può gestire due code e due budget di latenza. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.
Mooncake descrive un coordinamento della cache KV che tratta lo spostamento e l'archiviazione della cache KV come aspetti fondamentali del servizio. L'architettura mostra che la disaggregazione sposta il collo di bottiglia dalla pura pianificazione della GPU verso il trasferimento dello stato e il coordinamento della cache.
Il limite di guasto è una scala o una larghezza di banda insufficienti. Una o due GPU domestiche potrebbero non avere dispositivi liberi per la specializzazione, mentre la duplicazione dei pesi del modello e il trasferimento KV possono consumare più memoria e latenza dell'interferenza che si intende eliminare.
Confronta i budget delle fasi in configurazione collocata e disaggregata
Misura i token del prompt al secondo, il tempo fino al primo token, il tempo per token generato, i byte KV trasferiti, il tempo di trasferimento, l'attesa in coda, la duplicazione della memoria del modello, il consumo energetico e il recupero dagli errori per prompt brevi, lunghi e misti. Questa dipendenza deve rimanere esplicita nell'interfaccia finale.
Usa il prefill a blocchi come alternativa collocata. Testa il prefill a blocchi prima di aggiungere un secondo pool, quindi confronta tracce di arrivo identiche in entrambe le architetture. Il risultato deve quindi essere verificato rispetto alle evidenze originali.
Adotta la disaggregazione solo quando l'interferenza tra le fasi è misurata e il percorso di trasferimento preserva entrambi gli obiettivi di latenza. Su un piccolo server, una pianificazione collocata con blocchi di prefill limitati può offrire lo stesso risultato per l'utente con un minore spostamento di stato.
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...
