LoRA

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

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

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

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR – Für eilige Leser In diesem Post kombinieren wir Training auf Apple Silicon mit Multi-LoRA Serving für A/B-Testing zweier LoRA-Adapter. Der neue Adapter v2 wurde mit 200 negativen Samples trainiert, die ihm beibringen “Ich kann die Frage nicht beantworten” zu sagen, wenn Information fehlt. Kernerkenntnisse: Mac-Training funktioniert: Kaum langsamer als Cloud T4, aber keine Cloud-Kosten und vollständig lokal 90% Hallucination-Reduction: v2 halluziniert nur noch bei 5% der unbeantwortbaren Fragen (vs. 92.5% bei v1) Minimaler Trade-off: False-Negative-Rate steigt nur um 0.78% (tatsächlich sogar niedriger nach manueller Review) Ende-zu-Ende Self-Hosting: Komplette Pipeline von Dataset-Generation über Training bis Serving ohne Cloud Was wir erreicht haben: Produktionsreifer LoRA-Adapter mit dramatisch reduzierter Hallucination-Rate bei gleichbleibender Qualität auf positiven Samples. Der komplette Workflow - Dataset-Generation, Training, Evaluation - läuft vollständig self-hosted. ...