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

Diese Arbeit stellt einen neuen Black-Box-Online-Controller vor, der durch End-to-End-Messungen und Hill-Climbing den Goodput von LLMs maximiert, und nutzt dieses Beispiel, um die Notwendigkeit zu unterstreichen, Leistungs- und Nachhaltigkeitsmetriken in AI-Factsheets zu integrieren.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschung, als würde man sie einem Freund beim Kaffee erzählen, mit ein paar bildhaften Vergleichen.

Das Problem: Der überfüllte Supermarkt

Stellen Sie sich vor, Sie betreiben einen sehr beliebten Supermarkt (das ist Ihr KI-Modell, das Texte schreibt). Kunden (die Nutzer) kommen herein, um Dinge zu kaufen (Fragen zu stellen).

Das Problem ist: Der Supermarkt ist oft chaotisch.

1. Die Warteschlange: Wenn zu viele Kunden gleichzeitig an der Kasse sind, staut es sich. Die meisten kommen schnell durch, aber ein paar wenige warten ewig. In der Technik nennt man das "Tail Latency" (die Verzögerung am Ende der Warteschlange).
2. Der Manager: Der Ladenmanager (der Server) versucht, so viele Kunden wie möglich pro Stunde zu bedienen. Aber wenn er zu gierig wird und zu viele Kunden gleichzeitig an die Kassen drängt, bricht das System zusammen. Die Warteschlangen werden lang, und die ungeduldigen Kunden gehen wütend wieder.
3. Der "Zauberspruch": Es gibt einen Trick namens "spekulatives Decodieren". Das ist wie ein Kellner, der versucht, das Essen zu erraten, bevor der Koch es fertig hat. Meistens hat er recht und spart Zeit. Aber manchmal liegt er falsch, muss dann alles korrigieren, und das dauert am Ende sogar länger als wenn er einfach gewartet hätte.

Bisher haben die Manager oft nur auf die Durchschnittsgeschwindigkeit geachtet. Das ist wie wenn der Manager sagt: "Im Durchschnitt warten alle nur 2 Minuten!" – aber er ignoriert, dass 10 % der Kunden 20 Minuten warten müssen. Das ist unfair und nervig.

Die Lösung: Der "SLO-Tuner" (Der kluge Assistent)

Die Autoren haben einen neuen, cleveren Assistenten namens SLO-Tuner entwickelt. Dieser Assistent ist wie ein blindes Testkochen.

• Blindes Testen: Der Assistent darf nicht in die Küche schauen (er sieht nicht den Code oder die internen Maschinen). Er steht nur am Ausgang und zählt: "Wie viele Kunden haben ihre Bestellung innerhalb von 1,2 Sekunden bekommen?"
• Das Ziel (SLO): Sein einziges Ziel ist es, sicherzustellen, dass niemand länger als 1,2 Sekunden wartet. Wenn das Ziel erreicht ist, versucht er, so viele Kunden wie möglich zu bedienen.
• Der Versuch-und-Irrtum-Algorithmus: Der Assistent probiert kleine Änderungen aus:
  • "Lass uns 2 Kunden mehr an die Kasse lassen." -> Oh, jetzt warten die letzten 5 Minuten zu lange. Zurücksetzen!
  • "Lass uns den Zauberspruch (spekulatives Decodieren) ausschalten." -> Super! Plötzlich warten alle schnell.
  • "Lass uns die Kassenbänder etwas anders gruppieren." -> Perfekt.

Er klettert quasi einen kleinen Berg hoch (Hill-Climbing), immer nur einen Schritt weiter, bis er den höchsten Punkt findet, an dem niemand warten muss, aber trotzdem viele bedient werden.

Das Ergebnis: Ein Wunder für den Supermarkt

In ihren Tests mit einem kleinen KI-Modell (TinyLlama) hat dieser Assistent Wunder gewirkt:

• Vorher: Die Kunden warteten im schlimmsten Fall fast 1,4 Sekunden. Der Laden schaffte nur 8 Kunden pro Sekunde.
• Nachher: Die Wartezeit für die ungeduldigsten Kunden sank auf nur noch 0,7 Sekunden! Und der Laden schaffte plötzlich 15 Kunden pro Sekunde.

Das ist, als würde man den Supermarkt verdoppeln, ohne einen einzigen neuen Kellner einzustellen – nur durch besseres Management.

Der Simulator: Die Flugzeug-Simulation

Bevor der Assistent den echten Supermarkt betritt, testet er in einer Flugzeug-Simulation. Er simuliert Tausende von Kunden in einer Computerwelt, um zu sehen, welche Strategien funktionieren, ohne das echte System zu stören. Das ist wie ein Pilot, der erst im Simulator fliegt, bevor er mit echten Passagieren abhebt.

Warum das für "Vertrauenswürdige KI" wichtig ist

