Die gleichen 16 GPUs, doppelt so viele Nutzende: Inferenzbewusstes Routing für LLM-Cluster

TL;DR: Die gleichen 16 GPUs, doppelt so viele Nutzende. Ihre GPU-Rechnung bleibt unverändert, während sich die Kapazität verdoppelt. Ein Cluster, der 20 gleichzeitige Nutzende verwaltet hat, kann jetzt 200 bewältigen. Diese Zahlen werden durch den Inferenz Scheduler von llm-d ermöglicht, der jede Anfrage über einen verteilten Cluster mit Einblick in sämtliche Knoten, Warteschlangen und Caches weiterleitet. LLM-Anfragen (Large Language Model) sind langsam, uneinheitlich und teuer – der Inferenz Scheduler wurde genau dafür entwickelt.

Das Pattern, das auch sonst funktioniert

Jede GPU-Stunde hat ihren Preis. Die Frage ist, wie viel Arbeit Sie daraus gewinnen.

Über Kubernetes werden verteilte Services in großem Umfang erstellt, bereitgestellt und ausgeführt. In einer standardmäßigen Kubernetes-Konfiguration definieren Sie ein Deployment, legen eine Replikatanzahl fest, und ein Kubernetes-Service bietet Ihnen eine Einstiegsleiste mit Round Robin-Load Balancing für sämtliche Pods. Für REST APIs, Webservices und Microservices ist dieses Muster im Wesentlichen perfekt. Anfragen sind schnell und einheitlich und benötigen jeweils etwa die gleiche Zeit von unter einer Sekunde.

Sobald Sie jedoch damit beginnen, große generative Modelle in großem Umfang bereitzustellen, wie beispielsweise Open Source-Modelle der Llama-, Mistral- oder GPT-Klasse, gilt diese Annahme nicht mehr.

Wo Round Robin an seine Grenzen stößt

LLM-Inferenzanforderungen sind nicht wie normale HTTP-Anfragen. Diese Unterschiede beeinträchtigen das standardmäßige Load Balancing:

• Zeitvariabilität: Eine Anfrage kann weniger als eine Sekunde oder über eine Minute dauern, je nachdem, was das Modell tun soll. Round Robin verteilt Anforderungen, nicht Arbeit. Wenn ein Replikat eine Reihe langer, teurer Anfragen erhält, kommt es zu einem Engpass, während ein anderes weitgehend ungenutzt bleibt.
• Formvariabilität: Kurze Prompts mit langen generierten Antworten verhalten sich anders als lange Prompts mit kurzen Antworten. Das Compute-Profil, die Speicherauslastung und die Zeit bis zur Fertigstellung sind unterschiedlich.
• Phasenvariabilität: Jede Inferenzanforderung hat 2 interne Phasen: Prefill, wobei das System den gesamten Eingabe-Prompt in einem parallelen Durchlauf verarbeitet, und Decode, wobei das System die Antwort mit jeweils 1 Token generiert. Diese 2 Phasen haben unterschiedliche Ressourcenprofile, unterschiedliche Laufzeiten und unterschiedliche Lastempfindlichkeit. Ein System, das die beiden nicht unterscheiden kann, lässt sich auch nicht für beide optimieren.

Round Robin wurde für Workloads entwickelt, bei denen Anfragen kurzlebig, einheitlich und kostengünstig sind. Ein Scheduler, der keinen Einblick in die Anforderung hat, behandelt sie alle gleich.

Abbildung 1: Das Round Robin verteilt die Anzahl der Anfragen, nicht die Arbeit. Die gleichen 5 Anfragen (mit unterschiedlichen Größen und Rechenkosten) werden ungleichmäßig bei den Pods angezeigt. Ein Pod wird mit 2 langen Anfragen überlastet, während ein anderer hauptsächlich ungenutzt bleibt. Das inferenzbewusste Routing berücksichtigt Form, Größe und Last und verteilt die eigentliche Arbeit entsprechend.

Ein Cache-Hit im falschen Pod ist ein Cache-Miss

