↓ Skip to main content
RTX 3080 20GB: ReBAR und P2P ohne vBIOS-Flash freischalten

RTX 3080 20GB: ReBAR und P2P ohne vBIOS-Flash freischalten

·2697 words·13 mins
AI / Homelab Lokales LLM Betreiben KI AI / Homelab
Table of Contents

Eine modifizierte RTX 3080 mit 20 GB VRAM ist für ein lokales LLM verlockend günstig. Ab Werk liefert sie aber nicht ihr volles Potenzial: Ihr PCIe-Speicherfenster (BAR1) hängt bei 256 MiB fest, und zwei dieser Karten dürfen einander nicht direkt beschreiben. Beides trifft genau die Szenarien, für die man solche Karten kauft: Tensor-Parallel-Inferenz, bei der sich zwei GPUs ein Modell teilen und bei jedem Schritt Daten austauschen müssen.

Dieser Artikel zeigt, wie du beide Bremsen löst, ohne ein vBIOS zu flashen. Die erste Stufe weitet das Speicherfenster per Konfigurationsschreibzugriff von 256 MiB auf 32 GiB. Die zweite Stufe aktiviert GPU-zu-GPU-Peer-to-Peer (P2P) über gepatchte offene NVIDIA-Kernelmodule. Dazu die Befehle, Prüfschritte, Rückbauwege und die ehrlichen Messwerte: was tatsächlich schneller wird und was nicht.

Kurzantwort
#

Anleitung: 32-GiB-ReBAR und GPU-P2P auf modifizierten RTX 3080 20GB ohne vBIOS-Flash freischalten. Mit Befehlen, Tests und gemessenen Werten.

Die Aufgabe
#

Konkret geht es um diesen Arbeitsauftrag: Auf einem Linux-Rechner mit zwei modifizierten RTX 3080 20GB (Geräte-ID 10de:2206) soll erstens BAR1 von 256 MiB auf 32 GiB wachsen, zweitens P2P zwischen den Karten funktionieren, damit vLLM im Tensor-Parallel-Modus nicht mehr jede GPU-zu-GPU-Kopie über den Hauptspeicher schicken muss. Wer nur eine einzelne Karte betreibt und keine Tensor-Parallel-Inferenz fährt, braucht die zweite Stufe nicht; dazu unten mehr.

Die beiden Bausteine stammen aus zwei zusammenhängenden Projekten: 3080-20gb-rebar für das Speicherfenster 1 und 3080-20g-p2p für die Peer-to-Peer-Kopien 2 . Beide sind frei (MIT beziehungsweise NVIDIAs duale MIT/GPLv2-Lizenz) und setzen auf NVIDIAs offene Kernelmodule auf 3 .

Warum die Karte ausgebremst ist
#

Die CPU erreicht den Grafikspeicher über ein PCIe-Speicherfenster namens BAR1. Ist dieses Fenster klein, ist immer nur ein kleiner Ausschnitt der 20 GB gleichzeitig sichtbar, und größere host-sichtbare Zuweisungen schlagen fehl. Eine unveränderte RTX 3080 20GB bekommt ein 256-MiB-Fenster 1 .

Bei unmodifizierten Karten hat NVIDIA das Problem gelöst: Seit dem 30. März 2021 unterstützt die GeForce-RTX-30-Serie Resizable BAR; für RTX 3080 und Co. braucht es dafür ein VBIOS-Update, ein passendes Mainboard-SBIOS und einen aktuellen Treiber 5 . Für die speichermodifizierten 20-GB-Boards veröffentlicht NVIDIA aber kein passendes ReBAR-vBIOS. Der klassische Weg wäre ein vBIOS-Flash: riskant und ohne offizielles Image kaum sauber machbar.

Das zweite Problem ist P2P. Consumer-Karten melden dem Treiber normalerweise keine Peer-Zugriffe, also kopieren CUDA, NCCL und vLLM jede GPU-zu-GPU-Übertragung über den Hauptspeicher der CPU: Daten wandern von GPU A in den RAM und von dort auf GPU B. Im Tensor-Parallel-Modus passiert das bei jedem Schritt.

Konkret läuft Tensor-Parallel 2 so: Jede GPU hält die Hälfte der Gewichte eines Modells. Nach dem Attention- und nach dem MLP-Block jedes Layers führen die beiden Karten ihre Teilergebnisse per All-Reduce zusammen, damit beide mit dem vollständigen Zwischenergebnis weiterrechnen können. Ohne P2P läuft dieses All-Reduce durch den Hauptspeicher und über die CPU, bei jedem Layer und bei jedem Token. Beim Prefill, wo ein langer Prompt in wenigen großen Durchläufen verarbeitet wird, dominiert diese Kommunikation einen spürbaren Teil der Zeit. Genau diese Umwege machen die Prompt-Verarbeitung und die Kommunikation zwischen den Karten langsamer als nötig 2 .

