Hardware ab Werk gedrosselt! RTX 3090 entsperren
Wie sich gpu-unlock in einer Proxmox-VM mit durchgereichter RTX 3090 installieren und prüfen lässt.
Ich war etwas erstaunt, als ich ein git-Rpository fand, das die Behauptung aufstellte, dass die Hardware von Enterprise-Grafikkarten auch in Consumer-Grafikkarten verwendet wird. Über die verfügbare Leistung entscheidet lediglich der verwendete Treiber. Die Installation von gpu-unlock in einer VM unterscheidet sich dann kaum von einem Bare-Metal-Setup, mit einer Ausnahme: Das Modul gehört in den Gast, nicht auf den Proxmox-Host. Die Karte ist bei mir per vfio-pci durchgereicht, und nur der Gast hat den NVIDIA-Treiber geladen, also muss dort auch der Unlock eingesetzt werden.
Der Host bleibt treiberfrei
Auf dem Proxmox-Host hat der NVIDIA-Treiber nichts verloren. Die Karte wird ja per vfio-pci an die VM gereicht, und das gilt auch für den Unlock. Ergänzend zur IOMMU- und VFIO-Konfiguration ist im Host-BIOS zwingend „Above 4G Decoding“ zu aktivieren, damit die 24 GB VRAM der Karte überhaupt fehlerfrei adressiert werden können. Auf Proxmox-Ebene verhindert der Kernel-Parameter initcall_blacklist=sysfb_init, dass sich der Host beim Booten am Framebuffer der Karte festkrallt. In der VM selbst ist das Deaktivieren des Memory-Balloonings Pflicht, da PCIe-Passthrough zwingend fest reservierten Arbeitsspeicher verlangt. Beim Hinzufügen der Hardware sollten zudem „PCI-Express“ und „All Functions“ aktiv sein, um GPU und Audio-Chip als geschlossene Einheit an das Gastsystem zu binden.
Treiber im Gast installieren
Im Debian-13-Gast braucht der Treiber Kernel-Headers. Ich habe Kernel 7.2.9 aus den trixie-backports getestet, der den NVIDIA-Open-Treiber 615.71.09 über DKMS verwendet, zusammen mit CUDA 13.4 aus dem NVIDIA-Repository. Auf dem Backport-Kernel reicht linux-headers-amd64 nicht zwingend, weil der Paketname je nach Kernelzweig abweicht. Ob der Treiber sauber gebaut wurde, zeigt nvidia-smi.
root@ai:~ # apt install linux-headers-$(uname -r)
root@ai:~ # nvidia-smi
Wed Nov 4 20:50:47 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 615.71.09 KMD Version: 615.71.09 CUDA UMD Version: 13.4 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 3090 On | 00000000:01:00.0 Off | N/A |
| 0% 47C P8 30W / 370W | 22927MiB / 24576MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1047 C ...rver/ComfyUI/venv/bin/python3 256MiB |
+-----------------------------------------------------------------------------------------+
Ein Vorteil des Gast-Setups: Der Unlock ist vom Treiber getrennt. Das Modul läuft vor dem NVIDIA-Treiber und überlebt deshalb auch Treiber-Updates, solange die Firmware-Basis passt. Die Firmware stammt laut Projekt aus dem Paket der Treiberversion 610.43.03.
gpu-unlock bauen und installieren
Das Repository liefert für Debian ein Target, das die Abhängigkeiten nachzieht und die Pakete baut. Der Bericht aus Issue #9 hat so vorgegangen:
git clone https://github.com/Zagitta/gpu-unlock
cd gpu-unlock
make install-deb
Der Build lädt die NVIDIA-Files über HTTPS nach ~/.cache/gpu-unlock/inputs. Die Firmware landet unter /usr/lib/firmware/gpu-unlock/, das DKMS-Modul wird für den laufenden Kernel gebaut. Ohne Netzwerk im Gast schlägt der Schritt logischerweise fehl.
Bootparameter setzen
Das Modul bleibt inaktiv, solange der Kernel nicht ausdrücklich dazu auffordert. Die PCI-Adresse ermittelst du im Gast, nicht auf dem Host, denn dort kann sie abweichen:
root@ai:~ # lspci -D | grep -i nvidia
0000:01:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
0000:01:00.1 Audio device: NVIDIA Corporation GA102 High Definition Audio Controller (rev a1)
Die Adresse trägt man dann in die GRUB-Konfiguration ein:
sudo nano /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet gpu_unlock.targets=0000:01:00.0"
sudo update-grub
sudo update-initramfs -u
sudo reboot
Der Bericht aus Issue #9 hat genau diese Reihenfolge verwendet. Die Option gpu_unlock.targets=all geht auch, aber mit einer festen Adresse ist sauber nachvollziehbar, welche Karte entsperrt wurde.
Prüfen, ob der Unlock gegriffen hat
Nach dem Neustart zeigt das Kernel-Log, ob die Karte entsperrt wurde:
journalctl -k -b | grep gpu_unlock
Die Meldung unlocked für die Adresse sollte erscheinen. Ein Warnhinweis auf „module verification failed“ ist normal, weil das Modul nicht signiert ist. Im Gast mit deaktiviertem Secure Boot stört das nicht. Bei aktivem Secure Boot müsste man das Modul signieren, sonst lädt der Kernel es nicht. Wenn die Karte nach dem Unlock nicht mehr sauber initialisiert, hilft laut Projekt ein kompletter Kaltstart, weil der Firmware-Zustand der Karte erhalten bleiben kann.
Was sich in der Praxis ändert
Die Gewinne hängen stark vom Workload ab, das zeigen auch die Recherchen, die ich diesbezüglich im Internet gemacht habe. Bei llama.cpp mit quantisierten Modellen ist der Effekt überschaubar. Mit nur 4k-Kontext habe ich fast keine Veränderung beim Prompt-Durchsatz gemessen, bei 16k dagegen im Durchschnitt 15%. Die Token-Generierung blieb praktisch gleich, weil sie an der Speicherbandbreite hängt.
Bei ComfyUI sieht es anders aus. Ein Test mit SD 1.5 in FP16 und Z-Image in BF16 zeigte je nach Modell 38 bis 51 Prozent mehr Bilder pro Zeit, bei gleichzeitig etwa 40 Prozent weniger Energie pro Bild (mit zusätzlichem Undervolting). Bei INT8-Graphen bleibt der Unterschied aus.
Stolpersteine
Das Projekt ist experimentell für die Karten außerhalb der Ampere-Stable-Liste, und es gibt keinen Schutz gegen Fehler in der Firmware-Basis. Wer den Unlock produktiv einsetzt, sollte nach jedem Treiber-Update prüfen, ob journalctl -k -b | grep gpu_unlock noch die Entsperrung meldet.
Fazit
Unter Proxmox hat der Unlock bei mir funktioniert, wenn er im Gast installiert wird. Auch die Berichte im Internet zeigen ähnliche Gewinne auf Bare Metal. Am meisten profitiert man bei Bildgenerierung und Prompt-Verarbeitung mit FP16- oder BF16-Modellen. Für reine Token-Generierung mit quantisierten Modellen bringt der Eingriff leider nur wenig.