Technische Samenvatting: Astrolabe

Probleemstelling

Het serveren van Large Language Model (LLM) inferentie staat voor aanzienlijke uitdagingen op het gebied van load balancing vanwege de inherente onvoorspelbaarheid van werkbelastingen. In tegenstelling tot traditionele cloudtaken vertonen LLM-verzoeken variabele responslengtes, dynamisch geheugengebruik (KV-cache) en een hoge variantie in de latentie van decodingsstappen door schommelingen in de batchgrootte en interferentie tussen verzoeken.

Huidige multi-instance serving frameworks vertrouwen vaak op eenvoudige heuristieken (bijv. round-robin) of reactieve rebalanceringstrategieën zoals live migratie (bijv. Llumnix).

• Heuristieken: Houden geen rekening met de specifieke belasting die een nieuw verzoek zal opleggen, wat leidt tot "herding" (geitengedrag), waarbij meerdere verzoeken naar dezelfde instantie worden gerouteerd, wat zorgt voor transiënte overbelasting.
• Live Migratie: Hoewel effectief bij het herverdelen van de belasting, introduceert het migreren van KV-caches tussen instanties aanzienlijke netwerk-, geheugen- en orchestratieoverhead. Onder hoge belasting kunnen deze kosten zich ophopen, concurreren met het normale servingverkeer en de tail-latentie verslechteren of zelfs de prestaties van de cluster doen instorten.

De kernuitdaging is het bereiken van hoogwaardige load balancing in een multi-instance LLM-cluster zonder te vertrouwen op dure migratie of te lijden onder het "thundering herd"-probleem, terwijl de control-plane overhead van de scheduler zelf wordt geminimaliseerd.

Methodologie: Astrolabe

Astrolabe is een gerandomiseerde, voorspellingsgestuurde scheduler ontworpen voor one-shot request dispatch. Het vermijdt migratie door hoogwaardige plaatsingsbeslissingen te nemen vóór de uitvoering, gebaseerd op gesimuleerde latentievoorspellingen.

Systeemarchitectuur

Het systeem bestaat uit vier hoofdonderdelen:

1. Query Length Tagger: Een lichtgewicht service (gebruikmakend van een fine-tuned RoBERTa regressiemodel) die de responslengte van een inkomend verzoek schat op basis van de prompt.
2. Global Scheduler: Een stateless service die verzoeken ontvangt en een doelinstantie selecteert.
3. Predictor Sidecars: Per-instance services die naast de inference backend draaien. Ze raadplegen de lokale runtime-status (bijv. lopende verzoeken, geheugenblokken) en simuleren het inkomende verzoek om een doelmetriek te schatten (standaard: End-to-End latentie).
4. Inference Backends: De eigenlijke LLM serving frameworks (bijv. vLLM, SGLang) die agnostisch zijn voor de scheduling-logica.

Kern Dispatch Policy: Power-of-Two Choices (Po2)

In plaats van alle $N$ instanties te bevragen (full fanout), wat $O(N)$ control-plane kosten met zich meebrengt en herding verergert, hanteert Astrolabe een Power-of-Two Choices strategie:

1. Voor elk inkomend verzoek selecteert de scheduler twee willekeurige instanties.
2. Het bevraagt de Predictor sidecars van deze twee instanties parallel.
3. Het verzoek wordt gedispatched naar de instantie met de laagste voorspelde latentie.

Deze aanpak doorbreekt het herding-effect door de probe-set te randomiseren (gelijktijdige verzoeken zullen onwaarschijnlijk dezelfde paren selecteren) en vermindert de CPU-kosten voor scheduling per verzoek met een factor van $\sim N/2$ vergeleken met full fanout.

Voorspellingsmechanisme

De Predictor sidecar maakt gebruik van een simulatie-gebaseerde aanpak (geadapteerd van het Vidur framework) om latentie te schatten:

