Lokale KI & Self-Hosting

Einführung

Die lokale Bereitstellung von KI-Modellen erlebt seit dem Aufkommen der Open-Source-LLMs einen erheblichen Aufschwung. Wo Organisationen zuvor ausschliesslich auf proprietäre Cloud-APIs angewiesen waren – mit wiederkehrenden Kosten, Latenzeinschränkungen und Datenschutzbedenken – eröffnet sich nun die Möglichkeit, leistungsstarke Modelle auf der eigenen Infrastruktur zu hosten, auszuführen und zu optimieren. Dieser Wandel, ermöglicht durch Fortschritte bei Quantisierung, Destillation und optimierten Inferenz-Engines, verändert das Verhältnis von Unternehmen zur künstlichen Intelligenz grundlegend.

Souveränität und Kosten

Die Datensouveränität ist der erste Treiber für die Adoption von Self-Hosting. Wenn eine Organisation eine Cloud-API zur Verarbeitung ihrer Dokumente, E-Mails, Sprachaufzeichnungen oder Wissensdatenbanken nutzt, vertraut sie ihre sensibelsten Daten einem Dritten an. Für regulierte Branchen – Gesundheitswesen, Finanzen, Verteidigung, Recht – ist dieser Transfer schlichtweg unmöglich: Die DSGVO, sektorale Vorschriften und interne Sicherheitsrichtlinien schreiben vor, dass die Daten in der Infrastruktur der Organisation verbleiben müssen. Lokales Hosting hebt diese Einschränkung auf: Keine Daten verlassen die kontrollierte Umgebung, die Modelle laufen auf internen Servern, und die vollständige Nachvollziehbarkeit der Verarbeitung ist gewährleistet. Diese vollständige Kontrolle über den Datenlebenszyklus ist für viele Organisationen eine nicht verhandelbare Voraussetzung.

Die Kostensenkung ist das zweite entscheidende Argument. Cloud-APIs berechnen nach Nutzung: Jeder generierte Token, jede gestellte Anfrage, jedes verarbeitete Dokument wird abgerechnet. Bei geringem Volumen bleiben die Kosten akzeptabel. Sobald die Nutzung jedoch intensiver wird – Dokumentenassistenz für hundert Mitarbeiter, automatisierte Verarbeitung tausender Dokumente pro Tag, kontinuierliche Sprachanalyse – kann die monatliche Rechnung mehrere tausend oder gar zehntausend Euro erreichen. Lokales Hosting ersetzt diese wiederkehrenden Kosten durch eine einmalige Investition in Hardware und überschaubare Wartung. Ein Server mit zwei professionellen GPUs, über drei bis fünf Jahre abgeschrieben, kostet nur einen Bruchteil der Cloud-API-Kosten bei vergleichbarem Volumen. Die Rentabilitätsschwelle hängt vom Volumen und dem gewählten Modell ab, aber unsere Benchmarks zeigen, dass ab einigen hunderttausend Anfragen pro Monat die lokale Lösung systematisch wirtschaftlicher wird.

Die minimale Latenz ist der dritte Wettbewerbsvorteil von Self-Hosting. Cloud-APIs führen eine unvermeidbare Netzwerklatenz ein: Die Round-Trip-Zeit zwischen dem Server der Organisation und dem Cloud-Anbieter, addiert zur Inferenzzeit des Modells. Diese Latenz, typischerweise zwischen 200 und 800 Millisekunden, ist für asynchrone Anwendungen akzeptabel, aber problematisch für Echtzeitanwendungen – Live-Transkription, Konversationsassistent, Videoanalyse. Lokal ist die Netzwerklatenz nahezu Null, und die Inferenzzeit wird zum alleinigen bestimmenden Faktor. Für ein quantisiertes Modell mit 7 bis 14 Milliarden Parametern auf einer modernen GPU liegen die Antwortzeiten unter 50 Millisekunden und ermöglichen so hochwertige interaktive Anwendungen.

Optimierung

