AWS separa prefill e decode su SageMaker HyperPod per evitare code causate da prompt lunghi

AWS introduce Disaggregated Prefill and Decode (DPD) su SageMaker HyperPod: prefill e decode corrono su pool di GPU distinti, collegati via Elastic Fabric Adapter con RDMA, per impedire che prompt lunghi rallentino le generazioni in corso¹. Obiettivo dichiarato: rendere più prevedibile la tail latency rispetto al chunked prefill¹.

Le due fasi dell’inferenza LLM hanno profili opposti. Il prefill è compute‑bound: elabora l’intero prompt in parallelo e crea la cache key‑value. Il decode è memory‑bound: produce un token alla volta, legge spesso i pesi e accede a una cache KV che cresce a ogni step¹. Quando condividono la stessa GPU, un contesto lungo può degradare la latenza dei token già in uscita¹.

DPD separa questi carichi su pool diversi e scambia i dati tra le fasi via EFA/RDMA¹. La disaggregazione consente di applicare strategie di parallelismo su misura e di ottimizzare in modo indipendente time to first token (TTFT) e inter‑token latency (ITL)¹.

Sotto concorrenza, l’effetto è netto: un prefill con contesto lungo non blocca i decode già avviati, perché non competono più per le stesse GPU¹. Il chunked prefill, invece, spezza il prompt in parti ma lascia prefill e decode sullo stesso nodo; le due fasi continuano a contendersi compute e memoria. Risultato: anche con il chunking, un prompt molto lungo può allungare la coda dei token in uscita perché i batch di prefill interrompono o rallentano i cicli di decode sullo stesso acceleratore¹.

Il confronto con le ottimizzazioni intra‑nodo chiarisce il perimetro. vLLM mira all’efficienza del singolo nodo con tecniche come continuous batching e PagedAttention¹. DPD attacca un problema diverso: disaccoppia le fasi e le distribuisce in rete su pool distinti, per rimuovere l’interferenza tra prefill e decode¹. Le due strade sono complementari: una aumenta l’utilizzo locale, l’altra isola i carichi delle fasi¹.

Per chi gestisce workload con prompt di lunghezze variabili, cambia anche la telemetria. Ha senso osservare TTFT e ITL separatamente e impostare politiche diverse per i due pool, perché la capacità che satura il prefill non è la stessa che limita il decode¹. Affidarsi solo al chunked prefill mantiene incertezza quando i contesti si allungano; la separazione dei pool rende più stabile il comportamento sotto carico¹.

Takeaway operativo: dimensionare due gruppi di GPU distinti per prefill e decode, collegati a bassa latenza, e monitorare TTFT e ITL come metriche separate. Regolare la capacità dei pool in base alla pressione osservata su ciascuna fase, così da contenere la tail latency senza sacrificare throughput complessivo¹.