Verteilte KI-Inferenz: Prefill und Decode getrennt skalieren

Eine GPU, zwei völlig verschiedene Jobs

Wer ein Sprachmodell selbst betreibt, kennt das Rätsel: Die teuren Grafikkarten sind zu 100 Prozent ausgelastet, und trotzdem warten Nutzer auf ihre Antworten. Der Grund steckt tief in der Mechanik der Modelle. Eine Anfrage durchläuft zwei Phasen, die gegensätzlicher kaum sein könnten. Zuerst liest das Modell den gesamten Prompt und baut daraus den sogenannten KV-Cache auf – die Prefill-Phase. Danach erzeugt es Token für Token die Antwort – die Decode-Phase.

Prefill ist rechenlastig. Hier arbeitet die GPU an großen Matrizen und bringt ihre Rechenwerke an die Grenze. Decode dagegen ist speicherlastig: Pro Schritt entsteht nur ein einziges Token, aber das Modell muss jedes Mal den kompletten Cache aus dem Speicher ziehen. Die Rechenwerke langweilen sich, während die Speicherbandbreite zum Flaschenhals wird. Zwingen Sie beide Phasen auf dieselbe Karte, blockiert ein langer Prompt die Antwortgenerierung anderer Nutzer – und umgekehrt.

Genau dieses Nebeneinander kostet Unternehmen bares Geld. Sie kaufen Hardware für Spitzenlast, nutzen sie aber nie effizient aus. Die Antwort heißt Disaggregation: Prefill und Decode trennen und auf spezialisierte Maschinen verteilen.

Was llm-d 1.0 verändert

Am 20. Oktober 2026 erschien llm-d 1.0, ein quelloffener Stack für verteilte Inferenz. Hinter dem Projekt stehen IBM, Red Hat und über 500 Mitwirkende aus mehr als 25 Organisationen. Der Ansatz ist kein akademisches Experiment mehr, sondern für den Produktivbetrieb freigegeben. IBM nennt für kontextlastige, agentische Arbeitslasten bis zu fünf- bis zehnfach geringere Kosten und die dreifache Ausgabe-Durchsatzrate.

llm-d baut auf vLLM auf und nutzt dessen native Fähigkeit, Prefill und Decode voneinander zu lösen. Die eigentliche Übergabe des KV-Caches zwischen den Maschinen übernimmt NIXL, eine Bibliothek für schnellen Speichertransfer. Darüber sitzt ein Router mit Scheduler, der für jede Anfrage entscheidet, welche Maschine die Prefill-Arbeit erledigt und welche die Antwort generiert.

Der Clou liegt im Detail der Orchestrierung. Pods, also einzelne Recheneinheiten auf Kubernetes, tragen die Rolle prefill oder decode als Label. Vor jeder Engine sitzt ein Proxy-Sidecar. Kommt eine Anfrage herein, schickt der Sidecar sie zunächst an einen Prefill-Pod, fängt die Transfer-Parameter des fertigen Caches ab und reicht sie an einen Decode-Pod weiter. Für Ihre Anwendung bleibt der Vorgang unsichtbar – sie spricht weiterhin eine einzige Schnittstelle an.

KV-Cache-bewusstes Routing: der eigentliche Hebel

Der größte Gewinn entsteht nicht durch die Trennung allein, sondern durch kluges Routing. Viele Anfragen teilen sich Textbausteine: denselben System-Prompt, dieselbe Dokumentenvorlage, denselben Gesprächsverlauf. Wird dieser Teil einmal berechnet, liegt er als Cache vor. Ein naiver Router verteilt Anfragen reihum und wirft diesen Vorteil weg. llm-d schaut nach, wo passende Cache-Fragmente bereits liegen, und schickt die Anfrage dorthin.

Rechnen Sie das für einen Support-Chatbot durch. Tausende Gespräche beginnen mit identischen Anweisungen und Produktinfos. Landet jede Folgeanfrage auf der Maschine, die den Gesprächskontext schon kennt, entfällt die teure Neuberechnung. Die Prefill-Last sinkt spürbar, und die Nutzer bekommen das erste Wort der Antwort schneller zu sehen.

Dieser Effekt skaliert mit der Länge der geteilten Präfixe. Je umfangreicher Ihre System-Prompts und je länger Ihre Dokumentkontexte, desto mehr sparen Sie. Gerade bei RAG-Anwendungen, die großen Kontext in jede Anfrage packen, macht das den Unterschied zwischen tragbaren und ruinösen Betriebskosten.

