LLM-D: der Fluglotse für Inference

TL;DR

LLM-D (LLM-Distributed) ist ein Open-Source-Ansatz, der LLM-Inference auf Kubernetes schneller und günstiger macht — durch intelligente Verteilung über den Cluster. Statt Round-Robin: Routing nach Last, Latenz und Cache-Treffer. Prefill und Decode werden getrennt skaliert; ähnliche Prompts teilen den KV-Cache. Praxisberichte: 3× bessere P90-Latenz, 57× schnelleres Time-to-First-Token.

Warum Round-Robin scheitert

LLM-Anfragen sind heterogen: kleine RAG-Requests (viel Input, wenig Output) vs. große Agent-Sessions. Klassisches Round-Robin über einheitliche Replicas erzeugt Kongestion — spürbar als Inter-Token-Latenz.

Viele Requests teilen sich ähnliche Prefixes. Ohne Prefix-Routing und Caching wird GPU-Arbeit wiederholt, die schon berechnet war.

Inference Gateway als Lotse

LLM-D nutzt ein Inference Gateway, das jede Anfrage anhand mehrerer Signale routet:

• aktuelle Last
• prognostizierte Latenz
• Cache-Treffer-Wahrscheinlichkeit

Ein Endpoint-Picker wählt die beste Ziel-Instanz — das Gegenstück zu blindem Load-Balancing.

Prefill/Decode-Disaggregation

LLM-Inference hat zwei Phasen:

1. Prefill: Kontext/Prompt verarbeiten (speicherintensiv)
2. Decode: Tokens generieren (anders skaliert)

LLM-D trennt die Phasen:

• Prefill auf High-Memory-GPUs
• Decode auf eigenen Ressourcen
• beide teilen denselben KV-Cache für ähnliche Requests

Ergebnis: Hardware wird dem jeweiligen Engpass zugeordnet — nicht „eine Replica macht alles". Das ist dieselbe Richtung wie Accelerator-Native Kubernetes.

Gemessene Verbesserungen

Für SLOs und QoS-Agreements entscheidend — besonders bei High-Demand- und mission-critical Workflows.

Die ehrliche Einordnung:

1. Round-Robin ist der Feind bei heterogenen Workloads.
2. Disaggregation ist Architektur — nicht ein Config-Flag.
3. KV-Cache will gemessen werden — sonst verpufft der Gewinn.
4. Integration braucht Betrieb — vLLM/Kubernetes-Erfahrung vorausgesetzt.
5. Ohne SLO merkt man es zu spät — Latenzziele vor dem Produktions-Engpass setzen.

Häufige Fragen

Ist LLM-D dasselbe wie vLLM?

Nein. vLLM ist die Engine; LLM-D orchestriert verteilte Inference darüber (Routing, Disaggregation, Cache). Ergänzend: LLM Self-Hosting.

Lohnt sich das für kleine Cluster?

Erst wenn mehrere Replicas und heterogene Last da sind. Ein einzelner GPU-Server profitiert stärker von Partitionierung und Modellwahl.

Was ist der größte Hebel?

Oft Prefix-/KV-Cache plus intelligentes Routing — bevor Sie die nächste GPU kaufen.

Fazit

Verteilte Inference ist der Hebel, GPU-Kosten zu senken und Latenz-SLOs zu halten. LLM-D macht aus dem Cluster einen Lotsen statt einer Warteschlange.

Wer Hardware noch wählt: NVIDIA GPU-Server-Familien. Wir beraten, ob Disaggregation und Inference-Gateway zu Ihren SLOs passen, und betreiben die Kette mit Monitoring und Kostenkontrolle.