GPU-Effizienz verdoppeln – ohne Zusatzkosten

Lumen Photos | shutterstock.com

Ende 2025 wurde ich in eine Kapazitätsplanungsmaßnahme für einen global tätigen Einzelhändler einbezogen. Dieser hatte ein 70B-Modell in seine Pipeline für Produktsuchen und -empfehlungen integriert. Dabei löste jede Suchanfrage einen Inferenz-Call aus. Das sorgte zum Weihnachtsgeschäft schließlich für einen GPU-Stunden-Verbrauch, der dem Finance Team körperliches Unwohlsein bereitete.

Das Unternehmen hatte bereits von 24 auf 48 NVIDIA-H100-GPUs aufgestockt – die Latenz stieg jedoch unter Spitzenlast immer noch sprunghaft an. An dieser Stelle wurde meine Wenigkeit hinzugezogen, um eine einfache Frage zu beantworten: Werden angesichts der anhaltenden Probleme für den Januar-Ausverkauf 96 GPUs benötigt – oder spielt hier noch etwas anderes eine Rolle?

Ich begann also dort, wo ich bei solchen Projekten immer beginne: mit dem Profiling. Ich instrumentierte den Serving-Layer und schlüsselte die Nutzungsdaten nach Inferenzphasen auf. Das Ergebnis hat meine Perspektive auf die GPU-Infrastruktur grundlegend verändert: Während der Prompt-Verarbeitung – der Phase, in der das Modell den gesamten Benutzer-Input parallel liest – liefen die H100-GPUs mit einer Rechenauslastung von 92 Prozent, die Tensor-Kerne waren vollständig ausgelastet. Das ist bei einer 30.000-Dollar-GPU auch zu erwarten. Allerdings dauerte diese Phase etwa 200 Millisekunden pro Anfrage. Die nächste Phase, die Token-Generierung, nahm drei bis neun Sekunden in Anspruch. Während dieser Zeit sank die Auslastung der (selben) GPUs auf 30 Prozent. Die Rechenkerne blieben untätig, der Memory Bus lief allerdings auf Hochtouren, um den Attention-Cache auszulesen.

So wurden H100-Stundensätze vollständig bezahlt, lieferten allerdings nur für etwa fünf Prozent der Gesamtlaufzeit jeder Anfrage „Peak Performance“. Die restlichen 95 Prozent wurden von einem Problem mit der Speicherbandbreite aufgefressen.

Workloads splitten ist eine Lösung

Bei der LLM-Inferenz handelt es sich um zwei Workloads, die „vorgeben“, einer zu sein:

• Die Prompt-Verarbeitung (auch als „Prefill“ bezeichnet) ist eine dichte Matrixmultiplikation, die jeden Kern auf dem Chip auslastet.
• Die Token-Generierung (auch „Decode“) stellt einen sequenziellen Speicherzugriff dar, der nur einen Bruchteil der Rechenleistung beansprucht.

Diese beiden Workloads wechseln sich auf derselben Hardware innerhalb derselben Scheduling-Schleife ab. Obwohl ich bereits mit Kubernetes-Clustern im Carrier-Maßstab und Daten-Pipelines mit hohem Durchsatz gearbeitet habe, hatte ich noch nie zuvor ein solches bimodales Workload-Profil auf derart teurer Hardware gesehen. Würde man eine Datenbank auf dieselbe Weise betreiben, würde man sie ohne zu zögern in primäre Write-Server und Read-Replikate unterteilen.

Leider haben die meisten Teams, die LLMs betreiben, diesen Zusammenhang noch nicht erkannt. Und Monitoring-Tools machen die Sache nicht besser: Jedes Inferenz-Dashboard, das ich mir angesehen habe, meldete einen singulären Wert für die „GPU-Auslastung“ – den Durchschnittswert beider Phasen. Die Dashboards „versteckten“ so quasi die bimodale Verteilung hinter dieser Zahl.

Die Forscher des Hao AI Lab der UC San Diego sind ebenfalls auf dieses Problem gestoßen – und haben auch einen Lösungsvorschlag parat. Dieser hört auf den etwas sperrigen Namen „Disaggregated Inference“ und setzt darauf, zwei GPU-Pools einzurichten – statt einen für beide Phasen zu nutzen. Dabei ist:

• einer auf Rechendurchsatz (Prompt-Verarbeitung) ausgelegt, während
• der andere auf Speicherbandbreite (Token-Generierung) fokussiert.

Ein vorgelagerter Routing-Layer leitet dabei jede Anfrage zum richtigen Zeitpunkt an den richtigen Pool weiter. Übertragen werden diese über den Attention-Cache und eine schnelle Netzwerkverbindung.

Als ich diese Lösung erstmals dem Kunden vorschlug, war dieser zunächst skeptisch. Schließlich bedeuten zwei Pools auch mehr Komplexität im Betrieb. Und: Ein Cache-Übertragungsprotokoll sorgt für eine Netzwerkabhängigkeit, die bei monolithischem Serving nicht besteht. Berechtigte Einwände – also wies ich ihn darauf hin, wer diese Methode bereits in der Praxis einsetzt.

