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

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