NVIDIA-GPUs in Proxmox-LXC-Containern: Host-Treiber, Gerätedateien, Teilen, Grenzen

Wie eine NVIDIA-GPU in einen Proxmox-LXC-Container kommt

Ein Proxmox-LXC-Container läuft auf dem Kernel des Hosts; der Host lädt also den NVIDIA-Treiber und behält die Karte, und jeder Container bekommt die Gerätedateien /dev/nvidia* sowie die User-Space-Bibliotheken desselben Treiber-Releases. Mehrere Container können die Karte dann gleichzeitig nutzen, was für einige interne Dienste auf einer GPU passt. Sie teilen sich den Speicher der Karte ohne jede Trennung, und weder NVIDIA noch Proxmox dokumentiert die Kombination als unterstützt.

Dieser Leitfaden richtet sich an einen Proxmox-Host im Unternehmen, der eine Handvoll GPU-Dienste tragen soll, etwa einen Inferenz-Endpunkt, einen Embedding-Dienst und eine Transkription, ohne eine VM je Karte. Die VM-Wege selbst behandeln unsere Leitfäden zu NVIDIA vGPU unter Proxmox VE und zur RTX PRO 6000 Max-Q in virtuellen Maschinen.

Proxmox pct-Handbuch 9.2.13 (24. September 2026); NVIDIA GPU Operator, Seite zu GPU Sharing (14. Oktober 2026); NVIDIA MIG User Guide (13. Oktober 2026); NVIDIA Container Toolkit, Platform Support (18. September 2026); vGPU-Zeile aus unserem Proxmox-vGPU-Leitfaden; alle gelesen am 25. Oktober 2026.

Was Proxmox und NVIDIA dokumentieren und was offen bleibt

Auf der Seite von Proxmox sind die Bausteine dokumentiert. Das pct-Handbuch für Proxmox VE 9.2.13 vom 24. September 2026 hält fest, dass Container „use the kernel of the host system that they run on, instead of emulating a full operating system“. Es führt die Option dev[n], „Device to pass through to the container“, mit den Unteroptionen path, mode, uid, gid und deny-write; die Seite „Linux Container“ im Proxmox-Wiki, zuletzt bearbeitet am 21. Mai 2026, beschreibt uid und gid als die IDs, die „to be assigned to the device node“ sind, und mode als „access mode to be set on the device node“. Im Proxmox-Forum schrieb ein Mitarbeiter am 4. Juni 2024, dieses Durchreichen gebe es auf Kommandozeile und API seit 8.1 und in der Weboberfläche seit 8.2, unter Resources, Add, Device Passthrough. GPUs und NVIDIA kommen auf keiner der beiden Seiten vor.

NVIDIAs Dokumente behandeln den Host und den Container-Stack getrennt, und keines nennt LXC. Die Plattformseite des Container Toolkit vom 18. September 2026 listet die Distributionen, auf denen aktuelle Releases „are tested and expected to work“: darunter Ubuntu 22.04, 24.04 und 26.04, RHEL 8 bis 10 und Debian 11 als einzige Debian-Version. Proxmox VE 9.2 ist laut Proxmox-Roadmap „Based on Debian Trixie (13.5)“. NVIDIAs Treiber-Installationsleitfaden für den Branch 615, aktualisiert am 23. September 2026, behandelt Debian 12 und 13, ein Proxmox-Host läuft aber mit dem eigenen Kernel von Proxmox, nicht mit dem von Debian. NVIDIAs vGPU-Dokumentation führt Proxmox VE zwar als validierte Plattform unter Linux mit KVM, diese Aussage gilt für vGPU in virtuellen Maschinen.

Der Weg funktioniert also mit dokumentierten Teilen, für das Ganze steht niemand ein. Wer einen Dienst freigibt, auf den sich eine Abteilung verlässt, sollte wissen: Ein Treiberproblem in diesem Aufbau löst der Betreiber selbst, ein Herstellerticket gibt es dafür nicht.

Der Host: Treiber, Kernelmodule und Gerätedateien

Am Anfang steht ein funktionierender NVIDIA-Treiber auf dem Proxmox-Host.