Am Ende des Papers diskutieren die Autoren etwas Philosophisches: Warum sollten wir uns das überhaupt ansehen?

Stellen Sie sich vor, Sie kaufen ein Auto. Der Verkäufer gibt Ihnen ein "Factsheet" (eine Datenkarte) und sagt: "Dieses Auto ist sicher und fair." Aber er erwähnt nicht, dass das Auto bei Regen schlechte Bremsen hat.

Die Autoren sagen: Das ist unser Problem mit KI.
Wir haben Datenkarten für KI, die sagen: "Dieses Modell ist genau" oder "Es ist fair". Aber sie sagen oft nichts darüber, wie das System unter Stress funktioniert.

• Wenn das System langsam wird, fangen Firmen vielleicht an, Tricks zu nutzen, die die Ergebnisse verzerren (Bias).
• Wenn das System zu viel Energie verbraucht, um langsam zu sein, schadet das der Umwelt (Nachhaltigkeit).

Die Forderung: Wir müssen diese technischen Leistungsdaten (wie schnell ist es wirklich? Wie fair ist es für die letzten 1 % der Nutzer?) direkt auf die "Datenkarte" (Factsheet) schreiben. Nur so können Nutzer und Firmen wirklich vertrauen, dass die KI auch in der echten Welt funktioniert und nicht nur auf dem Papier.

Zusammenfassung in einem Satz

Die Autoren haben einen blinden Assistenten gebaut, der KI-Systeme so einstellt, dass niemand lange warten muss, und fordert, dass wir diese Leistungsdaten endlich offenlegen, damit KI wirklich vertrauenswürdig wird.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Improving LLM performance through black-box online tuning: a case for adding system specs to Factsheets for Trusted AI" auf Deutsch.

1. Problemstellung

Der Einsatz von Large Language Models (LLMs) in interaktiven Diensten steht vor einer zentralen Herausforderung: Die Benutzererfahrung wird maßgeblich durch die Tail-Latenz (z. B. p99, die 99. Perzentil-Latenz) bestimmt, nicht durch den Durchschnitt.

• Konflikt: Operatoren versuchen oft, die GPU-Auslastung durch höhere Parallelität (Concurrency) und größere Batch-Größen zu maximieren. Dies führt jedoch häufig zu einem „Knie-Effekt" im Warteschlangenverhalten, bei dem die p99-Latenz plötzlich stark ansteigt und eine Minderheit der Nutzer extreme Verzögerungen erfährt.
• Fehlende Automatisierung: Bestehende Standardkonfigurationen sind oft suboptimal. Zudem werden Parameter wie spekulatives Decoding (die Verwendung eines kleinen Draft-Modells zur Vorhersage von Tokens) meist statisch gesetzt. Obwohl sie die durchschnittliche Latenz senken können, erhöhen sie durch abgelehnte Vorhersagen und zusätzliche Verifikationsarbeit oft die Varianz und verschlechtern die p99-Latenz.
• Mangel an Transparenz: Bisherige „Factsheets" für vertrauenswürdige KI (Trusted AI) konzentrieren sich auf Fairness und Bias, ignorieren jedoch oft systemische Leistungsdaten wie Tail-Latenz und Nachhaltigkeit, was zu einer unvollständigen Bewertung der Zuverlässigkeit führt.

2. Methodik: SLO-Tuner

Die Autoren stellen SLO-Tuner vor, einen Black-Box-Online-Controller, der die Leistung von LLM-Servern optimiert, ohne auf interne Instrumentierung des Servers zugreifen zu müssen.

• Zielsetzung (SLO-first): Das Ziel ist nicht die Maximierung des Rohdurchsatzes, sondern die Maximierung der Goodput (Anzahl der Anfragen, die eine Service-Level-Objective, SLO, erfüllen). Als SLO wird eine explizite p99-Latenzgrenze definiert (z. B. $\le 1,2$ Sekunden).
• Steuerungsparameter (Knobs): Der Controller passt drei logische Parameter an:
  1. Client Concurrency: Anzahl der parallelen Anfragen.
  2. Batch Size: Maximale Anzahl von Sequenzen pro GPU-Batch (max_num_seqs).
  3. Speculative Decoding: Aggressivität des spekulativen Decodings (Anzahl der Tokens oder Ein/Aus).
• Algorithmus:
  • Es wird ein Hill-Climbing-Verfahren verwendet. Der Controller startet von einer Basis-Konfiguration, misst die Goodput und p99-Latenz über kurze Segmente und bewertet benachbarte Konfigurationen.
  • Bewertungsfunktion: $S(K) = \text{Goodput}(K) - \lambda \cdot \max(0, p99(K) - \text{SLO}) - \text{HardwareCost}(K)$.
  • Der Parameter $\lambda$ bestraft SLO-Verletzungen stark, sodass Konfigurationen, die die Latenzgrenze überschreiten, auch bei höherem Durchsatz abgelehnt werden.
