🤖 AI

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

Coral is een adaptief, heterogeniteitsbewust multi-LLM-servingsysteem dat de resource-toewijzing en de servingstrategieën over diverse cloud-GPU's gezamenlijk optimaliseert, waarbij tot 2,79 $\times$ kostenreductie en 2,39 $\times$ hogere goodput worden bereikt door gebruik te maken van een verliesvrije tweestapsdecompositie om snelle, bijna optimale besluitvorming mogelijk te maken.

Oorspronkelijke auteurs: Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

Gepubliceerd 2026-05-07

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme, high-end restaurantkeuken runt. In het verleden dacht iedereen dat je de duurste, top-of-the-line chef en het grootste, snelste fornuis nodig had om elk gerecht te bereiden. Maar in de wereld van Large Language Models (LLMs)—de AI-geesten achter chatbots en code-generatoren—is dit veranderd. Geen enkel "AI-model" is het beste in alles. Sommigen zijn geweldig in het schrijven van code, anderen in chatten, en weer anderen zijn gewoon goed in simpele taken.

Bovendien is de "keuken" (de cloud-servers) een rommel van verschillende apparatuur. Je hebt supersnelle, dure "H100"-fornuizen, maar die zijn vaak uitverkocht. Je hebt ook oudere, goedkopere "L4"- of "A100"-fornuizen die beschikbaar zijn en, verrassend genoeg, net zoveel kookkracht bieden per dollar.

Het probleem is: Hoe run je een keuken met 46 verschillende recepten (modellen) met een mix van dure en goedkope fornuizen, zonder geld te verspillen of klanten te laten wachten?

Dit is het probleem dat Coral oplost.

De Oude Weg: De "One-Size-Fits-All"-Fout

Vorige systemen probeerden dit op te lossen door elk gerecht als een black box te behandelen. Ze zouden zeggen: "Voor het code-schrijfgerecht hebben we een heel H100-fornuis nodig. Voor het chat-gerecht hebben we een A100 nodig." Ze keken niet in het recept om te zien of ze onderdelen van het fornuis konden mixen en matchen.

Dit leidde tot twee grote problemen:

Verspild Geld: Ze kochten vaak het duurste materiaal, zelfs wanneer een goedkopere mix net zo goed zou werken.
Bottlenecks: Als de dure fornuizen op waren, stopte de hele keuken, zelfs al hadden ze talloze goedkopere fornuizen die stil stonden.

De Coral-oplossing: De "Slimme Mix-en-Match"-Chef

Coral is als een genie-kefchef die beseft dat een enkel gerecht niet op slechts één type fornuis hoeft te worden bereid. In plaats daarvan breekt Coral het kookproces op in fasen en wijst het het perfecte fornuis toe aan elke fase.

Hier is hoe het werkt, met een simpele analogie:

1. De Twee-Fase Strategie (Offline vs. Online)

Coral splitst zijn denken op in twee delen om overweldigd te raken:

Fase 1: Het Receptenboek (Offline)
Voordat de restaurantopening, besteedt Coral tijd aan het maken van een enorm "Receptenboek". Voor elk mogelijk gerecht (model) en elke mogelijke combinatie van fornuizen (GPUs) berekent het de absolute beste manier om het te bereiden.
- Voorbeeld: Het berekent dat voor het "Qwen-3 235B"-gerecht, de beste manier om het eerste deel (prefill) te bereiden, het gebruik is van drie goedkope L40S-fornuizen en twee dure H100-fornuizen, gerangschikt in een specifieke lijn.
- Het schrijft deze perfecte "recepten" op als Serving Templates. Dit kost veel tijd om te doen, maar het hoeft slechts één keer te gebeuren.
Fase 2: De Dagelijkse Shift (Online)
Wanneer het restaurant opent en bestellingen binnenkomen, stopt Coral niet om uit te zoeken hoe het vanaf nul moet koken. Het kijkt gewoon naar zijn Receptenboek.
- Het controleert: "We hebben nu 5 L40's en 2 H100's beschikbaar. We moeten 100 Qwen-3-gerechten bereiden."
- Het kiest direct het vooraf berekende recept dat past bij die specifieke fornuizen en voldoet aan de snelheidseisen van de klant.
- Omdat de zware wiskunde van tevoren is gedaan, kan Coral deze beslissingen in seconden nemen, niet in uren. Hierdoor kan de keuken direct inspelen als een fornuis kapot gaat of een nieuwe bestelling binnenstroomt.

