🤖 AI

Coral: Cost-Efficient Multi-LLM Serving over Heterogeneous Cloud GPUs

Coral ist ein adaptives, Heterogenität bewahrendes Multi-LLM-Bereitstellungssystem, das durch den Einsatz einer verlustfreien Zwei-Stufen-Zerlegung zur Ermöglichung schneller, nahezu optimaler Entscheidungsfindung die Ressourcenallokation und Bereitstellungsstrategien über diverse Cloud-GPUs hinweg gemeinsam optimiert und damit eine Kostensenkung von bis zu 2,79-fach sowie eine 2,39-fach höhere Goodput-Rate erreicht.

Ursprüngliche Autoren: Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

Veröffentlicht 2026-05-07

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

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 führen eine riesige, hochpreisige Restaurantküche. In der Vergangenheit glaubte jeder, man benötige den teuersten, hochmodernen Küchenchef und den größten, schnellsten Herd, um jedes einzelne Gericht zuzubereiten. Doch in der Welt der Large Language Models (LLMs) – den KI-Gehirnen hinter Chatbots und Code-Generatoren – hat sich dies geändert. Kein einzelnes „KI-Modell" ist in allem das Beste. Manche sind hervorragend im Schreiben von Code, andere im Chatten, und einige eignen sich nur für einfache Aufgaben.

Darüber hinaus ist die „Küche" (die Cloud-Server) ein Chaos aus unterschiedlicher Ausstattung. Sie haben superschnelle, teure „H100"-Herde, doch diese sind oft ausverkauft. Sie verfügen auch über ältere, günstigere „L4"- oder „A100"-Herde, die verfügbar sind und überraschenderweise genauso viel Kochleistung pro Dollar bieten.

Das Problem lautet: Wie betreibt man eine Küche mit 46 verschiedenen Rezepten (Modellen) unter Verwendung einer Mischung aus teuren und günstigen Herden, ohne Geld zu verschwenden oder Kunden warten zu lassen?

Genau dieses Problem löst Coral.

Der alte Weg: Der „Einheitsgröße"-Fehler

Frühere Systeme versuchten, dies zu lösen, indem sie jedes Gericht als Blackbox behandelten. Sie sagten: „Für das Code-Schreib-Gericht benötigen wir einen ganzen H100-Herd. Für das Chat-Gericht benötigen wir einen A100." Sie blickten nicht in das Rezept hinein, um zu sehen, ob sie Teile des Herds mischen und anpassen konnten.

Dies führte zu zwei großen Problemen:

Verschwundenes Geld: Sie kauften oft die teuerste Ausrüstung, selbst wenn eine günstigere Mischung genauso gut funktioniert hätte.
Engpässe: Wenn die teuren Herde ausgingen, kam die gesamte Küche zum Stillstand, obwohl sie viele günstigere Herde hatten, die untätig herumstanden.

Die Coral-Lösung: Der „intelligente Mix-and-Match"-Küchenchef

Coral ist wie ein genialer Küchenchef, der erkennt, dass ein einzelnes Gericht nicht auf nur einer Herdart zubereitet werden muss. Stattdessen zerlegt Coral den Kochprozess in Phasen und weist jedem Stadium den perfekten Herd zu.

So funktioniert es, anhand einer einfachen Analogie:

1. Die Zwei-Phasen-Strategie (Offline vs. Online)

Coral teilt sein Denken in zwei Teile auf, um nicht überfordert zu werden:

Phase 1: Das Rezeptbuch (Offline)
Bevor das Restaurant öffnet, verbringt Coral Zeit damit, ein massives „Rezeptbuch" zu erstellen. Für jedes mögliche Gericht (Modell) und jede mögliche Kombination von Herden (GPUs) berechnet es die absolut beste Art, es zuzubereiten.
- Beispiel: Es ermittelt, dass für das „Qwen-3 235B"-Gericht die beste Art, den ersten Teil (Prefill) zu kochen, darin besteht, drei günstige L40S-Herde und zwei teure H100-Herde in einer spezifischen Reihenfolge zu verwenden.
- Es schreibt diese perfekten „Rezepte" als Serving-Vorlagen auf. Dies dauert lange, muss aber nur einmal geschehen.
Phase 2: Die tägliche Schicht (Online)
Wenn das Restaurant öffnet und die Bestellungen eingehen, hört Coral nicht auf, um von Grund auf neu zu überlegen, wie gekocht werden soll. Es schaut einfach in sein Rezeptbuch.
- Es prüft: „Wir haben gerade 5 L40s und 2 H100s verfügbar. Wir müssen 100 Qwen-3-Gerichte zubereiten."
- Es wählt sofort das vorausberechnete Rezept aus, das zu diesen spezifischen Herden passt und die Geschwindigkeitsanforderungen des Kunden erfüllt.
- Da die harte Mathematik im Voraus erledigt wurde, kann Coral diese Entscheidungen in Sekunden treffen, nicht in Stunden. Dies ermöglicht es der Küche, sich sofort anzupassen, wenn ein Herd ausfällt oder eine neue Bestellung hereinströmt.

