Wichtigste Erkenntnisse
- Single Machine: 1 GPU, 10-50 gleichzeitige Benutzer, einfaches Setup.
- Multi-GPU: 2-8 GPUs, 50-200 Benutzer, Kubernetes-Orchestrierung.
- Enterprise: 5-50 GPUs, 500+ Benutzer, verteilt, hochverfügbar.
- Load Balancing: Round-Robin verteilt Anfragen über GPU-Pods.
- Monitoring: Verfolge Latenz, Warteschlangentiefe, GPU-Auslastung, Fehlerquoten.
- Im April 2026 ist Kubernetes der Standard für Enterprise-LLM-Deployment.
Wie skalierst du vom Single-Machine- zum verteilten System?
Progression von Single Machine zu Production:
| Deployment-Stufe | Anzahl GPUs | Gleichzeitige Benutzer | SLA-Verfügbarkeit | Infrastruktur-Setup |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
Wie implementierst du Load Balancing?
Load Balancer leitet Anfragen an den am wenigsten belasteten Inference-Pod weiter.
Round-Robin: Verteile gleichmäßig über Pods (am einfachsten).
Least-Loaded: Sende zum Pod mit der kürzesten Warteschlange (bessere Latenz).
Sticky Sessions: Derselbe Benutzer verwendet immer denselben Pod (für Kontext, aber riskant bei Pod-Ausfall).
# Kubernetes Service mit Load Balancing
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # Round-Robin über PodsWie implementierst du Redundanz und Failover?
Hochverfügbarkeit erfordert redundante Komponenten:
Pod-Replikas: Mehrere Inference-Pods. Falls einer ausfällt, übernehmen andere die Anfragen.
Health Checks: Kubernetes entfernt automatisch unhealthy Pods.
Storage-Redundanz: Modelldateien sind über Knoten repliziert.
DNS-Failover: Falls ein ganzes Rechenzentrum ausfällt, leite zu einer Backup-Einrichtung weiter.
Was solltest du überwachen?
Enterprise-Deployments müssen folgende Metriken überwachen:
- Latenz: Pro-Request-Zeit (p50, p95, p99 Perzentile).
- Warteschlangentiefe: Wie viele Anfragen warten. >10 = Überlastung.
- GPU-Auslastung: Sollte 70-90 % sein. <50 % = zu groß dimensioniert. >95 % = zu klein dimensioniert.
- Fehlerquote: % fehlgeschlagener Anfragen. Sollte <0,1 % sein.
- Durchsatz: Token/Sek. über alle Pods.
- Verfügbarkeit: % der Zeit, in der der Service verfügbar ist (Ziel 99,9 %).
- Kosten pro Anfrage: €/Request (amortisierte Hardware).
Wie optimierst du Kosten in der Skalierung?
Konzentriere dich bei der Skalierung auf:
- GPU-Auslastung: Höher ist günstiger pro Request. Ziel 80-90 %.
- Modell-Quantisierung: Q4 vs. FP16 benötigt 4× weniger VRAM, gleiche Geschwindigkeit. Reduziert benötigte GPU-Anzahl.
- Batch-Größe: Größere Batches = niedrigere Kosten pro Request (aber höhere Latenz).
- Auto-Scaling: Skaliere nachts herunter, tagsüber hoch (spart 30-50 % Cloud-Kosten).
- Multi-Tenancy: Betreibe 2-3 Modelle pro GPU (falls VRAM erlaubt). Höhere Auslastung.
Häufige Fehler beim Enterprise-Skalieren
- Latenzanforderungen ignorieren. Einige dich auf p99-Latenz-SLA vor dem Deployment. 2-Sekunden-Latenz mag OK aussehen, bis Benutzer sich beschweren.
- Überbereitstellung für Spitzenlast. Falls die Spitzenlast 100 Benutzer für 2 Stunden/Tag ist, kaufe nicht Hardware für 100 gleichzeitige Benutzer den ganzen Tag. Nutze Auto-Scaling.
- Schlechte Fehler-Isolation. Falls ein Pod-Crash den Load Balancer herunterfährt, ist die Architektur falsch. Teste Fehler-Szenarien.
- Falsche Metriken überwachen. GPU-Auslastung zu überwachen, aber nicht Latenz, ist rückwärts. Latenz beeinflusst Benutzer.
- Annahme, dass Open-Source-Tools zu Enterprise skalieren. Ollama funktioniert großartig für 1 Benutzer. Für 500 gleichzeitige Benutzer brauchst du Enterprise-Monitoring und Orchestrierung.
Was sind häufige Fragen zum Skalieren von Local LLMs?
Wie viele GPUs brauchen wir für Enterprise-Deployment?
Hängt von Parallelität und Latenzanforderungen ab. 100 gleichzeitige Benutzer auf 7B-Modell: ~5-8 GPUs. 500 gleichzeitige Benutzer: 20-30 GPUs. Formel: (gleichzeitige Benutzer × erwartete Latenz) / (Token/Sek. pro GPU).
Was ist der Unterschied zwischen Load Balancing und Auto-Scaling?
Load Balancing verteilt Anfragen über bestehende Pods. Auto-Scaling fügt Pods hinzu oder entfernt sie basierend auf Last. Beides wird benötigt: Load Balancing verteilt die Arbeit jetzt, Auto-Scaling passt die Kapazität an.
Wie behandeln wir GPU-Ausfälle?
Kubernetes plant Pods automatisch auf healthy GPUs um. Falls eine GPU ausfällt, markiert Kubernetes sie als nicht verfügbar und leitet Traffic zu anderen Pods weiter. Habe Redundanz: Falls du 8 GPUs brauchst, stelle 10 bereit.
Welche Latenz-SLA sollten wir anstreben?
p99-Latenz <2 Sekunden ist Standard für Chatbots. p99 <500ms für Real-Time-Autocomplete. Definiere SLA basierend auf Benutzererfahrung, wähle dann Hardware/Batch-Größe, um diese zu erfüllen.
Wie überwachen wir einen verteilten Inference-Cluster?
Überwache pro-Pod und Cluster-weit: GPU-Auslastung, Warteschlangentiefe, Latenz (p50/p95/p99), Fehlerquote, Durchsatz und Verfügbarkeit. Nutze Prometheus + Grafana oder Äquivalent.
Ist lokale Skalierung günstiger als Cloud?
Ja, bei Skalierung. Break-Even liegt bei ~500k Token/Monat. Lokal: hohe Anschaffungskosten (€400k-1,5M Hardware), dann niedrige Kosten pro Request. Cloud: keine Anschaffungskosten, hohe Kosten pro Request (€0,15-60/1M Token).
Muss ich bei der Verwendung von Local LLMs die DSGVO beachten?
Ja, besonders bei Enterprise-Skalierung. DSGVO Artikel 28: Falls deine Local-LLM-Infrastruktur personenbezogene Daten verarbeitet (z.B. Kundenabfragen, Trainings-Daten), benötigst du eine Datenverarbeitungsvereinbarung (DPA) mit deinem Cloud-Provider oder deinem System-Administrator. Datenschutz durch Design: Local Inference erfüllt von Natur aus Anforderungen zur Datensparsamkeit und Datenminimierung. Implementiere RBAC, Verschlüsselung in Transit/Rest und Audit-Logging, um BSI-Grundschutz-Kataloge zu erfüllen (Standard für deutsche und österreichische Mittelstand-IT-Sicherheit).
Ist Local LLM-Skalierung für den deutschen Mittelstand geeignet?
Ja, besonders für Mittelstand. Kostenmodell: Initial-Investition (€300k-1M für 5-10 GPUs), dann 30-50 % niedrigere Kosten pro Request vs. Cloud. IT-Sicherheit: Erfüllt BSI-Grundschutz-Kataloge (Datenschutz, Verfügbarkeit, Integrität) besser als Cloud-Abhängigkeit. Datenhoheit: Deine Daten bleiben on-premises, wichtig für regulierte Industrien (Finanzwesen, Gesundheit, Recht). Empfehlung: Für Mittelstand mit >10 Mitarbeitern, die täglich LLMs nutzen, ist lokale Skalierung ROI-positiv innerhalb von 18-24 Monaten.
Quellen
- Kubernetes-Dokumentation -- kubernetes.io/docs
- vLLM Deployment Guide -- docs.vllm.ai/en/serving/distributed_serving.html
- Prometheus Monitoring -- prometheus.io
- BSI-Grundschutz-Kataloge -- bsi.bund.de/grundschutz