Kubernetes

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

In den bisherigen Posts haben wir einen Agenten von Grund auf gebaut, ihm ein Fundament gegeben, Multi-Agent-Koordination untersucht, Evaluation und Guardrails implementiert und den Agenten als lokalen Service exponiert. Jetzt der letzte Schritt: Alles auf eigene Infrastruktur. Kein API-Call verlässt das Netzwerk. Das Szenario: Ein MLflow-Agent im Cluster Der Agent, den wir in dieser Phase bauen, hat einen konkreten Zweck: Er greift direkt auf MLflow zu — Experimente vergleichen, Modell-Deployments prüfen, Alias-Strategien abfragen. Ohne UI-Navigation, ohne manuelle API-Calls. Stattdessen natürliche Sprache: “Welche Modelle sind im Status Live?” — und der Agent ruft die richtigen Tools auf. ...

Most MLflow setups use about 20% of what the platform offers. Teams log metrics, compare a few training runs, maybe register a model. That’s useful for notebooks and early experimentation — but it doesn’t get you to production. The gap between “we track experiments” and “we have a production ML pipeline” is filled with questions that experiment tracking alone can’t answer: Which model is live right now? What data trained it? Why was the previous version replaced? Can we roll back in under a minute? ...

Die Entscheidung für Self-Hosting ist gefallen. Das Unternehmen betreibt ML-Modelle auf eigener Infrastruktur – aus regulatorischen Gründen, zum Schutz von Betriebsgeheimnissen oder weil das Anfragevolumen eine eigene Infrastruktur wirtschaftlich macht. Damit beginnt die eigentliche Arbeit. Denn wer Modelle selbst betreibt, übernimmt die Verantwortung für alles, was Cloud-Anbieter sonst im Hintergrund erledigen: Training, Deployment, Versionierung, Qualitätssicherung, Rollback. Die Frage ist nicht mehr ob man MLOps braucht, sondern wie gut das Setup sein muss, damit Self-Hosting in der Praxis funktioniert. ...

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