DOPD: A Dynamic PD-Disaggregation Architecture for Maximizing Goodput in LLM Inference Serving

Each language version is independently generated for its own context, not a direct translation.

Immagina di dover gestire un ristorante di lusso molto affollato, dove i clienti arrivano con richieste molto diverse: alcuni vogliono solo un caffè veloce (richieste brevi), altri ordinano un menu degustazione di 20 portate (richieste lunghe).

In questo ristorante, ci sono due tipi di chef:

Lo Chef "Menu" (Prefill): È un genio della cucina che prepara il piano del pasto e gli ingredienti iniziali. Lavora velocemente ma deve concentrarsi molto sulla pianificazione.
Lo Chef "Portata" (Decoding): È lo chef che cuoce e serve le singole portate una alla volta. Deve essere costante e veloce nel servire, ma non deve pianificare il menu.

Il Problema: Il Caos nella Cucina

Fino a poco tempo fa, i ristoranti (i sistemi di Intelligenza Artificiale) avevano una sola cucina dove tutti gli chef facevano tutto. Il problema? Quando lo Chef "Menu" era impegnato a preparare un piano complesso, lo Chef "Portata" rimaneva fermo ad aspettare, e viceversa. Era un disastro: la cucina era piena di gente che non faceva nulla mentre altri erano schiacciati dal lavoro.

Per risolvere questo, hanno inventato una cucina "disaccoppiata": una zona solo per i "Menu" e una zona solo per le "Portate". Sembra perfetto, ma c'è un nuovo problema: come bilanciare il numero di chef nelle due zone?

Se hai troppi chef "Menu" e pochi chef "Portata", i piani sono pronti ma nessuno li serve. Gli chef "Portata" restano fermi (spreco di soldi).
Se hai pochi chef "Menu" e troppi chef "Portata", gli chef "Portata" devono aspettare ore per ricevere il prossimo ordine. I clienti si arrabbiano (lentezza).

Peggio ancora, le richieste degli utenti cambiano continuamente: a volte arrivano 100 persone che vogliono solo un caffè, a volte 10 persone che vogliono un menu lunghissimo. Un sistema statico (che non cambia mai il numero di chef) non può adattarsi a questo caos.

La Soluzione: DOPD (Il Manager Intelligente)

Gli autori di questo articolo hanno creato DOPD, un sistema che funziona come un Manager di Ristorante Super Intelligente che guarda in tempo reale cosa sta succedendo e aggiusta la cucina istantaneamente.

Ecco come funziona, passo dopo passo:

1. Il Manager che Indovina il Futuro (Predizione)

Il Manager non aspetta che la cucina si riempia per agire. Usa un "oracolo" (un algoritmo matematico chiamato ARIMA) che guarda la storia degli ultimi ordini e prevede cosa succederà nei prossimi minuti.

Metafora: È come un metereologo che vede arrivare una tempesta di clienti e prepara i tavoli prima ancora che piova.

2. Il Bilanciere Perfetto (Calcolo del Rapporto Ottimale)

Il Manager calcola esattamente quanti chef "Menu" e quanti chef "Portata" servono in quel preciso momento.

Se arrivano molti ordini brevi, serve più gente a cucinare le portate.
Se arrivano ordini lunghi, serve più gente a preparare i menu.
Il sistema aggiunge o toglie chef (GPU) in modo dinamico per mantenere il rapporto perfetto, così nessuno rimane mai inattivo e nessuno è sovraccarico.

3. L'Organizzatore di Ordini (Scheduling Intelligente)

C'è un altro trucco. A volte, ordinare un caffè (richiesta brevissima) attraverso il sistema complesso di due cucine separate richiede più tempo del necessario solo per spostare il caffè da una stanza all'altra.
Il Manager DOPD è così intelligente che dice: "Ehi, questa richiesta è così piccola che non vale la pena mandarla allo chef 'Menu' esterno. Fallo qui, nella cucina principale, insieme alle altre portate!".

Metafora: È come se il cameriere dicesse: "Per un bicchiere d'acqua, non chiamo il barista specializzato, te lo porto io direttamente dal bancone". Questo evita attese inutili.