• Input: De prompt van het verzoek, de geschatte responslengte en de huidige lokale runtime-status.
• Proces: Het simuleert het verzoek door de lokale scheduler-batching logica en gebruikt een lineair model om de executietijden voor de resulterende batches te voorspellen.
• Output: Een scalaire metriek (bijv. verwachte E2E latentie).
• Robuustheid: Het systeem gaat om met voorspellingsfouten door te vertrouwen op de relatieve rangorde tussen de twee gesamplede kandidaten in plaats van op absolute waarden. Common-mode fouten (bijv. systeemruis) vallen tegen elkaar weg, en het systeem is ontworpen om aanzienlijke ruis (tot 100% Gaussische ruis in experimenten) te tolereren met minimale prestatieverslechtering.

Belangrijkste Bijdragen

1. Analyse van Onvoorspelbaarheid: Het paper identificeert waarom runtime-metrieken (geheugen, doorvoer) onvoldoende zijn voor LLM load balancing en benadrukt de specifieke "herding" problemen veroorzaakt door deterministische dispatch in omgevingen met een hoge variantie.
2. Astrolabe Systeemontwerp: Het stelt een one-shot, gerandomiseerde scheduler voor die response-lengte schatting, per-instance simulatie en Po2 dispatch combineert. Dit ontwerp bereikt hoogwaardige load balancing zonder live migratie.
3. Uitgebreide Evaluatie: De auteurs evalueren Astrolabe over twee clusters (12-GPU A30 en 2-node A100), twee modellen (Llama-2-7B/70B, Qwen2-7B) en meerdere datasets (ShareGPT, BurstGPT). Ze vergelijken het met vijf baselines (Random, Round-Robin, Min QPM, INFaaS++, Llumnix-) en analyseren de gevoeligheid voor voorspellingsfouten, bursty verkeer en configuratiewijzigingen.

Experimentele Resultaten

Geëvalueerd op een 12-GPU A30 cluster met Llama-2-7B en ShareGPT:

• Capaciteit: Astrolabe evenaart de SLO capaciteit van de beste load-aware baseline (Llumnix- zonder migratie) bij 31.6 QPS (vs. 31.5 QPS).
• Latentie:
  • Gemiddelde TTFT: 8–36% lager dan de beste baseline.
  • P99 TTFT: 16–77% lager dan de beste baseline.
  • Gemiddelde E2E: Tot 5.6% lager.
• Stabiliteit: Bij capaciteit (QPS=32) ervaart Astrolabe ~6× minder preempties (300) vergeleken met Llumnix- (1,800).
• Overhead: De per-predictor CPU-utilisatie is met ~2.8× verminderd vergeleken met een full fanout aanpak.
• Vergelijking met Migratie (A100 Cluster): Vergeleken met volledige Llumnix (met live migratie ingeschakeld) op een A100 cluster, presteert Astrolabe tot 2.6× beter in doorvoer bij verzadiging en bereikt ordes van grootte lagere per-token latentie. Dit demonstreert dat migratie-overhead de serving-prestaties onder hoge belasting kan laten instorten.
• Robuustheid: Astrolabe behoudt prestaties onder configuratiewijzigingen (verschillende batchgroottes, modellen, datasets) en is veerkrachtig tegen geïnjecteerde voorspellingsruis.

Betekenis en Claims

Het paper claimt dat Astrolabe aantoont dat voorspellingsgestuurde one-shot dispatch een gelijkwaardige of betere load balancing kan bieden dan migratie-gebaseerde rebalancering, terwijl het de aanzienlijke overhead van KV-cache transfers vermijdt.

Belangrijkste punten die door de auteurs worden benadrukt:

• Migratie is niet altijd de oplossing: Onder hoge belasting kunnen de netwerk- en orchestratiekosten van migratie de tail-latentie en doorvoer meer verslechteren dan de voordelen van rebalancering.
• Randomisatie is effectief: De Power-of-Two Choices policy mitigeert het request herding effect effectief en vermindert de control-plane overhead zonder dat complexe globale status nodig is.
• Simulatie is levensvatbaar: Ondanks de onvoorspelbaarheid van LLM's is simulatie-gebaseerde latentievoorspelling gecombineerd met lengteschatting accuraat genoeg om effectieve scheduling beslissingen te sturen, zelfs met imperfecte predictors.

De auteurs concluderen dat Astrolabe een praktische, schaalbare oplossing biedt voor multi-instance LLM serving die de latentie en doorvoer verbetert, terwijl het compatibel blijft met bestaande backends en de complexiteit van live migratie vermijdt.