Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models

Cornserve ist ein verteiltes Serving-System, das auf Kubernetes basiert und durch flexible Aufgabenabstraktion sowie eine effiziente Record-and-Replay-Ausführung die Skalierbarkeit und Leistung von beliebigen Any-to-Any-Multimodalmodellen mit bis zu 3,81-fach höherem Durchsatz und 5,79-fach niedrigerer Tail-Latenz verbessert.

Das Wesentliche

Stell dir vor, du hast einen riesigen, hochmodernen Koch, der nicht nur einfache Gerichte zubereitet, sondern alles kann: Von einem einfachen Text-Rezept bis hin zu komplexen Videos mit Ton und Bildern. Dieser Koch ist ein sogenanntes „Any-to-Any"-Modell. Er kann Texte, Bilder, Videos und Töne verstehen und auch wieder daraus erzeugen.

Das Problem? Wenn du ihn fragst, ist er oft überfordert.

Das Problem: Der überlastete Ein-Mann-Betrieb

Stell dir vor, dieser Koch arbeitet in einer winzigen Küche (dem Computer).

• Wenn du ihn bittest, ein Bild zu beschreiben, muss er erst das Bild ansehen (Encoder), dann darüber nachdenken (LLM) und dann schreiben.
• Wenn du ihn bittest, ein Video mit Ton zu erstellen, muss er erst einen Text schreiben, dann daraus Bilder generieren und schließlich einen Soundtrack komponieren.

In einem normalen System (wie es heute oft läuft) macht ein einziger Koch alles. Das ist ineffizient:

1. Wartezeiten: Wenn der Koch gerade das Bild analysiert, steht der Teil, der den Text schreibt, untätig herum.
2. Unterschiedliche Geschwindigkeiten: Das Analysieren von Bildern dauert lange, das Schreiben von Text geht schnell. Der schnelle Teil wartet auf den langsamen.
3. Chaos: Jede Anfrage nimmt einen anderen Weg durch die Küche. Einmal wird der Ofen benutzt, ein anderes Mal der Mixer. Es ist schwer, das zu organisieren.

Die Lösung: Cornserve – Das hochmoderne Restaurant-Team

Die Forscher haben Cornserve entwickelt. Stell dir Cornserve nicht als einen einzelnen Koch vor, sondern als ein perfekt organisiertes Restaurant-Management-System.

Hier ist, wie es funktioniert, mit ein paar einfachen Vergleichen:

1. Das „Rezept-System" (Flexible Aufgaben)

Statt den Koch zu zwingen, alles selbst zu machen, erlaubt Cornserve dem Chefkoch (dem Entwickler), das Rezept in kleine, einfache Schritte zu zerlegen.

• Einheitliche Aufgaben: Es gibt einen Spezialisten für Bilder, einen für Texte, einen für Audio.
• Zusammengesetzte Aufgaben: Diese Spezialisten können zu Teams zusammengefasst werden, um komplexe Gerichte zu kochen.
• Der Clou: Du kannst das Rezept in reiner Python-Sprache schreiben (wie eine normale Einkaufsliste), und Cornserve kümmert sich darum, wer was macht.

2. Die „Küchen-Entzerrung" (Model Fission)

Das ist das Herzstück. Cornserve zerlegt den riesigen Ein-Koch-Betrieb in viele kleine, spezialisierte Stationen.

• Stell dir vor, die „Bild-Analyse"-Station hat ihre eigene Küche mit eigenen Öfen.
• Die „Text-Schreib"-Station hat eine andere.
• Die „Audio-Produktion"-Station eine dritte.

Jede Station kann unabhängig wachsen. Wenn du 100 Leute hast, die Bilder analysieren wollen, stellst du einfach 10 neue Bild-Köche ein. Wenn nur 5 Leute Text schreiben wollen, reicht ein Text-Koch. Niemand muss warten, weil der andere zu langsam ist.

3. Der „Kurier-Service" (Record-and-Replay & Datenfluss)

Wie kommen die Zutaten von einer Station zur nächsten?

• Das Aufzeichnen (Record): Bevor das Essen wirklich gekocht wird, schaut Cornserve kurz auf das Rezept und notiert sich: „Okay, zuerst Bild-Station, dann Text-Station, dann Audio-Station." Es ist, als würde man den Weg im Kopf durchgehen, ohne wirklich zu kochen.
• Das Nachspielen (Replay): Jetzt wird das Essen wirklich gekocht. Cornserve schickt die Zutaten (die Daten) direkt von der Bild-Station zur Text-Station, ohne Umwege durch den Chef.
• Der Kurier (Sidecar): Es gibt kleine Boten (Sidecars), die die Zutaten (Tensoren) blitzschnell zwischen den Stationen hin und her tragen. Wenn die Stationen im selben Gebäude sind, nutzen sie einen schnellen Aufzug (Shared Memory). Wenn sie in verschiedenen Gebäuden stehen, nutzen sie einen Hochgeschwindigkeits-Paketdienst (RDMA).

