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

Prism ist ein speicherzentriertes LLM-Co-Serving-Framework, das eine neuartige Memory-Ballooning-Technik namens kvcached nutzt, um GPU-Speicher dynamisch über mehrere Modelle hinweg zurückzugewinnen und neu zuzuweisen, wodurch räumliches und zeitliches Sharing vereinigt wird, um die Kosteneffizienz und die Einhaltung von SLOs in Produktionsumgebungen zu verbessern.

Das Wesentliche

Stellen Sie sich vor, Sie führen ein riesiges Hotel mit Tausenden von Zimmern (GPUs) und Tausenden von verschiedenen Gästen (KI-Modellen). Einige Gäste sind Prominente, die rund um die Uhr ein Zimmer wollen, während andere Touristen sind, die nur einmal am Tag für einen 10-minütigen Check-in auftauchen.

Das Problem ist, dass Ihr Hotel teuer im Betrieb ist. Wenn Sie jedem Touristen ein privates Zimmer reservieren, nur für den Fall, dass er auftaucht, bleibt 90 % Ihres Hotels leer und ungenutzt. Aber wenn Sie versuchen, alle in ein einziges Zimmer zu quetschen, entsteht Chaos, und die Prominenten werden wütend, weil sie warten müssen.

Prism ist ein neuer, smarter Hotelmanager, der dies durch einen Trick namens „Memory Ballooning“ löst.

So funktioniert es, unterteilt in einfache Konzepte:

1. Das Problem: Die „Statische Zimmer“-Falle

Auf die alte Art des KI-Betriebs: Wenn einem Modell (einem Gast) ein Zimmer zugewiesen wurde, war dieses Zimmer für immer sein, selbst wenn es schlief (idle).

• Platzteilung (Die alte Art): Sie versuchen, mehrere Gäste in ein Zimmer zu stecken. Das funktioniert großartig, wenn sie alle wach sind und plaudern. Aber wenn ein Gast für eine Woche verreist, liegt seine Hälfte des Zimmers leer, und der andere Gast kann sie nicht nutzen.
• Zeitteilung (Die andere alte Art): Sie werfen einen Gast raus, um Platz für einen anderen zu machen. Das funktioniert gut, wenn Gäste nur zu unterschiedlichen Zeiten kommen. Aber wenn zwei Gäste im exakt gleichen Moment eintreffen, müssen Sie ständig Leute rein- und rausschmeißen. Dieses „Rauswerfen“ ist langsam und lässt alle warten (Lag), wodurch sie ihre Fristen verpassen.

Der reale KI-Verkehr ist chaotisch. Manchmal werden Gruppen von Modellen gleichzeitig aktiv, und manchmal werden sie alle gleichzeitig ruhig. Keine einzelne alte Strategie konnte dieses Umschalten bewältigen.

2. Die Lösung: Der „Ballooning“-Trick

Prism führt einen neuen Manager namens kvcached (den Ballon-Treiber) ein. Stellen Sie sich den GPU-Speicher nicht als eine Reihe fester Zimmer vor, sondern als aufblasbare Ballons.

• Der elastische Ballon: Wenn ein Modell beschäftigt ist und mehr Platz zum Nachdenken braucht, bläst der Manager seinen Ballon auf und stiehlt die leere Luft von anderen Modellen, die gerade schlafen.
• Deflation für andere: Wenn ein Modell schläft, schrumpft sein Ballon und gibt den Platz frei, damit ein neues, gerade aufwachendes Modell seinen eigenen Ballon sofort aufblasen kann.
• Keine Möbelbewegung: Das Beste daran? Die Modelle merken nicht einmal, dass das passiert. Sie sehen nur ein Zimmer, das magisch expandiert und schrumpft. Der Manager erledigt die schwere Arbeit im Hintergrund.

3. Die Zwei-Schritte-Strategie

Prism nutzt zwei kluge Regeln, um zu entscheiden, wer die Luft bekommt:

