LLM

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. ...

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 ...

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. ...

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. ...

Projekt: Self-Hosted LLMs für Datensouveränität – Blog-Serie Zweck: Zentrale Begriffserklärungen für alle Posts Dieses Glossar erklärt technische Begriffe, die in der Blog-Serie verwendet werden. Die Begriffe sind alphabetisch sortiert und nach Kategorien gruppiert. Inhaltsverzeichnis Training & Optimization Model Architecture & LoRA Memory & Hardware Serving & Infrastructure Evaluation & Metriken Data & Datasets Training & Optimization Activation / Activations Zwischenergebnisse, die während des Forward Pass (Berechnung der Predictions) eines Neural Networks entstehen. Diese müssen für den Backward Pass (Gradient-Berechnung) im Speicher gehalten werden. Bei großen Models und Batches können Activations mehrere GB VRAM benötigen. ...

Ein RAG-System nach Benchmark-Listen zu bauen, bedeutet für die Daten von jemand anderem zu optimieren. Vor einiger Zeit sprach ich mit einem potenziellen Kunden. Ihm war ein multimodales RAG-System hingestellt worden — mit aktuellen Technologien, sauber aufgesetzt, alles state of the art. Das Problem: Es hat ihm einfach nicht die Informationen gegeben, die er brauchte. Im Gespräch wurde klarer, was er eigentlich wollte: Fragen wie “Welche Analysen haben wir zu Thema X in Verbindung mit Thema Y gemacht?” — über Hunderte von PowerPoint-Dateien hinweg. Für solche Anfragen braucht man entweder eine relationale Datenbank, Graph-RAG oder Agentic RAG. Klassisches RAG ist die falsche Architektur. ...

Im letzten Post haben wir gemessen, wie gut ein Agent arbeitet. Aber Evaluation beantwortet nur die Frage “wie gut?” — nicht “wie sicher?” Der Unterschied ist fundamental: Ein klassisches ML-Modell macht falsche Vorhersagen. Ein Agent kann falsche Aktionen ausführen — Tool-Calls, Deployments, Datenbankschreibvorgänge. Das eine ist ein Qualitätsproblem. Das andere kann konkreten Schaden anrichten. Deshalb brauchen Agenten Guardrails. Nicht als optionales Feature, sondern als Voraussetzung für den produktiven Einsatz. Fünf Schichten, ein Prinzip Die Guardrails werden von außen um den Agenten gelegt — ohne den Agenten-Code zu ändern. Das ist bewusst so: Je mehr man den Agenten selbst ändern muss, um ihn abzusichern, desto schlechter ist die Architektur. Fachlogik und Sicherheitslogik gehören in getrennte Schichten. ...

Im letzten Post haben wir Agenten auf mehrere Schultern verteilt — Handoff, Supervisor, Swarm. Aber egal ob ein Agent oder zehn: Woher weiß man, ob sie gut arbeiten? Bei einem klassischen ML-Modell gibt es klare Metriken: Accuracy, F1-Score, AUC. Man hat ein Testset, lässt das Modell laufen und bekommt eine Zahl. Besser oder schlechter — eindeutig. Bei Agenten ist das anders. Das LLM als zentrale Komponente ist nicht-deterministisch — derselbe Input kann zu unterschiedlichen Pfaden führen. Die Anzahl der Schritte variiert. Und “richtig” ist oft eine Einschätzung, keine Ja/Nein-Entscheidung. War die Diagnose vollständig? Waren die Maßnahmen umsetzbar? Hat der Agent halluziniert? ...

Im letzten Post haben wir dem Agenten ein Fundament gegeben — LangGraph für Struktur, MCP für standardisierte Tools. Das Ergebnis: ein einzelner Agent, der verschiedene Tool-Quellen kombiniert und dessen Kontrollfluss transparent und testbar ist. Aber irgendwann reicht ein einzelner Agent nicht mehr aus. Nicht weil er zu wenig Tools hat, sondern weil die Aufgabe so komplex wird, dass ein einzelnes LLM zu viele Rollen gleichzeitig übernehmen muss. Es soll analysieren, Maßnahmen ableiten und einen Bericht schreiben — alles in einem Kontext. Je mehr Verantwortung man einem Agent gibt, desto größer wird der Kontext und desto wahrscheinlicher wird Halluzination. ...

Im letzten Post haben wir einen Agenten von Grund auf gebaut — ohne Framework, direkt gegen die Anthropic API. Das Ergebnis: ein funktionierender ReAct-Agent mit Calculator und Wikipedia als Tools. Funktioniert. Aber bei genauerem Hinsehen zeigen sich schnell einige Grenzen: Bei einem Crash startet der Agent von vorne — es gibt kein Checkpointing. Der Loop ist linear — bedingte Verzweigungen lassen sich zwar mit if/else einbauen, werden aber schnell unübersichtlich, intransparent und schwer wartbar. ...