🤖 AI

M*: A Modular, Extensible, Serving System for Multimodal Models

Dieses Paper stellt M* vor, ein modulares und erweiterbares Serving-System, das zusammengesetzte multimodale Modelle als Datenflussgraphen darstellt, um eine flexible Komposition von Komponenten und eine verteilte Optimierung zu ermöglichen, wobei signifikante Verbesserungen bei Latenz und Durchsatz gegenüber bestehenden Frameworks bei vielfältigen Aufgaben wie Text-zu-Bild, Text-zu-Sprache und robotergestützter Planung erzielt werden.

Ursprüngliche Autoren: Atindra Jha, Naomi Sagan, Keisuke Kamahori, Irmak Sivgin, Rohan Sanda, Steven Gao, Mark Horowitz, Luke Zettlemoyer, Olivia Hsu, Jure Leskovec, Baris Kasikci, Stephanie Wang

Veröffentlicht 2026-06-12

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Atindra Jha, Naomi Sagan, Keisuke Kamahori, Irmak Sivgin, Rohan Sanda, Steven Gao, Mark Horowitz, Luke Zettlemoyer, Olivia Hsu, Jure Leskovec, Baris Kasikci, Stephanie Wang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie leiten eine riesige, hochtechnologische Küche.

Der alte Weg (Bestehende Systeme):
Lange Zeit waren KI-Modelle wie einfache, einspurige Fließbandstraßen. Wenn man einen Kuchen backen wollte (Text generieren), gingen alle Zutaten denselben Weg: mischen, backen, glasieren, servieren. Systeme wie vLLM wurden speziell für diese „Text-nur“-Fließbandstraße gebaut. Sie waren unglaublich schnell darin, Kuchen zu backen.

Doch jetzt tritt die KI in eine neue Ära ein. Wir backen nicht mehr nur Kuchen; wir betreiben eine zusammengesetzte Küche. Wir haben Modelle, die:

Ein Foto betrachten und beschreiben können (Vision).
Einer Stimme zuhören und mit einer anderen Stimme antworten können (Speech).
Ein Video beobachten und vorhersagen können, was als Nächstes passiert (World Models).
Einen Roboterarm basierend auf einem Befehl steuern können (Robotik).

Diese neuen „zusammengesetzten“ Modelle sind unordentlich. Sie folgen nicht einer einzigen geraden Linie. Manchmal müssen sie zurückschleifen, um ihre Arbeit zu überprüfen (wie ein Diffusionsmodell, das ein Bild verfeinert). Manchmal müssen sie sich gleichzeitig in drei parallele Pfade aufteilen (wie das Betrachten eines Bildes aus drei verschiedenen Winkeln). Manchmal müssen sie Audio in Echtzeit streamen, Wort für Wort.

Die alten Küchensysteme (vLLM, SGLang) versuchten, diese komplexen Multi-Task-Modelle in ihre einfachen, geraden Fließbandstraßen zu pressen. Es war, als würde man versuchen, einen Jonglierakt in ein Förderband zu zwängen. Es funktionierte, aber es war langsam, klobig und erforderte viel benutzerdefinierten „Kleber-Code“, um die Teile zusammenzuhalten.

Die neue Lösung: M*
Das Paper stellt M* vor, ein neues Betriebssystem für diese komplexen KI-Küchen. Anstatt die Modelle in eine gerade Linie zu zwingen, behandelt M* sie wie eine dynamische Karte oder ein Flussdiagramm.

So funktioniert M* anhand einfacher Analogien:

1. Der „Walk Graph“ (Die Karte)

In den alten Tagen musste der Küchenmanager das exakte Rezept für jedes Gericht kennen. In M* zeichnet der Modellentwickler einfach eine Karte (einen Graphen) der Küche.

Knoten (Nodes): Dies sind die Stationen (z. B. „Die Vision-Station“, „Die Sprach-Station“, „Die Audio-Station“).
Walks (Pfade): Dies sind die spezifischen Routen, die eine Bestellung eines Kunden nimmt.
- Bestellung A (Text-zu-Bild): Verläuft von der Sprach-Station → loopt 50 Mal an der Kunst-Station → endet am Drucker.
- Bestellung B (Sprache-zu-Sprache): Verläuft von der Mikrofon-Station → teilt sich in zwei Pfade auf → führt wieder zusammen → geht zum Lautsprecher.

M* nennt dies den Walk Graph. Er ermöglicht es dem System zu verstehen, dass verschiedene Aufgaben unterschiedliche Wege durch dieselbe Küche nehmen, ohne dass das Layout der Küche jedes Mal neu geschrieben werden muss.