• Regel 1: Der Globale Scheduler (Der Hotelmanager): Er betrachtet das gesamte Hotel. Er fragt: „Welche Gruppe von Gästen ist gerade aktiv?“ Dann platziert er diese aktiven Gäste auf demselben Stockwerk (GPU), damit sie den Platz leicht teilen können. Wenn ein Gast schläft, bewegt er ihn in einen Abstellraum (CPU), um Platz zu schaffen. Er arrangiert das Hotel ständig neu, um sicherzustellen, dass kein Stockwerk überfüllt ist, während ein anderes leer steht.
• Regel 2: Der Lokale Scheduler (Der Concierge): Er betrachtet die spezifischen Anfragen, die gerade jetzt eingehen. Wenn zwei Gäste um das letzte Stück Platz kämpfen, prüft der Concierge, wer die dringendste Frist hat. Er lässt den dringenderen Gast zuerst herein und sagt dem weniger dringenden, er solle einen Moment warten. Dies stellt sicher, dass die wichtigsten Aufgaben rechtzeitig erledigt werden.

4. Die Ergebnisse

Das Paper testete Prism mit realen Daten von großen KI-Anbietern und fand heraus:

• Schnellerer Service: Es erfüllte seine Geschwindigkeitsversprechen (SLOs) bis zu 3,3-mal besser als bisherige Methoden.
• Geringere Kosten: Um das gleiche Leistungsniveau zu erreichen, benötigte Prism die Hälfte der Anzahl an GPUs (oder konnte doppelt so viele Anfragen mit derselben Hardware bewältigen).
• Praxisbeweis: Es wurde bereits in Produktionsumgebungen mit über 10.000 GPUs eingesetzt und hilft Unternehmen dabei, signifikant mehr Umsatz pro GPU zu generieren, indem die verschwendete „Idle“-Zeit in abrechenbare Arbeit umgewandelt wird.

Zusammenfassung

Prism ist wie ein smarter, elastischer Hotelmanager. Anstatt Gäste in feste Zimmer einzusperren oder sie ständig rauszuwerfen, nutzt es aufblasbare Ballons, um den Platz dynamisch zu teilen. Es erweitert den Platz für beschäftigte Modelle und schrumpft ihn für schlafende Modelle, sodass das Hotel immer voll, effizient und schnell ist, ohne dass jemand in der Schlange warten muss.

Technische Zusammenfassung

Technisches Resümee: Prism

Problemstellung

Inferenz-Provider, die Tausende von Large Language Models (LLMs) hosten, stehen vor einer kritischen Effizienzherausforderung: die Verfügbarkeit für Modelle mit geringem Volumen aufrechtzuerhalten und gleichzeitig die Kosten bei sinkenden Token-Preisen zu minimieren. Die Analyse von Produktions-Traces zeigt, dass reale Arbeitslasten ein dynamisches, burstartiges Gruppenmuster (bursty-group pattern) aufweisen, bei dem spezifische Teilmengen von Modellen gemeinsam aktiv werden und sich über die Zeit verschieben, getrieben durch zusammengesetzte KI-Systeme und agentische Pipelines.

Bestehende Serving-Strategien können sich nicht an diese Variabilität anpassen:

• Space Sharing (Kolokation): Das Kolokieren mehrerer Modelle auf einer GPU, um ungenutzten Speicher zu nutzen, funktioniert für kontinuierliche Modelle mit geringem Traffic gut, führt aber während langer Leerlaufzeiten zu schwerer Speicherfragmentierung. Es verhindert, dass aktive Modelle skalieren, um die Anforderungen an die Service Level Objectives (SLOs) zu erfüllen, da der Speicher statisch durch idle Modelle blockiert ist.
• Time Sharing (Swapping): Das Ein- und Auslagern (Swapping) von Modellen aus dem GPU-Speicher bewältigt sporadischen Traffic gut, leidet jedoch unter hohem Latenz-Overhead (Sekunden) bei schnellen Schwankungen der Arbeitslast. Dies führt zu „Thrashing“, wenn mehrere Modelle mit zwischengeschalteten Anfragen interagieren, was SLO-Verletzungen zur Folge hat.

