🤖 machine learning

Cascade: Exploiting SLO-Aware latency budget for fair and high goodput LLM inference serving

Cascade è un sistema di serving per LLM che sfrutta un budget di latenza dinamico per richiesta per ottimizzare congiuntamente lo scheduling e la gestione della cache KV, migliorando così significativamente il goodput che soddisfa gli SLO e l'equità, riducendo al contempo le violazioni rispetto agli approcci tradizionali first-come-first-served.

Autori originali: Muhammad Adnan, Rohan Mahapatra, Prashant J. Nair, Daniel Berger, Pantea Zardoshti, Rodrigo Fonseca, Esha Choukse

Pubblicato 2026-08-10

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Muhammad Adnan, Rohan Mahapatra, Prashant J. Nair, Daniel Berger, Pantea Zardoshti, Rodrigo Fonseca, Esha Choukse

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate una stazione ferroviaria frenetica e ad alta velocità dove migliaia di passeggeri cercano di salire su treni diversi esattamente nello stesso momento. Alcuni passeggeri hanno appena uno zainetto (una domanda breve e veloce), mentre altri trascinano enormi e pesanti valigie piene di anni di ricordi (una storia lunga e complessa o un compito di ragionamento profondo). Nel mondo dell'Intelligenza Artificiale, questi "treni" sono i Large Language Models (LLM) — i computer super intelligenti che alimentano chatbot, assistenti alla programmazione ed agenti di ragionamento. I "passeggeri" sono le richieste che inviamo loro.