2. Der „Dirigent“ (Der Verkehrskontrolleur)

Sob einmal die Karte gezeichnet ist, hat M* einen Dirigenten. Dies ist ein intelligenter Verkehrskontrolleur, dem es egal ist, was das Essen ist, sondern nur, wohin es gehen muss.

Wenn eine Anfrage eine Schleife benötigt (um ein Bild zu verfeinern), schickt der Dirigent sie zurück zum Anfang der Schleife.
Wenn eine Anfrage sich in drei Teile aufspalten muss (um Sicherheit, Stil und Inhalt zu prüfen), schickt der Dirigent drei Kopien gleichzeitig an drei verschiedene Köche.
Wenn eine Anfrage Audio streamt, stellt der Dirigent sicher, dass der Koch das erste Wort sofort übergibt, anstatt auf den ganzen Satz zu warten.

3. Flexible Sitzordnung (Platzierung)

In den alten Systemen galt: Wenn Sie einen großen Chef (ein großes KI-Modell) hatten, mussten Sie ihn an einen riesigen Tisch (einen einzelnen GPU) setzen. Wenn Sie einen kleinen Helfer (einen kleinen Encoder) hatten, musste er an einem winzigen Tisch sitzen.
M* erlaubt es Ihnen, die Küche zu disaggregieren. Sie können den „Vision-Chef“ auf einen anderen Computer setzen, den „Sprach-Chef“ auf einen dritten und den „Audio-Chef“ auf einen vierten. Sie können sofort miteinander kommunizieren. Das bedeutet, dass Sie nur den Teil des Modells skalieren können, der langsam ist, ohne Geld für die schnellen Teile zu verschwenden.

Was haben sie bewiesen? (Die Ergebnisse)

Die Autoren haben M* gegen die alten Systeme (vLLM-Omni, SGLang-Omni, VoxServe) auf fünf verschiedenen Arten komplexer Modelle getestet. Und das ist passiert:

Bildgenerierung (BAGEL): Beim Umwandeln von Text in Bilder war M* 20 % bis 50 % schneller als die alten Systeme. Es handhabte die komplexen „Loops“, die zur Verfeinerung des Bildes nötig sind, viel effizienter.
Sprache (Qwen3-Omni & Orpheus): Bei der Generierung von Sprache war M* in der Echtzeit-Performance bis zu 2,9-mal schneller und konnte 2,7-mal mehr Anfragen gleichzeitig bearbeiten. Es war wie der Wechsel von einem langsamen, stotternden Radio zu einer kristallklaren Live-Übertragung.
Robotik (V-JEPA 2): Bei der Vorhersage zukünftiger Videobilder für die Roboterplanung war M* bis zu 12,5-mal schneller. Das alte System musste bei jedem Schritt alles von Grund auf neu berechnen; M* erinnerte sich an die vorherigen Schritte und aktualisierte nur die neuen.

Das Fazit

M* ist ein universelles System, das aufhört, zu versuchen, jedes KI-Modell in eine einzige, starre Form zu pressen. Stattdessen lässt es das Modell seine eigene Form (einen Graphen) definieren und baut dann eine flexible, Hochgeschwindigkeits-Engine, um diese Form auszuführen.

Es ist der Unterschied zwischen einem starren Fließband, das kaputtgeht, wenn man versucht, ein Auto statt eines Toasters zu bauen, und einer intelligenten, anpassungsfähigen Werkstatt, die alles – vom Toaster bis zum Raumschiff – mit gleicher Geschwindigkeit und Effizienz bauen kann. Das Paper behauptet, dass dies Entwicklern ermöglicht, diese komplexen, multimodalen Modelle mit minimalem Aufwand bereitzustellen und dabei eine signifikant bessere Leistung zu erzielen.

Technisches Resümee: M* – Ein modulares, erweiterbares Serving-System für multimodale Modelle

1. Problemstellung

Die KI-Landschaft verschiebt sich hin zu zusammengesetzten Modellarchitekturen (composite model architectures), die diverse Komponenten wie Vision-Encoder, Sprach-Backbones, Diffusions-Heads, Audio-Codecs und Aktionsgeneratoren integrieren. Diese Modelle – darunter Unified Multimodal Models (UMMs), Omni-Modelle, Speech-Language Models (SpeechLMs), Vision-Language-Action (VLA)-Policies und World Models – weisen Ausführungsstrukturen auf, die sich je nach Eingangsmodalität und Aufgabe signifikant unterscheiden. Im Gegensatz zu traditionellen textbasierten Large Language Models (LLMs), die einer festen autoregressiven (AR) Schleife folgen, zeichnen sich zusammengesetzte Modelle durch Folgendes aus:

