Prism: Cost-Efficient Multi-LLM Serving via GPU Memory Ballooning

Prism è un framework di co-serving per LLM centrato sulla memoria che utilizza una nuova tecnica di memory ballooning chiamata kvcached per reclamare e riallocare dinamicamente la memoria GPU tra più modelli, unificando così la condivisione spaziale e temporale per migliorare l'efficienza dei costi e l'aderenza agli SLO in ambienti di produzione.

L'essenziale

Immagina di gestire un enorme hotel con migliaia di stanze (GPU) e migliaia di ospiti diversi (modelli AI). Alcuni ospiti sono celebrità che vogliono una stanza 24 ore su 24, 7 giorni su 7, mentre altri sono turisti che si presentano solo per un check-in di 10 minuti una volta al giorno.

Il problema è che gestire questo hotel è costoso. Se dai a ogni turista la propria stanza privata per precauzione, finisci con il 90% del tuo hotel vuoto e sprecato. Ma se provi a stipare tutti in una sola stanza, si crea il caos e le celebrità si arrabbiano perché devono aspettare.

Prism è un nuovo, intelligente gestore dell'hotel che risolve questo problema usando un trucco chiamato "Memory Ballooning" (Gonfiaggio della Memoria).

Ecco come funziona, suddiviso in concetti semplici:

1. Il Problema: La trappola della "Stanza Statica"

Nel vecchio modo di gestire l'IA, se un modello (un ospite) veniva assegnato a una stanza, quella stanza era sua per sempre, anche quando dormiva (inattivo).