Erstens die Variante des Kernelmoduls. NVIDIAs Treiber-README für Release 580.95.05 hält fest: „Blackwell and later are only supported by the open kernel modules“; jede RTX-PRO-Blackwell-Karte braucht also die offenen Module. NVIDIAs Anleitung für Debian installiert sie mit dem Paket nvidia-open, für einen Compute-Host ohne Bildschirm mit nvidia-driver-cuda und nvidia-kernel-open-dkms, und sie braucht die Header des laufenden Kernels. Unter Proxmox sind das die Header für den Proxmox-Kernel, und das Modul wird bei jedem Kernel-Update über DKMS neu gebaut. Hosts mit Secure Boot brauchen ein signiertes Modul, wie unser Leitfaden zum NVIDIA-Treiber mit Secure Boot auf Linux-Servern erklärt.

Zweitens der Branch. Ein Treiber-Update auf dem Host ändert das Kernelmodul für alle Container zugleich, der Branch sollte deshalb nur wechseln, wenn Sie es entscheiden. NVIDIAs Seite zum Version Locking zeigt für Debian und Ubuntu Pinning-Pakete mit Namen wie nvidia-driver-pinning-<branch> oder mit voller Versionsnummer. Welcher Branch passt und welche Releases die Sicherheitslücken vom 30. September 2026 beheben, steht in unserem Artikel zu NVIDIA-Treiber-Branches und CUDA-Versionen. Sicherheit wiegt hier schwerer als auf einem VM-Host: Jeder Container mit den Gerätedateien spricht direkt mit dem Kerneltreiber des Hosts.

Drittens müssen die Gerätedateien existieren, bevor die Container starten. Das README beschreibt nvidia-uvm.ko, das „provides functionality for sharing memory between the CPU and GPU in CUDA programs“, als geladen, sobald ein CUDA-Programm startet, und nvidia-modprobe als setuid-Werkzeug, das die Module lädt und die Gerätedateien /dev/nvidia* anlegt. Ein Proxmox-Host, der selbst kein CUDA-Programm ausführt, kann also ohne das UVM-Modul und seine Gerätedatei hochfahren, und ein Container, der dann startet, findet kein /dev/nvidia-uvm. Der NVIDIA-Hook des LXC-Projekts gibt für genau diesen Fall eine Warnung aus: „Kernel module nvidia_uvm is not loaded, nvidia-container-cli might fail.“ Planen Sie beim Hochfahren des Hosts einen Schritt ein, der die Module lädt und die Gerätedateien anlegt; auch nvidia-persistenced, laut NVIDIA der Daemon „for allowing the NVIDIA kernel module to maintain persistent state“, gehört auf einen solchen Host.

NVIDIA MIG User Guide, „Device Nodes and Capabilities“ (13. Oktober 2026); NVIDIA-Linux-Treiber-README 580.95.05, Installed Components; gelesen am 25. Oktober 2026.

Der Container: Gerätezugriff und User-Space des Treibers

Ein Container braucht zwei Dinge für CUDA: die Erlaubnis, die Gerätedateien zu öffnen, und die Bibliotheken, die mit ihnen sprechen, etwa libcuda.so und die Management-Bibliothek hinter nvidia-smi. Die Kernel-Hälfte bleibt auf dem Host.

Proxmox legt neue Container standardmäßig unprivilegiert an; das pct-Handbuch nennt das „the default option when creating a new container“. Root im Container wird auf einen unprivilegierten Benutzer außerhalb abgebildet, und die Gerätedateien werden mit dev[n] übergeben, wobei uid, gid und mode so gesetzt werden, dass das Dienstkonto im Container sie öffnen kann. Privilegierte Container vermeiden die Abbildung, das Handbuch ist zu ihnen aber deutlich: „The LXC team considers this kind of container as unsafe“, und sie „should only be used in trusted environments“. Ein GPU-Container für einen internen Dienst rechtfertigt keinen privilegierten Container. Ältere Anleitungen vergeben den Zugriff mit rohen Zeilen lxc.cgroup2.devices.allow und lxc.mount.entry, die Proxmox „directly to the LXC low-level tools“ weitergibt; laut Proxmox-Wiki wurde cgroup v1 mit Proxmox VE 9.0 vollständig entfernt, und Proxmox VE 9.2 warnt vor rohen cgroup-v1-Einträgen in Container-Konfigurationen. Solche Zeilen sollten Sie also prüfen.