2. De "Teamwerk"-Analogie

Stel je voor dat je twee teams van werknemers hebt (twee verschillende AI-modellen) en een beperkte voorraad gereedschap (GPUs).

De Oude Weg: Team A grijpt alle beste gereedschappen omdat ze het "beste" team zijn. Team B krijgt kapotte gereedschappen over en kan zijn werk niet afmaken.
De Weg van Coral: Coral kijkt naar het hele plaatje. Het beseft dat Team A eigenlijk zijn werk prima kan doen met een mix van goede en okay gereedschappen als ze hun workflow herschikken. Dit maakt de beste gereedschappen vrij voor Team B. Beide teams maken hun werk op tijd af en er wordt geen gereedschap verspild.

Waarom Dit Belangrijk Is

Het paper testte Coral met 6 verschillende AI-modellen en 20 verschillende soorten computerchips (GPUs). De resultaten waren indrukwekkend:

Goedkoper: Coral verlaagde de kosten voor het draaien van deze AI-modellen met maximaal 2,79 keer in vergelijking met de beste bestaande methoden. Dat is alsof je $100 betaalt voor een maaltijd en slechts $36 betaalt voor dezelfde kwaliteit.
Sneller (Wanneer Middelen schaars zijn): Wanneer de "keuken" vol zit en gereedschap moeilijk te vinden is, slaagde Coral erin om 2,39 keer meer klanten te bedienen dan de concurrentie zonder te vertragen.

De Conclusie

Coral is een systeem dat stopt met het behandelen van AI-modellen als stijve, single-block machines. In plaats daarvan behandelt het ze als flexibele recepten die kunnen worden bereid op een mix van oud en nieuw materiaal. Door van tevoren de "perfecte mix" te plannen en deze vervolgens snel in real-time toe te passen, bespaart het enorme bedragen geld en houdt het de AI soepel draaiend, zelfs wanneer de hardwarevoorraad wankel is.

Kortom: Coral is de slimme manager die weet hoe je een mix van dure en goedkope gereedschappen gebruikt om de klus sneller en goedkoper te klaren dan wie dan ook.

Technische Samenvatting: Coral – Kostenefficiënte Multi-LLM Serving over Heterogene Cloud GPU's

1. Probleemstelling