I Risultati: Perché è Fantastico?

Grazie a questo sistema, il ristorante (il servizio di Intelligenza Artificiale) ottiene risultati incredibili:

Più clienti serviti: Riesce a gestire il 50% in più di clienti rispetto ai metodi precedenti.
Nessuna attesa: I clienti ricevono la prima parola (o il primo piatto) molto più velocemente.
Risparmio: Non spreca soldi in chef (schede video/GPU) che stanno fermi a guardare il muro.

In Sintesi

DOPD è come un direttore d'orchestra che non segue uno spartito fisso, ma ascolta la musica mentre viene suonata e cambia il numero di violini o trombe in tempo reale per garantire che la melodia sia sempre perfetta, veloce e senza errori, anche se il pubblico cambia idea ogni secondo.

È un passo avanti enorme per rendere le Intelligenze Artificiali più veloci, più economiche e più pronte a servire milioni di utenti contemporaneamente.

Each language version is independently generated for its own context, not a direct translation.

1. Il Problema

L'inferenza dei Modelli Linguistici su Grande Scala (LLM) presenta due fasi computazionali distinte con caratteristiche opposte:

Prefill (P): Intensiva dal punto di vista computazionale (compute-bound), elabora l'input dell'utente.
Decoding (D): Intensiva dal punto di vista della memoria (memory-bound), genera i token di output uno alla volta.

Le architetture moderne adottano il PD-Disaggregation (separazione Prefill/Decoding) su GPU diverse per mitigare le interferenze tra queste due fasi. Tuttavia, questo approccio introduce sfide critiche:

Squilibrio Produttore-Consumatore: La natura eterogenea dei carichi di lavoro LLM (lunghezze di input/output variabili e imprevedibili) causa spesso uno squilibrio tra la capacità di produzione delle istanze P e quella di consumo delle istanze D.
Configurazione Statica Subottimale: Le implementazioni attuali utilizzano rapporti P/D statici. Un rapporto errato porta a:
- Sovra-provisioning: GPU inattive e spreco di risorse.
- Sotto-provisioning: Violazioni degli SLO (Service-Level Objectives) e degradazione dell'esperienza utente.
Gestione delle Richieste a Lunghezza Mista: La miscelazione di richieste brevi e lunghe in un'unica configurazione statica crea colli di bottiglia. Le richieste brevi soffrono della latenza di trasferimento del KV-cache tra istanze P e D, mentre quelle lunghe richiedono più risorse di prefill.

2. Metodologia: DOPD

Gli autori propongono DOPD (Dynamic Optimal Prefill/Decoding), un sistema di inferenza dinamico che adatta in tempo reale l'allocazione delle risorse. L'architettura si basa su cinque componenti principali:

A. Calcolo del Rapporto P/D Ottimale

DOPD deriva una formula analitica per determinare il rapporto ottimale tra istanze Prefill ( $n_p$ ) e Decoding ( $n_d$ ) basato sul carico di lavoro previsto.

Obiettivo: Massimizzare la concorrenza aggregata supportata dalle istanze D minimizzando i tempi di inattività delle istanze P.
Fattori considerati: Capacità di memoria GPU, larghezza di banda, dimensioni del modello, e le statistiche del carico (lunghezza media input/output, varianza).
Formula chiave: Il rapporto è calcolato per bilanciare il tempo necessario a un'istanza D per completare la decodifica di una richiesta con il tempo necessario a un'istanza P per generare una nuova richiesta prefillata, garantendo che la produzione eguagli il consumo ( $n_p \times \text{capacità\_prod} = n_d \times \text{capacità\_cons}$ ).

B. Previsione del Carico di Lavoro

Per gestire la non stazionarietà dei carichi LLM:

Utilizza un modello ARIMA (AutoRegressive Integrated Moving Average) per prevedere le lunghezze medie future delle sequenze e la concorrenza.
Applica un fattore di correzione moltiplicativo basato sulle misurazioni recenti per attenuare i bias sistematici tra previsioni e valori reali, mantenendo l'errore entro limiti ridotti.

C. Scheduling Intelligente e Consapevole della Lunghezza

