Improving LLM Performance Through Black-Box Online Tuning: A Case for Adding System Specs to Factsheets for Trusted AI

Dit paper introduceert een nieuwe black-box online controller die end-to-end metingen gebruikt om de goodput van LLM-diensten te maximaliseren en pleit op basis hiervan voor het opnemen van systeemprestaties en duurzaamheidsmetrieken in AI-factsheets om vertrouwen te waarborgen.

De kern

Stel je voor dat je een populaire koffiezaak runt. Je hebt een fantastische barista (de AI, of "LLM" in vakjargon) die heerlijke koffie (antwoorden) maakt. Maar er is een probleem: op drukke tijden wordt de rij lang, en sommige klanten moeten zo lang wachten dat ze boos worden en weglopen, terwijl anderen hun koffie snel krijgen.

De eigenaar van de zaak (de systeembeheerder) probeert vaak de barista sneller te maken door meer klanten tegelijk te bedienen of de machine harder te laten draaien. Maar dit werkt averechts: de rij wordt chaotisch, de wachttijd voor de laatste klanten (de "staart" van de rij) explodeert, en de kwaliteit zakt.

Dit artikel introduceert een slimme automatische manager genaamd SLO-Tuner die dit probleem oplost, en pleit ervoor dat we in de "gebruikershandleidingen" van AI-systemen ook eerlijk vertellen hoe goed ze presteren onder druk.

Hier is de uitleg in drie simpele delen:

1. Het Probleem: De "Stille" Wachtrij

In de wereld van AI draait alles om snelheid. Maar vaak kijken bedrijven alleen naar het gemiddelde.

• De analogie: Stel, 99 klanten krijgen hun koffie in 1 minuut, maar 1 klant moet 10 minuten wachten. Het gemiddelde is prima, maar die ene klant is razend.
• In AI noemen we dit de p99 (de 99e percentiel). Het betekent: "99% van de gebruikers moet binnen een bepaalde tijd (bijv. 1,2 seconde) een antwoord hebben." Als dit niet lukt, is het systeem voor die 1% failliet, zelfs als de rest blij is.

2. De Oplossing: SLO-Tuner (De Slimme Manager)

De auteurs hebben een systeem bedacht dat de AI-server als een zwarte doos behandelt. Ze kijken niet naar de interne schroeven, maar alleen naar het resultaat: "Krijgt de klant zijn koffie op tijd?"

• Hoe werkt het?
  De manager probeert continu kleine aanpassingen, alsof je de temperatuur van de koffie regelt:

  • Meer klanten tegelijk? (Concurrentie)
  • Grotere bakken koffie zetten? (Batchgrootte)
  • De barista laten voorspellen wat de klant wil? (Speculatieve decoding - een trucje om sneller te zijn).

  De manager gebruikt een heuvelklim-methode: "Als ik dit knopje iets draai, wordt de wachtrij korter en blijven de klanten tevreden? Ja? Dan houd ik het zo. Nee? Dan draai ik terug."

• Het verrassende resultaat:
  Vaak denken mensen: "Hoe meer voorspelling (speculatie), hoe sneller." Maar de manager ontdekte dat bij drukte juist minder voorspellen beter werkt! De barista probeerde dan te veel te gissen, maakte fouten, en moest alles opnieuw doen, wat de wachtrij juist lang maakte.

  • Het resultaat: Door de instellingen slim aan te passen, halveerde de wachttijd (van 1,36 naar 0,70 seconde) en verdubbelde het aantal tevreden klanten dat op tijd bediend werd.

3. De Simulatie: De Proefkeuken

Voordat ze de manager in de echte zaak zetten, hebben ze een virtuele proefkeuken (een simulator) gebouwd.

• De analogie: Net als een kok die eerst een recept in de keuken test voordat hij het aan de klanten serveert.
• Deze simulator is niet perfect (de koffie smaakt er net iets anders), maar hij voorspelt wel goed hoe de rij zich zal gedragen als je de instellingen verandert. Dit bespaart tijd en geld, want je hoeft niet elke keer de echte server te resetten om te testen.

4. De Belangrijkste Boodschap: Eerlijke Gebruikershandleidingen (Factsheets)

Dit is het meest interessante deel voor de gewone gebruiker.
Tot nu toe zeggen bedrijven over hun AI: "Onze AI is slim, eerlijk en veilig." Maar ze vergeten vaak te zeggen: "Hoe snel is hij als het druk is?"

De auteurs pleiten ervoor dat AI-systemen een Factsheet (een soort voedingsinformatielabel) moeten krijgen.