Diverse Ausführungspfade: Unterschiedliche Aufgaben (z. B. Bildgenerierung vs. Bildverständnis) durchlaufen unterschiedliche Teilmengen der Komponenten innerhalb desselben Modells.
Komplexe Kontrollflüsse: Muster umfassen nicht-autoregressive Schleifen (z. B. Diffusionsschritte, World-Model-Rollouts), interne Parallelität (z. B. Classifier-Free Guidance-Zweige) und Streaming-Datenabhängigkeiten.
Heterogene Hardwareanforderungen: Komponenten müssen möglicherweise unabhängig voneinander skaliert oder auf spezifische Hardware-Topologien platziert werden.

Bestehende Serving-Frameworks (z. B. vLLM, SGLang) sind für die AR-Textgenerierung optimiert. Während jüngste Erweiterungen (vLLM-Omni, SGLang-Omni) versuchen, multimodale Modelle über feste gerichtete azyklische Graphen (DAGs) von „Stages“ zu unterstützen, scheitern sie an der Erfassung komplexer Muster wie Cross-Stage-Schleifen, interner Parallelität und dynamischem Streaming. Dies führt zu suboptimaler Leistung, starrer physischer Platzierung und dem Bedarf an erheblichem individuellem „Glue Code“ für neue Architekturen.

2. Methodik: Die Walk-Graph-Abstraktion

Die Autoren schlagen M* vor, ein universelles Serving-System, das auf einer Kernabstraktion namens Walk Graph basiert. Diese Abstraktion entkoppelt die Modellarchitektur von der Systemlaufzeit.

2.1 Kerndefinition

Ein Modell in M* wird als Tupel $(G, W)$ definiert:

$G$ (Berechnungsgraph): Ein gerichteter Graph aus heterogenen Knoten (z. B. Encoder, Decoder, Transformer-Layer) und Kanten (Tensor-Flüsse).
$W$ (Walks): Eine endliche Menge benannter Subgraphen, die spezifische Phasen des Modellverhaltens repräsentieren (z. B. prefill_text, image_gen). Eine Benutzeranfrage ist eine Sequenz dieser Walks.

2.2 Kompositionale Primitive

Der Graph wird unter Verwendung von vier Primitiven konstruiert, um komplexe Kontrollflüsse zu handhaben:

Sequential: Verkettung von Subgraphen, bei denen die Ausgaben in den nächsten Schritt fließen.
Parallel: Fan-out-Ausführung von Kindknoten (z. B. für CFG-Zweige).
Loop: Gebundene Iteration mit akkumulierten Ausgaben (z. B. Diffusionsschritte).
DynamicLoop: Iteration mit pro-Anfrage basierenden Early-Exit-Bedingungen (z. B. End-of-Sequence in AR oder variable Horizonte in World Models).

2.3 Streaming und Chunking

Um Echtzeitgenerierung (z. B. Sprache) zu unterstützen, führt M* StreamingGraphEdges ein, die durch ChunkPolicies parametrisiert sind. Diese Policies legen fest, wann ein Konsumenten-Knoten basierend auf akkumulierten Input-Tensoren feuert. Unterstützte Policies sind:

FixedChunkPolicy: Feuert alle $K$ Items.
SlidingWindowChunkPolicy: Feuert, wenn ein Buffer $W$ Items enthält, mit einem Fortschritt von $S$ .
LeftContextChunkPolicy: Fügt Kontext-Frames vor den Chunks ein.

2.4 Runtime-Architektur

Die M*-Laufzeit führt den Walk Graph durch eine verteilte Architektur aus:

Conductor: Verwaltet den pro-Anfrage-Zustand und verteilt Arbeit an Worker via ZeroMQ.
Worker: Ein Prozess pro GPU-Rank, der lokale Subgraphen ausführt. Sie unterstützen Continuous Batching, CUDA-Graph Capture und torch.compile.
Engines: Spezialisierte Inferenz-Instanzen (z. B. KVCacheEngine für Transformer mit FlashInfer Paged Attention, StatelessEngine für einfache Knoten).
Placement: Benutzer definieren eine Abbildung von GraphNodes auf GPU-Ranks. Dies ermöglicht flexible Strategien wie Prefill-Decode-Disaggregation, Encoder/Decoder-Disaggregation und unabhängige Skalierung von Komponenten.