4. Das „Teilen von Ressourcen" (Component Sharing)

Was, wenn zwei verschiedene Restaurants (Modelle) denselben „Bild-Experten" brauchen?
Cornserve ist schlau: Es stellt nur einen Bild-Experten auf, den beide Restaurants nutzen können. Das spart enorm viel Platz und Geld (GPU-Ressourcen).

Das Ergebnis: Warum ist das so toll?

In Tests hat sich gezeigt, dass dieses System ein echtes Wunder ist:

• Geschwindigkeit: Es ist bis zu 3,8-mal schneller als die alten Ein-Koch-Systeme.
• Geduld: Wartezeiten für Kunden (die Latenz) sind bis zu 5,8-mal kürzer.
• Stabilität: Selbst wenn das System sehr groß wird (mit 16 Grafikkarten statt 8), läuft es stabil, während alte Systeme oft zusammenbrechen, weil ihnen der Platz ausgeht.

Fazit

Cornserve ist wie der Übergang von einem einsamen Straßenverkäufer, der alles selbst macht, zu einem riesigen, effizienten Industrie-Restaurant mit Fließband und Spezialisten. Es ermöglicht es, diese komplexen, vielseitigen KI-Modelle („Any-to-Any") so zu betreiben, dass sie schnell, günstig und zuverlässig für alle funktionieren – egal ob du ein Bild beschreiben oder ein Video mit Musik erstellen willst.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models" auf Deutsch:

1. Problemstellung

Any-to-Any-Modelle sind eine neue Klasse multimodaler KI-Modelle, die beliebige Kombinationen von Eingabe- und Ausgabemodalitäten (Text, Bild, Video, Audio) verarbeiten und generieren können. Das Serving (die Bereitstellung) dieser Modelle stellt bestehende Systeme vor erhebliche Herausforderungen:

• Heterogenität der Anfragepfade: Unterschiedliche Anfragen durchlaufen unterschiedliche Pfade im Berechnungsgraphen des Modells. Eine Anfrage mit Bild und Text aktiviert andere Komponenten als eine rein textbasierte Anfrage.
• Heterogenität der Skalierung: Die einzelnen Komponenten eines Modells (z. B. Encoder, LLM, Generator) haben sehr unterschiedliche Ressourcenanforderungen und Skalierungseigenschaften. Beispielsweise kann ein Text-Generator auf einer GPU viermal höhere Durchsatzraten erreichen als ein Audio-Generator.
• Fehlende Generalisierung: Bestehende Serving-Systeme wie vLLM (fokussiert auf Text-LLMs) oder xDiT (fokussiert auf Diffusionsmodelle für Bilder/Video) bieten nur punktuelle Lösungen für spezifische Teilaspekte und können die komplexe, dynamische Struktur von Any-to-Any-Modellen nicht effizient handhaben.

2. Methodik und Systemarchitektur

Cornserve ist ein verteiltes Serving-System, das auf Kubernetes aufbaut und speziell für generische Any-to-Any-Modelle entwickelt wurde. Es besteht aus ca. 23.000 Zeilen Python-Code und gliedert sich in folgende Kernkomponenten:

A. Flexible Task-Abstraktion

Cornserve führt eine dreistufige Abstraktion ein, um komplexe Berechnungsgraphen in reinem Python auszudrücken:

1. Unit Tasks: Atomare Modellkomponenten (z. B. EncoderTask, LLMTask, GeneratorTask).
2. Composite Tasks: Kombinieren Unit Tasks zu logischen Einheiten.
3. Apps: Python-Module, die die Ausführung definieren und als Einstiegspunkt (serve-Funktion) dienen.

B. Model Fission (Modell-Fissionierung)

Anstatt das gesamte Modell monolithisch auf einem Executor laufen zu lassen, zerlegt Cornserve Modelle an Komponentengrenzen in unabhängig skalierbare Einheiten.

• Jede Komponente (z. B. ein Video-Encoder) kann auf dedizierten GPUs mit spezialisierten Executoren laufen.
• Das System erkennt automatisch, wenn mehrere Apps dieselben Komponenten nutzen (z. B. einen gemeinsamen Vision-Encoder), und teilt diese Ressourcen (Component Sharing), um den GPU-Verbrauch zu optimieren.

C. Verteilte Laufzeit und Record-and-Replay

Da der Berechnungspfad von der Eingabe abhängt, verwendet Cornserve ein Record-and-Replay-Ausführungsmodell:

1. Record-Phase: Die Anfrage wird verarbeitet, aber die Unit Tasks geben Platzhalter-Ergebnisse zurück. Währenddessen wird der tatsächliche Aufrufgraph und die Datenabhängigkeiten aufgezeichnet. Dieser Schritt ist extrem schnell, da keine echte Modellberechnung stattfindet.
2. Dispatch: Der aufgezeichnete Graph wird an den Task-Dispatcher gesendet, der die Aufrufe an die entsprechenden Executors verteilt.
3. Replay-Phase: Die Anfrage wird erneut verarbeitet, wobei die Unit Tasks nun die echten Ergebnisse vom Dispatcher erhalten. Dies ermöglicht die Unterstützung komplexer Kontrollflüsse (Schleifen, Verzweigungen).

D. Datenweiterleitung (Data Forwarding)

Zwischen den fissionierten Komponenten auf verschiedenen GPUs werden Tensordaten über Sidecars (Daemon-Prozesse pro GPU) übertragen:

• Intra-Node: Nutzung von Linux Shared Memory (/dev/shm), um die Bandbreite von NVLink/NVSwitch nicht zu blockieren.
• Inter-Node: Nutzung von RDMA über die UCX-Bibliothek für hohe Geschwindigkeit.
• Die Daten fließen direkt vom Produzenten zum Konsumenten, ohne den Control Plane zu belasten.

3. Wichtige Beiträge

1. Erstes generisches Serving-System: Cornserve ist das erste System, das Any-to-Any-Modelle mit beliebigen Eingabe-/Ausgabekombinationen und dynamischen Berechnungsgraphen unterstützt.
2. Dynamische Disaggregation: Durch die Fissionierung können Komponenten unabhängig voneinander skaliert werden (z. B. mehr Repliken für langsame Audio-Generatoren, weniger für schnelle Text-Generatoren), was die Ressourcennutzung optimiert.
3. Effiziente Datenpipeline: Die Kombination aus Record-and-Replay und direkter Tensor-Weiterleitung über Shared Memory/RDMA minimiert Latenz und Overhead.
4. Open Source: Das System ist als Open-Source-Projekt verfügbar und auf Kubernetes implementiert.

4. Ergebnisse

Die Evaluation wurde mit realen Multimodal-Datensätzen (ServeGen) auf NVIDIA A100-GPUs durchgeführt und verglich Cornserve mit monolithischen Bereitstellungen (basierend auf Hugging Face Transformers):

• Durchsatz (Throughput):
  • Für Qwen 2.5 Omni (7B) erreichte Cornserve eine 3,09-fache (8 GPUs) bzw. 3,81-fache (16 GPUs) Steigerung des Durchsatzes im Vergleich zum Monolithen.
  • Für Qwen 3 Omni (30B) scheiterte der monolithische Ansatz aufgrund von GPU-Speicherüberlauf (OOM), während Cornserve durch Fissionierung erfolgreich lief.
• Latenz (Latency):
  • Die Tail-Latenz (P99) wurde um bis zu 5,79-fach reduziert.
  • Die P50-Latenz verbesserte sich um den Faktor 3,24.
  • Ursache: In monolithischen Systemen blockieren langsame Komponenten den gesamten Prozess. Cornserve eliminiert diese Blockaden durch Parallelisierung und ermöglicht zudem „Continuous Batching" für Audio-Generatoren, was im Monolithen technisch schwierig ist.
• Skalierbarkeit: Beim Skalieren von 8 auf 16 GPUs wurde eine Durchsatzsteigerung von 2,68-fach erreicht (besser als die erwartete lineare 2-fache Steigerung), da die zusätzliche Hardware besser zur Lastverteilung genutzt werden konnte.
• Overhead: Die Latenz durch Sidecar-Transfers (RDMA/Shared Memory) ist vernachlässigbar gering (ca. 5–27 ms für Tensoren bis 32 MB).

5. Bedeutung und Ausblick

Cornserve adressiert eine kritische Lücke in der Infrastruktur für die nächste Generation multimodaler KI-Modelle. Durch die Entkopplung von Komponenten und die flexible Orchestrierung ermöglicht das System:

• Die effiziente Bereitstellung komplexer, heterogener Modelle, die bisher kaum skalierbar waren.
• Kosteneffizienz durch geteilte Ressourcen und maßgeschneiderte Skalierung einzelner Teile des Modells.
• Eine Grundlage für zukünftige Forschung und die Entwicklung noch leistungsfähigerer Any-to-Any-Modelle.

Das System demonstriert, dass eine spezialisierte, verteilte Architektur notwendig ist, um die inhärente Heterogenität multimodaler Workloads zu bewältigen, und setzt einen neuen Standard für das Serving solcher Modelle.