Het landschap van Large Language Model (LLM)-implementatie wordt steeds meer gefragmenteerd, waarbij geen enkel model dominant is; in plaats daarvan moeten providers meerdere modellen gelijktijdig bedienen, elk met unieke architecturen en afwegingen tussen kosten en kwaliteit. Tegelijkertijd bieden cloudproviders een heterogene mix van GPU-generaties (van top-tier H100's tot mid-tier A100's en oudere L4's). Hoewel top-tier hardware piekprestaties biedt, bieden mid-tier en oudere GPU's vaak vergelijkbare of superieure prestaties per dollar en betere beschikbaarheid.

De kernuitdaging die door Coral wordt aangepakt, is de kostenefficiënte, adaptieve serving van meerdere LLM's op heterogene cloudbronnen. Dit vereist het gezamenlijk optimaliseren van twee nauw met elkaar verbonden beslissingen:

Resource Allocatie: Bepalen welke knooppunten moeten worden geprovisioneerd in verschillende cloudregio's.
Model Plaatsing: Beslissen hoe elk model over die heterogene knooppunten moet worden gepartitioneerd (bijvoorbeeld via pipeline-parallelisme en data-parallelisme).

Bestaande systemen slagen er niet in om dit end-to-end aan te pakken. Eerdere werken optimaliseren ofwel de resource allocatie onder de aanname van homogene replica's (waardoor modelplaatsingsoptimalisatie wordt genegeerd), of ze optimaliseren de plaatsing voor een enkel model op een vaste set knooppunten (waardoor globale allocatie wordt genegeerd). Een brute-force gezamenlijke optimalisatie is onuitvoerbaar vanwege de exponentiële zoekruimte van beide dimensies en de vereiste voor snelle heroplossing (minuten, niet uren) om zich aan te passen aan fluctuerende vraag en resourceprijzen.

2. Methodologie

Coral introduceert een adaptief, heterogeniteitsbewust systeem dat het gezamenlijke optimalisatieprobleem ontbindt in een verliesvrije tweestapsdecompositie.

Kerninzicht: Serving Templates

Coral observeert dat voor een vast model en een latency Service Level Objective (SLO), de doorvoeroptimale modelplaatsing op een specifieke set knooppunten alleen afhankelijk is van die knooppuntencombinatie, onafhankelijk van hoe de rest van het cluster is toegewezen. Dit maakt het mogelijk om de zoektocht naar plaatsing offline te verplaatsen.

Stap 1: Offline Generatie van Serving Templates

Proces: Voor elk (model, SLO)-paar enumerateert Coral een principieel subset van knooppuntencombinaties. Voor elke combinatie gebruikt het een Integer Lineair Program (ILP) om de doorvoeroptimale modelplaatsing (laagpartitionering en knooppunttoewijzing) te berekenen die voldoet aan de latency SLO.
Output: Een Serving Template Library. Elke template is een herbruikbaar artefact dat een knooppuntencombinatie en de bijbehorende optimale plaatsingsstrategie specificeert.
Optimalisatie: Het ILP maximaliseert de doorvoer onderhevig aan latency-beperkingen. Om de combinatorische complexiteit het hoofd te bieden, snoept Coral de zoekruimte in door het maximum aantal knooppunten per template ( $N_{max}$ ) en de totale memory ratio ( $\rho$ ) ten opzichte van de modelgrootte te beperken, aangezien grotere combinaties vaak onaanvaardbare communicatie- overhead met zich meebrengen.

Stap 2: Online Resource Allocatie

Proces: De online resource allocator vraagt periodiek de vooraf berekende Serving Template Library op. Het lost een tweede, lichtgewicht ILP op om te bepalen welke templates over regio's moeten worden geïnstancieerd om de huidige doorvoervraag tegen minimale kosten te vervullen.
Inputs: Real-time doorvoervraag, GPU-beschikbaarheid en prijsstelling in verschillende regio's.
Doel: Minimaliseren van totale provisioneringskosten plus een initialisatieboete (om excessieve churn te ontmoedigen) terwijl doorvoer- en beschikbaarheidsbeperkingen worden nageleefd.
Efficiëntie: Door de complexe zoektocht naar modelplaatsing uit het kritieke pad te tillen, voltooit de online solver in tientallen seconden in plaats van uren, waardoor het cluster zich kan aanpassen aan dynamische verschuivingen in vraag en aanbod.

Systeemimplementatie

Coral is geïmplementeerd als een runtime-systeem met ZeroMQ voor controle, NCCL voor communicatie binnen een instantie en vLLM als uitvoeringsengine. Het ondersteunt zowel Prefill-Decode (PD) gedisaggreerde als geaggregeerde serving. Een high-fidelity event-based simulator, gevalideerd tegen echte hardware, wordt gebruikt voor evaluatie op grote schaal waar fysieke provisionering kostenprohibitief is.

3. Belangrijkste Bijdragen

Het artikel claimt de volgende bijdragen:

Probleemformulering: Een formalisering van heterogeniteitsbewuste multi-LLM serving als een gezamenlijke optimalisatie over resource allocatie en model plaatsing onder per-model latency SLO's.
Verliesvrije Decompositie: Een nieuwe tweestapsbenadering met behulp van herbruikbare Serving Templates om de complexe zoektocht naar plaatsing offline te verplaatsen, waardoor online oplostijden van uren naar tientallen seconden worden teruggebracht zonder in te leveren op optimaliteit.
Schalbare Solvers: ILP-gebaseerde solvers voor zowel offline plaatsing als online allocatie die schalen tot clusters van duizenden knooppunten.
End-to-End Systeem: Een volledige implementatie van Coral en een gevalideerde simulator voor evaluatie op grote schaal.
Empirische Validatie: Evaluatie over 6 modellen en 20 GPU-configuraties die aanzienlijke kostenreducties en verbeterde goodput aantonen.

4. Resultaten

De evaluatie werd uitgevoerd over diverse modellen (variërend van 14B tot 235B parameters) en GPU-configuraties (inclusief H100, A100, L40S, L4, A10G) onder variërende resourcebeschikbaarheid.

Kostenefficiëntie: Coral verlaagt de servingkosten met maximaal 2,79× ten opzichte van de beste baseline (Homo, die homogene replica's gebruikt) en 2,66× ten opzichte van Cauchy (een PD-gedisaggreerde baseline) in uitgebreide setups. In kernsets waren de reducties respectievelijk 1,62× en 1,60×.
Goodput onder Schaarste: Onder schaarste aan resources levert Coral tot 2,39× hogere goodput (tokens per seconde die voldoen aan SLO's) op dan baselines. Dit wordt bereikt door gezamenlijk resources over modellen te coördineren om contentie op te lossen, terwijl baselines falen om vraag voor specifieke modellen in te vullen.
Oplostijd: De online resource allocatie ILP lost gemiddeld op in 0,24 seconden (kernset-up) en 9,68 seconden (uitgebreide set-up), ruim binnen het vereiste aanpassingsvenster.
Vergelijking met Helix: In een single-model regime op een vaste heterogene cluster verlaagde Coral de kosten met 21% en verbeterde de doorvoer met 26% ten opzichte van Helix, terwijl strikt werd voldaan aan latency SLO's.
Sensitiviteit: Analyse toont aan dat de kostenefficiëntie van gegenereerde templates plateauert wanneer de knooppuntcap ( $N_{max}$ ) op 6 wordt ingesteld en de memory ratio ( $\rho$ ) op 12, wat de snoeistrategie rechtvaardigt.

5. Betekenis

Het artikel betoogt dat gezamenlijke optimalisatie van resource allocatie en model plaatsing essentieel is voor kostenefficiënte multi-LLM serving. Door modelreplica's als black boxes te behandelen op homogene hardware, laten bestaande systemen aanzienlijke kostenbesparingen liggen en worstelen ze onder resourcebeperkingen. Coral toont aan dat inhoudelijke heterogeniteit binnen replica's—het mengen van verschillende GPU-types binnen een enkele modelreplica via hybride pipeline- en data-parallelisme—systemen in staat stelt instanties af te stemmen op specifieke workloadkenmerken en SLO's.

De betekenis van Coral ligt in het vermogen om deze gezamenlijke optimalisatie uitvoerbaar en adaptief te maken. Door optimale plaatsingen vooraf te berekenen als herbruikbare templates, overbrugt het de kloof tussen de theoretische optimaliteit van gezamenlijke zoektochten en de praktische noodzaak van snelle, online herconfiguratie. Dit stelt cloudproviders in staat een bredere, kosteneffectievere reeks GPU-inventaris te benutten terwijl ze strikte latency-garanties handhaven voor diverse, gelijktijdige LLM-workloads.