Quantisierungstechniken stehen im Mittelpunkt der Modelloptimierung für die lokale Bereitstellung. Ein Sprachmodell wird traditionell in 16-Bit- (FP16) oder 32-Bit-Genauigkeit (FP32) gespeichert, was bedeutet, dass jeder Parameter 2 oder 4 Byte Speicher belegt. Ein Modell mit 70 Milliarden Parametern in FP16 benötigt daher 140 GB GPU-Speicher – das Äquivalent mehrerer High-End-GPUs. Die Quantisierung reduziert diese Genauigkeit: Ein in 8 Bit (INT8) quantisiertes Modell halbiert den Speicher, in 4 Bit (INT4) viertelt er ihn. Das von llama.cpp und Ollama populär gemachte GGUF-Format ist im Open-Source-Ökosystem am weitesten verbreitet: Es unterstützt asymmetrische Quantisierung, Speicherung auf CPU und GPU sowie eine breite Palette von Quantisierungsstufen (Q2_K bis Q8_0). Jede Stufe bietet einen anderen Kompromiss zwischen Speichergröße und Generierungsqualität. Ein Llama 3 70B, quantisiert in Q4_K_M, belegt etwa 40 GB – der Speicher einer einzigen professionellen GPU wie der RTX 6000 Ada.

AWQ (Activation-Aware Weight Quantization) ist ein neueres Format, das die Quantisierung an die Bedeutung jedes Gewichts für die Inferenzqualität anpasst. Im Gegensatz zu GGUF, das eine gleichmässige Quantisierung anwendet, analysiert AWQ die Aktivierung der Gewichte bei Kalibrierungsdurchläufen und bewahrt eine höhere Genauigkeit für die einflussreichsten Gewichte. Das Ergebnis ist eine bessere Generierungsqualität bei gleicher Modellgrösse. GPTQ (GPT Post-Training Quantization) ist ein weiteres optimiertes Format, das besonders für Llama- und Mistral-Architekturen geeignet ist. Es verwendet Batch-Quantisierung und Kompensation des Quantisierungsfehlers, um den Qualitätsverlust zu minimieren. In der Praxis bietet ein in AWQ oder GPTQ 4 Bit quantisiertes Modell eine Qualität nahe dem ursprünglichen FP16-Modell bei um 75 Prozent reduziertem Speicherverbrauch. Die Wahl zwischen GGUF, AWQ und GPTQ hängt von der verwendeten Inferenz-Engine ab: Ollama bevorzugt GGUF, vLLM unterstützt AWQ und GPTQ, während Frameworks wie text-generation-webui mehrere Formate unterstützen.

Die Destillation ist eine weitere grundlegende Optimierungstechnik, die sich von der Quantisierung unterscheidet, aber komplementär ist. Während die Quantisierung die numerische Genauigkeit der Gewichte reduziert, besteht die Destillation darin, ein kleines Modell (den Studenten) zu trainieren, das Verhalten eines grossen Modells (des Lehrers) zu reproduzieren. Der Student lernt nicht nur, die richtigen Antworten zu produzieren, sondern auch die Wahrscheinlichkeitsverteilung des Lehrers nachzuahmen und so die Nuancen seiner Argumentation zu erfassen. Destillierte Modelle wie die Serien Llama 3.2 (1B, 3B), Mistral Small (7B) oder Qwen 2.5 (1.5B, 7B) erreichen eine mit zwei- bis dreimal grösseren Modellen vergleichbare Leistung bei einem Bruchteil des Speichers und der Inferenzzeit. Die Kombination von Destillation und Quantisierung ist besonders leistungsstark: Ein destilliertes Modell mit 7 Milliarden Parametern, quantisiert in 4 Bit, kann auf einer handelsüblichen GPU mit überraschend hoher Antwortqualität ausgeführt werden.

Die Inferenz-Engines bilden die Software-Schicht, die die Ausführung der Modelle auf der Hardware orchestriert. Ollama ist die zugänglichste Lösung für den Einstieg ins Self-Hosting: Es kapselt die Komplexität der Modellverwaltung in einem einfachen Befehlszeilentool mit automatischem Download, Versionsverwaltung, OpenAI-kompatibler REST-API und nativer GGUF-Unterstützung. Seine modulare Architektur ermöglicht den Wechsel des Modells mit einem Befehl und die Konfiguration der Inferenzparameter – Temperatur, Top-p, Kontext, Batch Size. Ollama ist ideal für Einzelmodell-Bereitstellungen, schnelle Tests und Entwicklungsumgebungen. Seine Hauptbeschränkung ist die Single-GPU-Verwaltung: Für Modelle, die mehrere GPUs benötigen, sind andere Lösungen besser geeignet.