• Huidige situatie: "Deze AI is goed." (Maar wat als hij traag is op drukke momenten? Of veel energie verbruikt?)
• Nieuwe eis: "Deze AI is goed, en hier is de waarheid: Hij werkt snel tot 100 gebruikers, maar daarna wordt hij traag. Hij verbruikt X energie."

Waarom is dit belangrijk?
Als bedrijven niet weten hoe een AI presteert onder druk, kunnen ze onbewust fouten maken:

• Ze zetten de AI in voor kritieke taken (zoals medische diagnoses), maar bij piekmomenten is hij te traag.
• Ze proberen de snelheid te forceren door de instellingen verkeerd te zetten, wat leidt tot onrechtvaardige resultaten of bias (vooringenomenheid).
• Ze vergeten dat snellere AI vaak meer energie kost, wat slecht is voor het milieu (duurzaamheid).

Conclusie

Deze paper zegt eigenlijk: "Stop met blind vertrouwen op het gemiddelde."
Met een slimme, automatische manager (SLO-Tuner) kunnen we AI-systemen veel eerlijker en sneller maken voor iedereen, niet alleen voor de gemiddelde gebruiker. En we moeten die prestaties eerlijk op een label plakken, zodat iedereen weet waar hij aan begint.

Het is alsof we eindelijk eisen dat een auto niet alleen "snel" is, maar ook eerlijk aangeeft hoe hij zich gedraagt in de file, zodat je als bestuurder een goede keuze kunt maken.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Improving LLM performance through black-box online tuning: a case for adding system specs to Factsheets for Trusted AI", geschreven in het Nederlands.

Probleemstelling