2. Die „Teamwork"-Analogie

Stellen Sie sich vor, Sie haben zwei Teams von Arbeitern (zwei verschiedene KI-Modelle) und eine begrenzte Menge an Werkzeugen (GPUs).

Der alte Weg: Team A schnappt sich alle besten Werkzeuge, weil sie das „beste" Team sind. Team B bleibt mit kaputten Werkzeugen zurück und kann seine Arbeit nicht abschließen.
Coral's Weg: Coral betrachtet das Gesamtbild. Es erkennt, dass Team A seine Aufgabe tatsächlich genauso gut mit einer Mischung aus guten und ordentlichen Werkzeugen erledigen kann, wenn sie ihren Arbeitsablauf neu organisieren. Dies setzt die besten Werkzeuge für Team B frei. Beide Teams beenden ihre Arbeit pünktlich, und keine Werkzeuge werden verschwendet.

Warum dies wichtig ist

Die Studie testete Coral mit 6 verschiedenen KI-Modellen und 20 verschiedenen Arten von Computerchips (GPUs). Die Ergebnisse waren beeindruckend:

Günstiger: Coral senkte die Kosten für den Betrieb dieser KI-Modelle im Vergleich zu den besten bestehenden Methoden um das bis zu 2,79-fache. Das ist, als würde man 100 Dollar für eine Mahlzeit zahlen und nur 36 Dollar für die gleiche Qualität.
Schneller (bei knappen Ressourcen): Wenn die „Küche" überfüllt ist und Werkzeuge schwer zu finden sind, schaffte es Coral, 2,39-mal mehr Kunden als die Konkurrenz zu bedienen, ohne langsamer zu werden.

Das Fazit

Coral ist ein System, das aufhört, KI-Modelle als starre, einblockige Maschinen zu behandeln. Stattdessen behandelt es sie wie flexible Rezepte, die auf einer Mischung aus alter und neuer Ausrüstung zubereitet werden können. Indem es die „perfekte Mischung" im Voraus plant und sie dann schnell in Echtzeit anwendet, spart es enorme Geldmengen und hält die KI reibungslos am Laufen, selbst wenn die Hardwareversorgung wackelig ist.

Kurz gesagt: Coral ist der intelligente Manager, der weiß, wie man eine Mischung aus teuren und günstigen Werkzeugen nutzt, um den Job schneller und billiger zu erledigen als jeder andere.

Technische Zusammenfassung: Coral – Kosteneffizientes Multi-LLM-Serving über heterogene Cloud-GPUs

1. Problemstellung

Die Landschaft des Deployments von Large Language Models (LLMs) ist zunehmend fragmentiert, wobei kein einzelnes Modell dominiert; stattdessen müssen Anbieter mehrere Modelle gleichzeitig bedienen, die jeweils unterschiedliche Architekturen und Kosten-Qualitäts-Abwägungen aufweisen. Gleichzeitig bieten Cloud-Anbieter eine heterogene Mischung von GPU-Generationen an (von High-End H100 über Mid-Range A100 bis hin zu älteren L4). Während High-End-Hardware Spitzenleistungen bietet, liefern Mid-Range- und ältere GPUs oft vergleichbare oder überlegene Performance pro Dollar sowie eine bessere Verfügbarkeit.

Die zentrale Herausforderung, die Coral adressiert, ist das kosteneffiziente, adaptive Serving mehrerer LLMs auf heterogenen Cloud-Ressourcen. Dies erfordert die gemeinsame Optimierung zweier eng gekoppelter Entscheidungen:

Ressourcenzuweisung: Bestimmung, welche Knoten in verschiedenen Cloud-Regionen bereitgestellt werden sollen.
Modellplatzierung: Entscheidung, wie jedes Modell auf diesen heterogenen Knoten partitioniert werden soll (z. B. durch Pipeline-Parallelismus und Datenparallelismus).