vLLM ist die Hochleistungs-Inferenz-Engine für Produktionsbereitstellungen. Seine zentrale Innovation ist der PagedAttention-Algorithmus, der den Speicher des KV-Cache-Attention wie die Seiten eines Betriebssystems verwaltet: Seiten werden dynamisch zugewiesen und freigegeben, wodurch die Speicherverschwendung traditioneller Ansätze entfällt. Diese Optimierung ermöglicht es, die Anzahl gleichzeitiger Anfragen pro GPU um das 2- bis 5-Fache im Vergleich zu herkömmlichen Engines zu erhöhen, ohne Qualitäts- oder Latenzeinbussen. vLLM unterstützt GPU-Parallelität (Tensor Parallelism, Pipeline Parallelism), dynamisches Batching, Token-Streaming und die Quantisierungsformate AWQ und GPTQ. Es bietet eine OpenAI-kompatible API, sodass ein Cloud-API-Aufruf durch einen lokalen Aufruf ersetzt werden kann, ohne den Anwendungscode zu ändern. Für hohe Volumina – Dokumentenassistenz, Batch-Analyse von Dokumenten, Chat in Produktion – ist vLLM die Referenz-Engine.

Die Bereitstellung mit Docker und Kubernetes bildet die Standardinfrastruktur für Produktionsumgebungen. Jede Inferenz-Engine ist in einem Docker-Image mit ihren GPU-Abhängigkeiten (CUDA, cuDNN, TensorRT) verpackt, was die Reproduzierbarkeit zwischen Entwicklungs-, Test- und Produktionsumgebungen gewährleistet. Die Orchestrierung mit Docker Compose ermöglicht die Verknüpfung mehrerer Dienste: ein vLLM-Container für die Inferenz, ein Redis-Container für das Antwort-Caching, ein Nginx-Container für den Lastausgleich und ein Prometheus-Container für die Metriksammlung. Für grössere Bereitstellungen orchestriert Kubernetes GPU-Knoten-Cluster mit lastabhängigem Auto-Scaling, Modellverteilung auf die Knoten, unterbrechungsfreien Updates und Fehlertoleranz. Helm Charts vereinfachen die Bereitstellung komplexer Inferenz-Stacks mit deklarativer versionierter Konfiguration.

Die CUDA-Optimierung ist ein entscheidender Leistungsfaktor. Moderne Inferenz-Engines nutzen CUDA, um massgeschneiderte Kernel zu kompilieren, die auf jedes Modell und jeden GPU zugeschnitten sind. TensorRT-LLM, die NVIDIA-Optimierungsbibliothek, führt Operationen des Rechengraphen zusammen, wendet In-Flight-Quantisierung an und generiert spezialisierte CUDA-Kernel, die die Architektur der Ziel-GPU voll ausnutzen. Die Gewinne gegenüber einer naiven Ausführung sind beträchtlich: bis zu 4-mal mehr Tokens pro Sekunde auf einer A100-GPU und eine signifikante Reduzierung des Speicherverbrauchs. Zu den fortgeschrittenen Optimierungen gehören FlashAttention zur Beschleunigung der Attention-Berechnung auf langen Sequenzen, PagedAttention von vLLM für die Speicherverwaltung und JIT-Kompilierung (Just-In-Time), die die Kernel an die genauen Abmessungen des Modells und des Batches anpasst. Die Wahl der GPU ist entscheidend: Professionelle GPUs (A100, H100, RTX 6000 Ada) bieten mehr Speicher und Bandbreite, aber Consumer-GPUs (RTX 4090, RTX 5090) bieten das beste Preis-Leistungs-Verhältnis für Modelle moderater Grösse.

Das Cloud-vs.-Lokal-Benchmarking ist ein zentraler Schwerpunkt dieses Projekts. Wir haben ein systematisches Protokoll entwickelt, um die Kosten und Leistungen beider Ansätze an zwanzig repräsentativen Modellen, drei Cloud-Anbietern (OpenAI, Anthropic, Mistral API) und vier lokalen Konfigurationen (RTX 4090, RTX 5090, 2x RTX 4090, 2x RTX 6000 Ada) zu vergleichen. Die gesammelten Metriken decken sechs Dimensionen ab: Kosten pro Million generierter Tokens, Durchsatz in Tokens pro Sekunde, Latenz der ersten Antwort, gesamte Abschlusslatenz, gemessene Qualität durch automatische und menschliche Metriken sowie Zuverlässigkeit gemessen an Fehlerrate und Antwortvarianz. Die Schätzungen deuten darauf hin, dass die Rentabilitätsschwelle für lokale Lösungen je nach Modell zwischen 500.000 und 2 Millionen Tokens pro Tag liegt und die Latenz durchweg 60 bis 80 Prozent niedriger ist als bei Cloud-APIs.