3. Kernbeiträge

Walk Graph Abstraktion: Eine vereinheitlichte Repräsentation, die beliebige zusammengesetzte Modellstrukturen (Schleifen, Parallelität, Streaming) als Datenflussgraphen erfasst und damit die Grenzen fester Stage-DAGs überwindet.
Modulare Laufzeit: Ein System, das die Graph-Abstraktion in eine Hochleistungs-Ausführung kompiliert und modernste Optimierungen (Paged Attention, CUDA Graphs) über verschiedene Modalitäten hinweg integriert, ohne dass modellspezifischer Glue Code erforderlich ist.
Flexible physische Platzierung: Eine entkoppelte API, die es Deployern ermöglicht, Komponenten beliebig auf Hardware abzubilden, was unabhängige Skalierung und Ressourcenverteilung über verschiedene Anfragetypen hinweg ermöglicht.
Streaming-Unterstützung: Native Handhabung von Producer-Consumer-Mustern via Chunk-Policies, essenziell für Echtzeit-Sprach- und Videogenerierung.

4. Experimentelle Ergebnisse

Die Autoren evaluierten M* anhand von fünf repräsentativen Modellen: BAGEL (UMM), Qwen3-Omni (Omni), Orpheus (SpeechLM), V-JEPA 2 (World Model) und $\pi$ 0.5 (VLA).

BAGEL (Text-to-Image & Image Editing):
- Im Vergleich zu vLLM-Omni erreichte M* eine ~30% niedrigere p50 End-to-End Latenz für Text-to-Image und ~50% niedrigere für Image Editing (mit CFG-Parallelität).
- M* nutzte eine einzige Konfiguration, um alle Modalitäten zu optimieren, während vLLM-Omni Trade-offs zwischen Konfigurationen (z. B. Single-Stage vs. Multi-Stage) erforderte, die die Leistung in spezifischen Aufgaben verschlechterten.
- Die Gewinne wurden dem Paged-KV-Cache-Management von M* für CFG-Zweige zugeschrieben, welches die dichte Tensor-Konkatenation in vLLM-Omni vermeidet.
Qwen3-Omni (Text-to-Speech):
- Beim Seed-TTS-Benchmark lieferte M* einen bis zu 2,9-mal niedrigeren Real-Time Factor (RTF) und einen 2,7-mal höheren Durchsatz im Vergleich zu vLLM-Omni und SGLang-Omni.
- Bei einer Batch Size von 16 war der Durchsatz ~15% höher als bei vLLM-Omni.
- Die Verbesserungen resultierten aus der per-Submodul CUDA-Graph-Capture (wodurch der gesamte Talker-Loop als ein einziger Graph laufen kann) und der Eliminierung von Inter-Process-Communication für kolokalisierte Komponenten.
Orpheus (Speech):
- M* erreichte einen 13,6% niedrigeren p50 RTF und Durchsatzverbesserungen zwischen 20% und 52% im Vergleich zu VoxServe (einem spezialisierten Speech-Serving-System).
V-JEPA 2 (Robotic Planning/World Models):
- Für aktionsbedingte Rollouts übertraf M* die native Meta-Implementierung um bis zu das 12,5-fache bei einem Rollout-Horizont von 30.
- Dies wurde durch die Kodierung des Rollouts als DynamicLoop mit Paged-Attention-KV-Caching erreicht, wodurch die kostspieligen wiederholten Prefills der Baseline-Schleife vermieden wurden.

5. Bedeutung und Ansprüche

Das Paper behaupten, dass M* den Weg für das effiziente Serving komplexer, nächster Generation zusammengesetzter Modelle mit minimalem Entwicklungsaufwand ebnet. Indem es die multimodale Inferenz als Graph-Traversal behandelt, erlaubt M* Modellautoren, Architekturen einmal zu deklarieren, während Deployer die physische Platzierung und Ausführung dynamisch optimieren können.

Die Autoren behaupten, dass M* eine Leistung erbringt, die gleichwertig mit oder besser als spezialisierte, modalitätsspezifische Baselines (wie VoxServe) und allgemeine Frameworks (wie vLLM-Omni) über eine Vielzahl von Aufgaben hinweg ist. Die Fähigkeit des Systems, beliebige Schleifen, Parallelität und Streaming ohne kundenspezifischen Glue Code zu handhaben, adressiert den grundlegenden Abstraktionskonflikt aktueller Serving-Stacks und erleichtert die Bereitstellung vereinheitlichter multimodaler, Omni- und World-Modelle in realen Anwendungen.