Post 1: Warum Self-Hosting? Der Business Case für Datensouveränität

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR – Für eilige Leser Das Problem: Unternehmen wollen generative KI nutzen, aber sensible Daten dürfen nicht an externe APIs. Die Lösung: Self-Hosted LLMs bieten volle Kontrolle über Daten und Modellverhalten. Diese Tutorial-Serie zeigt: ✅ Von “erstes LLM deployen” bis “vollständige Datensouveränität” ✅ Echte Debugging-Stories statt “happy path” ✅ Production-Grade Stack: Kubernetes, vLLM, MLflow, Prometheus ✅ Schrittweiser Aufbau – nach Post 2 läuft dein erstes selbst gehostetes LLM Für wen? ML Engineers, Data Scientists, Tech Leads und technische Entscheider im DACH-Raum. ...

Post 2: vLLM auf Kubernetes – Dein erstes selbst gehostetes LLM

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR - Für eilige Leser Was wir bauen: vLLM auf Kubernetes mit Mistral-7B (4-bit quantized) OpenAI-kompatible API für einfache Integration Monitoring mit Prometheus/Grafana out-of-the-box Kostenoptimiert mit scale-to-zero Tech-Stack: vLLM 0.14.1, Mistral-7B-AWQ, Kubernetes (EKS), g6.xlarge (L4 GPU) Code: Alle Manifeste auf GitHub | Willst du mehr? Inhaltsverzeichnis Inhaltsverzeichnis Schnellstart: Warum vLLM auf Kubernetes? Was wollen wir erreichen? Teil 1: Design-Entscheidungen Architekturüberblick Serving Framework Auswahl (vLLM vs TGI vs Triton) Quantisierung (AWQ 4-bit) Hardware-Wahl (g6.xlarge mit L4) Teil 2: Kubernetes Deployment ...

Post 3: Warum Fine-tuning? Wenn RAG und Prompting nicht reichen

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR – Für eilige Leser Die Ausgangslage: Dein LLM läuft (Post 2), aber das Verhalten ist inkonsistent. Prompting allein reicht nicht. Die drei Ansätze: Prompting: Flexibel, aber variable Ergebnisse RAG: Fügt Wissen hinzu, aber keine Verhaltensgarantien Fine-tuning: Brennt konsistentes Verhalten ein Wann Fine-tuning? Spezifische Output-Formate (JSON, strukturierte Daten) 100% Regeleinhaltung erforderlich Latenz-Optimierung durch kürzere Prompts Kleinere, spezialisierte Modelle statt große Generalisten Unser Ansatz: Instruction Fine-tuning mit QLoRA – ressourcenschonend und kombinierbar mit RAG. ...

Post 4: Dataset Engineering: Von Dokumenten zu Trainingsdaten

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Inhaltsverzeichnis Das Problem: Keine Daten, kein Training Die Pipeline im Überblick Was wir bauen: Ein Instruction Dataset für RAG-QA Schritt 1: Document Loading und Chunking Schritt 2: QA-Pair Generation mit GPT-4o-mini Schritt 3: Quality Control – Der unterschätzte Schritt Schritt 4: Dataset Generation - Vom QA-Pair zum Instruction Sample Schritt 5: Train/Val/Eval Split Lessons Learned Was wir beim nächsten Mal besser machen würden Code & Ressourcen Fazit Das Problem: Keine Daten, kein Training Die meisten Fine-tuning-Tutorials starten so: ...

Post 5: LoRA Training – 7B Model auf 16GB GPU

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Technische Begriffe in diesem Post werden beim ersten Auftreten kurz erklärt. Detaillierte Definitionen findest du im Glossar. TL;DR – Für eilige Leser Das Problem: Full Fine-tuning von Mistral-7B würde ~90GB VRAM benötigen (Model + Gradients + Optimizer States). Selbst mit Optimierungen (Mixed Precision, Gradient Checkpointing) kommst du nicht unter 50GB. Du hast nur 16GB. Die Lösung: QLoRA kombiniert 4-bit Quantization mit LoRA (Low-Rank Adaptation). Statt alle 7 Milliarden Parameter zu trainieren, trainierst du nur 6.8 Millionen zusätzliche Parameter — das sind 0.09% des Originals. ...

Post 5.1: Experiment Tracking mit MLflow - Die Kontrolle behalten

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR – Für eilige Leser Das Problem: Mehrere LoRA-Training-Runs mit verschiedenen Hyperparametern werden schnell unübersichtlich: Welches Modell war am besten? Welche Config hatte welche Metriken? Wie reproduziere ich das beste Ergebnis? Die Lösung: MLflow Tracking bietet systematisches Experiment-Management mit automatisiertem Logging von Parametern, Metriken und Modell-Artefakten. Unser Custom Callback gibt volle Kontrolle über das Logging ohne Framework-Magic. Das Ergebnis: Vergleichbare Runs in einer Web-UI, vollständige Reproduzierbarkeit durch Parameter-Tracking, und automatisiertes Metriken-Logging während des Trainings. ...

Post 5.2: Model Evaluation – Qualität messen

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Dieser Post ist optional und vertieft die Evaluation-Methodik aus Post 5. Du kannst direkt zu Post 6 (vLLM Deployment) springen, wenn du mit deinem Training zufrieden bist. TL;DR – Für eilige Leser Das Problem: Training Loss = 0.35 sieht gut aus. Validation Loss = 0.35 zeigt kein Overfitting. Aber sind die generierten Antworten tatsächlich gut? Metrics alleine sagen wenig über Output Quality. ...

Post 5.3: Debugging Story – Das pad_token Problem

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Dieser Post ist ein Bonus-Kapitel zur Blog-Serie. Er dokumentiert eine echte Debugging-Journey und zeigt, dass nicht alles beim ersten Mal glatt läuft – selbst wenn die Metrics perfekt aussehen. TL;DR – Für eilige Leser Das Problem: Nach erfolgreichem Training (Loss 0.33, Validation Loss 0.33) generierte das Model endlos weiter statt nach der Antwort zu stoppen. Statt einer präzisen Antwort kam: “Answer… Question: … [/INST] Answer… Question: …” bis max_new_tokens erreicht war. ...

Post 6: LoRA Serving – Dein Fine-tuned Model in Produktion

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Technische Begriffe in diesem Post werden beim ersten Auftreten kurz erklärt. Detaillierte Definitionen findest du im Glossar. TL;DR – Für eilige Leser Das Problem: Du hast ein Base Model auf Kubernetes (Post 2) und einen trainierten LoRA-Adapter (Post 5). Aber der Adapter liegt als Datei auf S3 – das laufende vLLM weiß nichts davon. Die Lösung: Drei Änderungen am bestehenden Deployment: Ein Init-Container lädt den Adapter von S3, zwei zusätzliche CLI-Flags aktivieren LoRA in vLLM. Das war’s. ...

Post 7: Dataset-Generierung selbst gehostet – Der ehrliche Vergleich

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Alle Zahlen sind gemessen, nicht geschätzt. Unternehmen stehen vor einem Dilemma: Sie wollen, dass ihre Entwickler und Data Scientists Generative KI nutzen - für schnellere Entwicklung, bessere Lösungen, synthetische Trainingsdaten. Aber niemand will Firmendaten, interne Dokumentation oder Intellectual Property an OpenAI, Anthropic oder andere externe Provider schicken. Besonders kritisch: Dataset Generation. Entwickler brauchen synthetische QA-Pairs für Instruction Tuning, realistische Test-Daten für Evaluation, augmentierte Daten für Training. Genau die Art von Daten, die man NICHT extern generieren lassen möchte. ...