vLLM ist die De-facto-Standard-Inferenz-Engine für LLMs. Die wichtigen Hardware-Beschleuniger sind dafür optimiert, und neue Modelle werden mit Day-0-vLLM-Unterstützung ausgeliefert. Die Engine behandelt die Mechanismen der Inferenz auf einem einzelnen Knoten hervorragend.

vLLM hat das Interferenzmuster Caching eingeführt, um einen der teuersten Aspekte der Inferenz zu bewältigen, bei dem immer wieder die gleichen Prompt-Präfixe neu verarbeitet werden. Wenn mehrere Anfragen ein gemeinsames Präfix haben (ein System-Prompt, ein Dokument, eine Konversationshistorie), kann vLLM den Schlüssel-Wert-Zustand (Key-Value, KV) der ersten Berechnung zwischenspeichern und für nachfolgende Anfragen wiederverwenden. Bei einem Cache-Hit wird der Prefill-Schritt vollständig übersprungen: Die Zeit bis zum ersten Token (TTFT) verringert sich proportional auf den Anteil des Prompts, der bereits zwischengespeichert wurde, jedoch nur, wenn die Anforderung das spezifische Replikat erreicht, das diesen Cache enthält.

Eine Anfrage, die auf einem Replikat nahezu kostenlos wäre, wird an ein anderes weitergeleitet, wo sie von Grund auf neu beginnt. Die Optimierung ist vorhanden, wird aber vom Round Robin-Routing ignoriert.

Bei geringem Datenverkehr ist dies eine verpasste Gelegenheit. In großem Umfang zahlen Sie doppelt für die gleiche Rechenleistung.

Vom Knoten zum Cluster

Die Pods sehen nur sich selbst, obwohl die vLLM-Pods ihren Anteil an Anfragen gut bewältigen – Speicher verwalten, Batch-Verarbeitung effizient durchführen und Token so schnell bereitstellen, wie es die Hardware zulässt. Er weiß nicht, was seine Peers verarbeiten, welche Replikate ausgelastet sind oder wo sich der Prefix Cache-Zustand im Cluster befindet. 

Das Koordinierungsproblem befindet sich über dem Knoten, und Kubernetes ist die Plattform der Wahl für verteilte Infrastruktur und Orchestrierung in großem Umfang. Daher ist llm-d von Grund auf Kubernetes-nativ konzipiert, um genau dieses Problem zu lösen. 

In der Praxis zeigt sich das Inference Gateway (IGW) – eine Datenverkehrsschicht, die auf Envoy und der Kubernetes Gateway-API aufbaut, die LLM-Workloads versteht, nicht nur HTTP. Dahinter überwacht der Inference Scheduler die Pods im InferencePool in Echtzeit – Tiefe der Warteschlange, KV-Cache-Status und Auslastung – und leitet die Anfragen jeweils an die richtige Instanz weiter, statt an die nächste in der Rotation.

Abbildung 2: Das Inference Gateway (IGW) empfängt jede Anfrage und befragt den Inference Scheduler (EPP) über ext_proc. Der Scheduler bewertet alle Pods im InferencePool anhand von 2 Live-Signalen (KV-Cache-Status und Last), gibt den ausgewählten Endpunkt an IGW zurück und IGW leitet die Anfrage weiter. Bei einem Cache Hit wird der zwischengespeicherte Teil von Prefill wiederverwendet und Decode beginnt sofort. Bei einem Cache Miss wird Prefill vollständig ausgeführt.

Inferenzplanung in großem Umfang: Gleiche Hardware, doppelte Kapazität

Der Inferenz Scheduler (Inferenz Scheduler von llm-d oder EPP) macht die Koordination auf Cluster-Ebene konkret. Anstatt alle Pods austauschbar zu behandeln, wird jede Anforderung basierend auf Echtzeitsignalen weitergeleitet: Status des KV-Cache, Warteschlangenlänge und Auslastung Jede Anfrage wird zeitnah an die richtige Instanz gesendet.