• Simulator: Um kostengünstiges Stress-Testing zu ermöglichen, wurde ein diskretes Ereignissimulations-Modell entwickelt. Dieses simuliert Warteschlangendynamiken und Batch-Verhalten, um Trends vorherzusagen, bevor Änderungen am Live-System vorgenommen werden. Der Simulator dient der groben Suche, während der Online-Controller die finale Feinabstimmung auf der echten Hardware vornimmt.
• Black-Box-Ansatz: Das System interagiert nur über öffentliche APIs (z. B. OpenAI-kompatible Endpunkte) und Kommandozeilen-Flags. Es erfordert keine Änderungen am Server-Code (z. B. vLLM).

3. Wichtige Beiträge

1. SLO-First-Optimierung: Formulierung des Tuning-Problems als Maximierung der SLO-erfüllenden Anfragen unter einer expliziten p99-Bedingung, anstatt nur den Durchschnittslatenzen zu folgen.
2. Spekulatives Decoding als Runtime-Knob: Die Erkenntnis, dass spekulatives Decoding nicht immer vorteilhaft ist und als dynamisch anpassbarer Parameter behandelt werden muss, der stark von der Arbeitslast und der SLO abhängt.
3. Portierbare Logik: Einführung einer kleinen Menge logischer „Knobs", die durch einen Adapter auf stackspezifische Flags (z. B. vLLM, MLX) abgebildet werden, was eine Black-Box-Bereitstellung ermöglicht.
4. Simulator-Live-Ausrichtung: Ein leichtgewichtiger Simulator, der qualitative Trends der Live-Systeme (z. B. vLLM) korrekt abbildet und zur Vorab-Exploration genutzt werden kann.

4. Ergebnisse

Die Evaluation erfolgte mit dem Modell TinyLlama (1.1B) auf einem vLLM-Server mit einer NVIDIA L40S GPU und einem Ziel-SLO von 1,2 Sekunden p99.

• Leistungssteigerung:
  • p99-Latenz: Reduktion von ca. 1,36 s (Standardkonfiguration) auf 0,70 s.
  • Goodput: Steigerung von ca. 8,1 auf 15,0 Anfragen pro Sekunde (fast eine Verdopplung).
• Verhalten der Parameter:
  • Spekulatives Decoding: In diesem Szenario war spekulatives Decoding mit großer Breite (z. B. 16 Tokens) schädlich für die p99-Latenz. Der Tuner schaltete es effektiv aus (Breite = 0), was zu den besten Ergebnissen führte.
  • Batch-Größe & Concurrency: Es zeigte sich ein klarer „Knie-Effekt". Zu große Batches oder zu hohe Concurrency-Werte führten zu einem Zusammenbruch der Goodput, da die p99-Latenz die SLO-Grenze überschritt.
• Simulator vs. Live: Der Simulator sagte die Trends korrekt voraus (z. B. dass größere Batches die Tail-Latenz erhöhen), auch wenn die absoluten Latenzwerte unterschiedlich waren. Dies bestätigte die Eignung des Simulators für die Trendanalyse.
• Portabilität: Ein Test mit MLX auf Apple Silicon bestätigte, dass die Richtung der Reaktion auf Parameteränderungen (z. B. Verschlechterung bei höherer Concurrency) konsistent ist, auch wenn die Hardware-Plattform wechselt.

5. Bedeutung und Fazit

Das Paper liefert zwei wesentliche Beiträge:

1. Technisch: Es demonstriert, dass Black-Box-Online-Tuning effektiv ist, um LLM-Dienste sowohl schneller als auch fairer (geringere Tail-Latenz) zu machen. Es widerlegt die Annahme, dass spekulatives Decoding immer vorteilhaft ist, und zeigt, dass es als kritischer, anpassbarer Parameter behandelt werden muss.
2. Gesellschaftlich/Verantwortungsvolle KI: Die Autoren argumentieren, dass Systemleistung und Nachhaltigkeit zwingend in Factsheets für Trusted AI integriert werden müssen.
   • Ohne transparente Leistungsdaten (wie p99-SLO-Einhaltung) könnten Organisationen gezwungen sein, Kompromisse einzugehen, die Fairness und Bias-Probleme verschärfen (z. B. durch Reduzierung der Datengüte oder Intransparenz, um Geschwindigkeit zu erzwingen).
   • Effizientere Systeme tragen auch zur Nachhaltigkeit bei, da weniger Rechenressourcen für die gleiche Anzahl erfolgreicher Anfragen benötigt werden.

Zusammenfassend zeigt die Arbeit, dass es nicht nur möglich, sondern notwendig ist, systemische Metriken in die Bewertung und Zertifizierung von KI-Systemen aufzunehmen, um deren Zuverlässigkeit und Vertrauen in der Praxis zu gewährleisten.