<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gpu on René Zander | KI-Automatisierungsberater</title><link>https://renezander.com/de/tags/gpu/</link><description>Recent content in Gpu on René Zander | KI-Automatisierungsberater</description><generator>Hugo</generator><language>de</language><lastBuildDate>Sun, 05 Apr 2026 07:00:00 +0200</lastBuildDate><atom:link href="https://renezander.com/de/tags/gpu/index.xml" rel="self" type="application/rss+xml"/><item><title>Self-Hosted LLM auf Kubernetes: Produktives vLLM-Deployment</title><link>https://renezander.com/de/blog/self-hosted-llm-kubernetes/</link><pubDate>Sun, 05 Apr 2026 07:00:00 +0200</pubDate><guid>https://renezander.com/de/blog/self-hosted-llm-kubernetes/</guid><description>&lt;p>Die meisten Teams, die nach Self-Hosted-LLM-Kubernetes-Deployments fragen, sollten dafür gar kein Kubernetes fahren. Die ehrliche Antwort: vLLM auf einer einzelnen GPU-Box, eingepackt in systemd oder Docker Compose, deckt mehr Use Cases ab, als man gerne zugibt. Kubernetes verdient sich seinen Platz erst, wenn Sie es ohnehin betreiben — oder wenn Sie horizontale Skalierung, Multi-Tenancy-Isolation oder saubere Rolling Deploys über einen GPU-Node-Pool brauchen.&lt;/p>
&lt;p>Dieser Leitfaden setzt voraus, dass Sie sich für Kubernetes entschieden haben. Ich gehe die Referenzarchitektur durch, die ich beim LLM-Deployment nach k8s nutze, liefere vollständige Manifests für vLLM mit Llama 3.3 70B quantisiert und die operativen Stolpersteine, die jedes Team beim ersten Mal erwischen. Keine plattformspezifische Magie, keine Abstraktion hinter einem Managed Vendor. Nur die YAML, die Sie brauchen, und die Begründung hinter jedem Feld.&lt;/p></description></item></channel></rss>