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. Neben dem Compute beginnen GPU-Auslastung, Speicherdurchsatz, Ost-West-Traffic, Failure Domains, Virtualisierungs-Overhead, Orchestrierung, Backup und operative Komplexität 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 als Kontrollschicht, die GPUs können woanders laufen

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 beseitigt womöglich nur eine Einschränkung und legt dabei die nächste offen.

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, und genau 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, und 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. Diese Komplexität soll 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 Wert dieses Homelabs liegt im architektonischen Lernen

Beeindruckend an einem 200-Gb-KI-Homelab finde ich weniger die Benchmark-Zahl als 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. Mit Ceph kommen verteiltes Speicherverhalten und Failure Recovery dazu, mit den GPU-Nodes eine knappe Hardware-Ressource mit eigenen Treibern, Speichergrenzen und Performance-Eigenschaften.

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?

Solche Fragen bringen mehr, 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.