• Perplexity hat seinen gesamten Produktions-Serving-Stack auf Disaggregated Inference aufgebaut – unter Verwendung von RDMA für Cache-Übertragungen. Dieser kommt auch bei Meta, LinkedIn und Mistral zum Einsatz.
• Anfang 2026 brachte NVIDIA ein Orchestrierungs-Framework namens Dynamo auf den Markt, das Prefill und Decode als First-Class-Pool-Typen behandelt.
• Die Open-Source-Engines vLLM und SGLang wurden um native Disaggregated-Serving-Modi ergänzt.
• Red Hat und IBM Research haben eine Kubernetes-native Open-Source-Implementierung namens llm-d veröffentlicht, die die Architektur auf Standard-Cluster-Management-Workflows abbildet.

Es handelt sich also nicht um einen Prototyp für Research-Zwecke, sondern die Standardarchitektur der Unternehmen, die ein Gros des weltweiten LLM-Traffic bedienen. Das konnte schließlich auch den Kunden überzeugen – ich bekam grünes Licht, um ein zweiwöchiges Proof of Concept zu fahren.

GPU-Sparerfahrungen aus der Praxis

Ich begann damit, das Cluster in zwei Pools aufzuteilen: Acht GPUs waren ausschließlich für die Prompt-Verarbeitung zuständig. Die übrigen übernahmen die Token-Generierung. Neue Hardware oder Cluster waren nicht nötig – lediglich eine Konfigurationsänderung in der Serving-Ebene und eine Routing-Richtlinie, die jede Anfrage je nach ihrer Inferenzphase an den richtigen Pool weiterleitete.

Der Pool für die Prompt-Verarbeitung erreichte durchgehend eine Rechenauslastung von 90 bis 95 Prozent, da er ausschließlich diese Aufgabe ausführte. Keine Token-Generierung, die um Scheduling-Slots konkurrierte, keine Decode-Anfragen, die untätig blieben, während ein Prefill-Burst die Kerne beanspruchte. Der Pool für die Token-Generierung hielt am Ende die größere Überraschung parat: Indem Hunderte paralleler Decode-Anfragen gebündelt wurden, verteilten sich die Speicherzugriffe besser. Die Bandbreitennutzung stieg von 30 auf über 70 Prozent. Die Gesamt-Recheneffizienz verdoppelte sich in etwa.

Die Kostenberechnung folgte: Zuvor investierte der Kunde jährlich etwa zwei Millionen Dollar für GPU-Stunden in Sachen Inferenz. Nach der Entflechtung war er auf dem besten Weg, diese Kosten um 600.000 bis 800.000 Dollar zu reduzieren – bei identischen Anforderungsvolumen und Latenzzielen. Apropos Latenz: Auch hier zeigte sich eine deutliche Verbesserung. In der monolithischen Konfiguration führte jeder neue Prompt dazu, dass aktive Anfragen zur Token-Generierung blockiert wurden. Für die Benutzer bedeutete das, dass der Output mitten im Satz unterbrochen wurde, damit der Prompt eines anderen Nutzers verarbeitet werden konnte. Nach der Umstellung verzeichneten wir eine gleichmäßige Token-Rate ohne Prefill-bedingte Verzögerungen. Die P99-Latenz zwischen den Token flachte vollständig ab.

Ein One-Size-Fits-All-Ansatz ist jedoch auch diese Lösung nicht:

• Kurze Prompts unter 512 Token mit kurzen Outputs generieren nicht genug Cache, um eine Netzwerkübertragung zu rechtfertigen.
• Multi-Turn-Konversationen, bei denen bereits über 80 Prozent des Caches aus einer vorherigen Runde auf dem Decode-Worker vorhanden sind, werden lokal besser bedient.
• Wenn weniger als ein Dutzend GPUs vorhanden ist, kann der Scheduling-Overhead, den zwei Pools mit sich bringen, die Einsparungen zunichtemachen.

All das dürfte allerdings auch nicht auf Teams zutreffen, für die GPU-Knappheit und -Kosten ein Problem darstellen. Sie betreiben eher Dutzende bis Hunderte von GPUs im Enterprise-Maßstab, bei denen sich die Auslastungsverluste jedes Jahr auf Millionen summieren.

Ein Appell an die Branche

Unsere Branche verwendet viel Energie auf die GPU-Angebotsseite: Mehr Fabriken bauen, bessere Chips entwerfen, umfassendere Cloud-Verträge aushandeln. Diese Dinge sind zweifellos wichtig. Allerdings würde sich das effektiv verfügbare GPU-Angebot quasi über Nacht verdoppeln, wenn die Teams, die heute monolithische LLM-Inferenz betreiben, auf Disaggregated Serving umsteigen würden.

Wenn Sie Ihre Inferenzauslastung also noch nicht nach Phasen aufgeschlüsselt haben, kann ich Ihnen nur ans Herz legen, das nachzuholen. Fügen Sie Ihrer Serving-Schicht eine Instrumentierung pro Phase hinzu. Stellen Sie die Prefill- und die Decode-Auslastung separat über einen Zeitraum von 24 Stunden grafisch dar. Wenn die beiden Linien so aussehen, als gehörten sie in unterschiedliche Diagramme (Spoiler: das werden sie) tun sie genau das auch. Und Sie bezahlen nicht mehr für Rechenleistung, die Sie nicht nutzen. (fm)

Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschen Experten-Netzwerk finden Sie hier.