HEXGEN-FLOW: Optimizing LLM Inference Request Scheduling for Agentic Text-to-SQL

Dit paper introduceert HEXGEN-FLOW, een kader voor het optimaliseren van de planning en uitvoering van multi-stap agentic Text-to-SQL-workflows op heterogene GPU-clusters, wat aanzienlijke verbeteringen oplevert in doorvoersnelheid en vermindering van latentie ten opzichte van bestaande frameworks.

De kern

Stel je voor dat je een zeer slimme, maar soms wat trage assistent hebt die een complexe opdracht moet uitvoeren: het vertalen van een vraag in gewone taal (bijvoorbeeld "Toon mij de winst van de laatste drie maanden") naar een complexe database-opdracht (SQL).

In de wereld van kunstmatige intelligentie (LLM's) is dit een populaire taak. Maar er is een probleem: deze assistent werkt niet in één keer. Hij moet eerst de database "lezen", dan een paar voorstellen doen, die testen, fouten corrigeren en uiteindelijk het beste antwoord kiezen. Dit is een keten van stappen.

Het probleem in grote bedrijven is dat ze honderden mensen tegelijk deze opdracht laten geven, op een serverpark met verschillende soorten computers (sommige supersnel, sommige wat trager). De bestaande systemen behandelen elke vraag als een losse, onafhankelijke taak. Dat is alsof je een postkantoor hebt waar elke brief apart wordt behandeld, zonder te kijken dat ze allemaal bij elkaar horen. Het resultaat? Verkeerde routes, lange wachtrijen en mensen die wachten tot hun vraag beantwoord is.

HEXGEN-FLOW is de oplossing die de auteurs van dit paper hebben bedacht. Laten we het uitleggen met een paar creatieve analogieën.

1. Het Probleem: De Verkeerde Postbode

Stel je een groot postkantoor voor (het serverpark) met verschillende bussen (de GPU's). Sommige bussen zijn snelle sportwagens (A100-chips), andere zijn wat langzamere bestelwagens (A6000-chips).

• Huidige systemen: Ze gooien de postbrieven willekeurig in de bus. Een zware, complexe brief belandt misschien in een trage bus, terwijl een lichte brief in een snelle bus zit die toch al vol zit.
• Het agens-probleem: Een "Text-to-SQL" vraag is geen enkele brief. Het is een reis van 20 brieven die op elkaar wachten. Als de eerste brief (de "schema linking") in de verkeerde bus zit en vertraging oploopt, wachten alle volgende 19 brieven. De hele reis vertraagt.

2. De Oplossing: HEXGEN-FLOW als Slimme Verkeersleider

HEXGEN-FLOW is als een super-slimme verkeersleider met twee niveaus van controle:

Niveau 1: De Globale Verkeersleider (De Dispatcher)

Deze persoon kijkt naar de hele keten van brieven.

• Slimme Routekeuze: Hij kijkt niet alleen naar welke bus het snelst is, maar ook naar welke bus de juiste "kracht" heeft voor die specifieke brief. Een zware, rekenkracht-gebaseerde brief krijgt hij mee in de snelle sportwagen. Een simpele brief mag in de bestelwagen.
• Geen Willekeur: Hij zorgt dat de zware taken niet allemaal in één bus belanden (overbelasting), terwijl de andere bus leeg staat. Hij balanceert het gewicht perfect.

Niveau 2: De Lokale Wachtrij (De Prioriteit)

Zodra een bus (een server) zijn brieven heeft, moet hij beslissen welke hij eerst bezorgt.

• De "Urgentie"-Meter: In de oude systemen werd er "eerstkomende, eerstbediend" gewerkt (FCFS). Maar wat als een brief die net binnenkwam, een deadline heeft die over 5 seconden verloopt, terwijl de brief die 10 minuten geleden binnenkwam, nog uren tijd heeft?
• HEXGEN-FLOW's truc: De lokale manager kijkt naar de urgentie. Hij zegt: "Die brief die net binnenkwam en bijna te laat is, gaat er nu uit, zelfs als hij later is aangekomen dan de andere." Hij houdt constant de tijd in de gaten die nog over is voor de hele reis. Als een stap vertraging oploopt, worden de volgende stappen "paniekeriger" en krijgen ze voorrang.

3. De "Zelflerende" Instelling (Alpha-Tuning)

Het systeem heeft een knop genaamd Alpha.

• Soms is het belangrijker om alles gelijkmatig te verdelen over de bussen.
• Soms is het belangrijker om de zware taken naar de snelste bussen te sturen.
• HEXGEN-FLOW heeft een simulatie die in de achtergrond draait. Het is alsof de verkeersleider elke paar minuten een "proefrit" doet in een virtuele wereld om te zien: "Hoe zou het zijn als ik de knop iets anders zet?" Als hij ziet dat de vertragingen toenemen, past hij de knop direct aan. Zo blijft het systeem altijd optimaal, zelfs als het verkeer plotseling verandert (bijvoorbeeld 's avonds veel meer gebruikers).

Waarom is dit zo belangrijk?

De resultaten van het paper zijn indrukwekkend:

• Sneller: De "staart" van de vertraging (de langzaamste 5% van de vragen) is 1,4 tot 1,5 keer sneller. Dat betekent dat de mensen die het langst moeten wachten, nu veel minder lang hoeven te wachten.
• Meer capaciteit: Het systeem kan 1,5 tot 1,8 keer meer vragen per seconde afhandelen zonder in te leveren op snelheid.

Samenvattend

HEXGEN-FLOW is als het verschil tussen een chaotisch postkantoor waar iedereen in de rij staat en een geautomatiseerd, slim logistiek centrum.

1. Het weet dat een vraag uit meerdere stappen bestaat (een keten).
2. Het stuurt de zware stappen naar de krachtigste machines.
3. Het laat de "paniekerige" taken (die bijna te laat zijn) altijd voorrang krijgen op de rustige taken.
4. Het leert continu bij om de beste route te kiezen.

Dit zorgt ervoor dat bedrijven hun slimme AI-assistenten kunnen gebruiken voor complexe database-vragen, zonder dat hun gebruikers urenlang hoeven te wachten op een antwoord.

Technische samenvatting

Probleemstelling

Recente vooruitgang in agentische Large Language Models (LLM's) heeft Text-to-SQL aanzienlijk verbeterd, waardoor gebruikers zonder database-expertise databases kunnen bevragen. Een typische agentische Text-to-SQL-workflow bestaat echter uit meerdere afhankelijke stadia (zoals schema-linking, SQL-candidaatgeneratie, zelfcorrectie en evaluatie) die een lange, sequentiële reeks LLM-aanroepen vereisen.

Het implementeren van deze systemen in productie op heterogene GPU-clusters (waarbij verschillende GPU-modellen met verschillende prestaties worden gebruikt) brengt drie fundamentele uitdagingen met zich mee:

1. Afhankelijkheden tussen verzoeken: Vertragingen in vroege stadia hebben een cascade-effect op latere stadia, wat het risico op het schenden van Service Level Objectives (SLO's) voor de totale query vergroot. Bestaande schedulers behandelen verzoeken vaak als onafhankelijk.
2. Heterogeniteit: Er is variatie in zowel de rekenkosten van de verschillende stadia van de workflow als in de rekenkracht van de beschikbare GPU-instanties. Bestaande frameworks (zoals vLLM) zijn niet ontworpen om deze combinatie van workflow-afhankelijkheden en hardware-heterogeniteit te optimaliseren.
3. Variërende SLO-beperkingen: In multi-tenant omgevingen moeten concurrente queries met verschillende SLO-eisen worden afgehandeld. Bestaande systemen missen vaak fijnmazige, query-specifieke deadline-bewustzijn over de verschillende stadia heen.

Methodologie: HEXGEN-FLOW

HEXGEN-FLOW is een nieuw framework dat is ontworpen om agentische Text-to-SQL-workflows efficiënt te plannen en uit te voeren op heterogene GPU-clusters. Het systeem maakt gebruik van een twee-niveau architectuur die direct ingaat op de bovengenoemde uitdagingen:

1. Globale Coördinator (Workload-Balanced Dispatching)

De globale coördinator is verantwoordelijk voor het toewijzen van binnenkomende LLM-inferentie-verzoeken aan specifieke modelinstanties.

• Strategie: In plaats van een simpele Round-Robin, gebruikt het een werklast-gebalanceerde dispatching.
• Mechanisme: Het schat de uitvoeringstijd van een verzoek op elke instantie (gebaseerd op input/output token lengtes) en combineert dit met de huidige wachtrijduur van die instantie.
• Formule: Een heuristische score wordt berekend: $Score = (1-\alpha) \cdot \frac{\beta}{t_{queue}} - \alpha \cdot t_{comp}$.
  • Hierbij wordt $\alpha$ gebruikt om de afweging te balanceren tussen het kiezen van de snelste instantie (uitvoeringstijd) en het balanceren van de werklast (wachtrijduur).
  • Dit zorgt ervoor dat zware taken naar krachtige hardware worden gestuurd, terwijl lichtere taken onderbenutte bronnen benutten.

2. Lokale Prioriteitswachtrij (Adaptive Local Priority Queue)

Elke modelinstantie beheert zijn eigen lokale wachtrij met een urgentie-gedreven prioriteitsmechanisme.

• SLO-budgettoewijzing: Voor elke query wordt een totaal SLO-budget dynamisch verdeeld over de individuele stadia. Als een vroeg stadium vertraging oploopt, wordt het resterende budget voor latere stadia aangescherpt.
• Urgentie-metriek: Verzoeken worden niet op aankomsttijd (FCFS) gesorteerd, maar op urgentie ($U_{i,j}$), gedefinieerd als het verschil tussen de geschatte uitvoeringstijd en het resterende SLO-budget.
  • $U_{i,j} = t_{comp} - (t_{SLO} - \tau_{elapsed})$.
  • Verzoeken die dichter bij het overschrijden van hun deadline komen, krijgen hogere prioriteit. Dit voorkomt "starvation" en maximaliseert de kans op het halen van SLO's.

3. Simulatie-gestuurde Tuning ($\alpha$-Tuning)

Om de optimale waarde voor de parameter $\alpha$ (in de dispatching-functie) te vinden, gebruikt HEXGEN-FLOW een lichtgewicht, online simulatieproces.

• Het systeem monitort de "tail latency" (P95) in een glijdend venster.
• Bij significante prestatiedegradatie wordt een simulatie uitgevoerd die historische traces herhaalt met verschillende $\alpha$-waarden om de waarde te vinden die de P95-latentie minimaliseert.
• Dit zorgt voor adaptiviteit aan veranderende werklastpatronen en hardware-configuraties.

Belangrijkste Bijdragen

1. Formulering van ontwerpprincipes: De auteurs identificeren drie kernprincipes voor het serveren van agentische Text-to-SQL: expliciet beheer van multi-stadia-afhankelijkheden, heterogeniteitsbewuste toewijzing en end-to-end SLO-garanties.
2. HEXGEN-FLOW Framework: Een nieuw systeem dat globale werklast-balancering combineert met lokale urgentie-gestuurde prioritering, specifiek ontworpen voor heterogene clusters.
3. Uitgebreide Evaluatie: Een robuuste evaluatie die aantoont dat het framework significant beter presteert dan de state-of-the-art (SOTA) LLM-servingsystemen (zoals vLLM, TGI, Ray Serve) onder diverse werklasten en hardware-configuraties.

Resultaten

De evaluatie is uitgevoerd op realistische benchmarks (o.a. BIRD-bench) met verschillende GPU-configuraties (Hetero-1, Hetero-2, Homogeen) en werklasten (tot 30 QPS). HEXGEN-FLOW overtreft alle baselines (vLLM, VTC, QLM, LLF, Ray) consistent:

• Latentie: HEXGEN-FLOW reduceert de P95 tail latency met een factor van 1,42x tot 1,56x (een reductie van 19,2% tot 56,2% in absolute termen) vergeleken met SOTA-systemen.
• Throughput: De systeemthroughput neemt toe met een factor van 1,49x tot 1,81x.
• Robuustheid: Het systeem behoudt zijn superioriteit ook onder zware werklasten, fluctuerende aankomstpatronen, en in multi-tenant scenario's met verschillende SLO-eisen.
• Ablatiestudies: De studies tonen aan dat zowel de globale werklast-balancering (WB) als de lokale prioriteitswachtrij (PQ) essentieel zijn; het verwijderen van een van beide componenten leidt tot aanzienlijke prestatieverlies.

Betekenis

HEXGEN-FLOW vult een cruciale lacune in de infrastructuur voor generatieve AI. Terwijl bestaande LLM-servers zijn geoptimaliseerd voor onafhankelijke inferentietaken, biedt dit framework de eerste robuuste oplossing voor multi-stadia, agentische workflows in heterogene productieomgevingen.

De belangrijkste implicaties zijn:

• Het maakt de productie-uitrol van complexe agentische Text-to-SQL-systemen haalbaar door SLO-garanties te bieden ondanks hardware-variatie.
• Het demonstreert dat dynamische, deadline-bewuste planning essentieel is voor het maximaliseren van de efficiëntie van dure GPU-bronnen.
• De aanpak is niet beperkt tot Text-to-SQL, maar biedt een blauwdruk voor het optimaliseren van andere complexe, DAG-gebaseerde (Directed Acyclic Graph) agentische workflows in de toekomst.