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.
📍 In einem Satz
Die Skalierung eines lokalen LLM von einem einzelnen Rechner zum Enterprise-Produktionsbetrieb bedeutet, Multi-User-Load-Balancing, GPU-Redundanz, Monitoring und Disaster Recovery hinzuzufügen -- typischerweise mit Kubernetes über 5-50 GPUs orchestriert, um 50-500 gleichzeitige Nutzer bei 99,9 % Verfügbarkeit zu bedienen.
💬 In einfachen Worten
Ein KI-Modell auf einem Computer für sich selbst laufen zu lassen ist einfach. Es für Hunderte von Mitarbeitern gleichzeitig laufen zu lassen ist ein anderes technisches Problem: Sie brauchen mehrere GPUs, die zusammenarbeiten, ein System, das jede Anfrage an eine freie GPU weiterleitet, Backups für den Fall, dass ein Server ausfällt, und Dashboards, die Sie warnen, wenn etwas schiefläuft. Kubernetes (ein Tool zur Verwaltung vieler Server gleichzeitig) ist die Standardlösung, mit der Unternehmen dies bewältigen.
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 |
|---|---|---|---|---|
| Prototyp | 1 | 1-10 | Nicht erforderlich | Ollama auf Laptop |
| Kleine Production | 2-4 | 10-50 | 95 % | Docker, grundlegendes Monitoring |
| Mittlere Enterprise | 5-16 | 50-200 | 99 % | Kubernetes, Load Balancer |
| Große Enterprise | 20-100 | 200-1000 | 99,9 % | Kubernetes Multi-Zone, Auto-Scaling |
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