Der Qualitätsunterschied zwischen quantisierten Open-Source-Modellen und proprietären Modellen verdient eine differenzierte Analyse. Bei alltäglichen Aufgaben – Klassifikation, Extraktion, kurze Zusammenfassung, einfaches Q&A – erreichen quantisierte Modelle mit 7 bis 14 Milliarden Parametern mit GPT-4 oder Claude 3.5 vergleichbare Werte mit einer Differenz von weniger als 2-3 Prozent bei standardisierten Metriken. Bei komplexen Aufgaben – mehrstufiges Denken, juristische Analyse, fortgeschrittenes Coding – vergrössert sich der Abstand zugunsten der proprietären Modelle, aber die Destillation und 8-Bit-Quantisierung grosser Modelle (70B+) verringert diese Kluft erheblich. Die Wahl zwischen Cloud und Lokal ist daher nicht binär: Eine hybride Architektur, bei der einfache Anfragen lokal und komplexe Anfragen an die Cloud delegiert werden, bietet den besten Qualitäts-Kosten-Kompromiss.

Das Monitoring mit Prometheus und Grafana ist unverzichtbar für den Betrieb einer lokalen Inferenzinfrastruktur. Prometheus sammelt kontinuierlich die von den Inferenz-Engines bereitgestellten Metriken: GPU-Auslastung (Speicher, Nutzung, Temperatur, Leistung), Inferenzdurchsatz (Tokens pro Sekunde, Anfragen pro Minute), Latenz (Durchschnitt, P50, P95, P99), Fehlerrate, Warteschlangen und Sättigung. Jeder Docker-Container stellt einen /metrics-Endpunkt im Prometheus-Format bereit, und spezialisierte Exporter (nvidia-exporter für GPU-Metriken, node-exporter für Systemmetriken) ergänzen die Sammlung. Grafana aggregiert diese Daten in dynamischen Dashboards: Cluster-Übersicht, Analyse nach Modell, Kostenverfolgung, Alarmierung bei Schwellenwertüberschreitungen. Die Alarme sind so konfiguriert, dass sie die Teams bei Leistungseinbussen benachrichtigen – gesättigter GPU-Speicher, übermässige Latenz, fehlerhaftes Modell – und ermöglichen ein Eingreifen, bevor die Benutzer betroffen sind.

Anwendungsfälle

Die konkreten Anwendungsfälle decken ein breites Spektrum professioneller Anwendungen ab. Die interne Dokumentenassistenz ist der häufigste Fall: Ein lokal mit vLLM bereitgestelltes LLM und eine Qdrant-Vektordatenbank betreiben einen RAG-Chatbot, der Fragen auf Basis der Unternehmenswissensdatenbank beantwortet. Sensible Daten – Verträge, Kundendaten, Finanzinformationen – verlassen nie die Infrastruktur. Die Batch-Verarbeitung von Dokumenten ist ein zweiter Anwendungsfall: Analyse hunderter Berichte, Extraktion strukturierter Daten aus Rechnungen, automatische Klassifikation eingehender Post. Die Batch-Inferenz mit vLLM ermöglicht die Verarbeitung grosser Volumina mit optimalem Durchsatz. Die Schreibhilfe und Content-Generierung – E-Mails, Berichte, Protokolle, Angebote – profitiert von der minimalen Latenz des lokalen Systems für eine flüssige interaktive Erfahrung.

Die Echtzeit-Sprachtranskription kombiniert ein lokales Whisper-Modell (über Ollama oder den WhisCPP-Server) mit einem LLM für Verständnis und Zusammenfassung. Die gesamte Pipeline läuft lokal ohne Cloud-Abhängigkeit und gewährleistet die Vertraulichkeit der Gespräche. Auch die Code-Analyse und Entwicklungsunterstützung sind relevant: Ein lokal mit Ollama bereitgestelltes Modell wie Code Llama oder DeepSeek Coder bietet Programmierunterstützung, ohne den Quellcode an externe Server zu senden – ein entscheidendes Argument für Softwareunternehmen, die ihr geistiges Eigentum schützen wollen. Die Inhaltsmoderation und Sentiment-Analyse auf internen Textströmen runden das Anwendungsspektrum ab.

Technische Herausforderungen

Die technischen Herausforderungen des Self-Hostings sind real und müssen antizipiert werden. Die Verwaltung der GPU-Ressourcen ist die erste Herausforderung: Mehrere Modelle oder mehrere Benutzer können um denselben GPU konkurrieren und Leistungseinbussen verursachen. vLLM bewältigt diese Konkurrenz durch dynamisches Batching, aber eine Kapazitätsplanung ist erforderlich. Die Modellwartung ist die zweite Herausforderung: Modelle entwickeln sich schnell weiter, neue Versionen bringen Qualitäts- und Sicherheitsverbesserungen, und die Quantisierungsformate müssen aktualisiert werden. Eine automatisierte Aktualisierungspipeline mit Regressionstests vor der Bereitstellung ist unerlässlich. Die Hochskalierung ist die dritte Herausforderung: Die lokale Infrastruktur muss für Spitzenlast ausgelegt sein, was in Schwachlastzeiten zu Überdimensionierung führen kann. Kubernetes mit horizontalem Auto-Scaling mildert dieses Problem, indem es Ressourcen dynamisch zuweist und freigibt.

