Ein deutschsprachiges Tutorial, das Schritt für Schritt zeigt, wie Unternehmen mit Self-Hosted LLMs ihre Datensouveränität bewahren: Von der Installation über Fine-tuning bis zur vollständigen Unabhängigkeit – inklusive echter Debugging-Stories und transparenten Trade-offs.
Warum diese Tutorial-Serie?
Unternehmen im DACH-Raum stehen vor einem Dilemma: Sie wollen generative KI nutzen, aber sensible Daten dürfen nicht an externe APIs fließen — sei es aus DSGVO-Gründen, Branchenregulierung oder zum Schutz von Betriebsgeheimnissen.
Diese Tutorial-Serie zeigt den Weg von der ersten LLM-Installation bis zur kompletten Datensouveränität — ohne externe Abhängigkeiten. Jeder Post hat ein klares, erreichbares Ziel, und wir dokumentieren echte Probleme und Debugging-Journeys statt nur den “Happy Path”.
Was diese Serie auszeichnet
Schrittweiser Aufbau statt Fertiglösungen Jeder Schritt wird erklärt und begründet. Statt YAML-Dateien zum Copy-Paste erhältst du das Verständnis, um eigene Entscheidungen zu treffen.
Design-Entscheidungen transparent gemacht Wir zeigen nicht nur wie, sondern auch warum. Jede Architektur-Entscheidung wird mit ihren Trade-offs erklärt.
Debugging-Journeys inklusive Echte Probleme und ihre Lösungen – wie die 20-stündige EOS-Token-Debugging-Story. Hier lernst du, was Tutorials normalerweise auslassen.
Vollständige Datensouveränität als Ziel Der komplette Weg zur Unabhängigkeit von externen APIs – von der ersten Installation bis zur selbst gehosteten Dataset-Generierung.
Der Weg zur Datensouveränität
Phase 1: Self-Hosting Basics
“Kann ich ein LLM überhaupt selbst betreiben?”
Post 1: Warum Self-Hosting? Der Business Case für Datensouveränität Das Problem, die Lösung und wann Self-Hosting sinnvoll ist. Entscheidungsmatrix: Cloud-API vs. Self-Hosted.
Post 2: vLLM auf Kubernetes — Dein erstes selbst gehostetes LLM Mistral-7B auf Kubernetes deployen mit vLLM. Nach diesem Post läuft ein LLM auf deiner Infrastruktur.
Phase 2: Anpassung durch Fine-tuning
“Wie mache ich es besser für meinen Use Case?”
Post 3: Warum Fine-tuning? Wenn RAG und Prompting nicht reichen Prompting vs. RAG vs. Fine-tuning — wann welcher Ansatz passt und warum wir Fine-tuning brauchen.
Post 4: Dataset Engineering — Von Dokumenten zu Trainingsdaten Die Pipeline von Rohdokumenten zu QA-Paaren: Chunking, Synthetic Data Generation, Quality Control. 80% der eigentlichen Arbeit.
Post 5: LoRA Training — 7B Model auf 24GB GPU QLoRA macht große Modelle auf Consumer-Hardware trainierbar. Mit MLflow Experiment Tracking.
Post 5.1: Experiment Tracking mit MLflow (Optional) Self-hosted MLflow für Datensouveränität. Custom Callbacks für HuggingFace Trainer.
Post 5.2: Model Evaluation (Optional) Qualitative Evaluation durch Manual Inspection & stratifiziertes Sampling. Baseline Comparison mit Mistral-Instruct.
Post 5.3: Der pad_token Bug – Eine Debugging-Geschichte (Optional)
20 Stunden Debugging dokumentiert: Warum pad_token = eos_token alles kaputt macht.
Post 6: vLLM Deployment mit LoRA – Fine-tuned Models deployen LoRA-Adapter auf dem Base Model laden mit vLLM. Multi-Adapter Serving. Performance-Vergleiche.
Phase 3: Dataset-Generierung
“Wie nutze ich self-hosted LLMs, um synthetische Trainingsdaten zu generieren?”
Post 7: Dataset-Generierung selbst gehostet Können wir Dataset-Generierung selbst hosten — und zu welchen Trade-offs?
Post 7.1: Parallele Dataset-Generierung (Optional) Dataset-Generierung parallelisiert – 9× schneller durch Batching.
Post 7.2: Modell Vergleich (Optional) Quality Comparison Redux – Fairer Vergleich mit Llama-3.1-8B.
Phase 4: LLM-as-Judge
“Kann ich self-hosted LLMs als Judge einsetzen?”
Post 8: LLM-as-Judge Self-Hosted — Evaluation ohne externe APIs Nach diesem Post ist die gesamte Pipeline datensouverän: Dokumente → QA-Paare → Training → Serving → Evaluation.
Post 8.1: Llama-70B als Judge – Apple Silicon statt Cloud GPUs (Optional) Llama-70B-as-Judge auf Apple Silicon — schneller als die Cloud, für $0.
Phase 5: Multi-Adapter Serving und lokales Training
“Kann ich mehrere LoRA-Adapter auf einem Server betreiben?”
Post 9: Multi-LoRA A/B-Testing & Adapter Training auf Apple Silicon Wir trainieren einen zweiten LoRA-Adapter auf Apple Silicon und nutzen Multi-LoRA für das A/B-Testing.
Resümee
Post 10: Resümee – Was wir über Self-Hosted LLMs gelernt haben Der letzte Post dieser Serie. Wir ziehen Bilanz: Was funktioniert, was würden wir anders machen?
Datensouveränität als roter Faden
Von pragmatisch zu souverän
Die Serie geht ehrlich mit externen Abhängigkeiten um. In Post 4 nutzen wir GPT-4o-mini für die Dataset-Generierung — ein bewusster Kompromiss, der transparent gemacht wird. In Post 7 zeigen wir dann die self-hosted Alternative.
Nach Post 8 ist die gesamte Pipeline datensouverän: Kein API-Call verlässt deine Infrastruktur — weder für Training, Serving, Evaluation noch für Dataset-Generierung.
Für wen ist diese Serie?
- ML Engineers & Data Scientists, die den Schritt von Notebooks zu Production-Deployments machen wollen
- Tech Leads & Architekten, die einen Self-Hosted AI-Stack evaluieren und Trade-offs verstehen müssen
- Technische Entscheider (CTO, Head of Data), die Machbarkeit und Aufwand für Datensouveränität einschätzen wollen
- Implementierungspartner, die eine Referenzimplementierung für Kundenprojekte suchen
Der gesamte Code ist auf GitHub verfügbar — zum Nachbauen, Anpassen und Weiterentwickeln.