Was ist llm-d?
llm-d ist ein Kubernetes-natives Framework, um Inferenz von Sprachmodellen über viele Maschinen zu betreiben. Es sitzt über Model-Servern wie vLLM und ersetzt sie nicht: vLLM führt ein Modell auf einem Knoten aus, und llm-d entscheidet, welcher Knoten welche Anfrage übernimmt und wie die Arbeit zwischen ihnen aufgeteilt wird.
Es ist eine gemeinsame Initiative unter anderem von Red Hat, Google, IBM Research, CoreWeave und NVIDIA, und im März 2026 wurde es in die CNCF Sandbox aufgenommen.
Das Problem, das es löst
Ein einzelner GPU-Server hat eine Obergrenze. Ist sie erreicht, liegt der Griff zu mehreren Kopien des Modells hinter einem Load Balancer nahe, und das trägt eine Weile. Es ist auch verschwenderisch, denn ein gewöhnlicher Load Balancer weiss nichts darüber, was Inferenz von Sprachmodellen teuer macht.
Zwei Eigenschaften der Inferenz machen naive Lastverteilung zur schlechten Wahl:
Eine Anfrage hat zwei sehr verschiedene Phasen. Zuerst liest das Modell den Prompt, was rechenlastig und parallelisierbar ist. Danach erzeugt es Tokens einzeln nacheinander, was die Speicherbandbreite belastet und sequenziell abläuft. Die beiden Phasen verlangen Unterschiedliches von der Hardware, und beide auf derselben GPU auszuführen heisst, dass eine von ihnen sie immer schlecht nutzt.
Gespräche haben teuren Speicher. Der Zustand, den eine Anfrage anhäuft, der KV-Cache, ist gross. Landet eine Folgenachricht auf einem anderen Server, ist dieser Zustand weg und die Arbeit beginnt von vorn. Ein Load Balancer nach Reihum-Prinzip erzeugt genau das laufend.
Was es dagegen tut
Trennung von Prefill und Decode. Die beiden Phasen laufen auf getrennten Pools von Workern, jeder für sein eigenes Profil dimensioniert und abgestimmt, sodass keiner Hardware teilen muss, die für die andere Phase optimiert ist.
Verteilter KV-Cache. Zwischengespeicherter Zustand lässt sich zwischen Knoten verschieben statt neu berechnen, eine Folgeanfrage zahlt also nicht noch einmal die vollen Kosten des Gesprächs.
Routing mit Kenntnis der Inferenz. Anfragen werden nach dem verteilt, was das System über den Workload weiss, unter anderem darüber, welcher Knoten den passenden zwischengespeicherten Zustand bereits hält, statt reihum.
Wann du es brauchst
Direkt gesagt: später, als die meisten denken.
- Wenn ein Knoten tatsächlich die Obergrenze ist, und du das gemessen und nicht angenommen hast.
- Wenn Gespräche lang sind und Prompts wiederverwendet werden, denn dort ist Cache-Lokalität bares Geld wert.
- Wenn Latenz und Durchsatz beide zählen und du das eine nicht mit dem anderen erkaufen kannst.
- Wenn die GPU-Ausgaben gross genug sind, dass ein Prozentsatz davon den Betrieb eines verteilten Systems rechtfertigt.
Wann nicht
Wenn ein einzelner, gut abgestimmter vLLM-Knoten deinen Verkehr bedient, hör hier auf. Eine verteilte Schicht bringt zusätzliche Fehlerfälle und Betriebsarbeit, im Tausch gegen Kapazität, die du nicht nutzt.
Wenn du das Vorhandene noch nicht abgestimmt hast. Bei Batching, Quantisierung und Modellwahl liegt meist mehr Spielraum, als erwartet, und sie zu ändern ist deutlich günstiger als die Architektur.
Wenn dein Verkehr stossweise, aber klein ist. Replicas einer einfachen Installation zu skalieren ist leichter zu betreiben und leichter zu durchschauen.
Diese Reihenfolge ist der wichtige Teil dieser Seite. llm-d ist die Antwort auf ein Skalierungsproblem, und auf ein Abstimmungsproblem angewendet entsteht daraus ein kompliziertes System, das nicht schneller ist.
Was der Betrieb verlangt
- Es setzt Kubernetes-Können voraus. Das ist ein verteiltes System auf einem verteilten System. Beide brauchen jemanden, der sie debuggen kann.
- Die GPU-Topologie zählt. Wie die Knoten verbunden sind, entscheidet darüber, ob der Cache-Transfer eine Ersparnis oder ein Engpass ist, womit die Wahl der Hardware Teil des Entwurfs wird.
- Mehr bewegliche Teile, mehr Fehlerfälle. Routing, Cache-Transfer und Worker-Pools fallen jeweils auf eigene Art aus, und die nützlichen Kennzahlen erstrecken sich über alle drei.
- Es ist jung. Die CNCF Sandbox ist die früheste Reifestufe. Schnittstellen ändern sich, und es einzusetzen heisst, dem Projekt zu folgen, statt es einmal zu installieren.
Wo VSHN ins Bild kommt
VSHN rollt sowohl vLLM als auch llm-d auf Schweizer Cloud-Infrastruktur aus und betreibt beides. Wir haben also keinen Grund, dir die grössere Architektur zu verkaufen, wenn die kleinere reicht. Prompts, Antworten und zwischengespeicherter Zustand bleiben in der gewählten Rechtsordnung, und die Souveränitätsbewertung legt dar, wie das bewertet wird.
Der richtige erste Schritt ist meist eine Messung: ob ein einzelner Knoten wirklich deine Obergrenze ist, und wenn ja, ob Abstimmung oder Verteilung der günstigere Weg darüber hinaus ist. Für die Hälfte der Frage, die den einzelnen Knoten betrifft, ist vLLM der Ausgangspunkt.