Per mitigare gli effetti delle richieste a lunghezza mista:

Scheduling delle richieste P: Le richieste brevi vengono raggruppate (batched) in base a una soglia di lunghezza prevista o a un timeout, mentre le richieste lunghe vengono inviate immediatamente per evitare ritardi.
Aggregazione PD per richieste ultra-brevi: Le richieste con prefill computazionalmente trascurabile vengono eseguite direttamente sulle istanze D (in-place), evitando il trasferimento del KV-cache e riducendo la latenza TTFT (Time-To-First-Token).
Algoritmo di Knapsack: Utilizza una logica euristica per massimizzare l'utilizzo del batch senza superare le soglie di latenza.

D. Gestione Dinamica delle Istanze (PD Manager)

Il modulo PD Manager monitora le metriche in tempo reale (utilizzo GPU, profondità della coda, occupazione KV-cache) e:

Ricalcola il rapporto P/D ottimale in base alle previsioni.
Esegue il scaling elastico (aggiunta/rimozione) delle istanze P e D senza interruzione del servizio (zero-downtime).
Attua un scaling proattivo in caso di picchi imminenti, bypassando gli intervalli di aggiornamento regolari se si rileva un sovraccarico.

3. Contributi Chiave

Framework DOPD: Un sistema di inferenza LLM dinamico che regola continuamente il numero e la configurazione delle istanze P e D.
Modello Teorico e Analisi: Una modellazione approfondita del PD-Disaggregation che identifica le sfide specifiche delle architetture disaggregate e propone un metodo per calcolare il rapporto P/D ottimale.
Algoritmo di Scheduling: Un algoritmo di scheduling delle richieste "consapevole della lunghezza" che mitiga lo spreco di risorse causato dalla miscelazione di carichi di lavoro eterogenei.
Validazione Sperimentale: Dimostrazione empirica che DOPD supera significativamente gli approcci esistenti in termini di goodput e rispetto degli SLO.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su un cluster di 8 GPU NVIDIA H100, utilizzando modelli come LLaMa-3.3-70B e OPT-30B, e tracciati di carico reali (Microsoft Azure, BurstGPT).

Miglioramento del Goodput: DOPD aumenta il goodput complessivo del sistema fino a 1.5x rispetto a vLLM (approccio aggregato) e DistServe (approccio disaggregato statico).
Riduzione della Latenza:
- Diminuzione del P90 TTFT (Time-To-First-Token) fino al 67.5%.
- Diminuzione del P90 TPOT (Time-Per-Output-Token) fino al 22.8%.
Conformità agli SLO: Raggiunge un tasso di conformità agli SLO del 99.4% (rispetto all'80.8% di DistServe e 87.3% di strategie di scaling basate sul carico), utilizzando meno risorse aggiuntive.
Efficienza delle Risorse: Dimostra che un rapporto P/D dinamico e ottimizzato permette di ottenere prestazioni simili a sistemi con 8 GPU aggregati utilizzando solo 6 GPU in configurazione disaggregata ottimizzata.

5. Significato e Impatto

Il lavoro di DOPD è significativo perché risolve il problema fondamentale dell'inefficienza nelle architetture disaggregate per LLM, che finora erano limitate da configurazioni statiche incapaci di adattarsi alla variabilità dei carichi di produzione.

Efficienza Economica: Permette ai fornitori di servizi LLM di ridurre drasticamente i costi infrastrutturali minimizzando l'over-provisioning delle GPU.
Robustezza Operativa: La capacità di prevedere i picchi di carico e ridistribuire le risorse proattivamente garantisce un'esperienza utente stabile anche in scenari ad alta concorrenza.
Fondamento per il Futuro: Offre una base solida per la gestione dinamica delle risorse in ambienti di calcolo distribuiti, aprendo la strada a futuri sviluppi su modelli multimodali e tecniche di inferenza avanzate.

In sintesi, DOPD trasforma l'architettura PD-Disaggregation da una soluzione statica e spesso inefficiente in un sistema elastico e ottimizzato, massimizzando l'utilizzo dell'hardware e garantendo prestazioni elevate in scenari di produzione reali.