Die Kernherausforderung liegt im Fehlen eines fundierten Mechanismus zur Vereinigung von räumlichem und zeitlichem Sharing. Aktuelle Systeme erzwingen einen Kompromiss zwischen der Einhaltung von SLOs und der Ressourceneffizienz, da sie nicht in der Lage sind, fließend zwischen Strategien zu wechseln, wenn sich die Arbeitslastmuster von volatilen Bursts zu zwischengeschalteten Aktivitäten verschieben.

Methodik

Prism ist ein speicherzentriertes GPU-Sharing-Framework, das durch elastische Speicherallokation darauf ausgelegt ist, räumliches und zeitliches Sharing zu vereinigen. Seine Architektur besteht aus drei primären Komponenten:

1. GPU-Memory-Ballooning (Der kvcached-Driver)

Prism führt einen Balloon-Driver namens kvcached ein, der zwischen Inferenz-Engines (z. B. SGLang) und dem physischen GPU-Speicher sitzt. Dieser Driver implementiert Memory Ballooning, um Speicher über Modelle hinweg zurückzufordern und neu zuzuweisen, ohne die Ausführung zu stören.

• Virtuelle/Physische Entkopplung: Engines reservieren einen großen virtuellen Adressraum, aber der physische Speicher wird auf Abruf allokiert und gemappt. Dies ermöglicht es dem System, den physischen Fußabdruck (Gewichte und KV-Cache) eines Modells zur Laufzeit zu verkleinern oder zu vergrößern.
• Vereinheitlichtes Management: kvcached behandelt Modellgewichte und KV-Cache als einen vereinheitlichten Pool physischer Pages. Es unterstützt diverse Modellarchitekturen, indem es Token-Blöcke auf virtuelle Pages abbildet und sie physisch segregiert, um Shape-Konflikte zu vermeiden.
• Optimierungen: Um den Overhead zu minimieren, verwendet es 2MB-Speicherpages, priorisiert teilweise gefüllte Pages und nutzt einen Pre-Allocation-Thread für die asynchrone Page-Vorbereitung. Es stellt eine elastische Tensor-Abstraktion (eTensor) bereit, die mit bestehenden Attention-Kerneln und CUDA-Graphs kompatibel ist und keinerlei Codeänderungen an den Serving-Engines erfordert.
• Schnelles Laden: Um den Cold-Start-Latenz-Overhead zu mildern, entkoppelt Prism die Engine-Lebenszyklen von den Modell-Lebenszyklen durch einen wiederverwendbaren Engine-Pool und nutzt paralleles Laden von Gewichten über mehrere GPUs via NVLink, um die Interconnect-Bandbreite zu sättigen.

2. Speicherzentrierte Control Plane

Prism verwendet einen hierarchischen Scheduler, um die durch kvcached ermöglichte Elastizität zu verwalten:

• Lastbewusste Modellplatzierung (Global): Ein globaler Scheduler platziert Modelle über GPUs hinweg, um den Speicher-Headroom für das Ballooning zu maximieren. Er nutzt eine KV-Druck-Ratio (KVPR) Heuristik, welche den Speicherwettbewerb basierend auf SLO-gewichteten Token-Raten quantifiziert. Der Algorithmus platziert hochfordernde Modelle gierig (greedy) auf GPUs mit dem niedrigsten bestehenden Druck, um sicherzustellen, dass aktive Modelle während Bursts Raum zur Erweiterung ihrer KV-Caches haben.
• Slack-bewusste Request-Arbitrierung (Lokal): Ein GPU-lokaler Scheduler verwaltet gleichzeitige Anfragen von kolokierten Modellen. Statt statischer Isolation nutzt er eine gemeinsame Request-Queue und wendet den Moore-Hodgson-Algorithmus an, um Deadline-Verfehlungen zu minimieren. Er priorisiert Anfragen basierend auf ihrem Zeit-Slack (der Differenz zwischen der Deadline und der benötigten Ausführungszeit), wodurch sichergestellt wird, dass dringende, kurz laufende Anfragen vor länger laufenden bedient werden, was die TTFT (Time-to-First-Token) SLO-Erfüllung maximiert.

