LLM-D: Verteilte Inference auf Kubernetes

TL;DR

• LLM-D (LLM Distributed) behandelt Inference wie Flugverkehr: Requests (Flugzeuge) brauchen einen intelligenten Controller — Round-Robin reicht nicht.
• Disaggregated Serving trennt Prefill (Kontext verarbeiten) und Decode (Antwort generieren) in eigene Workloads mit unterschiedlichen GPU-Profilen.
• Ein Inference Gateway routet nach Last, vorhergesagter Latenz und Cache-Trefferwahrscheinlichkeit — Prefix-Routing spart teure Neuberechnung.
• Gemeldete Effekte: deutlich bessere P90-Latenz und Time-to-First-Token — relevant für SLOs und QoS in produktiven AI-Systemen.
• Für RAG, Coding-Agents und Chat auf dem eigenen Cluster ist das der Hebel zwischen „Modell läuft" und „Inference skaliert wirtschaftlich".

Das Problem: Round-Robin trifft auf LLM-Requests

Klassisches Load Balancing verteilt Requests gleichmäßig auf Replicas. Bei LLMs scheitert das Muster:

• RAG-Requests haben oft viele Input-Tokens und wenige Output-Tokens.
• Agentic-/Coding-Requests erzeugen lange Decode-Phasen und halten KV-Caches warm.
• Ähnliche Prompts teilen Präfixe — wer sie auf denselben Worker schickt, spart Hardware-Zyklen.

Ohne intelligente Steuerung steigt Inter-Token-Latenz. Nutzer spüren Stocken; GPUs rechnen dieselben Prefixe mehrfach.

LLM-D adressiert genau das: Inference über den Cluster verteilen — schneller und günstiger.

Architektur: Gateway, Prefill und Decode

Client / Agent / RAG
        │
        ▼
 Inference Gateway
 (Load, Latenz-Prognose, Cache-Likelihood)
        │
   ┌────┴────┐
   ▼         ▼
 Prefill    Decode
 (High-Mem) (skalierbar)
   └── KV-Cache ──┘
        │
        ▼
     vLLM u. a.

Inference Gateway und Endpoint Picker

Das Gateway bewertet eingehende Prompts anhand mehrerer Signale:

Statt Round-Robin entsteht ein Endpoint Picker, der Requests dorthin schickt, wo Prefill/Decode und Cache am sinnvollsten zusammenspielen.

Disaggregated Serving

Prefill und Decode sind unterschiedliche Profile:

• Prefill: speicherintensiv, Kontext aufbauen, KV-Blöcke erzeugen
• Decode: Token für Token generieren, oft anders skalierbar

LLM-D splittet sie in getrennte Workloads, die denselben KV-Cache für ähnliche Requests nutzen. So können Prefill-GPUs und Decode-Replicas unabhängig wachsen.

# Skizze: getrennte Deployments für Prefill und Decode
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-prefill
spec:
  replicas: 2
  selector:
    matchLabels:
      app: llm-prefill
  template:
    metadata:
      labels:
        app: llm-prefill
        role: prefill
    spec:
      containers:
        - name: engine
          image: vllm/vllm-openai:latest
          resources:
            limits:
              nvidia.com/gpu: 1
          args:
            - '--model'
            - your-org/model
# Decode analog mit role: decode und eigener Replica-Zahl

Was das für SLOs bedeutet

In Berichten zu LLM-D-Deployments wurden unter anderem genannt:

• spürbar bessere P90-Latenz (die langsamsten 10 % der Requests)
• deutlich niedrigere Time-to-First-Token

Für Plattform-Teams heißt das: Inference wird messbar steuerbar — nicht nur „GPU an, Chat an". Hyperscaler und regulierte Branchen brauchen genau solche Hebel für QoS- und SLA-Vereinbarungen.

Zahlen variieren stark nach Modell, Hardware und Traffic-Mix. Entscheidend ist das Muster: Routing + Disaggregation + Cache statt blinder Replica-Skalierung.

Wann sich LLM-D lohnt

Wer bereits GPU-Workloads auf Kubernetes betreibt, hat die Basis. LLM-D ist die Inference-Schicht darüber — ergänzend zu DRA und Accelerator-Native-Features.

Praxis-Checkliste

1. Metriken zuerst: TTFT, Inter-Token-Latenz, GPU-Util, Cache-Hit-Rate.
2. Traffic-Mix verstehen: RAG vs. lange Agent-Sessions trennen.
3. vLLM (oder vergleichbar) stabil betreiben, bevor Disaggregation kommt.
4. Gateway vor dem Engine-Pool — nicht nur Ingress Round-Robin.
5. Prefill/Decode getrennt skalieren, sobald Profile klar messbar sind.
6. Kosten pro Token tracken — sonst wird „mehr Replicas" zur Default-Antwort.

# Service-Skizze: getrennte Endpoints für Rollen
apiVersion: v1
kind: Service
metadata:
  name: llm-decode
spec:
  selector:
    app: llm-decode
    role: decode
  ports:
    - port: 8000
      targetPort: 8000

Fazit

LLM-D macht aus „wir haben ein Modell auf Kubernetes" eine Inference-Plattform: Requests werden nach Last und Cache geroutet, Prefill und Decode entkoppelt, GPUs besser ausgelastet.

Für Teams mit RAG, Coding-Assistenten und Agents auf dem eigenen Cluster ist das der Unterschied zwischen Prototyp-Latenz und produktionsfähigen SLOs — ohne sofort jede GPU zu verdoppeln.

FAQ

Ist LLM-D dasselbe wie vLLM? Nein. vLLM ist typischerweise die Engine. LLM-D orchestriert verteilte Inference darüber (Routing, Disaggregation, Cache).

Brauche ich RDMA? Für große Multi-Node-Setups oft ja — Netzwerk wird schnell zum Flaschenhals. Siehe auch Networking unter Kubernetes AI at Scale.

Reicht Horizontal Pod Autoscaler? HPA skaliert Replicas; er versteht keine Prefix-Caches und Prefill/Decode-Profile. Für LLM-Traffic braucht es zusätzliche Intelligenz im Gateway.

Verwandte Artikel

• Kubernetes AI at Scale: DRA und Inference
• GPU Workloads auf Kubernetes
• Kubernetes AI & Machine Learning
• Azure AI Studio als Enterprise-KI-Plattform