• Condivisione dello Spazio (Il Vecchio Modo): Cerchi di mettere più ospiti in una stanza. Funziona benissimo se sono tutti svegli e chiacchierano. Ma se un ospite se ne va per una settimana, la sua metà di stanza rimane vuota e l'altro ospite non può usarla.
• Condivisione del Tempo (L'Altro Vecchio Modo): Cacci un ospite per far entrare un altro. Funziona se gli ospiti arrivano solo in momenti diversi. Ma se due ospiti arrivano esattamente nello stesso secondo, devi continuamente cacciarli e farli rientrare nella stanza. Questo "cacciarli" è lento e fa aspettare tutti (lag), causando la mancata rispettabilità delle loro scadenze.

Il traffico reale dell'IA è disordinato. A volte un gruppo di modelli diventa impegnato tutto insieme, e a volte tutti diventano silenziosi. Nessuna vecchia strategia da sola poteva gestire questo passaggio.

2. La Soluzione: Il Trucco del "Gonfiaggio"

Prism introduce un nuovo gestore chiamato kvcached (il pilota del palloncino). Immagina la memoria della GPU non come un insieme di stanze fisse, ma come palloncini gonfiabili.

• Il Palloncino Elastico: Quando un modello è impegnato e ha bisogno di più spazio per pensare, il gestore gonfia il suo palloncino, rubando l'aria vuota da altri modelli che al momento stanno dormendo.
• Sgonfiare per gli Altri: Quando un modello va a dormire, il suo palloncino si rimpicciolisce, rilasciando quello spazio in modo che un nuovo modello, che si sta svegliando, possa gonfiare istantaneamente il proprio palloncino.
• Nessun Trasloco di Mobili: La cosa migliore? I modelli non sanno nemmeno che sta succedendo. Vedono solo una stanza che magicamente si espande e si contrae. Il gestore si occupa di tutto il lavoro pesante dietro le quinte.

3. La Strategia in Due Fasi

Prism usa due regole intelligenti per decidere chi riceve l'aria:

• Regola 1: Lo Scheduler Globale (Il Direttore dell'Hotel): Guarda l'intero hotel. Chiede: "Quale gruppo di ospiti è attualmente attivo?". Poi posiziona gli ospiti attivi sullo stesso piano (GPU) in modo che possano condividere lo spazio facilmente. Se un ospite sta dormendo, lo sposta in un armadio di stoccaggio (CPU) per liberare spazio. Riorganizza costantemente l'hotel per assicurarsi che nessun piano sia sovraffollato mentre un altro è vuoto.
• Regola 2: Lo Scheduler Locale (Il Concierge): Guarda le richieste specifiche che arrivano proprio in questo momento. Se due ospiti stanno combattendo per l'ultimo briciolo di spazio, il concierge controlla chi ha la scadenza più urgente. Fa entrare prima l'ospite urgente e dice a quello meno urgente di aspettare un momento. Questo assicura che i compiti più importanti vengano completati in tempo.

4. I Risultati

Il documento ha testato Prism su dati reali provenienti da importanti fornitori di IA e ha scoperto che:

• Servizio Più Veloce: Ha rispettato le sue promesse di velocità (SLO) fino a 3,3 volte meglio rispetto ai metodi precedenti.
• Costi Inferiori: Per ottenere lo stesso livello di prestazioni, Prism ha avuto bisogno di metà delle GPU (o ha potuto gestire il doppio delle richieste con lo stesso hardware).
• Prova nel Mondo Reale: È già stato implementato in ambienti di produzione con oltre 10.000 GPU, aiutando le aziende a generare significativamente più entrate per GPU trasformando il tempo "inattivo" sprecato in lavoro fatturabile.

Riassunto

Prism è come un intelligente ed elastico direttore d'hotel. Inveve di bloccare gli ospiti in stanze fisse o di cacciarli costantemente, usa palloncini gonfiabili per condividere lo spazio in modo dinamico. Espande lo spazio per i modelli impegnati e lo restringe per quelli che dormono, assicurando che l'hotel sia sempre pieno, efficiente e veloce, senza che nessuno debba fare la fila.

Sommario tecnico

Riepilogo Tecnico: Prism

Problematica

I provider di inferenza che ospitano migliaia di Large Language Models (LLM) affrontano una sfida critica di efficienza: mantenere la disponibilità per i modelli a basso volume ma essenziali, minimizzando al contempo i costi man mano che i prezzi dei token diminuiscono. L'analisi delle tracce di produzione rivela che i carichi di lavoro reali presentano un pattern dinamico a burst di gruppo (bursty-group pattern), in cui sottoinsiemi specifici di modelli diventano attivi insieme e cambiano nel tempo, guidati da sistemi di IA compositi e pipeline agentiche.

Le strategie di serving esistenti non riescono ad adattarsi a questa variabilità:

• Space Sharing (Colocazione): La co-locazione di più modelli su una GPU per utilizzare la memoria non utilizzata funziona per i modelli a traffico continuo, ma crea una severa frammentazione della memoria durante lunghi periodi di inattività. Impedisce ai modelli attivi di scalare per soddisfare i requisiti degli SLO (Service Level Objective) perché la memoria è bloccata staticamente dai modelli inattivi.
• Time Sharing (Swapping): Lo swapping di modelli in e fuori dalla memoria GPU gestisce bene il traffico sporadico, ma soffre di un elevato overhead di latenza (secondi) durante le rapide fluttuazioni del carico di lavoro. Ciò causa "thrashing" quando più modelli sperimentano richieste intercalate, portando a violazioni degli SLO.

La sfida centrale è la mancanza di un meccanismo fondato per unificare lo sharing spaziale e temporale. I sistemi attuali impongono un compromesso tra l'aderenza agli SLO e l'efficienza delle risorse, incapaci di passare fluidamente tra le strategie al variare dei pattern di carico, da burst volatili ad attività intercalate.

Metodologia

Prism è un framework di condivisione della GPU centrato sulla memoria, progettato per unificare lo sharing spaziale e temporale attraverso l'allocazione elastica della memoria. La sua architettura è composta da tre componenti primarie:

1. GPU Memory Ballooning (Il driver kvcached)

Prism introduce un driver di ballooning, kvcached, che si posiziona tra i motori di inferenza (es. SGLang) e la memoria fisica della GPU. Questo driver implementa il memory ballooning per recuperare e riallocare memoria tra i modelli senza interrompere l'esecuzione.

• Disaccoppiamento Virtuale/Fisico: Gli engine riserve un ampio spazio di indirizzamento virtuale, ma la memoria fisica viene allocata e mappata su richiesta. Questo permette al sistema di rimpicciolire o espandere l'impronta fisica di un modello (pesi e KV cache) a runtime.
• Gestione Unificata: kvcached tratta i pesi del modello e la KV cache come un pool unificato di pagine fisiche. Supporta diverse architetture di modelli mappando i blocchi di token a pagine virtuali e segregandoli fisicamente per evitare conflitti di forma.
• Ottimizzazioni: Per minimizzare l'overhead, utilizza pagine di memoria da 2MB, dà priorità alle pagine parzialmente riempite ed impiega un thread di pre-allocazione per la preparazione asincrona delle pagine. Espone un'astrazione di tensore elastico (eTensor) compatibile con gli existing attention kernel e i CUDA graph, richiedendo modifiche allo zero al codice degli engine di serving.
• Caricamento Rapido: Per mitigare la latenza di cold-start, Prism disaccoppia i cicli di vita degli engine dai cicli di vita dei modelli utilizzando un pool di engine riutilizzabili e impiega il caricamento parallelo dei pesi attraverso le GPU via NVLink per saturare la larghezza di banda dell'interconnessione.

2. Piano di Controllo Centrato sulla Memoria

Prism impiega uno scheduler gerarchico per gestire l'elasticità fornita da kvcached:

• Posizionamento dei Modelli Load-Aware (Globale): Uno scheduler globale posiziona i modelli sulle GPU per massimizzare l'headroom di memoria per il ballooning. Utilizza un'euristica KV Pressure Ratio (KVPR), che quantifica la contesa della memoria in base ai tassi di token pesati sugli SLO. L'algoritmo posiziona greedymente i modelli ad alta domanda sulle GPU con la pressione esistente più bassa, garantendo che i modelli attivi abbiano spazio per espandere le loro KV cache durante i burst.
• Arbitraggio delle Richieste Slack-Aware (Locale): Uno scheduler locale alla GPU gestisce le richieste concorrenti dai modelli co-localizzati. Invece di un isolamento statico, utilizza una coda di richieste condivisa e applica l'algoritmo di Moore-Hodgson per minimizzare le mancate scadenze. Prioritizza le richieste in base al loro time slack (la differenza tra la scadenza e il tempo di esecuzione richiesto), assicurando che le richieste urgenti e a bassa latenza siano servite prima di quelle più lunghe, massimizzando così l'ottenimento dello SLO di TTFT (Time-to-First-Token).

3. Integrazione di Sistema

Prism è implementato come una libreria che estende SGLang, utilizzando le API CUDA Virtual Memory Management (VMM). Opera come un processo di controllo separato che coordina le espulsioni, le attivazioni e le migrazioni dei modelli in base alle metriche di runtime.

Contributi Chiave

1. Meccanismo di Sharing Unificato: Prism è il primo sistema che unifica lo sharing spaziale e temporale sotto un unico schema, trattando la memoria GPU come una risorsa elastica. Permette al sistema di agire contemporaneamente come un sistema di time-sharing (espellendo i modelli inattivi) e come un sistema di space-sharing (co-servendo i burst attivi).
2. Driver kvcached: Un driver open-source che abilita la ridistribuzione flessibile e granulare (2MB) della memoria tra LLM eterogenei con overhead nell'ordine dei millisecondi e zero modifiche al kernel.
3. Deployment su Scala di Produzione: Il sistema è stato distribuito in ambienti di produzione su oltre 10.000 GPU ed è attivamente mantenuto.
4. Valutazione Esaustiva: Il paper fornisce un'analisi rigorosa di tracce di produzione provenienti dai principali provider (Hyperbolic, Novita AI) e piattaforme di valutazione (Chatbot Arena), coprendo 58 modelli eterogenei su periodi che vanno da 11 giorni a 16 mesi.

Risultati

Valutato su un cluster di fino a 32 GPU NVIDIA H100 utilizzando tracce reali:

• Ottenimento SLO: Prism raggiunge fino a 3,3 volte un maggiore ottenimento dello SLO TTFT e 2 volte un maggiore ottenimento dello SLO TPOT rispetto ai baseline allo stato dell'arte (inclusi MuxServe++, QLM e ServerlessLLM) a parità di GPU utilizzate.
• Efficienza dei Costi: Per raggiungere lo stesso livello di ottenimento SLO, Prism riduce il numero di GPU necessario di 2 volte (es. raggiungendo il 99% di SLO TTFT con 16 GPU rispetto a 32+ per i baseline) o gestisce 3,5 volte più richieste con lo stesso hardware.
• Impatto sulla Produzione: In deployment in ombra presso due aziende, Prism ha aumentato il throughput per GPU di 3,89× (Azienda A) e il ricavo per GPU di 2,86× (Azienda B), convertendo la capacità inattiva in token fatturabili senza violare gli SLO.
• Latenza: La latenza di attivazione del modello è ridotta a meno di 1,5 secondi anche per modelli da 70B, e l'overhead di migrazione è trascurabile (decine di millisecondi) quando si utilizza NVLink.

Significato

Il paper sostiene che il collo di bottiglia fondamentale nel serving multi-LLM sia la contesa della memoria GPU, non il calcolo. Spostando la prospettiva dalla partizione statica o dal time-slicing rigido verso una gestione elastica della memoria, Prism risolve il conflitto tra la necessità di risposta immediata (che richiede la co-locazione) e la necessità di efficienza delle risorse (che richiede l'espulsione). Il lavoro dimostra che una visione centrata sulla memoria può adattarsi fluidamente alla natura "bursty-group" dei moderni carichi di lavoro di IA, consentendo ai provider di ospitare miglia di modelli in modo efficiente dal punto di vista dei costi pur rispettando rigorosamente gli SLO di latenza. L'open-sourcing di kvcached e la sua adozione in ambienti di produzione su larga scala validano la fattibilità pratica di questo approccio.