Scheduling-Strategien zur Maximierung der Auslastung bei der Skalierung von LLMs

Stell dir vor, du hast 100 GPUs laufen - und 70 % davon sitzen untätig, während deine Nutzer auf Antworten warten. Das ist keine Fantasie. Das ist der normale Zustand, wenn du Large Language Models (LLMs) ohne richtige Scheduling-Strategien skalierst. Die meisten Unternehmen beginnen mit einfachen Ansätzen: warte, bis genug Anfragen eingetroffen sind, batche sie, und los. Aber LLMs arbeiten nicht wie klassische Deep-Learning-Modelle. Sie generieren Text Wort für Wort, und jedes Wort braucht Zeit. Wenn du nicht clever planst, verschwendest du Millionen an Rechenleistung - und deine Nutzer werden ungeduldig.

Warum herkömmliches Batching bei LLMs versagt

Bei traditionellen Modellen ist die Eingabe und Ausgabe meist gleich lang. Ein Bild wird eingegeben, ein Label ausgegeben. Bei LLMs ist das anders. Ein Nutzer fragt: „Was ist die Hauptstadt von Frankreich?“ - Antwort: „Paris.“ Ein anderer fragt: „Schreibe einen 500-Wörter-Artikel über die französische Revolution.“ - Antwort: 500 Wörter. Beide Anfragen landen im gleichen System. Wenn du beide in einem Batch verarbeitest, musst du warten, bis die lange Antwort fertig ist. Die GPU bleibt blockiert - obwohl sie eigentlich schon mit der kurzen Antwort fertig wäre. Das nennt man padding waste: du verbrauchst Rechenleistung für leere Stellen, die nie ausgefüllt werden.

Studien von Zheng et al. (2023) zeigen: Durch einfaches Batching mit gleich langen Ausgaben kann man diesen Verschwendungseffekt um 22,3 % reduzieren. Wie? Indem du Anfragen in Gruppen von etwa 50 Token Länge einteilst. Kurze Antworten werden zusammengefasst, lange bleiben zusammen. Das ist der erste Schritt zur effizienten Nutzung.

Continuous Batching: Die Revolution hinter vLLM

Der Durchbruch kam mit continuous batching, wie er in vLLM implementiert ist. Statt auf feste Batch-Intervalle zu warten, fügt das System neue Anfragen dynamisch zu laufenden Prozessen hinzu - während sie noch generieren. Du hast eine Anfrage, die 300 Token braucht, und eine andere, die 150 Token braucht. Die erste ist bei 200 Token angelangt. Die zweite ist noch bei 50. Statt zu warten, fügt das System eine neue Anfrage mit 100 Token hinzu. Die GPU läuft nahezu kontinuierlich - von 30-40 % Auslastung auf 70-85 %, wie NVIDIA 2024 gemessen hat.

Dieser Ansatz ist nicht nur theoretisch. Unternehmen wie Clarifai und Red Hat haben damit ihre Throughput-Raten um das 3,7-Fache erhöht. Und das bei gleichzeitig 62 % niedrigerer Spitzenlatenz. Das bedeutet: mehr Antworten pro Sekunde, und sie kommen schneller. Für Kundenservice-Chatbots, die auf Millisekunden reagieren müssen, ist das kein Luxus - das ist Überleben.

Wie Vorhersagen die Effizienz verdoppeln

Die größte Waffe im modernen Scheduling ist die Prognose der Antwortlänge. Wenn du weißt, wie lang eine Antwort wird, kannst du sie gezielt mit ähnlichen Anfragen bündeln. Das ist einfacher gesagt als getan. Ein LLM kann nicht einfach zählen - es muss lernen, wie lange eine Antwort wird, basierend auf der Frage, dem Kontext, sogar dem Stil des Nutzers.

Systeme wie Sarathi-Serve und Orca nutzen leichte Vorhersagemodelle - oft zusätzliche Schichten am Ende des LLM -, die in Millisekunden abschätzen, ob eine Antwort 100, 500 oder 1000 Token braucht. Diese Vorhersagen sind nicht perfekt. Aber sie sind gut genug. Chen et al. (2025) zeigten, dass ein Algorithmus, der mit niedrigeren Schätzungen startet und sich dann anpasst, 15,8 % höhere Auslastung erreicht als Systeme, die immer die schlechteste Annahme treffen.

Ein Fehler in der Vorhersage? Das kann bis zu 22 % Durchsatzverlust bedeuten. Deshalb verwenden führende Systeme jetzt Ensemble-Modelle: mehrere Vorhersagen, die abgestimmt werden. Das reduziert den Fehler auf 7,3 %. Und das macht den Unterschied zwischen einem System, das gerade so funktioniert, und einem, das die Kosten halbiert.

Memory-Management: PagedAttention und der Schlüssel zur Stabilität

Jede Antwort eines LLM speichert Zwischenergebnisse - den Key-Value-Cache. Bei traditionellen Systemen wird dieser Cache als ein großer, zusammenhängender Block reserviert. Wenn eine Antwort kürzer ist als erwartet, bleibt Speicher ungenutzt. Und wenn eine neue Anfrage kommt, muss der Speicher neu angeordnet werden - teuer, langsam, fehleranfällig.