Bestehende Systeme adressieren dies nicht end-to-end. Vorarbeiten optimieren entweder die Ressourcenzuweisung unter der Annahme homogener Replikate (und ignorieren dabei die Platzierungsoptimierung) oder optimieren die Platzierung für ein einzelnes Modell auf einem festen Satz von Knoten (und ignorieren dabei die globale Zuweisung). Eine brute-force-gemeinsame Optimierung ist aufgrund des exponentiellen Suchraums beider Dimensionen und der Anforderung einer schnellen Neuberechnung (Minuten, nicht Stunden) zur Anpassung an schwankende Nachfrage und Ressourcenpreise nicht praktikabel.

2. Methodik

Coral führt ein adaptives, Heterogenität bewahrendes System ein, das das gemeinsame Optimierungsproblem in eine verlustfreie Zwei-Phasen-Zerlegung aufteilt.

Kernidee: Serving-Templates

Coral stellt fest, dass für ein festes Modell und ein Latenz-Service-Level Objective (SLO) die durchsatzoptimale Modellplatzierung auf einem bestimmten Satz von Knoten nur von dieser Knotenkombination abhängt, unabhängig davon, wie der Rest des Clusters zugewiesen ist. Dies ermöglicht die Verlagerung der Platzierungssuche in den Offline-Bereich.

Phase 1: Offline-Generierung von Serving-Templates

Prozess: Für jedes (Modell, SLO)-Paar enumeriert Coral einen prinzipiellen Teilmenge von Knotenkombinationen. Für jede Kombination verwendet es ein ganzzahliges lineares Programm (ILP), um die durchsatzoptimale Modellplatzierung (Schichtpartitionierung und Knotenzuweisung) zu berechnen, die das Latenz-SLO erfüllt.
Ausgabe: Eine Serving-Template-Bibliothek. Jedes Template ist ein wiederverwendbares Artefakt, das eine Knotenkombination und deren optimale Platzierungsstrategie spezifiziert.
Optimierung: Das ILP maximiert den Durchsatz unter Einhaltung von Latenzbeschränkungen. Um die kombinatorische Komplexität zu handhaben, reduziert Coral den Suchraum, indem es die maximale Anzahl von Knoten pro Template ( $N_{max}$ ) und das gesamte Speicher-Verhältnis ( $\rho$ ) relativ zur Modellgröße begrenzt, da größere Kombinationen oft prohibitiven Kommunikationsaufwand verursachen.

Phase 2: Online-Ressourcenzuweisung

Prozess: Der Online-Ressourcen-Allocator fragt periodisch die vorausberechnete Serving-Template-Bibliothek ab. Er löst ein zweites, leichtgewichtiges ILP, um zu bestimmen, welche Templates in welchen Regionen instanziiert werden sollen, um den aktuellen Durchsatzbedarf bei minimalen Kosten zu decken.
Eingaben: Echtzeit-Durchsatzbedarf, GPU-Verfügbarkeit und Preise in den verschiedenen Regionen.
Ziel: Minimierung der gesamten Bereitstellungs-Kosten plus einer Initialisierungsstrafe (um übermäßige Änderungen zu vermeiden), unter Einhaltung von Durchsatz- und Verfügbarkeitsbeschränkungen.
Effizienz: Durch die Verlagerung der komplexen Modellplatzierungssuche aus dem kritischen Pfad schließt der Online-Löser in wenigen Sekunden statt Stunden, was es dem Cluster ermöglicht, sich an dynamische Verschiebungen von Nachfrage und Angebot anzupassen.

Systemimplementierung

Coral ist als Laufzeitsystem implementiert, das ZeroMQ für die Steuerung, NCCL für die Kommunikation innerhalb von Instanzen und vLLM als Ausführungsmotor verwendet. Es unterstützt sowohl disaggregiertes als auch aggregiertes Serving von Prefill-Decode (PD). Ein hochpräziser ereignisbasierter Simulator, der gegen reale Hardware validiert wurde, wird für die groß angelegte Evaluierung verwendet, wo eine physische Bereitstellung kostenprohibitiv wäre.

3. Hauptbeiträge

Die Arbeit beansprucht folgende Beiträge:

Problemformulierung: Eine Formalisierung des heterogenitätsbewussten Multi-LLM-Servings als gemeinsame Optimierung über Ressourcenzuweisung und Modellplatzierung unter modellindividuellen Latenz-SLOs.
Verlustfreie Zerlegung: Ein neuartiger Zwei-Phasen-Ansatz, der wiederverwendbare Serving-Templates verwendet, um die komplexe Platzierungssuche in den Offline-Bereich zu verlagern, wodurch die Online-Lösungszeiten von Stunden auf wenige Sekunden reduziert werden, ohne die Optimalität zu beeinträchtigen.
Skalierbare Löser: ILP-basierte Löser sowohl für die Offline-Platzierung als auch für die Online-Zuweisung, die auf Cluster mit Tausenden von Knoten skalieren.
End-to-End-System: Eine vollständige Implementierung von Coral und ein validierter Simulator für groß angelegte Evaluierungen.
Empirische Validierung: Evaluierung über 6 Modelle und 20 GPU-Konfigurationen hinweg, die signifikante Kostenreduktionen und verbesserten Goodput demonstrieren.

4. Ergebnisse

Die Evaluierung wurde über diverse Modelle (von 14B bis 235B Parametern) und GPU-Konfigurationen (einschließlich H100, A100, L40S, L4, A10G) unter variierender Ressourcenverfügbarkeit durchgeführt.

Kosteneffizienz: Coral reduziert die Serving-Kosten um bis zu 2,79× im Vergleich zum besten Baseline-System (Homo, das homogene Replikate verwendet) und um 2,66× im Vergleich zu Cauchy (ein PD-disaggregiertes Baseline-System) in erweiterten Setups. In Kern-Setups betrugen die Reduktionen 1,62× bzw. 1,60×.
Goodput bei Knappheit: Bei knapper Ressourcenverfügbarkeit liefert Coral bis zu 2,39× höheren Goodput (Tokens pro Sekunde, die SLOs erfüllen) im Vergleich zu Baselines. Dies wird durch die gemeinsame Koordination von Ressourcen über Modelle hinweg zur Lösung von Konflikten erreicht, während Baselines den Bedarf für spezifische Modelle nicht decken können.
Lösungszeit: Das Online-Ressourcenzuweisungs-ILP löst im Durchschnitt in 0,24 Sekunden (Kern-Setup) und 9,68 Sekunden (erweitertes Setup), was gut innerhalb des erforderlichen Anpassungsfensters liegt.
Vergleich mit Helix: In einem Single-Modell-Regime auf einem festen heterogenen Cluster reduzierte Coral die Kosten um 21 % und verbesserte den Durchsatz um 26 % im Vergleich zu Helix, unter strikter Einhaltung der Latenz-SLOs.
Sensitivität: Die Analyse zeigt, dass die Kosteneffizienz der generierten Templates abflacht, wenn die Knotenbegrenzung ( $N_{max}$ ) auf 6 und das Speicher-Verhältnis ( $\rho$ ) auf 12 gesetzt wird, was die Reduktionsstrategie rechtfertigt.

5. Bedeutung

Die Arbeit argumentiert, dass die gemeinsame Optimierung von Ressourcenzuweisung und Modellplatzierung für kosteneffizientes Multi-LLM-Serving unerlässlich ist. Indem bestehende Systeme Modellreplikate als Blackboxen auf homogener Hardware behandeln, lassen sie erhebliche Kosteneinsparungen ungenutzt und haben unter Ressourcenbeschränkungen Schwierigkeiten. Coral zeigt, dass Heterogenität innerhalb von Replikaten – die Mischung verschiedener GPU-Typen innerhalb einer einzelnen Modellreplikation durch hybriden Pipeline- und Datenparallelismus – es Systemen ermöglicht, Instanzen an spezifische Workload-Charakteristika und SLOs anzupassen.

Die Bedeutung von Coral liegt in seiner Fähigkeit, diese gemeinsame Optimierung praktikabel und adaptiv zu machen. Durch die Vorausberechnung optimaler Platzierungen als wiederverwendbare Templates schließt es die Lücke zwischen der theoretischen Optimalität der gemeinsamen Suche und der praktischen Notwendigkeit einer schnellen, Online-Neukonfiguration. Dies ermöglicht Cloud-Anbietern, ein breiteres und kosteneffektiveres Spektrum an GPU-Beständen zu nutzen, während sie strenge Latenzgarantien für diverse, parallele LLM-Workloads aufrechterhalten.