De implementatie van Large Language Models (LLM's) in interactieve diensten wordt gedomineerd door tail latency (de latentie van de langzaamste 1% van de verzoeken, vaak gemeten als p99). In de praktijk worden operationele punten bepaald door een kleine set instellingen van de server-stack, zoals:

• Client-concurrentie (aantal gelijktijdige verzoeken).
• Batching-limieten (hoeveelheid sequenties gegroepeerd voor GPU-executie).
• Parameters voor speculatieve decoding (het gebruik van een kleiner model om tokens te voorspellen).

Deze instellingen interageren op een manier die afhankelijk is van de werklast en de hardware. Standaardconfiguraties kunnen leiden tot twee uitersten:

1. Onderschatting: Expensive GPU's worden niet optimaal benut.
2. Overbelasting: Het systeem raakt in een wachtrij-probleem, waardoor de p99-latentie explodeert en een minderheid van de gebruikers extreme vertragingen ervaart, zelfs als de gemiddelde latentie acceptabel lijkt.

Het huidige probleem is dat systemen vaak worden geoptimaliseerd voor gemiddelde doorvoer, terwijl voor interactieve diensten het voldoen aan een Service Level Objective (SLO) voor tail latency (bijv. p99 ≤ 1,2 seconden) cruciaal is voor eerlijkheid en gebruikerservaring.

Methodologie: SLO-Tuner

De auteurs introduceren SLO-Tuner, een nieuwe aanpak voor black-box online tuning. Het systeem werkt zonder interne instrumentatie van de LLM-server en gebruikt alleen end-to-end metingen.

Kerncomponenten:

1. Black-box Controller: De tuner ziet de server als een "black box". Hij stuurt alleen publieke API-eindpunten en command-line flags aan.
2. Doelstelling (Goodput): In plaats van maximale doorvoer te maximaliseren, maximaliseert SLO-Tuner de goodput. Dit is het aantal verzoeken per seconde dat daadwerkelijk binnen de SLO-tijdslimiet wordt voltooid. Verzoeken die de SLO schenden, tellen niet mee.
3. Hill-Climbing Algorithm: De controller gebruikt een deterministische hill-climbing-strategie:
   • Het start met een basisconfiguratie.
   • Het voert korte meetsegmenten uit (bijv. 30 seconden met 10 seconden warm-up).
   • Het evalueert de huidige configuratie en een kleine set buren (naaste waarden van de knoppen).
   • Het verplaatst zich naar de beste buur als de score verbetert, met een sterke straf voor het schenden van de p99-SLO.
4. Logische Knoppen: De tuner manipuleert een vector van knoppen:
   • Concurrentie (conc).
   • Batchgrootte (max_num_seqs).
   • Speculatieve decoding breedte (spec_tokens) en aan/uit-schakeling.
5. Discrete-Event Simulator: Om kostbare stress-tests op live hardware te vermijden, gebruiken de auteurs een lichtgewicht simulator. Deze simuleert wachtrij- en batching-dynamiek en helpt bij het vinden van veilige zoekrichtingen voordat de live tuning begint. De simulator is gekalibreerd om kwalitatieve trends van het live systeem na te bootsen.

Scorefunctie:
De controller maximaliseert een score $S(K)$ die bestaat uit de goodput minus een straf voor SLO-schendingen en een kostenfactor voor hardware-intensiteit:
$$S(K) = \text{goodput}(K) - \lambda \cdot \max(0, p99(K) - \text{SLO}) - \text{hw\_cost}(K)$$
Hierbij zorgt een hoge $\lambda$ ervoor dat zelfs kleine SLO-schendingen zwaar wegen ten opzichte van kleine winsten in doorvoer.

Belangrijkste Bijdragen

1. SLO-first Doelstelling: Formulering van online tuning voor LLM-serving als het maximaliseren van goodput onder een expliciete p99-beperking, in plaats van het optimaliseren van gemiddelde latentie.
2. Speculatieve Decoding als Runtime-Knop: Behandeling van speculatieve decoding parameters als dynamisch instelbare waarden. De auteurs tonen aan dat de "beste" instelling werklast-afhankelijk is en dat te agressieve speculatie de p99 kan verslechteren.
3. Portable Logische Knoppen: Introductie van een kleine set operator-vriendelijke knoppen (wachtrijdruk, batchvorming, speculatie-agressiviteit) die via een dunne adapter worden gemapt naar stack-specifieke flags (bijv. vLLM). Dit maakt black-box deploy mogelijk.
4. Simulator-Live Uitlijning: Een discrete-event simulator die de dominante dynamiek vastlegt en kwalitatief overeenkomt met live vLLM-gedrag, wat zoektochten en stress-tests mogelijk maakt zonder directe hardware-belasting.

Resultaten

De auteurs testten hun aanpak op TinyLlama (1.1B parameters) met de vLLM server op een NVIDIA L40S GPU.

• Verbetering in Performance:
  • P99 Latentie: Verminderd van ongeveer 1,36 s (standaardconfiguratie) naar 0,70 s.
  • Goodput: Verhoogd van ongeveer 8 naar 15 verzoeken per seconde (rps) onder een SLO van 1,2 s.
• Ablatie-studies:
  • Speculatieve Breedte: Het verkleinen of uitschakelen van de speculatieve breedte bleek cruciaal voor het voldoen aan de p99-SLO. Aggressieve speculatie (brede drafts) verhoogde de p99 aanzienlijk zonder de goodput te verbeteren.
  • Batchgrootte: Er is een duidelijk "knie-punt" (knee) bij batchgroottes rond 11-13 sequenties. Grotere batches leidden tot een snelle toename van de p99 en een ineenstorting van de goodput.
  • Concurrentie: Verhogen van concurrentie boven een bepaald punt (bijv. >10 threads) leidde tot een p99 van >1,6 s en een goodput van bijna 0, omdat de meeste verzoeken de SLO schonden.
• Simulator vs. Live: De simulator voorspelde correct de trends (bijv. dat kleinere batches en minder speculatie de tail-latentie verbeteren), hoewel de absolute tijden verschilden. Dit bevestigt de bruikbaarheid van de simulator voor richtingsgeleide zoektochten.
• Portable Check: Een test op Apple Silicon (MLX) bevestigde dat de simulator de richting van de respons op knop-wijzigingen correct voorspelde, ondanks hardware-specifieke verschillen.

Betekenis en Conclusie

Het paper maakt een sterk pleidooi voor de integratie van systeemperformance-metrics (zoals tail-latentie en goodput) in Factsheets for Trusted AI.

• Verantwoordelijk AI (Responsible AI): Als systeemperformance niet wordt gemonitord en geoptimaliseerd, kunnen organisaties gedwongen worden om parameters aan te passen die ten koste gaan van eerlijkheid, transparantie of bias-reductie om maar resultaten te leveren.
• Duurzaamheid: Efficiëntere LLM-diensten (meer goodput per GPU) dragen bij aan duurzaamheid door minder energie te verspillen aan verzoeken die toch falen of te traag zijn.
• Praktische Toepasbaarheid: SLO-Tuner is een praktische, black-box oplossing die bestaande cluster-schedulers en autoscalers kan aanvullen zonder deze te vervangen. Het biedt een bewezen methode om de betrouwbaarheid van AI-systemen in de productie te garanderen.

Kortom, de auteurs tonen aan dat het optimaliseren voor tail-latentie (p99) in plaats van gemiddelde prestaties, leidt tot een significant betere gebruikerservaring en een robuuster, eerlijker AI-systeem.