SUN: Shared Use of Next-token Prediction for Efficient Multi-LLM Disaggregated Serving

Die Arbeit stellt SUN vor, einen neuartigen Ansatz für das effiziente Disaggregierte Serving mehrerer LLMs, der durch die Aufteilung des Decoders in einen feingetunten präfill-spezifischen und einen gemeinsamen eingefrorenen Decodier-Modul eine modellübergreifende Ressourcennutzung ermöglicht und so die GPU-Auslastung sowie den Durchsatz signifikant steigert.

Das Wesentliche

Das große Problem: Die leeren Kassen an der Theke

Stell dir vor, du betreibst ein riesiges Restaurant, in dem du nicht nur ein, sondern hundert verschiedene Spezialitäten anbietest (z. B. Pizza, Sushi, Burger, Vegan). Jedes Gericht wird von einem eigenen, hochspezialisierten Koch zubereitet.

In der aktuellen Welt der KI-Modelle (LLMs) läuft das so ab:

• Du hast für jedes Gericht einen eigenen Koch und eine eigene Theke.
• Wenn jemand eine Pizza bestellt, geht die Bestellung an den Pizzakoch. Wenn jemand Sushi will, geht es zum Sushi-Koch.
• Das Problem: Oft sind die Kunden für die Pizza sehr zahlreich, aber für das Sushi nur selten da.
  • Der Pizzakoch ist im Stress und hat eine lange Schlange.
  • Der Sushi-Koch steht aber nur herum und starrt auf seine leere Theke, weil niemand Sushi bestellt.
  • Ergebnis: Du zahlst für 100 Köche, aber nur 10 arbeiten wirklich. Das ist extrem teuer und ineffizient.

In der KI-Sprache nennt man das „GPU-Unterauslastung". Die teuren Grafikkarten (die Köche) warten vergeblich, während andere überlastet sind.

Die Lösung: SUN (Gemeinsame Nutzung)

Die Forscher von NAVER Cloud haben eine geniale Idee namens SUN entwickelt. Sie wollen die starre Trennung zwischen den Köchen aufheben, ohne die Qualität der Gerichte zu verschlechtern.

1. Die Aufteilung: Der Vorbereiter und der Servierer

Jedes KI-Modell macht zwei Dinge, wenn es eine Antwort generiert:

1. Der Vorbereiter (Prefill): Er liest die Frage des Kunden (den Prompt) und bereitet alles vor. Das ist wie das Ausmessen der Zutaten. Das ist rechenintensiv (viel Arbeit am Computer).
2. Der Servierer (Decode): Er gibt das Wort für Wort aus. Das ist wie das Servieren der fertigen Gerichte. Das ist speicherintensiv (er muss sich viele Dinge merken).

Das alte Problem: Jeder Spezialkoch hatte seinen eigenen Vorbereiter und seinen eigenen Servierer.

Die SUN-Methode:

• Der Vorbereiter bleibt individuell: Der Pizzakoch bereitet die Pizza vor, der Sushi-Koch das Sushi. Jeder ist ein Experte für sein Gericht.
• Der Servierer wird geteilt: Alle Servierer werden in eine gemeinsame, große Küche verlegt. Es gibt nur noch einen super-effizienten Servier-Team, das für alle Gerichte zuständig ist.

