Servizio di precompilazione e decodifica disaggregato
Un'architettura di servizio che divide l'inferenza del modello linguistico di grandi dimensioni in due fasi separate (precompilazione e decodifica) e le esegue su diversi pool di GPU.
Panoramica
It matters because these two phases have opposite hardware appetites, and forcing them onto the same machines wastes capacity and hurts latency.
Immersione profonda
Quando un LLM risponde, funziona in due fasi. La precompilazione legge l'intero prompt in una sola volta e crea la cache dei valori-chiave (KV); si tratta di un grande burst parallelo, legato al calcolo, che satura le unità matematiche della GPU. Decode quindi genera token uno alla volta, ogni passaggio legge l'intera cache KV: un rivolo limitato alla larghezza di banda della memoria e leggermente computazionale. Se eseguiti insieme, una lunga precompilazione blocca la decodifica di tutti (blocco head-of-line) e l'unione dei due crea interferenze. La disaggregazione inserisce la precompilazione su un pool GPU e la decodifica su un altro, trasferendo la cache KV tra di loro tramite interconnessioni veloci come NVLink o InfiniBand. Ogni pool viene ottimizzato e ridimensionato in modo indipendente, migliorando il goodput, attenuando la latenza della coda e consentendo agli operatori di raggiungere contemporaneamente obiettivi rigorosi di time-to-first-token e time-per-output-token.
Approfondimento tecnico
Le due fasi differiscono per il collo di bottiglia. Prefill elabora tutti i token di prompt in parallelo, quindi i suoi FLOP si adattano alla lunghezza del prompt e massimizza i core tensoriali. La decodifica è autoregressiva: ogni nuovo token necessita di un passaggio in avanti che rilegge l'intera cache KV da HBM, quindi il throughput è controllato dalla larghezza di banda della memoria, non dal calcolo. La disaggregazione sfrutta questo aspetto dimensionando, raggruppando e persino scegliendo un parallelismo diverso per ciascun pool, quindi inviando la cache KV dai lavoratori di precompilazione ai lavoratori di decodifica.
Impatto strategico
Costo e budget
Le decisioni relative all'architettura determinano prestazioni e costi operativi per anni.
Decisioni più chiare
La formazione tecnica aiuta i team a scegliere lo stack giusto, non solo quello più nuovo.
Controllo di qualità
Migliori scelte ingegneristiche riducono gli incidenti legati all’affidabilità nella produzione.
Il futuro della precompilazione e della decodifica disaggregate
Aspettatevi che la disaggregazione diventi un'impostazione predefinita negli stack di produzione. Sistemi come DistServe, Splitwise e Mooncake lo hanno reso popolare e vLLM e NVIDIA Dynamo ora forniscono modalità disaggregate. La ricerca sta spingendo verso l'ottimizzazione del trasferimento della cache KV, il pooling e il riutilizzo della cache tra le richieste, il ribilanciamento dinamico dei rapporti di precompilazione/decodifica in caso di traffico variabile e una più stretta integrazione con la memorizzazione nella cache dei prefissi e la precompilazione in blocchi. Man mano che le finestre di contesto diventano milioni di token, separare queste fasi diventa sempre più essenziale per un servizio conveniente e a bassa latenza.
Implementazione nel mondo reale
Un assistente chat instrada richieste di documenti lunghi a un cluster di precompilazione ad alto carico di calcolo, quindi trasmette le risposte da un cluster di decodifica ottimizzato per la memoria per mantenere fluida la latenza di digitazione.
NVIDIA Dynamo e vLLM consentono agli operatori di implementare gruppi di lavoro di precompilazione e decodifica separati in modo che una raffica di richieste lunghe non congeli le generazioni in corso.
Mooncake (utilizzato da Kimi di Moonshot AI) disaggrega la precompilazione e la decodifica e aggiunge un pool di cache KV distribuito per ridurre il ricalcolo ridondante dei prompt su larga scala.
Un servizio di completamento del codice dedica un piccolo pool di precompilazione per brevi richieste e un ampio pool di decodifica, poiché la maggior parte dei costi deriva dallo streaming di molti token di output.
Rischi e guardrail
L'ottimizzazione di un benchmark può nascondere debolezze di sistema più ampie.
I costi delle infrastrutture e della manutenzione sono spesso sottostimati.
Le lacune in termini di sicurezza e osservabilità possono aumentare man mano che i sistemi diventano più complessi.
Tabella di marcia per l'implementazione
Definire obiettivi di latenza, qualità e costi prima dell'implementazione.
Benchmark in condizioni di carico e dati realistiche.
Monitoraggio dello strumento per errori, deriva e impatto sull'utente.
Preparare percorsi di rollback e risposta agli incidenti prima della scalabilità.
Continua a esplorare
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the Disaggregated Prefill and Decode Serving quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Prossima guida
Kserve e Model Serving su Kubernetes
Domande frequenti
What is Disaggregated Prefill and Decode Serving?
Un'architettura di servizio che divide l'inferenza del modello linguistico di grandi dimensioni in due fasi separate (precompilazione e decodifica) e le esegue su diversi pool di GPU. È importante perché queste due fasi hanno esigenze hardware opposte e forzarle sulle stesse macchine spreca capacità e danneggia la latenza.
Qual è il motivo hardware principale per separare la precompilazione e la decodifica su diversi pool di GPU?
La precompilazione elabora l'intero prompt in parallelo e satura il calcolo, mentre la decodifica legge la cache KV a ogni passaggio ed è limitata dalla larghezza di banda della memoria: esigenze opposte che giustificano pool separati e ottimizzati in modo indipendente.
Quale struttura di dati deve essere trasferita dai lavoratori di precompilazione ai lavoratori di decodifica?
La precompilazione crea la cache KV per il prompt; la decodifica necessita che la cache continui a essere generata, quindi la cache viene inviata tramite un'interconnessione veloce al pool di decodifica.
Quale problema riduce specificamente la disaggregazione in una configurazione con GPU condivisa?
Sulle GPU condivise un lungo burst di precompilazione può bloccare i passaggi di decodifica in corso; separarli previene tale interferenza e stabilizza la latenza della coda.
Perché la precompilazione può essere raggruppata in batch in modo aggressivo ma la decodifica beneficia di una diversa ottimizzazione?
La precompilazione elabora tutti i token prompt insieme, quindi i batch più grandi alimentano bene i core tensoriali; la decodifica genera un token alla volta ed è controllata dalla memoria, quindi si ridimensiona in modo diverso.
Quali interconnessioni vengono in genere utilizzate per spostare la cache KV tra pool disaggregati?
Sono necessari collegamenti a larghezza di banda elevata e bassa latenza come NVLink (intra-nodo) e InfiniBand (inter-nodo) in modo che il trasferimento della cache KV non diventi il nuovo collo di bottiglia.