GPU-Inferenz unter Proxmox: Was LXC statt einer VM wirklich bringt

Anfang Oktober hat Bart Dworzanczyk auf LinkedIn den Text „Why Should You Run Your GPU Inference Box on Proxmox LXC Instead of a VM?" veröffentlicht. Seine Box: eine RTX 5090, ein EPYC 7352, Proxmox 9.1, darunter LVM-thin, darüber acht Container, von denen sieben die Karte öffnen dürfen, alle privilegiert, mit Docker und vLLM darin (Korrektur 9.10., zuerst stand dort „sechs"). Sein Argument: Passthrough in eine VM verschwendet eine Karte, LXC teilt sie, und Snapshots kosten Sekunden statt Stunden. Seine Zahlen stammen von einer einzigen Maschine, also sind sie selbstberichtet. Die Rohausgaben und Skripte dazu hat er in ein öffentliches GitHub-Repo gelegt, dadurch bleiben sie nachprüfbar (Korrektur 9.10., zuerst stand dort, ein großer Teil seiner Beweise liege hinter dem Login). Nachgerechnet haben wir an der Proxmox-Doku, an NVIDIA-Dokumenten und an unserem eigenen Bestand.

Die Kurzform: Die Technik ist real und die Doku belegt sie. Wir bauen trotzdem nicht um, und zwar aus gemessenen Gründen. Alle Zahlen in diesem Text sind eigene Messungen vom 9. Oktober 2026, alle Gäste und Hosts haben wir dabei nur gelesen.

Was die Proxmox-Doku hergibt und was nicht

Sein wichtigster Beleg ist ein Verweis auf die Doku, und der hält. Wörtlich: „If you pass through a device to a virtual machine, you cannot use that device anymore on the host or in any other VM." Und an anderer Stelle, im Wiki-Artikel zum Thema: „Note that VMs with passed-through devices cannot be migrated." Genau daran entscheidet sich bei uns die Architektur. Unsere Inferenz-Gäste hängen an einem Knoten, eine Live-Migration gibt es für sie nicht, und ein Umbau auf LXC würde diesen Preis nicht senken, sondern anders verteilen.

Bei einem zweiten Beleg wird es eng. Er schreibt, die Proxmox-Doku sage, Memory Ballooning funktioniere nicht mit PCIe-Passthrough. Diese Aussage steht dort nicht. Im Kapitel über QEMU-VMs steht etwas anderes, und zwar über ballooning: „When the host is running low on RAM, the VM will then release some memory back to the host, swapping running processes if needed and starting the oom killer in last resort." Und zur festen Zuteilung: „When setting memory and minimum memory to the same amount Proxmox VE will simply allocate what you specify to your VM." Die Kostenrechnung dahinter stimmt also, das Zitat ist nur keines. Das Detail interessiert uns, weil unser KI-Gast 24.576 MiB hat und das Feld balloon gar nicht setzt. Nach der Doku wird der Ballon-Treiber trotzdem eingebaut, und der kann dem Gast unter Druck RAM abnehmen.

Zwei weitere Punkte aus seiner Liste haben wir ebenfalls an der Doku festgemacht. Bind-Mounts sind tatsächlich nicht in jedem Backup: „The contents of bind mount points are not backed up when using vzdump." Das gilt auch für Geräte-Einhängepunkte. Für Replikation gilt allerdings das Gegenteil, dort werden Mount Points standardmäßig mitgenommen, wenn die Root-Disk repliziert wird. Wer das verallgemeinert, verliert im Ernstfall die falsche Hälfte. Und bei privilegierten Containern ist die Doku härter als der Post: „The LXC team considers this kind of container as unsafe, and they will not consider new container escape exploits to be security issues worthy of a CVE and quick fix. That's why privileged containers should only be used in trusted environments."

Der Satz, der wirklich zählt

Sein ehrlichster Absatz steht weit unten: Freigegebener Zugriff ist kein freigegebener Speicher. Er zeigt das an seinem eigenen Container, in dem vLLM 27 GiB von 32 GiB belegt und ein Start mit 24-GiB-Anfrage abstürzt. Denselben Zustand haben wir am Morgen des 9. Oktober auf unserer Ersatz-Box gemessen, ohne dass jemand experimentiert hätte.

An der Zeile mit 2.167 MiB frei zeigt sich sein Argument von der schlechtesten Seite. Auf dieser Box läuft unser Standby-Modell mit 27.534 MiB und unser Einbettungs-Ersatz mit 2.906 MiB. Ein drittes Modell, das 24 GiB haben will, kann dort nicht hoch. Das ist kein Virtualisierungsproblem, kein Treiberproblem und kein Containerproblem. Das ist eine Budgetfrage, und die wird durch LXC nicht beantwortet.

Was uns der Post wirklich zeigt

Die beiden Bare-Metal-Hosts haben weder Snapshot noch Backup. Kein vzdump-Job kennt sie, sie sind ja keine Gäste. Für die Karte ist das nicht tragisch, die Modelle liegen ohnehin auf Disk. Für alles drumherum gilt sein Satz über Bind-Mounts in voller Härte: Konfiguration, Compose-Dateien und Umgebungsvariablen existieren genau einmal. Ein Totalverlust heißt Lane neu aufsetzen, Treiber aus dem DKMS-Baum, Bilder ziehen, Profile wieder zusammensuchen.