Für den User-Space gibt es zwei verbreitete Ansätze.

1. NVIDIAs Container-Bibliothek über einen LXC-Hook. Das LXC-Projekt liefert einen Mount-Hook namens nvidia, der nvidia-container-cli aus NVIDIAs libnvidia-container aufruft, einer Bibliothek, die „designed to be agnostic of the container runtime“ ist. Der Hook liest NVIDIA_VISIBLE_DEVICES und NVIDIA_DRIVER_CAPABILITIES, und seine Optionen zeigen auf das Treiberverzeichnis und den Bibliothekscache des Hosts; der Container übernimmt die Treiberkomponenten also vom Host und trägt keine eigene Kopie. Zwei Details aus dem Skript: Es bricht mit „This hook currently only works in unprivileged mode“ ab, und in einem User Namespace übergibt es --no-cgroups, der Gerätezugriff muss also weiterhin in der Container-Konfiguration erteilt werden. Prüfen Sie, ob Hook und NVIDIA-Werkzeug auf Ihrem Host vorhanden sind.
2. Der User-Space des Treibers im Container installiert. Viele Anleitungen installieren dasselbe Treiber-Release im Container ohne dessen Kernel-Teil. NVIDIA dokumentiert dafür keine eigene Container-Variante, und die Versionen müssen gleich bleiben: NVIDIAs README warnt, „problems will arise if applications use the wrong version of a library“. Jedes Treiber-Update auf dem Host heißt dann, alle Container im selben Wartungsfenster nachzuziehen.

Im Container kann Docker oder Podman mit NVIDIAs Container Toolkit darauf laufen. Die Installationsanleitung des Toolkits dokumentiert nvidia-ctk config --set nvidia-container-cli.no-cgroups --in-place für Docker im Rootless-Modus, dieselbe Lage wie in einem unprivilegierten Container. Proxmox selbst rät bei verschachtelten Containern zu etwas anderem: „nesting containers inside a Proxmox QEMU VM remains a recommended practice“, wo Isolation oder Live-Migration zählt. Die Docker-Seite behandelt unser Leitfaden zur GPU-Zuweisung in Docker ohne Kubernetes.

Wir liefern die RTX PRO 6000 Server Edition und die anderen Karten unserer GPU-Seite als Karten oder in KI-Servern nach Auftrag; nennen Sie uns die Dienste, die sich einen Host teilen sollen, und den Speicherbedarf jedes Dienstes, und unser Team antwortet mit einer Karten- und MIG-Aufteilung dafür.

Eine GPU für mehrere LXC-Container: was sie teilen

Der Reiz von LXC liegt darin, dass drei Container /dev/nvidia0 gleichzeitig öffnen können. Sie erhalten einen Anteil an der Rechenzeit und teilen sich einen gemeinsamen Speicher. NVIDIAs GPU-Operator-Dokumentation beschreibt diesen Mechanismus für GPUs mit Time-Slicing: Die GPU „simply provides an equal share of time to all GPU processes“, und „unlike Multi-Instance GPU (MIG), there is no memory or fault-isolation between replicas“. Dasselbe gilt für Prozesse aus verschiedenen LXC-Containern auf einer Karte. Ein Container, der mehr Speicher belegt, lässt den anderen weniger übrig, und ein Prozess, der einen schweren GPU-Fehler auslöst, kann jeden Prozess auf der Karte treffen.