PagedAttention, entwickelt von vLLM, löst das, indem es den Cache in kleine, unabhängige Blöcke aufteilt - wie Seiten im RAM. Jede Anfrage greift nur auf die Blöcke zu, die sie braucht. Fragmentierung sinkt um 40,2 %. Das bedeutet: du kannst mehr Anfragen gleichzeitig halten, ohne den Speicher zu überlasten. Und du kannst schneller zwischen Aufgaben wechseln, ohne den Cache neu zu laden.

Dazu kommt prefix-aware routing: wenn ein Nutzer eine neue Frage stellt, die auf eine vorherige Antwort aufbaut, erkennt das System das automatisch. Red Hat fand heraus: dadurch wird die Zeit bis zum ersten Token um 63,4 Millisekunden verkürzt. Das ist nicht viel - aber für einen Nutzer, der auf eine Antwort wartet, fühlt es sich an wie eine Sekunde weniger Geduld.

Verteiltes Scheduling: Mehrere GPUs, eine kluge Strategie

Wenn du nur eine GPU hast, ist Scheduling wichtig. Wenn du 100 hast, ist es lebenswichtig. ExeGPT und PerLLM zeigen, wie man in verteilten Umgebungen effizient arbeitet. ExeGPT verteilt Aufgaben nicht gleichmäßig - sondern nach Last und Verarbeitungstiefe. Ein Layer, der besonders rechenintensiv ist, bekommt mehr GPU-Kapazität. Ein einfaches Round-Robin-Verfahren wäre hier ineffizient.

PerLLM geht noch einen Schritt weiter: es nutzt eine Kombination aus Edge- und Cloud-Computing. Kurze Anfragen werden am Rand verarbeitet - näher am Nutzer. Lange, komplexe Anfragen wandern in die Cloud. Durch ein Multi-Armed Bandit-Modell optimiert es Energieverbrauch und Latenz gleichzeitig. Ergebnis: 37,2 % weniger Energieverbrauch. Das ist nicht nur günstig - das ist nachhaltig.

Hardware-Anforderungen: Was du wirklich brauchst

Du kannst die beste Scheduling-Strategie der Welt nutzen - aber wenn deine Hardware nicht mithält, läufst du gegen eine Wand. Für produktive LLM-Systeme brauchst du NVIDIA A100 oder H100 GPUs mit mindestens 40 GB VRAM. Warum? Weil der KV-Cache bei großen Modellen (70B+ Parameter) gigantisch wird. Ein einziger langwieriger Request kann mehr als 10 GB Cache verbrauchen. Ohne genug Speicher bricht das System zusammen - oder du musst Anfragen abschneiden.

Und die Overhead-Kosten? Moderne Scheduler wie vLLM oder llm-d verbrauchen nur 1,2 bis 3,5 Millisekunden pro Anfrage. Das ist vernachlässigbar - wenn du sie richtig einstellst. Aber überkomplizierte Systeme mit zu vielen Vorhersagemodellen können bis zu 20 ms Overhead erzeugen. Das ist zu viel, wenn deine Latenz-SLO unter 200 ms liegen muss.

Implementierung: Wie lange dauert es, und lohnt es sich?

Du kannst mit vLLM in 2-3 Wochen loslegen. Du installierst es, stellst die Batch-Größe ein, und schon hast du 2,1-3,4-fach mehr Durchsatz. Kein großer Aufwand. Aber wenn du wirklich maximale Effizienz willst - mit Vorhersagemodellen, dynamischem Token-Budget, verteiltem Scheduling - brauchst du 6-8 Wochen. Und ein Team mit Erfahrung in verteilten Systemen, Transformer-Architekturen und Performance-Profiling.

Die ROI-Rechnung ist einfach: bei mehr als 500 gleichzeitigen Anfragen zahlt sich der Aufwand in durchschnittlich 8,2 Tagen aus. Ein Unternehmen mit 1.000 Anfragen pro Sekunde spart nach Gartner-Modellen bis zu 86,92 % der Kosten im Vergleich zu naivem Scheduling. Das sind nicht nur Tausende - das sind Millionen pro Jahr.

Was kommt als Nächstes?

Die Zukunft ist nicht nur smarteres Scheduling - sie ist selbstlernendes Scheduling. Meta testet bereits Systeme, bei denen ein leichtes LLM den Scheduler steuert. Es lernt aus vergangenen Lastmustern, Wetterbedingungen, Nutzerverhalten - und passt die Ressourcenverteilung in Echtzeit an. In Tests zeigte sich ein zusätzlicher Durchsatzgewinn von 12,7 %.

NVIDIA Triton Inference Server 3.0 (September 2025) integriert jetzt hardware-aware scheduling: es weiß, welche GPU welchen Typ von LLM am besten ausführt - und verteilt Aufgaben entsprechend. AWS SageMaker hat bereits 47 % seiner LLM-Nutzer auf seine eingebaute Scheduler-Schicht umgestellt - mit 68 % weniger Implementierungsaufwand.

Die Zukunft gehört nicht mehr den größten Modellen. Die Zukunft gehört den intelligentesten Systemen, die diese Modelle effizient nutzen. Scheduling ist nicht mehr ein Feature. Es ist die Grundlage für jede wirtschaftliche LLM-Implementierung.