SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

Questo articolo propone un approccio ibrido che combina modellazione teorica e benchmark empirico per determinare l'allocazione ottimale delle risorse hardware nella disaggregazione Prefill-Decode per l'inferenza di LLM, garantendo il rispetto degli obiettivi di livello di servizio (SLO) relativi a throughput e latenza.

L'essenziale

Immagina di gestire un ristorante di lusso molto affollato, dove gli chef devono preparare piatti complessi (le risposte di un'intelligenza artificiale) per centinaia di clienti contemporaneamente.

In passato, ogni chef faceva tutto da solo: prima preparava gli ingredienti (la fase di "Prefill") e poi cuoceva il piatto (la fase di "Decode"). Il problema? Se uno chef era troppo lento a preparare gli ingredienti, tutti gli altri restavano fermi ad aspettare, e se era troppo lento a cuocere, gli ingredienti si accumulavano. Era un caos, e i clienti si lamentavano perché il primo boccone arrivava troppo tardi o il servizio era lento.

La soluzione moderna è stata separare i compiti: abbiamo un team di "Preparatori" (Prefill) che si occupa solo degli ingredienti e un team di "Cuochi" (Decode) che si occupa solo della cottura. Questo è il concetto di Disaggregazione Prefill-Decode.

Ma ecco il nuovo problema: Quanti preparatori e quanti cuochi servono esattamente?
Se ne assumi troppi, sprechi soldi. Se ne assumi troppo pochi, i clienti si arrabbiano perché aspettano troppo.

Questo articolo scientifico di Kingsoft Cloud offre una ricetta matematica per trovare il numero perfetto di staff, garantendo che il ristorante sia veloce, economico e che non si rompa mai.

Ecco come funziona la loro "ricetta", spiegata in modo semplice:

1. La Teoria: Il Bilancio del Traffico

Immagina che il ristorante debba servire un certo numero di piatti al minuto (il "Throughput").

• Se i piatti sono lunghi (molte parole da generare), servono più Cuochi.
• Se gli ordini sono complessi (molte parole da leggere prima di iniziare), servono più Preparatori.

Gli autori hanno creato una formula che dice: "Se so quanti piatti devo fare e quanto sono lunghi, posso calcolare esattamente quanti preparatori e cuochi mi servono".

2. Il Problema del "Primo Boccone" (TTFT)

C'è una regola d'oro: il cliente non deve aspettare più di 2 secondi per vedere il primo boccone (chiamato TTFT).

• L'approccio vecchio: Si pensava che più veloce fosse il preparatore, meglio era.
• La scoperta di questo articolo: Se il preparatore corre troppo veloce, si crea una coda di ordini in attesa che lo rallenta! È come se un'autostrada fosse vuota ma ci fossero troppi incroci: il traffico si blocca.

Usando una teoria matematica chiamata Teoria delle Code (M/M/1), gli autori spiegano che per rispettare la regola dei "2 secondi", il preparatore deve lavorare a una velocità precisa, né troppo lenta né troppo veloce. Se il cliente è impaziente (vuole il primo boccone subito), il preparatore deve rallentare leggermente per non creare ingorghi, garantendo che il primo ordine esca sempre in tempo.

3. Il Problema della "Cottura" (TPOT)

Una volta iniziato il piatto, il cliente vuole che arrivi il resto velocemente (ogni parola nuova deve arrivare ogni 20 millisecondi, chiamato TPOT).

• Qui, i "Cuochi" lavorano meglio se cucinano più piatti insieme (in gruppo), ma se il gruppo è troppo grande, la cottura diventa lenta per tutti.
• Gli autori hanno fatto degli esperimenti pratici (benchmark) per trovare il "numero magico" di piatti da cuocere insieme. Hanno scoperto che c'è un punto esatto in cui il gruppo è abbastanza grande da essere efficiente, ma non così grande da far aspettare il cliente.

4. La Soluzione Pratica: Il Test di Assaggio

Per trovare il numero perfetto di staff, l'articolo suggerisce di fare due cose:

1. Misurare la velocità massima dei preparatori e dei cuochi quando non sono disturbati.
2. Applicare la "Teoria delle Code" e i dati reali per vedere quanto velocemente possono lavorare senza far aspettare i clienti.

Esempio reale dal testo:
Hanno testato questo metodo su un modello di intelligenza artificiale molto grande (DeepSeek-V3.1).

• Obiettivo: Servire 5 milioni di parole al minuto, con tempi di attesa brevissimi.
• Risultato: La loro formula ha detto: "Ti servono 3 Preparatori e 4 Cuochi".
• Verifica: Hanno provato a usare 3 Preparatori e 3 Cuochi. Risultato? Il servizio era lento e i clienti si lamentavano. Con 3 e 4, invece, tutto scorreva perfettamente e si risparmiavano risorse.

In Sintesi

Questo articolo ci dice che non serve indovinare quanti computer (GPU) usare per l'intelligenza artificiale. Basta:

1. Sapere cosa vogliono i clienti (quanto sono veloci e quanto sono lunghe le richieste).
2. Misurare quanto sono veloci i computer da soli.
3. Usare una semplice formula matematica (basata su come si comportano le code al supermercato) per calcolare il mix perfetto tra chi prepara e chi finisce il lavoro.

È come avere un GPS per l'efficienza: ti dice esattamente quante risorse usare per non sprecare soldi e per garantire che l'intelligenza artificiale risponda sempre in tempo, senza mai bloccarsi.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference" in italiano.

1. Il Problema

L'inferenza dei Modelli Linguistici su Grande Scala (LLM) è spesso eseguita in modalità non disaggregata, dove le stesse risorse GPU gestiscono sequenzialmente due fasi distinte: il Prefill (computazionale, legato all'input) e il Decode (limitato dalla larghezza di banda della memoria, legato all'output). Questa architettura crea interferenze che rendono difficile ottimizzare simultaneamente due metriche critiche di Service Level Objective (SLO):

• TTFT (Time-To-First-Token): Il tempo necessario per generare il primo token.
• TPOT (Time-Per-Output-Token): Il tempo necessario per generare ogni token successivo.

La disaggregazione Prefill-Decode (P/D) è emersa come soluzione per separare queste fasi su istanze hardware diverse, permettendo un'ottimizzazione indipendente. Tuttavia, manca una metodologia consolidata per determinare il numero ottimale di risorse hardware (rapporto tra GPU per Prefill e GPU per Decode) necessarie per soddisfare specifici requisiti di throughput totale e SLO, date le caratteristiche dei request (lunghezze di input e output). Un'allocazione errata porta o a sottoutilizzo delle risorse (costi elevati) o al mancato rispetto degli SLO.

2. Metodologia

Gli autori propongono un approccio ibrido che combina modellazione teorica e benchmark empirici per calcolare il numero esatto di istanze P/D necessarie.

A. Modello Teorico per l'Allocazione delle Risorse

Il metodo parte dal throughput totale richiesto ($TP_{total}$) e dalle lunghezze medie di input ($L_{in}$) e output ($L_{out}$).

• Si definiscono i tempi di calcolo per le fasi di Prefill ($T_{prefill}$) e Decode ($T_{decode}$).
• In un sistema a pipeline, per evitare tempi di inattività, i tempi di calcolo delle due fasi devono essere uguali ($T_{total} = T_{prefill} = T_{decode}$).
• Da queste equazioni, si derivano le formule per il numero di istanze necessarie ($N_{prefill}$ e $N_{decode}$) e il loro rapporto ottimale ($R_{P/D}$), che dipende dal rapporto tra le lunghezze dei token e i throughput effettivi delle singole istanze.

B. Determinazione del Throughput di Prefill (Vincolo TTFT)

Poiché il throughput di prefill effettivo dipende dal carico e dal vincolo di TTFT, gli autori modellano il processo di coda come un sistema M/M/1 (teoria delle code):

• Si misura il throughput massimo teorico ($\tilde{TP}_{prefill}$) in condizioni di non idle.
• Si calcola il tasso di arrivo dei request ($\lambda$) e il tasso di servizio ($\mu$).
• Utilizzando la formula del tempo di attesa nella coda, si deriva un throughput effettivo ($TP_{prefill}$) che garantisce il TTFT target, sottraendo i tempi di overhead (trasmissione KV cache e rete).
• Formula chiave: $TP_{prefill} = \tilde{TP}_{prefill} - \frac{L_{in}}{TTFT - T_{overhead}}$.
• Questo dimostra che un TTFT più stringente riduce il throughput effettivo raggiungibile.

C. Determinazione del Throughput di Decode (Vincolo TPOT)

Per la fase di decode, il throughput e il TPOT sono correlati positivamente alla dimensione del batch di decoding.

• Si eseguono benchmark empirici per tracciare la curva di TPOT e throughput in funzione della dimensione del batch.
• Si identifica la dimensione del batch massima che rispetta il vincolo TPOT.
• Il throughput di decode effettivo viene calcolato dividendo questa dimensione del batch valida per il TPOT corrispondente.

3. Contributi Chiave

1. Modello Teorico Unificato: Una formula matematica che calcola il numero di istanze P/D basandosi su throughput totale, SLO, lunghezze dei request e throughput raggiungibili.
2. Modellazione M/M/1 per il Prefill: Un metodo innovativo per derivare il throughput di prefill effettivo sotto vincoli di TTFT, superando la semplice misurazione statica.
3. Approccio Empirico per il Decode: Una procedura basata su benchmark per trovare il punto di equilibrio ottimale tra dimensione del batch e TPOT, massimizzando l'efficienza senza violare gli SLO.
4. Validazione Reale: Dimostrazione che il metodo predice accuratamente l'allocazione delle risorse in scenari reali, garantendo sia l'efficienza dei costi che il rispetto degli SLO.

4. Risultati Sperimentali

Gli autori hanno validato il metodo in uno scenario reale con i seguenti parametri:

• Modello: DeepSeek-V3.1-Terminus.
• Hardware: GPU NVIDIA H200.
• Requisiti: TTFT $\le$ 2s, TPOT $\le$ 20ms, Throughput totale target: 5 Milioni di token al minuto (M TPM).
• Lunghezze: Input medio 6144, Output medio 512.

Risultati:

• Il modello ha calcolato un rapporto ottimale P:D di 0.82:1.
• Ha proposto un deployment specifico di 3 istanze Prefill e 4 istanze Decode (3P4D).
• Conferma: Il deployment 3P4D ha raggiunto un throughput di circa 4.8 M TPM rispettando simultaneamente entrambi gli SLO (TTFT e TPOT).
• Confronto: Un deployment con risorse bilanciate diversamente (3P3D) ha raggiunto solo 3.6 M TPM prima di violare il vincolo TPOT, dimostrando che il metodo proposto migliora l'efficienza per nodo (0.69 M TPM contro 0.6 M TPM).

5. Significato e Impatto

Questo lavoro colma un vuoto critico nell'industria dell'inferenza LLM: la mancanza di strumenti per dimensionare correttamente le infrastrutture disaggregate.

• Ottimizzazione dei Costi: Permette di evitare il sovradimensionamento (spreco di GPU costose) o il sottodimensionamento (mancato rispetto degli SLO).
• Scalabilità: Fornisce una guida pratica per gli operatori cloud per configurare cluster P/D in base alla domanda specifica degli utenti.
• Fondamento Futuro: Il metodo può essere integrato con strumenti di configurazione automatica (come AIConfigurator) o esteso a sistemi multimodali con separazione in tre fasi (EPD), rendendolo un pilastro per l'infrastruttura LLM di prossima generazione.

In sintesi, il paper offre una soluzione rigorosa e validata per trasformare la complessa gestione delle risorse LLM da un processo empirico e approssimativo a una disciplina ingegneristica precisa e basata sui dati.