Zuerst geht es beim Speicher schief, weil Inferenz-Engines ihn im Voraus reservieren. vLLMs --gpu-memory-utilization steht laut der aktuellen Dokumentation der Engine-Argumente standardmäßig auf 0,92 und ist „a per-instance limit, and only applies to the current vLLM instance. It does not matter if you have another vLLM instance running on the same GPU.“ Mit Standardeinstellungen bekommt ein zweiter vLLM-Container auf derselben Karte nicht den Speicher, den er anfordert. Das Beispiel der Dokumentation sind zwei Instanzen mit je 0,5. Auf einer RTX PRO 6000 mit 95,6 GiB für den Treiber sichtbarem Speicher erhalten zwei Instanzen mit 0,45 nach unserer Schätzung je etwa 43,0 GiB (0,45 × 95,6 GiB); das lässt Platz für die CUDA-Kontexte und einen kleinen dritten Dienst. Ollama verhält sich anders: Es „evaluates the required VRAM for the model against what is currently available“ und hält ein Modell standardmäßig fünf Minuten nach der letzten Anfrage geladen. Ein Modell, das Ollama gerade geladen hat, kann also Speicher belegen, den ein vLLM-Container frei erwartet hat. Scheitert ein Container trotzdem, nennt unser Leitfaden zu vLLM CUDA Out of Memory die Ursachen.

Ein großes Modell passt in keinen Anteil. Llama 3.3 70B in FP8 hat 67,7 GiB Gewichte; nach unserer Nutzer-pro-Karte-Regel (0,9 × für den Treiber sichtbarer Speicher, minus 3 GiB Overhead je Karte, minus Gewichte) bleiben auf einer RTX PRO 6000 jeder Edition 83,0 GiB für Gewichte und Cache, genug für 12 Unterhaltungen mit 8.192 Token bei FP8-Cache. Ein solches Modell braucht die ganze Karte, und der LXC-Weg bringt dann gegenüber einer VM mit Passthrough keinen Vorteil beim Teilen.

MIG auf dem Host: getrennter Speicher je Container

Auf einem Proxmox-Host läuft der NVIDIA-Treiber auf Bare Metal, und NVIDIAs MIG-Leitfaden vom 13. Oktober 2026 nennt „Bare-metal, including containers“ als unterstützte Konfiguration. MIG teilt eine Karte in Hardware: Die RTX PRO 6000 Blackwell lässt sich in allen drei Editionen in bis zu vier Instanzen aufteilen, die RTX PRO 5000 48 GB und die RTX PRO 4500 in zwei, die H200 NVL in sieben (NVIDIAs Leitfaden nennt die RTX PRO 4500 ohne Edition, planen Sie MIG daher nur mit der Server Edition); L40S und L4 haben kein MIG. Auf einer RTX PRO 6000 heißen die Profile 1g.24gb, 2g.48gb und 4g.96gb, und vier Container mit je einer 1g.24gb-Instanz haben eigenen Speicher und eigene Speicherpfade. Das Anlegen der Instanzen und die Voraussetzungen, einschließlich der Umschaltung des Display-Modus bei Workstation und Max-Q Edition, beschreibt unser MIG-Leitfaden für RTX PRO Blackwell Schritt für Schritt, die Profiltabelle steht unter MIG-Profile der RTX PRO 6000.

Der Zugriff auf eine Instanz läuft über Capability-Gerätedateien. Der MIG-Leitfaden beschreibt die /dev-Schnittstelle unter /dev/nvidia-caps als „primarily“ auf cgroups gestützt, nennt sie die bevorzugte Methode und hält fest, dass „all future NVIDIA datacenter drivers will have a default of nv_cap_enable_devfs=1“, womit sie aktiviert ist. Über diese Schnittstelle erhält ein Container nur die Capability-Dateien der GPU-Instanz und der Compute-Instanz, die er nutzen soll. Der Leitfaden warnt außerdem: Wer einem Container die Capability mig-config gibt, gibt ihm Zugriff auf die Dateien jeder Instanz, die später angelegt werden kann; diese Capability bleibt deshalb auf dem Host. Zwei Vorbehalte gelten. NVIDIA dokumentiert das für Container allgemein, und wir haben keine Seite von Proxmox oder NVIDIA gefunden, die es mit LXC zeigt. Und die Aufteilung ist ein Zustand des Hosts: Ändert sie sich, ändern sich die Capability-Dateien der neuen Instanzen, und die Container-Konfiguration muss folgen.

MIG trennt Speicher und Fehler auf der Karte. Die Container teilen sich weiterhin einen Host-Kernel und einen Kerneltreiber; ein Treiberfehler oder eine Kompromittierung auf Host-Ebene trifft also alle, was eine vGPU-VM mit eigenem Gast-Kernel begrenzt.