lokales LLM betreiben – Illustration 2

Was die beiden Projekte ändern
#

Das ReBAR-Projekt arbeitet ohne Flash. Der GA102-Chip hat in seinem PCI-Konfigurationsraum an Adresse 0x610 ein Register zur Überschreibung der Framebuffer-Größe. Schreibt man dort 00001c81 hinein, meldet die Karte ein 32-GiB-Fenster an; das Resizable-BAR-Register (0xbbc) wechselt von 00001c00 auf 000ffc00. Das ist ein Konfigurationsschreibzugriff, kein Flash — bei Stromausfall oder Neustart ist die Änderung weg, und ein systemd-Dienst stellt sie bei jedem Boot wieder her 1 .

Der zweite Schritt ist nötig, weil der Treiber bei einem großen BAR standardmäßig auf „static BAR1" umschaltet und dabei den host-sichtbaren Speicher doppelt anrechnet. Mit der Treiberoption RMForceStaticBar1=0 kehrt die Karte zur On-Demand-Zuordnung zurück; statt etwa 10,2 GiB werden rund 20,0 GiB (etwa 98 Prozent) der 20 GB host-sichtbar 1 .

Das P2P-Projekt patcht NVIDIAs offene Kernelmodule der Version 615.71.09 so, dass zwei dieser Karten direkt in den Speicher der jeweils anderen schreiben. Die Patch-Reihe baut auf früheren Consumer-P2P-Patches auf: Der Ursprung liegt im tinygrad-Umfeld, darauf setzen Ports von aikitoria und Duanyll sowie die 20-GB-Fixes von dingiv auf 2 , 4 . Die gemessenen Werte auf dem Testsystem (X99-Board, Xeon E5-2696 v4, zwei Karten an getrennten Root-Ports):

  • P2P-Kopierbandbreite unidirektional: 10,27 GB/s statt 5,78 GB/s ohne P2P 2 .
  • Bidirektional: 19,33 GB/s statt 8,66 GB/s 2 .
  • Schreiblatenz über P2P: 0,99 µs statt 13,6 µs 2 .
  • NCCL-all_gather beziehungsweise reduce_scatter (1 GiB): 8,84/8,56 GB/s statt 6,06/5,96 GB/s 2 .

Wichtig ist die Einordnung: Diese Rohwerte sind Kopier- und Kommunikationswerte, kein End-to-End-Durchsatz. Wie viel davon beim Inferenzbetrieb ankommt, steht im Abschnitt „Nachmessen".

Schritt 1: 32-GiB-ReBAR ohne Flash
#

Voraussetzungen: Root-Rechte, pciutils (setpci, lspci), systemd, ein Kernel, der /sys/bus/pci/devices/<BDF>/resource1_resize bereitstellt, Above-4G-Decoding und genug 64-Bit-MMIO-Adressraum für 32 GiB pro Karte. Der NVIDIA-Treiber muss aus dem Root-Dateisystem laden, nicht aus der initramfs 1 .

Die Kurzfassung:

lspci -Dnn -d 10de::0300                          # eigene GPU-Adresse ermitteln, z. B. 0000:01:00.0
sudo scripts/rebar-check.sh --vram 20G            # read-only Vorprüfung der Voraussetzungen
sudo ./install.sh --bdfs "0000:01:00.0" --enable  # Dienst, Skript und Treiberoption schreiben
sudo reboot

Bei zwei Karten stehen die Adressen durch Leerzeichen getrennt in einem Anführungszeichenpaar:

sudo ./install.sh --bdfs "0000:01:00.0 0000:02:00.0" --enable

Die Karte, die das Display treibt, lässt install.sh standardmäßig aus, solange du nicht --include-console übergibst 1 .

Prüfen nach dem Neustart:

journalctl -b -u rebar-arm                          # <BDF> armed and resized to 32768 MiB
sudo setpci -s 0000:01:00.0 0x610.L 0xbbc.L        # 00001c81, 000ffc00
lspci -vv -s 0000:01:00.0 | grep "Region 1"        # [size=32G]
nvidia-smi -q -d MEMORY | grep -A1 BAR1            # Total 32768 MiB

Der Installer schreibt zusätzlich die Treiberoption, die den vollen VRAM durch BAR1 erreichbar macht, nach /etc/modprobe.d/zz-nvidia-static-bar1.conf 1 :