Die Benchmark-Ergebnisse von llm-d v0.5 zeigen, was dies in der Praxis bringt.

Inferenzplanung (Qwen3-32B, 8 vLLM-Pods, 16 NVIDIA H100):

• Bis zu 109 % höherer Durchsatz im Vergleich zu einem Kubernetes-Basisservice Dieselben 16 GPUs bedienen bei ihrem Service Level-Ziel (SLO) ungefähr doppelt so viele gleichzeitige Nutzende.
• Bis zu 99 % kürzere Zeit bis zum ersten Token (TTFT) bei gleicher Last Der Benchmark zeigt, dass die Basis-TTFT unter hoher Last auf problematische etwa 80 Sekunden steigt. Mit intelligenter Planung lässt sie sich auf etwa 150 ms ausführen. Das ist der Unterschied zwischen einem Produkt, das sich fehlerhaft anfühlt, und einem, das sofort reagiert.
  • Der Benchmark unterstützt etwa 11.000 Ausgabetoken/s auf 16 GPUs. Geht man von etwa 1.000 Token pro Antwort und etwa 3 Anfragen pro Minute und aktivem Nutzenden aus, entspricht das etwa 200 parallelen Nutzenden unter Einhaltung des SLO – auf Hardware, bei der der Kubernetes-Basisservice ab mehr als 20 keine Leistung mehr liefert.

Jedes Ergebnis unterliegt einer Versionskontrolle und ist an einen bestimmten reproduzierbaren Guide gebunden.

Abbildung 3: llm-d-Inferenzplanung im Vergleich zu Kubernetes-Baseline – Mittlere TTFT und Gesamtdurchsatz im Vergleich zu QPS. Topologie: 8 x vLLM-Pods, 16 x NVIDIA H100 (TP=2). Workload: gemeinsam genutztes Präfix synthetisch, 150 Gruppen x 5 Prompts, 6K/1,2K/1K System-/Frage-/Ausgabelänge Ergebnisse: P50 TTFT 136–157 ms, 4,5–11.000 Output-Tok/s, bis zu 109 % höherer Durchsatz und 99 % niedrigere TTFT ggü. Baseline. Quelle: llm-d v0.5

vLLM optimiert den Knoten, llm-d optimiert den Cluster

vLLM und llm-d wurden für eine gemeinsame Nutzung entwickelt. Der Unterschied in der Performance zwischen der Ausführung ohne die jeweils andere Lösung ist messbar: 2x so viele Nutzende auf derselben Hardware, 99 % bessere Latenz unter Last, ein Cluster, der mit 250 gleichzeitigen Nutzenden genauso gut umgehen kann wie mit 20.

Wenn Sie 2 oder mehr Replikate ausführen, wird die intelligente Inferenzplanung heute auf Ihren Workload angewendet. Diese Performance-Lücke tritt nicht schrittweise auf. Sie ist der Unterschied zwischen einem Cluster, der skaliert, und einem, der Schwierigkeiten hat. 

Und hier beginnt die verteilte Inferenz.

Überzeugen Sie sich selbst von der Skalierung

Die llm-d-Guides und Benchmark-Konfigurationen hinter den Zahlen in diesem Blog-Beitrag sind öffentlich und reproduzierbar. Ein guter Ausgangspunkt ist das Release llm-d v0.5.

Red Hat AI Enterprise enthält eine für Unternehmen unterstützte Version von llm-d mit einer 60-tägigen kostenlosen Testversion von Red Hat AI Enterprise. Dies ist ein guter Ausgangspunkt, wenn Sie es auf Ihrer eigenen Infrastruktur ausführen möchten.

Wenn Sie zuerst den Scheduler in Aktion sehen möchten, erfahren Sie in der Einführung in llm-d interaktive Demo, wie Anfragen weitergeleitet werden.

Anmerkung des Autors: Die Benchmark-Daten stammen aus dem Release llm-d v0.5. Alle Ergebnisse sind mit den in den llm-d-Guides veröffentlichten versionierten Konfigurationen reproduzierbar.