Ein KI-Homelab mit Proxmox, Kubernetes, 200-Gb-Networking und Ceph aufbauen
Ein im August auf Reddit geteiltes Homelab kombiniert drei Proxmox-Hosts, 36 physische CPU-Kerne, 192 GB DDR5-Speicher, vier als Kubernetes-Nodes genutzte ASUS-GX10-Systeme, insgesamt 512 GB VRAM und ein 200-Gb-Hochgeschwindigkeitsnetzwerk. Die Umgebung bedient lokale Large Language Models, Bildgenerierung, Identitätsdienste, GitOps-Workloads und weitere Projekte. Der Besitzer plant zudem, den Proxmox-Nodes Hochgeschwindigkeits-NICs hinzuzufügen und schnelleren Ceph-Speicher aufzubauen.
Das geht weit über das übliche Homelab mit einem einzelnen Mini-PC hinaus, ist aber nützlich, weil es dieselben Architekturfragen offenlegt, die auch in produktiver KI-Infrastruktur auftauchen. Compute ist nur ein Teil des Systems. GPU-Auslastung, Speicherdurchsatz, Ost-West-Traffic, Failure Domains, Virtualisierungs-Overhead, Orchestrierung, Backup und operative Komplexität beginnen alle miteinander zu interagieren.
Der Mr.PlanB-Proxmox-Hub ist ein nützlicher Ausgangspunkt für die Virtualisierungsschicht. Die interessantere Frage ist, wie diese Schicht mit Kubernetes und KI-spezifischer Hardware verbunden werden sollte, ohne das Lab in eine einzige riesige Abhängigkeitskette zu verwandeln.
Proxmox ist die Kontrollschicht, nicht zwangsläufig die GPU-Schicht
Proxmox funktioniert gut als allgemeines Virtualisierungsfundament für Management-Dienste, Utility-VMs, Testsysteme, Speicherdienste, Firewalls und konventionelle Anwendungs-Workloads. Es gibt einem Lab-Besitzer einen konsistenten Ort, um VMs und Container zu erstellen, Netzwerk und Speicher zu verwalten und mit Clustering und Automatisierung zu experimentieren.
GPU-intensive KI-Workloads bringen andere Prioritäten mit sich. Direkter Hardware-Zugriff, Treiberkompatibilität, Speicherkapazität, PCIe-Topologie und Netzwerkdurchsatz können wichtiger sein als VM-Dichte. Im vorgestellten Aufbau nehmen dedizierte KI-Nodes an Kubernetes teil, während Proxmox ein separater Cluster bleibt. Diese Trennung kann sinnvoll sein, weil sie jeder Schicht erlaubt, das zu tun, worin sie am besten ist.
Ein Lab muss nicht jeden Beschleuniger virtualisieren, nur weil ein Hypervisor verfügbar ist. Manchmal ist die sauberste Architektur, Proxmox für gemeinsam genutzte Infrastruktur und Kubernetes-Management-Workloads zu verwenden, während GPU-Nodes näher an Bare Metal bleiben. Die Wahl hängt davon ab, ob das Ziel Isolation, Portabilität, Hardware-Auslastung oder das Erlernen eines bestimmten Produktionsmusters ist.
Kubernetes macht aus den GPU-Maschinen einen gemeinsamen Compute-Pool
Sobald mehrere Beschleuniger-Nodes verfügbar sind, wird Kubernetes attraktiv, weil es Workloads über sie hinweg schedulen, Dienste konsistent bereitstellen und ein gemeinsames Deployment-Modell für Inferenz, Model Serving, APIs und unterstützende Anwendungen liefern kann.
Der schwierige Teil ist, teure GPUs produktiv zu halten. Der Leitfaden zu KI- und GPU-Workloads auf Kubernetes behandelt Accelerator-Discovery, Scheduling, Node-Pools, Treiber, Speicherdurchsatz, Netzwerk, Autoscaling, Resilienz, Observability und Kosten. Diese Belange werden in einem Homelab mit mehreren Modellen und Diensten, die um GPU-Speicher und Datenpfade konkurrieren, schnell sichtbar.
Ein lokales Modell mag schnell wirken, wenn es allein getestet wird, und dann langsamer werden, wenn Bildgenerierung, Embeddings, Speicher-Traffic und Hintergrundjobs sich dasselbe Fabric teilen. Kubernetes kann Workloads schedulen, aber es kann keine Bandbreite oder kein VRAM erschaffen, das nicht existiert. Gutes Cluster-Design erfordert weiterhin zu verstehen, wo der eigentliche Engpass liegt.
Ein 200-Gb-Fabric verändert, was aus dem Speicher werden kann
Hochgeschwindigkeitsnetzwerke sind besonders interessant, weil verteilter Speicher die Erwartungen oft nicht erfüllt, wenn das Netzwerk nur als Nebensache behandelt wird. Ceph repliziert Daten über Nodes hinweg und hängt bei normalen Schreibvorgängen, Recovery, Rebalancing und Fehlerszenarien stark vom Netzwerkverhalten ab.
Mit ausreichend schnellen Links kann Ceph für einen Proxmox-Cluster deutlich attraktiver werden, aber die reine Leitungsrate garantiert noch keinen guten Speicher. Laufwerksleistung, CPU-Fähigkeit, Netzwerklatenz, Switch-Konfiguration, MTU-Konsistenz, NIC-Treiber, Replikationseinstellungen und das Failure-Domain-Design bestimmen weiterhin das Ergebnis.
Der Ceph-Leitfaden erklärt die Bausteine, darunter Monitors, Manager, OSDs, Placement Groups, Replikation, Erasure Coding, Self-Healing und Scaling. Für einen Drei-Node-Proxmox-Cluster lautet die zentrale Lektion, Ceph an der langsamsten wichtigen Komponente auszurichten statt an der beworbenen Netzwerkgeschwindigkeit. Ein schnelles Fabric kann eine Einschränkung beseitigen und einfach die nächste offenlegen.
Trennen Sie Speicher-Traffic von allem anderen
Ein Lab, das VM-Traffic, Kubernetes-Traffic, Speicherreplikation, Backups, Management und KI-Modelldaten über denselben Pfad führt, kann unberechenbar werden. Hier zahlt sich ein produktionsnäheres Netzwerkdesign aus.
Ceph-Replikation und -Recovery können große Ost-West-Datenflüsse erzeugen. KI-Inferenz-Nodes bewegen womöglich Modellgewichte und Datensätze. Backup-Jobs können anhaltende Transfers erzeugen. Kubernetes fügt Service- und Control-Traffic hinzu. Der Management-Zugriff sollte auch dann erreichbar bleiben, wenn Workloads ausgelastet sind.
Logische Trennung über VLANs ist ein Ausgangspunkt, aber Umgebungen mit hohem Durchsatz benötigen womöglich auch physische Trennung oder sorgfältig geplante Schnittstellen. Das Ziel ist nicht Komplexität um ihrer selbst willen. Es geht darum, zu verhindern, dass ein einzelner schwerer Workload den Rest des Labs schwer bedienbar macht.
Dasselbe Denken gilt für Failure Domains. Trägt derselbe Switch, dieselbe Stromquelle oder derselbe Speicherpfad jede Schicht, kann ein hochentwickelter Cluster trotzdem einen sehr simplen Single Point of Failure haben.
Schnelle Infrastruktur braucht ebenso ernsthaftes Backup
Ein Lab mit Hunderten Gigabyte VRAM und schnellem Speicher kann Compute schnell wieder aufbauen, aber die Daten lassen sich womöglich schwerer neu erzeugen. Modelldateien können oft erneut heruntergeladen werden, während Git-Repositories, Anwendungsdatenbanken, Identitätskonfiguration, Fine-Tuning-Ergebnisse, Prompts, Datensätze und Service-State einzigartig sein können.
Das macht Backup-Architektur selbst in einer experimentellen Umgebung wichtig. Der Leitfaden zum Proxmox Backup Server behandelt inkrementelle deduplizierte Backups, Verifikation, Remote-Synchronisation, Verschlüsselung, Pruning und Tape-Unterstützung. Auch Kubernetes-Workloads brauchen ein eigenes Recovery-Design, weil Cluster-Ressourcen und persistente Anwendungsdaten nicht immer am selben Ort liegen.
Der praktische Ansatz besteht darin, Daten zu klassifizieren. Entbehrliche Modell-Caches sollten nicht denselben Schutz erhalten wie unersetzliche Datenbanken. Reproduzierbare Kubernetes-Manifeste brauchen womöglich eher Git-Historie als ein Backup auf Image-Ebene. Zustandsbehaftete Dienste brauchen anwendungskonsistenten Schutz und getestete Restores.
Der eigentliche Wert dieses Homelabs liegt im architektonischen Lernen
Das Beeindruckende an einem 200-Gb-KI-Homelab ist nicht die Benchmark-Zahl. Es ist die Gelegenheit zu beobachten, wie Infrastrukturschichten miteinander interagieren.
Proxmox kann Virtualisierung, Clustering, Speicher, Netzwerk, Backup und Automatisierung lehren. Kubernetes fügt Scheduling, Service-Networking, Desired State, Secrets, Operatoren und GitOps hinzu. Ceph fügt verteiltes Speicherverhalten und Failure Recovery hinzu. GPU-Nodes fügen eine knappe Hardware-Ressource mit eigenen Treibern, Speichergrenzen und Performance-Eigenschaften hinzu.
Sind diese Systeme miteinander verbunden, wird das Lab zu einem Ort, um realistische Fragen zu testen. Was passiert, wenn ein Ceph-Node bei starkem Inferenz-Traffic ausfällt? Wie lange braucht ein Modelldienst, um sich zu erholen, nachdem ein Kubernetes-Node verschwunden ist? Welcher Traffic dominiert das Fabric während eines Backups? Bleibt das Management während einer Speicher-Recovery reaktionsfähig? Welche Dienste sollten virtualisiert werden, und welche sollten auf Bare Metal bleiben?
Diese Fragen sind wertvoller, als einfach das schnellstmögliche Rack zu bauen. Ein starkes Homelab gibt Ihnen kontrolliertes Scheitern, messbare Engpässe und eine sichere Umgebung, um die Architektur wiederholt zu verändern. Genau deshalb ergeben Proxmox, Kubernetes, Ceph und KI-Infrastruktur eine so interessante Kombination.
Ursprünglich veröffentlicht im Mr.PlanB-Blog.