Serving

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