options nvidia NVreg_RegistryDwordsPerDevice="pci=0000:01:00.0;RMForceStaticBar1=0;pci=0000:02:00.0;RMForceStaticBar1=0;"

Regel: Alle Karten stehen in genau dieser einen Zeile, und die globale Option NVreg_RegistryDwords wird nicht zusätzlich gesetzt 1 . Ohne diese Option bleibt bei einem großen BAR nur etwa die Hälfte des VRAM host-sichtbar — wer host-sichtbare Zuweisungen bei halbem VRAM scheitern sieht, prüft zuerst diese Datei.

Schritt 2: P2P über gepatchte Kernelmodule
#

Das P2P-Projekt setzt auf Schritt 1 auf: Erst das 32-GiB-BAR1 mit RMForceStaticBar1=0, dann die gepatchten Module. Zusätzlich braucht es die NVIDIA-Userspace-Bibliotheken exakt in Version 615.71.09, Kernel-Header, make und den Compiler, mit dem der Kernel gebaut wurde, IOMMU aus oder im Passthrough-Modus (iommu=pt) sowie Secure Boot aus beziehungsweise mit einem Schlüssel signierte Module, dem die Maschine vertraut 2 .

Bauen und per Hand laden (nichts wird installiert, ein Neustart lädt wieder das, was modprobe auflöst):

git clone https://github.com/noon-at-cgn/3080-20g-p2p && cd 3080-20g-p2p
make modules -j"$(nproc)"
(cd kernel-open && sha256sum nvidia*.ko > SHA256SUMS)   # die Pins, die die Skripte prüfen
sudo contrib/3080-20g/p2p-load.sh --yes        # gepatchte Module laden
sudo contrib/3080-20g/p2p-check.sh             # read-only, Exit-Status = Anzahl FAIL-Zeilen

In contrib/3080-20g/config.sh müssen vorher OUT (der Pfad zum kernel-open-Verzeichnis des Builds) und GPUS (die Kartenadressen, durch Leerzeichen getrennt) gesetzt sein; jedes .ko, das nicht zu SHA256SUMS passt, verweigern die Skripte 2 .

Vor dem Laden muss jede Anwendung, die die GPUs nutzt, beendet sein. Die Moduloptionen lauten 2 :

nvidia      NVreg_RegistryDwordsPerDevice="pci=0000:01:00.0;RMForceStaticBar1=0;pci=0000:02:00.0;RMForceStaticBar1=0;" NVreg_EnableResizableBar=0
nvidia_uvm  uvm_disable_hmm=1

Für eine Boot-Installation (nur für den laufenden Kernel, geprüft):

sudo contrib/3080-20g/p2p-install.sh --yes
sudo reboot
sudo contrib/3080-20g/p2p-check.sh

Der Installer legt die Module nach /lib/modules/<kernel>/updates/p2p/ ab, schreibt einen depmod-Override und ein Modprobe-Pendant, und sichert die Originalmodule nach /var/backups/p2p-modules/. Die Stock-Module bleiben erhalten; andere Kernel starten unverändert 2 .

Für NCCL und vLLM gilt: Bei Karten an getrennten Root-Ports NCCL_P2P_LEVEL=PHB (oder SYS) setzen, damit das Log via P2P statt via SHM zeigt. vLLMs Custom-All-Reduce benötigt P2P; VLLM_SKIP_P2P_CHECK steht standardmäßig auf 1, vLLM folgt also cudaDeviceCanAccessPeer 2 .

Ob P2P tatsächlich aktiv ist, siehst du auf drei Wegen: cudaDeviceCanAccessPeer muss für das Kartenpaar 1 liefern, das NCCL-Log muss via P2P (statt via SHM) zeigen, und der CUDA-Test p2pBandwidthLatencyTest misst die direkte Kopierbandbreite zwischen den Karten 2 . Eine verweigerte Karte bekommt schlicht keinen Peer-Zugriff und hinterlässt im Kernel-Log rate-limitierte DynBar1P2P:-Zeilen, die Karte und Grund nennen; dort steht, welche Voraussetzung nicht erfüllt ist 2 .

Wer P2P gezielt wieder abschalten will, ergänzt in derselben Modulzeile hinter jeder Karte RMDynBar1P2PEnable=0 (im Boot-Install über die Zeile in modprobe.d, im Handbetrieb über P2P_ENABLE=0 in config.sh) 2 . Achtung: Ein erneutes Installieren des ReBAR-Schritts schreibt zz-nvidia-static-bar1.conf ohne diesen Opt-out neu; danach muss er wieder ergänzt werden 2 .

Nachmessen: was wirklich schneller wird
#