Affinché questi sistemi possano sembrare veloci e utili, devono promettere di fornire risposte entro un limite di tempo specifico, noto come Service Level Objective (SLO). Pensate a questo come a un biglietto che dice: "Devi essere sul treno e in movimento entro 5 secondi". Il problema è che i direttori della stazione hanno usato per molto tempo una regola molto vecchia: "Chi arriva prima, viene servito per primo". Ciò significa che se un passeggero con una valigia gigante arriva per primo, tutti gli altri devono aspettare dietro di lui, anche se la persona dietro ha solo un piccolo zainetto e potrebbe essere servita in una frazione di secondo. Questo causa un enorme ingorgo di traffico. Inoltre, la stazione dispone di una quantità limitata di memoria ad alta velocità (come una sala d'attesa VIP) per i bagagli dei passeggeri. Se il bagaglio viene conservato in un magazzino lento e distante, recuperarlo richiede tempo. Se il direttore della stazione non sa quanto tempo rimane a ogni passeggero prima che il suo treno parta, potrebbe sprecare secondi preziosi recuperando il bagaglio per qualcuno che è già in ritardo, mentre qualcun altro che è in tempo viene lasciato indietro.

Questa è la sfida affrontata da un nuovo sistema chiamato CASCADE, descritto in un recente articolo di ricercatori della University of British Columbia, Microsoft Azure Research e NVIDIA. I ricercatori si sono resi conto che ogni richiesta ha un "budget di tempo" nascosto — la differenza tra il tempo necessario per completare il proprio lavoro e il tempo che le è consentito impiegare. Alcune richieste hanno un budget enorme (molto tempo extra), mentre altre ne hanno quasi nessuno. L'articolo sostiene che, invece di guardare solo chi è arrivato prima o quanto è grande la richiesta, il sistema dovrebbe guardare questo budget di tempo rimanente per decidere chi va dopo e come gestire i propri dati.

L'idea centrale di CASCADE è trattare questo budget di tempo come una valuta condivisa per due diversi compiti: decidere l'ordine delle richieste e gestire dove risiedono i loro dati. Nelle simulazioni dell'articolo, che hanno utilizzato dati di traffico reali da server di produzione e testato su tre diversi modelli IA giganti (Qwen-2.5-72B, Llama-3-70B e Llama-3-405B), CASCADE ha mostrato risultati impressionanti. Calcolando costantemente quanto "margine di tempo" restava a ogni richiesta, il sistema poteva dare la priorità a quelle che stavano esaurendo il tempo, lasciando al contempo che le richieste con molto tempo attendessero un po' di più o recuperassero i propri dati da un'archiviazione più lenta e meno costosa.

I risultati suggeriscono che questo approccio è una svolta per l'efficienza. Nei loro test, CASCADE ha migliorato il numero di richieste completate con successo dal sistema (chiamato "goodput") fino a 2,4 volte rispetto al metodo standard "chi arriva prima, viene servito per primo" utilizzato da sistemi popolari come vLLM. Ancora più importante, ha ridotto il numero di richieste che hanno mancato i loro limiti di tempo (violazioni SLO) del 40%. Forse in modo più creativo, lo ha fatto senza far soffrire le richieste lunghe e complesse. A differenza di altri metodi che potrebbero affrettare le richieste brevi lasciando a secche quelle lunghe, CASCADE ha mantenuto l'esperienza equa per tutti, assicurando che sia i passeggeri con lo "zainetto" che quelli con la "valigia gigante" venissero serviti in tempo. Il sistema ha ottenuto questo decidendo dinamicamente se recuperare i dati dalla memoria veloce, dall'archiviazione più lenta o semplicemente ricalcolarli, basandosi interamente sul fatto che quella specifica richiesta avesse abbastanza budget di tempo per assorbire il ritardo.

Riepilogo Tecnico: CASCADE

Definizione del Problema

Le piattaforme di serving per i Large Language Model (LLM) affrontano attualmente un disallineamento fondamentale tra gli Obiettivi di Livello di Servizio (SLO) e la natura eterogenea delle richieste in ingresso. Sebbene gli SLO (specificamente il Time-to-First-Token [TTFT] e il Time-Per-Output-Token [TPOT]) siano definiti a livello di servizio, il costo di esecuzione delle singole richieste varia di ordini di grandezza a causa delle differenze nella lunghezza dell'input, nella lunghezza della generazione e nella disponibilità di stati di cache KV (Key-Value) riutilizzabili.

Gli attuali sistemi di serving, come vLLM, impiegano tipicamente uno scheduling First-Come-First-Served (FCFS) o semplici euristiche basate sulla dimensione (ad esempio, Shortest Job First). Questi approcci non tengono conto del "budget di latenza" delle singole richieste — ovvero la differenza tra la scadenza SLO di una richiesta e il suo tempo di esecuzione previsto. Di conseguenza:

Head-of-Line (HOL) Blocking: Le richieste a lungo contesto possono bloccare richieste brevi e urgenti, causando violazioni degli SLO per queste ultime.
Gestione inefficiente della KV Cache: I sistemi spesso recuperano gli stati KV da livelli di memoria profondi (ad esempio, NVMe) per risparmiare tempo di calcolo. Tuttavia, senza considerare il budget di latenza specifico della richiesta, questi trasferimenti possono introdurre ritardi che superano l'headroom SLO rimanente della richiesta, trasformando un "cache hit" in una violazione dello SLO.
Iniquità: Le policy che danno priorità ai lavori brevi (SJF) causano sistematicamente l'inedia (starvation) dei carichi di lavoro a lungo contesto (ad esempio, agenti di coding, task di ragionamento), mentre il FCFS non riesce a distinguere tra richieste con ampio budget e quelle criticamente urgenti.

Gli scheduler esistenti trattano l'ordinamento delle richieste e la gestione della cache KV come problemi indipendenti, non riuscendo a riconoscere che entrambi consumano la stessa risorsa: il budget di latenza per richiesta.

Metodologia: Il Sistema CASCADE

CASCADE è un sistema di serving per LLM progettato per coordinare congiuntamente lo scheduling delle richieste e la gestione della cache KV multi-livello utilizzando un budget di latenza unificato per ogni richiesta.

1. Definizione e Stima del Budget di Latenza

CASCADE definisce il budget di latenza ( $B_r$ ) per una richiesta $r$ come:
$B_r = S_{TTFT}^{c(r)} - L_r$
Dove $S_{TTFT}^{c(r)}$ è l'obiettivo SLO a livello di classe e $L_r$ è il tempo di servizio rimanente stimato.

Stima: Il sistema utilizza un estimatore della latenza TTFT che modella la latenza di prefill in base alla lunghezza dell'input, alla lunghezza dell'output prevista, agli stati della prefix KV disponibili attraverso la gerarchia di memoria (HBM, DRAM, NVMe) e al carico attuale del sistema.
Conservatività: Per garantire l'affidabilità, l'estimatore media le latenze previste sotto il carico effettivo e la capacità massima, scalate da un fattore di guardia empirico ( $\gamma$ ) per tenere conto degli errori di stima e della contesa.

2. Architettura di Scheduling a Due Livelli

CASCADE utilizza un meccanismo di queuing a due livelli basato sul budget calcolato:

Livello 1 (Budget Positivo): Le richieste con $B_r > 0$ sono ammesse in una coda a priorità. Queste vengono pianificate in ordine Least-Remaining-Budget-First. Ciò garantisce che le richieste con scadenze strette (budget rimanente basso) abbiano la priorità rispetto a quelle con ampio headroom, indipendentmente dalla loro dimensione di input.
Livello 2 (Budget Negativo): Le richieste con $B_r \le 0$ vengono declassate a una coda secondaria. Non vengono scartate, ma eseguite opportunisticamente durante i periodi di inattività del cluster. Una frazione fissa di ogni batch è riservata al Livello 2 per evitare l'inedia, e le richieste vengono promosse nuovamente al Livello 1 se il loro budget diventa positivo al diminuire del carico.

3. Gestione della Cache KV Consapevole del Budget

Lo stesso budget di latenza governa le decisioni di memoria attraverso la gerarchia (GPU HBM, CPU DRAM, NVMe):

Restaurazione Fattibile: Quando uno stato della prefix KV viene trovato in un livello profondo, CASCADE calcola il tempo di trasferimento necessario per ripristinarlo. La restaurazione viene avviata solo se il tempo di trasferimento rientra nel budget rimanente della richiesta.
Fallback alla Ricomputazione: Se il ritardo di trasferimento violerebbe lo SLO, il sistema bypassa il recupero dal livello profondo e ricompila la prefix sulla GPU, evitando una violazione dello SLO.
Preemption: Sotto pressione di memoria HBM, CASCADE interrompe (preempt) le richieste attive con i maggiori budget rimanenti. Poiché queste richieste hanno un significativo headroom, l'overhead di ri-esecuzione è improbabile che causi una violazione dello SLO.

4. Implementazione

CASCADE è implementato come estensione del motore di serving vLLM. Si integra con LMCache per il posizionamento e il movimento dei blocchi KV multi-livello. Il sistema aggiunge un overhead minimo eseguendo il threading dei metadati (SLO, latenza stimata, tempo di arrivo) attraverso gli oggetti richiesta esistenti e svolgendo i calcoli del budget sulla CPU, in sovrapposenza con l'esecuzione sulla GPU.

Contributi Chiave

Identificazione del Budget di Latenza come Risorsa Comune: Il documento identifica che lo scheduling delle richieste e il movimento della cache KV competono per la stessa risorsa: il budget di latenza per richiesta. Dimostra che le scadenze del servizio, la dimensione della richiesta e lo stato della cache da soli sono insufficienti per determinare quanto overhead una richiesta possa tollerare.
Meccanismo di Coordinamento Congiunto: CASCADE presenta un sistema di serving per LLM che mantiene e aggiorna un budget di latenza per richiesta e lo utilizza per coordinare l'ordinamento delle richieste con il ripristino, il prefetching e il posizionamento della cache KV e la ricomputazione attraverso la gerarchia di memoria.
Scheduling ad Alta Goodput e Equo: Lo scheduler basato sul budget proposto riduce il HOL blocking senza causare sistematicamente l'inedia per le richieste a lungo contesto, preservando l'equità tra diverse classi di richieste eterogenee.
Validazione Empirica: Il sistema è valutato su tracce di produzione su tre grandi modelli (Qwen-2.5-72B, Llama-3-70B, Llama-3-405B) utilizzando profili hardware NVIDIA GB200 NVL72.

Risultati

Le valutazioni su tracce di produzione contenenti carichi di lavoro ChatBot, Tool&Agent, Coder e Reasoning dimostrano quanto segue:

Miglioramento della Goodput: CASCADE migliora la goodput soddisfacente gli SLO fino a 2,4× rispetto allo scheduler vLLM FCFS predefinito.
Riduzione delle Violazioni SLO: Riduce le violazioni degli SLO del 40% rispetto a FCFS.
Equità: CASCADE mantiene un alto Indice di Equità di Jain (vicino a 1.0) attraverso diverse classi di dimensione delle richieste, mentre lo Shortest Job First (SJF) causa una grave inedia per le richieste a lungo contesto (facendo scendere l'equità a circa 0,6 nei carichi pesanti).
Robustezza: Sotto carico elevato e capacità ridotta del cluster, CASCADE mantiene un'alta goodput e bassi tassi di violazione, mentre i baseline soffrono di grave HOL blocking e accumulo di code.

Significato e Rivendicazioni

Il documento afferma che la causa principale delle violazioni degli SLO nei sistemi attuali non è la mancanza di un budget di calcolo intrinseco, ma piuttosto lo spreco di questo budget dovuto al HOL blocking e ai trasferimenti di cache KV non coordinati. Rendendo il budget di latenza una quantità di runtime esplicita, CASCADE indirizza gli overhead inevitabili (code, movimento dati) verso le richieste che possono assorbirli, proteggendo al contempo le richieste urgenti.

Gli autori sostengono che questo approccio consenta ai provider di massimizzare l'utilizzo degli acceleratori e la goodput rispettando rigorosamente gli SLO di latenza e garantendo l'equità tra diversi tipi di applicazioni (dai brevi scambi di chat ai lunghi compiti di ragionamento), il tutto senza richiedere hardware aggiuntivo o modifiche ai pesi del modello. Il sistema colma il divario tra scheduling e gestione della memoria, trattandoli come un problema di ottimizzazione unificato guidato dall'urgenza specifica di ogni richiesta.