Serving am Limit: LLM-Inferenz mit vLLM und Triton auf Kubernetes

Wenn ein KI-Modell die Trainingsphase verlässt, beginnt die eigentliche Herausforderung: Der produktive Inferenz-Betrieb. Ein Large Language Model (LLM) in einem Standard-Container zu „serven", ist ineffizient. Die Latenzen sind zu hoch und die GPU-Auslastung ist oft miserabel, da klassische Web-Server nicht für die sequenzielle Natur der Token-Generierung gebaut sind.

Um LLMs im Mittelstand wirtschaftlich und performant zu betreiben, müssen wir Kubernetes mit spezialisierten Inference Engines und intelligentem Batching kombinieren.

Die Ineffizienz des naiven Servings

Ein LLM generiert Token für Token. Wenn ein Nutzer eine Anfrage stellt, ist die GPU für die Dauer der gesamten Antwort belegt. In einem naiven Setup müsste der zweite Nutzer warten, bis die erste Antwort fertig ist – oder wir müssten für jeden Nutzer eine eigene GPU vorhalten. Beides ist im produktiven Umfeld inakzeptabel.

Die Lösung: PagedAttention und Continuous Batching

Der aktuelle Goldstandard, um dieses Problem in Kubernetes zu lösen, heißt vLLM (oder alternativ der NVIDIA Triton Inference Server).

1. vLLM und PagedAttention

vLLM revolutioniert die Speicherverwaltung. Inspiriert durch das virtuelle Memory-Management von Betriebssystemen, nutzt vLLM PagedAttention.

• Der Clou: Der KV-Cache (Key-Value-Speicher der vorherigen Token) wird nicht mehr in einem riesigen, zusammenhängenden Block im VRAM reserviert, sondern in dynamischen „Pages".
• Das Ergebnis: Wir können bis zu 24-mal mehr Requests auf derselben Hardware verarbeiten als mit herkömmlichen Methoden, da der Verschnitt im GPU-Speicher fast auf Null sinkt.

2. Continuous Batching

Statt zu warten, bis ein kompletter Batch von Anfragen fertig generiert wurde, schleust vLLM neue Anfragen sofort ein, sobald ein Token eines anderen Nutzers fertig ist. In Ihrem Kubernetes-Cluster führt das zu einer gleichmäßigen, hohen GPU-Auslastung und minimalen Wartezeiten für die Endnutzer.

Deployment-Strategien: KServe und Knative

Inferenz-Workloads sind extrem „spiky". Nachts braucht man oft null Kapazität, tagsüber schießen die Anfragen durch die Decke. Hier schlägt die Stunde von Serverless AI auf K8s.

Wir setzen dabei auf KServe:

• Scale-to-Zero: Wenn keine Anfragen kommen, werden die teuren GPU-Nodes via Knative heruntergefahren.
• Canary Rollouts: Sie können ein neues, feinjustiertes Modell (z.B. Llama-3-70B v2) erst an 5 % des Traffics testen, bevor Sie die gesamte Infrastruktur umschalten.
• Transformer-Architektur: KServe erlaubt es, Vor- und Nachbearbeitungsschritte (wie Tokenisierung oder Content-Filterung) vom eigentlichen Inferenz-Container zu trennen, was die Skalierung vereinfacht.

Die Rolle der Model Registry

In einer professionellen K8s-Infrastruktur liegen Modelle nicht „im Image". Das würde die Container-Images auf hunderte Gigabytes aufblähen.

• Der ayedo-Weg: Die Modelle liegen in einem S3-kompatiblen Speicher (MinIO oder Cloud-Native Storage). Beim Start des Pods lädt ein Init-Container das Modell direkt in den Shared Memory oder auf die lokale NVMe-Disk des Nodes. Das sorgt für schnelle Startup-Zeiten und saubere Versionierung.

Fazit: Inferenz ist ein Optimierungssport

Wer KI im Mittelstand erfolgreich einsetzen will, muss die Inferenz-Kosten pro Request senken. Kubernetes bietet mit vLLM und KServe die perfekte Plattform, um teure Hardware maximal auszulasten. Es ist der Schritt von der „Spielerei" zum skalierbaren digitalen Produkt.

Technical FAQ: Inferenz & Serving

Was ist besser: vLLM oder Hugging Face TGI (Text Generation Inference)? Beide sind exzellent. vLLM hat aktuell bei der Durchsatzrate (Tokens pro Sekunde) oft die Nase vorn, insbesondere durch PagedAttention. TGI ist hingegen sehr stabil und tief in das Hugging Face Ökosystem integriert. Wir evaluieren dies meist basierend auf dem spezifischen Modell-Typ.

Wie groß sollte der Shared Memory (/dev/shm) für Inferenz-Pods sein? KI-Frameworks nutzen Shared Memory massiv für die Inter-Prozess-Kommunikation. Standardmäßig ist dieser in K8s-Pods sehr klein (64MB). Wir konfigurieren diesen via emptyDir mit medium: Memory oft auf mehrere Gigabyte, um Abstürze bei großen Modellen zu vermeiden.

Kann ich Inferenz auf CPUs betreiben? Für sehr kleine Modelle (z.B. BERT für Textklassifizierung) oder mit Quantisierung (GGUF-Format via llama.cpp) ist das möglich. Für moderne LLMs ab 7B Parametern ist die Latenz auf CPUs jedoch meist zu hoch für eine gute UX.