Im dokumentierten Benchmark (vLLM 0.31, Tensor-Parallel 2, Modell Qwen3.8-27B-W4A16, Prompts mit 8k/32k/128k Token) sinkt die Zeit bis zum ersten Token (TTFT) durch P2P um 6 bis 9 Prozent, und die Prefill-Rate steigt um 6 bis 10 Prozent, bei jeder getesteten Länge. Die Dekodierrate profitiert stärker: Mit NCCL-P2P plus Custom-All-Reduce liegen die Zuwächse bei +12, +31 und +8 Prozent für 8k/32k/128k. Bei zwei parallelen Anfragen beträgt der aggregierte Dekodierzuwachs 5 bis 7 Prozent 2 .

Die Zahl „+70 % Prompt-Verarbeitung", die häufig neben diesem Thema steht, taucht in den Projekten selbst nicht auf. Die reproduzierbaren Messwerte liegen niedriger und trennen sauber: Der große Sprung steckt in der rohen Kopierbandbreite (rund 1,78-fach) und der Schreiblatenz (0,99 statt 13,6 µs) 2 . Beides übersetzt sich nicht eins zu eins in End-to-End-Durchsatz, weil Prefill auch rechengebunden ist und das All-Reduce nur ein Teil der Verarbeitungskette ist. Eine Sache fällt bei kleinen Nachrichten sogar leicht zurück: Die NCCL-all_reduce-Latenz für 8 Byte bis 32 KiB liegt mit P2P bei 15 bis 17 µs statt 13 bis 15 µs 2 . P2P hilft bei bandbreiten-gebundenen, großen Übertragungen — nicht bei winzigen, latenzgebundenen.

Das ReBAR-Fenster allein beschleunigt die reine Dekodierung kaum: Auf dem Testsystem waren es etwa 78 Token/s im Ausgangszustand und rund 80 Token/s bei 32 GiB, kein messbarer Unterschied 1 . Der Nutzen des Fensters liegt woanders: Es macht mehr VRAM host-sichtbar und ist die Voraussetzung dafür, dass P2P überhaupt greift.

Risiken und Grenzen
#

Beide Projekte sind als experimentell gekennzeichnet. Das P2P-Modul ist ein gepatchter Kernel-Treiber und kann „die Maschine hängen lassen oder Speicher korrumpieren", so die eigene Warnung 2 . Das ReBAR-Projekt warnt vor Hardwarefehlern, Instabilität oder Garantieverlust und nennt explizit eine Maschine, bei der ein Hängenbleiben von GPU oder Host akzeptabel ist 1 .

Getestet wurde eng: zwei modifizierte RTX 3080 20GB mit vBIOS 94.02.27.00.14, NVIDIA-Treiber 615.71.09, Linux 7.x, ein X99-Board mit Xeon E5-2696 v4, jede Karte an einem eigenen Root-Port ohne PCIe-Switch 1 , 2 . Andere GA102-Karten (RTX 3080, 3080 Ti, 3090) durchlaufen denselben Codepfad, sind aber ungetestet. Mehr als zwei GPUs, gemischte Kartenpaare, andere Treiber- oder Kernelversionen und Windows sind ebenfalls ungetestet 2 .

Die Korrektheit wurde auf dem Testsystem breit geprüft: 29 von 29 byte-genaue Fälle (64 KiB bis 1 GiB), ein 51-minütiger Dauerlauf mit vLLM und 3365 byte-genauen Läufen sowie 20 kill -9 während laufender Peer-Kopien, ohne Fehler und ohne Kernel-Fehler 2 . Diese Zahlen gelten für genau diese Plattform, nicht für jede beliebige.

Rückbau ist vorgesehen. Das ReBAR-Projekt liefert uninstall.sh; nach einem Neustart liegt BAR1 wieder bei 256 MiB. Für P2P gibt es einen Ein-Befehl-Fallback: sudo contrib/3080-20g/p2p-fallback.sh --yes und Neustart, oder --live, um den laufenden Treiber sofort zurückzutauschen 1 , 2 . Kommt das P2P-System nicht mehr hoch, startet man einen anderen Kernel und führt den Fallback mit KVER=<P2P-Kernel> aus 2 .

Ein Hinweis für Proxmox-Nutzer: Das P2P-Projekt wurde auf einem Linux-Kernel 7.0.14 unter Proxmox getestet 2 . Entscheidend sind nicht die Virtualisierungsfunktionen, sondern drei Dinge, die auf jedem Linux gelten: der NVIDIA-Treiber muss aus dem Root-Dateisystem laden (nicht aus der initramfs), IOMMU muss aus oder im Passthrough-Modus (iommu=pt) sein, und Secure Boot muss aus sein beziehungsweise die Module müssen signiert sein 2 . Getestet ist der direkte Betrieb dort, wo der NVIDIA-Treiber die Karten bindet; eine Weitergabe der Karten an eine VM ist im Projekt nicht getestet 2 .