Die Sicherheit der lokalen Infrastruktur ist eine oft unterschätzte Herausforderung. Die Modelle selbst können Schwachstellen enthalten – neuere Forschungen haben gezeigt, dass schädliche Verhaltensweisen in ein quantisiertes Modell injiziert werden können. Die Überprüfung der Integrität heruntergeladener Modelle mittels Checksums und Signaturen ist eine Mindestpraxis. Die Isolierung der Docker-Container verhindert, dass ein kompromittiertes Modell auf das restliche System zugreift. Die Einschränkung der Berechtigungen interner API-Tokens reduziert die Angriffsfläche. Die Protokollierung der Modellzugriffe und der gestellten Anfragen gewährleistet die für Vorfälle erforderliche Rückverfolgbarkeit. Schliesslich ist die Sicherung der von den Inferenz-Engines bereitgestellten API-Endpunkte – Authentifizierung, Rate Limiting, TLS-Verschlüsselung – unerlässlich, sobald das System aus dem internen Netzwerk zugänglich ist.

Perspektiven

Die Entwicklungsperspektiven des Self-Hostings sind besonders vielversprechend. Das Aufkommen von GPUs mit immer mehr Speicher (48 GB, 80 GB, bald 144 GB) verschiebt die Grenze der auf einer einzelnen Karte einsetzbaren Modelle. Die Quantisierungsformate verbessern sich: 3-Bit- und 2-Bit-Formate beginnen sich abzuzeichnen und bieten zusätzliche Speicherreduzierungen mit zunehmend beherrschbarem Qualitätsverlust. Die CPU-Inferenz mit für die Ausführung ohne GPU optimierten Modellen verbessert sich dank der AVX-512- und AMX-Instruktionen moderner Prozessoren und macht Self-Hosting auch ohne dedizierte Grafikkarte für kleine Modelle zugänglich. Standardisierte Protokolle wie das MCP-Protokoll erleichtern die Integration lokaler Modelle in bestehende Informationssysteme und vereinheitlichen den Zugang zu KI-Fähigkeiten unabhängig vom Anbieter oder Bereitstellungsmodus.

Die Multi-Modell-Orchestrierung ist eine natürliche Weiterentwicklung des Self-Hostings. Derselbe Server kann mehrere spezialisierte Modelle hosten: ein LLM für die Textgenerierung, ein Embedding-Modell für die Vektorisierung, ein Vision-Modell für die Bildanalyse, ein STT-Modell für die Sprachtranskription. Der Orchestrator leitet jede Anfrage an das zuständige Modell weiter, teilt die GPU-Ressourcen zwischen den Modellen und verwaltet die Prioritäten. Dieser Ansatz verwandelt den lokalen Server in eine vollständige KI-Plattform, vergleichbar mit Cloud-Angeboten, jedoch mit der zusätzlichen vollständigen Datenkontrolle. Die ersten Erfahrungsberichte von Organisationen, die Self-Hosting eingeführt haben, bestätigen den Trend: Die Reife der Werkzeuge, die Qualität der Open-Source-Modelle und der relative Rückgang der Hardwarekosten machen die lokale Bereitstellung nicht nur für grosse Unternehmen, sondern auch für KMU und Organisationen mit bescheidenen IT-Budgets zugänglich.

Fazit

Dieses Forschungsprojekt zur lokalen KI und zum Self-Hosting schafft einen umfassenden Rahmen für die Bewertung, Bereitstellung und Optimierung von KI-Modellen auf der eigenen Infrastruktur. Die Quantisierungstechniken GGUF, AWQ und GPTQ, die Destillation, die Inferenz-Engines Ollama und vLLM, die Docker- und Kubernetes-Orchestrierung, die CUDA-Optimierung, das systematische Benchmarking und das Prometheus-Grafana-Monitoring bilden einen kohärenten Technologie-Stack, der Self-Hosting lebensfähig und leistungsstark macht. Datensouveränität, Kostensenkung und Latenzkontrolle sind keine Kompromisse mehr: Es sind die konkreten Vorteile eines Ansatzes, bei dem die Organisation die Kontrolle über ihre KI-Infrastruktur zurückgewinnt.