Wann sich die Trennung lohnt – und wann nicht

Disaggregation ist kein Allheilmittel. Sie fügt einen Netzwerk-Sprung hinzu: Der Cache muss von der Prefill- zur Decode-Maschine wandern. Bei kurzen Prompts und wenig Last überwiegt dieser Zusatzaufwand den Nutzen. Ein kleines Modell, das auf einer einzigen Karte flüssig läuft, braucht den Mechanismus nicht.

Richtig stark wird der Ansatz bei hohem Durchsatz und ungleichen Lastprofilen. Stellen Sie sich eine Plattform vor, auf der morgens lange Dokumente analysiert und nachmittags viele kurze Fragen beantwortet werden. Mit getrennten Pools skalieren Sie die Prefill-Kapazität und die Decode-Kapazität unabhängig. Steigt die Zahl paralleler Gespräche, fügen Sie Decode-Pods hinzu, ohne teure Prefill-Hardware mitzukaufen.

Auch die Hardware lässt sich passgenauer wählen. Prefill verlangt rohe Rechenleistung, Decode vor allem Speicherbandbreite. Sie können ältere oder günstigere Karten für die eine Rolle einsetzen und die Spitzenhardware dort, wo sie wirklich zählt. Das verändert die Beschaffung – weg vom pauschalen „noch eine große GPU“, hin zur gezielten Investition.

Der Weg in den Betrieb

llm-d läuft auf Kubernetes und integriert sich in die übliche Gateway-Infrastruktur. Wer bereits Modelle mit vLLM betreibt, findet vertrautes Terrain: Dieselbe Engine, dieselben Modellgewichte, nur anders verschaltet. Der Einstieg beginnt sinnvollerweise klein, mit einem Modell und einer überschaubaren Zahl von Pods, bevor Sie die Rollen fein austarieren.

Messen Sie vorher und nachher. Die zwei Kennzahlen, auf die es ankommt, heißen Time-to-First-Token und Tokens pro Sekunde. Die erste sagt Ihren Nutzern, wie schnell eine Antwort anläuft; die zweite, wie flüssig sie weiterläuft. Disaggregation verbessert beide – aber nur, wenn Ihr Lastprofil dazu passt. Ohne Messung tappen Sie im Dunkeln.

Achten Sie auf das Netzwerk zwischen den Pods. Der KV-Transfer verlangt Bandbreite; auf langsamen Verbindungen frisst die Übertragung den Vorteil wieder auf. In der Praxis heißt das: schnelle Verbindungen zwischen den Knoten einplanen und die Pods nicht quer über das Rechenzentrum verteilen.

Souveränität als Nebeneffekt

Dass der Stack quelloffen und permissiv lizenziert ist, zahlt auf ein Thema ein, das viele deutsche Unternehmen umtreibt: Kontrolle über die eigene KI. Sie betreiben Modelle im eigenen Rechenzentrum, bestimmen selbst über Daten und Hardware und binden sich an keinen einzelnen Cloud-Anbieter. Verteilte Inferenz macht genau diesen Eigenbetrieb wirtschaftlich tragbar.

Denn der häufigste Einwand gegen selbst-gehostete KI lautet, sie sei zu teuer im Vergleich zur API. Dieser Einwand verliert an Gewicht, wenn Sie Ihre GPUs doppelt so gut auslasten und mit derselben Hardware deutlich mehr Anfragen bedienen. Aus „zu teuer“ wird „durchgerechnet günstiger“ – vorausgesetzt, Sie betreiben genug Volumen, um die Komplexität zu rechtfertigen.

Verteilte Inferenz ist damit weniger eine Spielerei für Hyperscaler als ein praktisches Werkzeug für mittelständische Betreiber mit ernsthaftem Durchsatz. Die Technik, die vor einem Jahr noch großen Laboren vorbehalten schien, steht heute als fertiger Baustein bereit.

Sie überlegen, ob sich der Eigenbetrieb eines Sprachmodells für Ihr Unternehmen rechnet, und wollen Architektur, Hardware und Kosten realistisch einschätzen? Sprechen Sie mit uns bei ai-designers.de – wir planen mit Ihnen eine selbst-gehostete KI, die zu Ihrem Lastprofil und Ihrem Budget passt.

Bilder: AI-Designed