Fehlerbehebung
#

Die häufigsten Fehlerbilder und ihre Ursache, direkt aus den beiden Projekten 1 , 2 :

  • echo ... > resource1_resize schlägt mit EINVAL fehl. Du schreibst Bytes statt des Größenindex. Für 32 GiB ist der Wert 15, nicht 32768 1 .
  • 0xbbc wechselt nach dem Armieren nicht auf 000ffc00. scripts/rebar-check.sh laufen lassen; ist Bit 11 in 0x60c gesetzt und es weitet trotzdem nicht, unterstützt die Karte es womöglich nicht 1 .
  • Das Journal meldet already bound to nvidia, skip, BAR1 bleibt bei 256 MiB. Der Treiber hat zuerst gebunden; die Unit aktivieren und den NVIDIA-Treiber aus der initramfs heraushalten 1 .
  • Unbind hängt oder der Bildschirm wird schwarz. Das ist die Display-Karte; zuerst die Konsole lösen, wie es die manuelle Prozedur im Projekt beschreibt 1 .
  • Host-sichtbare Zuweisungen scheitern bei etwa der Hälfte des VRAM. Die Treiberoption fehlt: prüfen, dass /etc/modprobe.d/zz-nvidia-static-bar1.conf die Karte listet, dann neu starten 1 .
  • CPU-Schreiben durch BAR1 fällt auf 5 oder 2,4 GB/s ab. Die unbelastete GPU senkt ihre PCIe-Linkgeschwindigkeit; mit Persistence-Mode (nvidia-smi -pm 1) und gesperrtem Speichertakt (nvidia-smi -i <BDF> -lmc <max>,<max>) gegensteuern 1 .
  • Ein Prozess stirbt beim Freigeben eines Puffers, in den noch eine Peer-Kopie läuft. Das ist Xid 31 und verhält sich wie beim Stock-Treiber 2 .
  • nvidia-smi zeigt BAR1 Used wachsend. Peer-Zugriffe mappen die Zuweisungen der Gegenseite; ist BAR1 voll, schlagen neue Peer-Mappings fehl 2 .

Entscheidungshilfe: lohnt sich das für dich?
#

Die Antwort hängt von deiner Konstellation ab, nicht vom Preis der Karte.

Du betreibst zwei modifizierte RTX 3080 20GB an getrennten Root-Ports, läufst vLLM im Tensor-Parallel-Modus und siehst, dass der Prefill oder die Kommunikation dein Flaschenhals ist? Dann sind die zwei Schritte der direkte Weg, 6 bis 10 Prozent Prefill und bis zu 31 Prozent Dekodierrate mitzunehmen, ohne ein vBIOS zu riskieren 1 , 2 . Die Voraussetzungen (Linux 7.x, Treiber 615.71.09, Secure Boot aus, IOMMU-Passthrough) musst du erfüllen können.

Du hast nur eine Karte und keine Tensor-Parallel-Inferenz? Dann bringt dir P2P nichts, und das ReBAR-Fenster ändert deine Dekodierrate nicht messbar 1 . Der Aufwand lohnt nicht.

Du willst vor allem viel VRAM ohne Mod und ohne zweite Karte? Dann ist eine Karte mit 24 GB ab Werk die einfachere Wahl: unmodifizierte Karten mit NVIDIAs eigenem ReBAR-vBIOS brauchen diesen Unlock nicht 1 , 5 .

Und wenn dir ein möglicher Systemhänger bei einem experimentellen Kernel-Treiber zu riskant ist: Beide Projekte sind rückbaubar, aber sie bleiben experimentell. Wer produktive Dienste auf der Maschine laufen lässt, testet zuerst auf einem getrennten System.

lokales LLM betreiben – Illustration 3

Weiterführende Artikel
#

Passende Produktrecherchen
#

Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.

Transparenzhinweis
#

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Quellen
#

[1] 3080-20gb-rebar: 32 GiB BAR1 ohne vBIOS-Flash

[2] 3080-20g-p2p: GPU-P2P für modifizierte RTX 3080 20GB

[3] NVIDIA open-gpu-kernel-modules

[4] tinygrad/open-gpu-kernel-modules: ursprünglicher Consumer-P2P-Patch

[5] NVIDIA: Resizable-BAR-Unterstützung für GeForce RTX 30

Related