Block-Schnappschüsse sind dort auch nicht nachrüstbar, ohne riskant zu werden. Auf .180.3 meldet vgs für die Volumengruppe VFree = 0, das eine lineare Logische Volume frisst die ganze Gruppe von 3,49 TB. Die 1,7 TB frei, die df zeigt, sind frei im Dateisystem. Ein Dünnpool braucht freie Extents, und die hätten wir nur, indem wir ein 3,49-TB-Dateisystem im laufenden Betrieb schrumpfen. Auf .180.202 gibt es gar kein LVM, dort liegt XFS direkt auf einer Partition.

Dazu kommt eine Entdeckung, die in keinem der beiden Lager vorkommt. Auf unseren Hosts liegt der NVIDIA-Treiber-Lizenztext im Paket libnvidia-compute, und in Abschnitt 2.8 steht: „You agree that GeForce or Titan SOFTWARE: (i) is licensed for use only on GeForce or Titan hardware products you own, and (ii) is not licensed for datacenter deployment." Sein Setup ist ein Homelab, diese Klausel betrifft ihn nicht. Unsere Karten stecken im eigenen Rack und tragen eine interne Firmen-Lane. Was genau „datacenter deployment" für ein Rack in Kufstein bedeutet, ist eine Rechtsfrage und keine Technikfrage. Die beantworten wir hier nicht, sie ist bei uns offen. Passend dazu NVIDIA CUDA Forward Compatibility: Das Dokument schränkt den Mechanismus ausdrücklich ein, anwendbar nur für Systeme mit Data Center GPUs, bestimmten NGC-Server-Varianten und Jetson. Auf GeForce-Karten hilft kein Vorwärtskompatibilitäts-Paket, dort muss der Treiber zum CUDA-Zweig passen. Das erklärt, warum unsere Treiberpflege so steif ist, wie sie ist.

Was wir daraus machen

Umgebaut wird nichts. Unsere einzige GPU-VM ist die Box, die seinen LXC-Vorteil am wenigsten braucht: Drei Sicherungsjobs decken den Cluster ab, zwei davon laufen mit all = 1 über alle Gäste, und der Gastname steht in keiner Ausschlussliste. Einfrieren können wir die VM ebenfalls. Die Proxmox-Doku sagt zum Verschachteln von Containern zudem, dass für Einsätze mit maximaler Isolation und mit Live-Migration das Paketieren von Containern in eine QEMU-VM eine empfohlene Vorgehensweise bleibt. Wir laufen exakt in dieser Variante. Auf .180.3 mit vier vollgestopften Karten bringt Teilen nichts, dort gibt es nichts zu teilen.

Wir nehmen zwei Dinge mit, und beide sind klein. Erstens: restic-Sicherung für die Konfiguration beider Bare-Metal-Hosts, Compose-Dateien und Umgebungsvariablen dazu in ein Git-Repo. Zweitens: ein VRAM-Budget je Lane mit Start-Gate, das zu bleibt, wenn der freie Platz nicht reicht. Sein Drehbuch für den Start hat genau diese Stelle als Warnung gebaut und startet nach drei Minuten trotzdem, nur ein Warnschild, kein Gate. Bei uns läuft der Fall anders: Ein Start mit 24 GiB Bedarf auf einer Lane mit 2.167 MiB frei darf nicht passieren, er muss abgewiesen werden.

Weiterführende Quellen

• Bart Dworzanczyk, „Why Should You Run Your GPU Inference Box on Proxmox LXC Instead of a VM?", LinkedIn Pulse, 7. Oktober 2026: Originaltext
• Dieselbe Person hat Rohausgaben, Skripte und den Bauplan zu dem Text abgelegt, darin auch das Startskript mit der Warnung nach drei Minuten: Beweis-Repo auf GitHub
• Proxmox VE Administrator's Handbook, Kapitel über QEMU-VMs, Abschnitt PCI-Passthrough und Speicher: chapter-qm
• Proxmox VE Administrator's Handbook, Kapitel über Container, Abschnitt Backup und Privilegierte Container: chapter-pct
• Proxmox-Wiki zum Durchreichen von PCI-Geräten, inklusive Hinweis auf fehlende Migration: PCI Passthrough
• NVIDIA MIG User Guide, Liste der unterstützten Profile, ohne GeForce-Eintrag: Supported MIG Profiles
• NVIDIA Driver License Agreement, Abschnitt 2.8 zu GeForce und Titan: NVIDIA Driver License Agreement
• NVIDIA CUDA Compatibility, Einschränkung der Forward Compatibility: CUDA Forward Compatibility
• NVIDIA Container Toolkit, Installation auf dem Host, damit Container die GPU erreichen: Install Guide
• warum wir überhaupt eine eigene Inferenzstrecke betreiben: eigene KI-Strecke mit LiteLLM und vLLM
• wie unsere Container-Entscheidung gegen Docker ausfiel: Docker oder LXC unter Proxmox
• welche Regel unsere Sicherungsarchitektur trägt: Der 3-2-1-Backup-Plan für Proxmox