3. Systemintegration

Prism ist als Library implementiert, die SGLang erweitert, und nutzt CUDA Virtual Memory Management (VMM) APIs. Es operiert als separater Control-Prozess, der Modell-Evictions, Aktivierungen und Migrationen basierend auf Laufzeitmetriken koordiniert.

Zentrale Beiträge

1. Vereinheitlichter Sharing-Mechanismus: Prism ist das erste System, das räumliches und zeitliches Sharing unter einem einzigen Schema vereint, indem es den GPU-Speicher als elastische Ressource behandelt. Es erlaubt dem System, gleichzeitig als Time-Sharing-System (Eviction von Idle-Modellen) und als Space-Sharing-System (Co-Serving aktiver Bursts) zu agieren.
2. kvcached Balloon-Driver: Ein Open-Source-Driver, der eine flexible, feingranulare (2MB) Speicherumverteilung über heterogene LLMs mit Millisekunden-Overhead und ohne Kernel-Modifikationen ermöglicht.
3. Produktionsreife Implementierung: Das System wurde in Produktionsumgebungen auf über 10.000 GPUs eingesetzt und wird aktiv gewartet.
4. Umfassende Evaluierung: Die Arbeit liefert eine rigorose Analyse von Produktions-Traces führender Provider (Hyperbolic, Novita AI) und Evaluierungsplattformen (Chatbot Arena), die 58 heterogene Modelle über Zeiträume von 11 Tagen bis zu 16 Monaten abdeckt.

Ergebnisse

Evaluierung auf einem Cluster von bis zu 32 NVIDIA H100 GPUs unter Verwendung realer Traces:

• SLO-Erfüllung: Prism erreicht eine bis zu 3,3-mal höhere TTFT-SLO-Erfüllung und eine 2-mal höhere TPOT-SLO-Erfüllung im Vergleich zu State-of-the-Art-Baselines (einschließlich MuxServe++, QLM und ServerlessLLM) bei gleicher Anzahl an GPUs.
• Kosteneffizienz: Um das gleiche Niveau der SLO-Erfüllung zu erreichen, reduziert Prism die benötigte GPU-Anzahl um den Faktor 2 (z. B. Erreichen von 99% TTFT-SLO mit 16 GPUs statt 32+ bei Baselines) oder bewältigt 3,5-mal mehr Anfragen mit derselben Hardware.
• Produktionswirkung: In Shadow-Deployments bei zwei Unternehmen steigerte Prism den Durchsatz pro GPU um den Faktor 3,89 (Unternehmen A) und den Umsatz pro GPU um den Faktor 2,86 (Unternehmen B), indem ungenutzte Kapazitäten in abrechenbare Tokens umgewandelt wurden, ohne die SLOs zu verletzen.
• Latenz: Die Modell-Aktivierungslatenz wird selbst für 70B-Modelle auf unter 1,5 Sekunden reduziert, und der Migrations-Overhead ist vernachlässigbar (zehn Millisekunden), wenn NVLink verwendet wird.

Bedeutung

Die Arbeit argumenttiert, dass der fundamentale Flaschenhals beim Multi-LLM-Serving der GPU-Speicherwettbewerb ist, nicht die Rechenleistung (Compute). Durch den Wechsel der Perspektive von statischer Partitionierung oder starrer Zeitteilung hin zu elastischem Speicher-Management löst Prism den Konflikt zwischen der Notwendigkeit sofortiger Reaktionsfähigkeit (erfordert Kolokation) und der Notwendigkeit der Ressourceneffizienz (erfordert Eviction). Die Arbeit zeigt, dass eine speicherzentrierte Sichtweise flexibel auf die „bursty-group“-Natur moderner KI-Arbeitslasten reagieren kann, was Providern ermöglicht, tausende von Modellen kosteneffizient zu hosten und gleichzeitig die Latenz-SLOs strikt einzuhalten. Die Open-Sourcing von kvcached und die Adoption in großskaligen Produktionsumgebungen validieren die praktische Umsetzbarkeit dieses Ansatzes.