Wann MIG oder vGPU in VMs der bessere Weg ist

LXC mit GPUs passt zu wenigen vertrauenswürdigen Linux-Diensten, die ein Team auf einem Host betreibt: Entwicklungswerkzeuge, ein interner Inferenz-Endpunkt, Batch-Jobs, ein Transkriptionsdienst. Weniger gut passt der Weg, sobald einer dieser Punkte zutrifft.

• Verschiedene Eigentümer oder Mandanten. Ohne MIG hindert nichts einen Container daran, den Speicher zu belegen, den die anderen brauchen, und mit MIG teilen sie sich weiterhin den Host-Kernel. Getrennte VMs geben jedem Eigentümer einen eigenen Kernel.
• Windows-Gäste, Desktops oder Grafik. Container sind Linux auf dem Host-Kernel. Virtuelle Desktops und Windows-Arbeitslasten gehören in vGPU-VMs, für die NVIDIAs Lizenzen vWS, vPC und vApps gelten.
• Live-Migration. Das pct-Handbuch hält fest: „running containers cannot live-migrated due to technical limitations“; es bietet eine Neustart-Migration an, die den Container herunterfährt und auf dem Ziel startet; ein GPU-Container braucht dort außerdem dieselben Geräte und denselben Treiber. VMs mit NVIDIA vGPU lassen sich seit Proxmox VE 8.4 live migrieren.
• Ein Supportvertrag. Proxmox nimmt vGPU-Tickets mit einem Basic-, Standard- oder Premium-Abonnement plus NVIDIA-vGPU-Berechtigung an, wie unser Proxmox-vGPU-Leitfaden darlegt. Für GPU-Container gibt es keine vergleichbare Aussage.
• Große Modelle. Ein Modell, das eine ganze Karte oder mehrere Karten für Tensor-Parallelität braucht, gewinnt durch Teilen nichts; eine Passthrough-VM oder Bare Metal ist einfacher.

Ein Host kann die Wege Karte für Karte mischen. Das Proxmox-Wiki zu PCI Passthrough hält fest: „If you 'PCI passthrough' a device, the device is not available to the host anymore.“ Eine an eine VM durchgereichte Karte ist also für den Host-Treiber und für jeden Container unerreichbar, und eine Karte, die der Host-Treiber für Container nutzt, kann nicht gleichzeitig an eine VM gehen. Für mehrere Teams in einem Cluster ist Scheduling mit Kubernetes die andere verbreitete Antwort; unser Leitfaden zum GPU-Sharing in Kubernetes vergleicht dort MIG, Time-Slicing und MPS.

Welche Karte für einen gemeinsam genutzten Proxmox-Host

Für einen Rack-Server im Dauerbetrieb empfehlen wir die RTX PRO 6000 Blackwell Server Edition: 96 GB je Karte, MIG mit bis zu vier Instanzen, und sie ist die Edition, die NVIDIA für vGPU führt; dieselbe Karte kann also später von Containern zu vGPU-VMs wechseln. Die RTX PRO 4500 Blackwell Server Edition mit 32 GB und zwei MIG-Hälften passt zu kleineren Diensten. RTX PRO 6000 Max-Q und Workstation Edition funktionieren auf dem LXC-Weg ebenfalls, weil der Host-Treiber sie wie jede andere Karte nutzt, sie haben aber kein vGPU, und in einem Rack-Server gehört die Max-Q nur in ein Gehäuse, dessen Hersteller sie listet. Hostgrößen vergleicht unser Leitfaden zu zwei, vier oder acht Karten RTX PRO 6000 Server Edition.

Wir bauen diese Karten in KI-Server nach Auftrag ein, vor der Lieferung montiert und getestet, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und Container-Laufzeit; die Herstellergarantie wickeln wir ab, und Mengen und Lieferzeit werden schriftlich mit dem Angebot bestätigt. Wenn Sie einen gemeinsam genutzten Proxmox-Host planen, senden Sie uns die Dienste und den Speicherbedarf jedes Dienstes, und wir schlagen Karten und eine MIG-Aufteilung vor.

FAQ