2. Wie funktioniert das ohne Chaos? (Das „Feinabstimmen")

Man könnte denken: „Wenn der Servierer für alle Gerichte zuständig ist, wird er doch verwirrt, wenn er Pizzadaten von einem Sushi-Vorbereiter bekommt?"

Genau hier kommt der Trick von SUN ins Spiel:

• Der gemeinsame Servierer (das „Decode-Modul") wird eingefroren. Er lernt nichts Neues und bleibt immer derselbe.
• Stattdessen werden die Vorbereiter (Prefill-Module) speziell für ihre Aufgabe „feinabgestimmt" (fine-tuned).
• Die Analogie: Stell dir vor, der Vorbereiter lernt, seine Zutaten so zu schneiden und zu verpacken, dass der gemeinsame Servierer sie sofort erkennen und servieren kann. Der Vorbereiter passt sich dem Servierer an, nicht umgekehrt.

Das Ergebnis: Der Servierer kann jetzt Pizzas, Sushi und Burger in einer einzigen großen Schlange servieren. Wenn gerade keine Pizzabestellungen da sind, serviert er Sushi. Niemand steht untätig herum.

Die Vorteile im Alltag

1. Geld sparen (TCO): Du brauchst viel weniger Servierer (GPU-Karten), weil sie nie leer stehen. Du kannst die gleiche Menge an Gerichten mit weniger Personal auskommen.
2. Schneller bei Schieflagen: Wenn plötzlich alle Burger wollen (eine „schiefe" Last), kann das gemeinsame Team alle Burger-Kunden bedienen, ohne dass andere Köche blockiert werden.
3. Qualität bleibt: Die Gerichte schmecken genauso gut wie vorher. Die Genauigkeit der KI bleibt gleich hoch wie bei den einzelnen Spezialmodellen.

Die Super-Version: QSUN (Quantized SUN)

Die Forscher haben noch einen zweiten Schritt gemacht, genannt QSUN.

• Das Problem: Selbst mit einem gemeinsamen Team sind die Servierer manchmal noch zu langsam, weil sie zu viele Daten (Gewichte) mit sich herumtragen müssen.
• Die Lösung: Sie machen die gemeinsamen Servierer „leichter". Sie komprimieren die Daten (Quantisierung), ähnlich wie man ein schweres Buch in ein leichtes Taschenbuch verwandelt.
• Der Clou: Normalerweise macht das Komprimieren die Gerichte schlechter (die KI wird dümmer). Aber bei QSUN passen sie den Vorbereiter noch einmal kurz an, damit er die leichteren Servierer perfekt bedienen kann.
• Ergebnis: Die Gerichte kommen 45 % schneller auf den Tisch, schmecken aber immer noch genauso gut wie vorher.

Zusammenfassung in einem Satz

SUN ist wie ein Restaurant, in dem jeder Koch seine eigene Spezialität vorbereitet, aber alle in einer einzigen, hoch-effizienten Servier-Linie arbeiten, damit keine Karte jemals leer steht und die Kunden schneller bedient werden – und das alles, ohne dass das Essen schlechter schmeckt.

Das ist ein großer Schritt, um KI-Dienste für alle erschwinglicher und schneller zu machen.

Technische Zusammenfassung

1. Problemstellung

Das Paper adressiert die Ineffizienz beim Betrieb mehrerer großer Sprachmodelle (Multi-LLM Serving), insbesondere in disaggregierten Architekturen (Trennung von Prefill- und Decode-Phasen auf verschiedenen Geräten).

• Inter-Modell-Isolation: In herkömmlichen disaggregierten Systemen sind die Decode-Ressourcen (GPUs) strikt pro Modell partitioniert. Da verschiedene spezialisierte Modelle (z. B. für Mathematik, Code, Tool-Calling) unterschiedlich stark nachgefragt werden, führt dies zu einer starken Auslastungsschieflast (Skew). Beliebte Modelle haben Warteschlangen, während unpopuläre Modelle ihre dedizierten GPUs unterauslasten.
• Fehlende Cross-Model-Batching: Da jedes Modell eigene Parameter und eigene Decode-Worker hat, können Anfragen verschiedener Modelle nicht zu einem gemeinsamen Batch zusammengefasst werden. Dies verhindert eine effiziente Auslastung der speicherintensiven Decode-Phase.
• Ressourcenverschwendung: Derzeit muss für jedes Modell eine separate Menge an GPUs bereitgestellt werden, was die Gesamtkosten (TCO) erhöht und die GPU-Auslastung bei speichergebundenen Decode-Operationen senkt.

2. Methodik: SUN (Shared Use of Next-token Prediction)

Die Autoren schlagen SUN vor, einen Algorithmus, der die Isolation zwischen Modellen aufhebt, indem er einen einzigen, eingefrorenen Decode-Modul über mehrere spezialisierte Modelle hinweg teilt.

Kernkonzept: Prefill-Only Tuning

Ein Decoder-only Transformer wird in zwei Module zerlegt:

1. Prefill-Modul: Verarbeitet den Eingabe-Prompt und erzeugt den Key-Value (KV) Cache.
2. Decode-Modul: Generiert Token basierend auf dem KV-Cache und dem vorherigen Token.

Der Ansatz von SUN:

• Gemeinsamer Decoder: Ein einziger, eingefrorener Decoder (mit Parametern $\theta_d^{base}$) wird für alle Aufgaben verwendet.
• Aufgabenspezifischer Prefill: Für jede spezifische Aufgabe (z. B. Mathematik) wird nur das zugehörige Prefill-Modul ($\theta_p^{task}$) feinabgestimmt (Fine-Tuning).
• Kompatibilität: Durch das Fine-Tuning des Prefill-Moduls lernt dieses, KV-Caches zu erzeugen, die vom eingefrorenen, gemeinsamen Decoder korrekt interpretiert werden können. Dies löst das Problem der „Train-Inference-Mismatch", das bei naiver Wiederverwendung von KV-Caches auftreten würde (wie in Abbildung 2 des Papers gezeigt, wo eine naive Wiederverwendung zu massiven Genauigkeitsverlusten führt).

Routing-Strategie

• Prefill-Routing: Anfragen werden deterministisch an den jeweiligen, aufgabenspezifischen Prefill-Worker geleitet.
• Modellagnostisches Decode-Routing: Sobald der KV-Cache erzeugt ist, werden die Decode-Anfragen unabhängig vom Ursprungsmodell an einen gemeinsamen Pool von Decode-Workern verteilt. Dies ermöglicht Cross-Model-Batching, bei dem Anfragen unterschiedlicher Modelle auf derselben GPU verarbeitet werden, was die Auslastung maximiert.

QSUN (Quantized SUN)

Um die Effizienz weiter zu steigern, wird QSUN eingeführt:

• Der gemeinsame Decode-Modul wird weight-only quantisiert (z. B. auf 4 Bit).
• Da Quantisierung die Genauigkeit beeinträchtigen kann, wird nach der Quantisierung ein Prefill-only Re-Tuning durchgeführt. Das Prefill-Modul lernt dabei, KV-Caches zu erzeugen, die mit dem quantisierten Decoder kompatibel sind.
• Der Prefill-Modul bleibt dabei in voller Präzision (16 Bit), um die Latenz beim ersten Token (TTFT) nicht zu verschlechtern.

3. Wichtige Beiträge

1. Robuster Cross-Model-Decode-Sharing: SUN ist der erste Ansatz, der die Isolation in Multi-LLM-Systemen durch das Teilen eines einzigen frozen Decode-Moduls beseitigt, ohne die Genauigkeit zu opfern.
2. Modellagnostisches Routing für hohe Auslastung: Durch das Entkoppeln der Decode-Routing-Logik von der Modellidentität wird eine Lastverteilung über einen gemeinsamen Pool ermöglicht. Dies reduziert die benötigte Anzahl an Decode-GPUs um bis zu 50 %, während der Gesamtdurchsatz erhalten bleibt.
3. Genauigkeitserhaltende Quantisierung: QSUN kombiniert die Vorteile der Low-Bit-Decodierung (höherer Durchsatz) mit der Genauigkeit durch Prefill-Re-Tuning, ohne die Vorteile des geteilten Decoders zu verlieren.

4. Ergebnisse

Die Experimente wurden auf Basis von vLLM auf einem DGX A100-Cluster (8 GPUs) durchgeführt, wobei Modelle wie LLaMA3.1-8B und Qwen3-Base in verschiedenen Domänen (Mathematik, Code, Tool-Calling) getestet wurden.

• Genauigkeit: SUN erreicht eine Genauigkeit, die mit vollständigem Fine-Tuning (Full-FT) vergleichbar ist. In einigen Fällen (z. B. HumanEval bei LLaMA3.1-8B) sogar leicht besser.
• Durchsatzsteigerung:
  • SUN verbessert den Durchsatz pro GPU um bis zu 2,0-fach im Vergleich zu herkömmlichen disaggregierten Baselines.
  • Die Zeit pro Ausgabetoken (TPOT) bleibt dabei innerhalb von 5 % des Baselines.
• Robustheit bei Schiefen Workloads: Unter stark schiefen Lastverteilungen (Zipf-Verteilung) behält SUN eine stabile Auslastung und Interaktivität bei, während Baselines mit dedizierten GPUs unter Auslastungsproblemen leiden.
• QSUN-Leistung:
  • QSUN erzielt einen 45%igen Geschwindigkeitsvorteil (TPOT-Reduktion) gegenüber Full-FT.
  • Die Genauigkeit von QSUN liegt nahe am Full-FT-Niveau und übertrifft deutlich reine Quantisierungsmethoden wie AWQ (Activation-Aware Weight Quantization), die ohne Re-Tuning massive Genauigkeitsverluste zeigen.
  • QSUN reduziert die Time-to-First-Token (TTFT) im Vergleich zu AWQ um 17 %, da der rechenintensive Prefill-Modul in voller Präzision bleibt.

5. Bedeutung und Ausblick

Das Paper stellt einen Paradigmenwechsel im Multi-LLM-Serving dar:

• Kosteneffizienz: Durch die Konsolidierung von Decode-Ressourcen und die Reduzierung der benötigten GPU-Anzahl sinkt die Total Cost of Ownership (TCO) erheblich.
• Skalierbarkeit: Die Methode ermöglicht es, Hunderte von spezialisierten Modellen effizient zu betreiben, was für Agenten-Workflows und komplexe Pipelines entscheidend ist.
• Praktische Anwendbarkeit: Die Integration in bestehende Frameworks wie vLLM und die Kompatibilität mit Quantisierung machen SUN zu einer sofort einsatzfähigen Lösung für Produktionsumgebungen.

Zusammenfassend demonstriert SUN, dass durch die intelligente Trennung von Prefill- und Decode-Phasen sowie die gezielte Anpassung nur des Prefill-Teils eine gemeinsame Nutzung von teuren Inferenzressourcen möglich ist, ohne Kompromisse bei der Modellqualität einzugehen.