Wo immer möglich aus der eigenen Dokumentation des Projekts beantwortet. Wo die ehrliche Antwort „das hat noch niemand gemessen“ lautet, steht genau das da.
Gegen die READMEs von gpu-unlock und gpu-unlock-ada geprüft · 2026-10-25
Bei GeForce-Karten der RTX-30-Serie halbiert NVIDIA die Rate, mit der FP16/BF16-FMA-Befehle (Fused Multiply-Add) in FP32-Operationen ausgegeben werden können, im Vergleich zu professionellen Karten auf demselben Silizium. gpu-unlock schreibt die Hardware-Speed-Selektoren (SS0 0x88888888, SS1 0x8), bevor der Originaltreiber die Karte bindet, und stellt die volle Rate wieder her. Es übertaktet nichts, hebt keine Leistungslimits an und verändert nicht, was ein Befehl berechnet — in den Berichten, die Ausgaben verglichen haben, waren sie bitidentisch.
Kalibrierte Antwort: Der Mechanismus ist absichtlich konservativ — er läuft früh beim Booten, überspringt Karten, die bereits gebunden oder abgeschaltet sind, und nichts wird dauerhaft auf die Karte geschrieben; im Normalfall stellt das Entfernen des einen Kernel-Parameters und ein Neustart das Stock-Verhalten wieder her. Das Projekt ist dennoch experimentell und inoffiziell, und es führt bei jedem Boot eine Firmware-Sequenz und einen PCIe-Reset auf deiner Karte aus. Sein dokumentierter Fehlermodus: Wenn die Firmware einer Karte während der Sequenz nie stoppt, protokolliert das Modul das und behält die relevanten DMA-Puffer — du musst vollständig ausschalten, bevor du es erneut versuchst. Es gibt keine Garantien, und du solltest „Nutzerberichte bis hierhin“ entsprechend abwägen. Wenn dich dieses Risikoprofil stört, installiere es nicht.
Das Projekt selbst macht in keine Richtung Aussagen, und NVIDIA empfiehlt es nicht — behandle alle Auswirkungen auf Garantie oder Support als dein eigenes Risiko, wie bei jeder inoffiziellen Low-Level-Hardwareänderung. Was „Sperren“ angeht: Beim Ausführen von lokalem Compute auf deiner eigenen Karte ist kein Konto oder Dienst beteiligt, und nichts im Projekt interagiert mit Spielen oder Anti-Cheat-Systemen. Was wir nicht können, ist dir zu versprechen, wie ein Hersteller einen Garantieanspruch für eine Karte behandeln würde, die so betrieben wurde — das veröffentlicht niemand, also rät jeder, der dir eine Antwort garantiert.
Das Kernelmodul ist nur für Linux. Es gibt zwei verwandte Datenpunkte: Ein Nutzerbericht im Ampere-Projekt vermerkt, dass dieselbe Freischaltung aus einem UEFI-Port der Technik unter Windows funktioniert hat (für eine RTX 3070 Ti), und der Ada-Fork dokumentiert einen experimentellen Windows-UEFI-Referenzport für ein bestimmtes MSI-RTX-4070-Ti-Board (übereinstimmende cuBLAS-Zuwächse von etwa +80% FP16 / +76% BF16). Keiner von beiden ist ein unterstütztes, installierbares Windows-Release. Wenn du das heute unter Windows brauchst, gibt es keine offizielle Antwort.
Unbekannt — und das ist die vollständige Antwort. Es gibt keine verifizierten Gaming-FPS-Daten für gpu-unlock in der Dokumentation des Projekts oder den verlinkten Berichten. Die veröffentlichten Zuwächse liegen alle in Compute-Workloads (GEMM, LLM-Inferenz, Diffusionsmodelle). Spiele stützen sich auf eine Mischung aus Shader-, Textur- und Bandbreitenpfaden, auf die diese Freischaltung nicht zielt. Wer dir konkrete FPS-Verbesserungen ohne veröffentlichte Methodik nennt, spekuliert.
GeForce-Karten mit GA102-, GA103-, GA104- und GA106-Chips — der größte Teil der RTX-30-Serie. Getestet und gemeldet: RTX 3090 Ti, 3090, 3080 10 GB, 3070 und 3060 12 GB. Die RTX 3050 (GA107) ist nicht abgedeckt. Die OEM 3080 Ti 20 GB (GA102-250) ist eine bekannte Ausnahme, bei der BF16 bei halber Rate bleibt. Alle Details auf der Kompatibilitätsseite; Karten der RTX-40-Serie sind ein separater Fork.
Kommt darauf an, welche Hälfte des LLM. Prefill ist compute-gebunden, und Nutzerberichte beziffern es auf +14–36%. Decode ist durch die Speicherbandbreite begrenzt — die Freischaltung hebt eine Obergrenze an, die Decode nie erreicht, also blieb die Decode-Geschwindigkeit in den berichteten LLM-Tests, wo sie war. Das ist Physik, keine fehlgeschlagene Installation: Verifiziere mit journalctl -k -b | grep gpu_unlock, statt auf Tokens zu schauen.
Neustarts ja — das ist das dokumentierte Design: Das Modul lebt in der initramfs und wendet sich bei jedem Boot erneut an, solange der Parameter gpu_unlock.targets= vorhanden ist; später installierte Kernel übernehmen das Modul und ein neu gebautes Image über die eigenen Installations-Hooks des Kernels. Treiber-Updates sind genau der Schmerz, den dieses Projekt vermeidet: Weil der NVIDIA-Treiber selbst nie gepatcht wird, braucht ein neues Treiber-Release keinen neuen Patch — das Modul läuft einfach wie zuvor vor ihm. Suspend-to-RAM (Standby) wird behandelt (es schaltet beim Aufwachen erneut frei und fügt etwa eine Sekunde hinzu); der Ruhezustand (Hibernation) ist nicht abgedeckt.
Ja — benenne sie per PCI-Adresse: gpu_unlock.targets=0000:21:00.0 (Adressen, wie lspci -D sie ausgibt), oder liste mehrere durch Kommas getrennt. Berichte decken bis zu vier Karten in einer Maschine ab, die Anzeigekarte und Karten, die mit vfio-pci an eine VM durchgereicht werden.
Lösche gpu_unlock.targets= aus deiner Kernel-Kommandozeile und starte neu — das Modul tut dann nichts. Das Entfernen der Pakete entfernt auch das Modul und seine initramfs-Integration. Für einen einzelnen Stock-Boot bearbeite den Parameter im Bearbeitungsbildschirm deines Bootloaders heraus. Siehe den Rollback-Abschnitt der Installationsanleitung.
Nichts — es ist Open Source. Das Kernelmodul und die Paketierung stehen unter GPL-2.0-only; die generierte Payload leitet sich von einer festgelegten CMP-Referenz ab, und die NVIDIA-Firmware bleibt unter NVIDIAs eigenen Bedingungen. Die Projektseite akzeptiert freiwillige Unterstützung, wenn du etwas zur GPU-Gewohnheit des Autors beisteuern willst.
Nein. GPU Unlocker ist eine unabhängige Anleitung, die das Projekt, seine Zahlen und seine Risiken dokumentiert. Der Code und die maßgebliche Dokumentation leben unter github.com/Zagitta/gpu-unlock (Ampere) und github.com/JustAResearcher/gpu-unlock-ada (Ada-Fork). Wenn diese Website und eine README je widersprechen, hat die README recht — und wir würden gern davon hören.
Höchstwahrscheinlich das Timing, nicht die Karte. Das Modul handelt nur in der initramfs, bevor der NVIDIA-Treiber die Karte bindet; eine Karte, die in diesem Moment bereits gebunden oder abgeschaltet ist, wird übersprungen, und das Modul nach dem Boot von Hand zu laden bewirkt bei einer gebundenen Karte nichts. Prüfe das Boot-Log mit journalctl -k -b | grep gpu_unlock, bestätige, dass gpu_unlock.targets= wirklich auf deiner Kernel-Kommandozeile ist (cat /proc/cmdline), und stelle sicher, dass deine Karte ein GA102-, GA103-, GA104- oder GA106-Modell ist — alles andere wird protokolliert und ignoriert.
Schalte vollständig aus, bevor du es erneut versuchst. Diese Meldung ist der dokumentierte Fehlermodus des Projekts: Wenn die Firmware einer Karte während der Sequenz nie stoppt, protokolliert das Modul das und behält absichtlich die DMA-Puffer, die diese Firmware möglicherweise noch nutzt, bis zum nächsten Ausschalten. Pfusche nicht weiter daran herum — ein vollständiges Ausschalten ist die dokumentierte Wiederherstellung, und der Rollback-Abschnitt der Installationsanleitung behandelt denselben Boden.
Du hast höchstwahrscheinlich die OEM RTX 3080 Ti 20 GB auf Basis des GA102-250-Chips — die eine dokumentierte Ausnahme in der Liste getesteter Karten des Projekts. Bei dieser Karte läuft die Entsperrung durch, aber der BF16-Durchsatz bleibt bei halber Rate. Die Retail-3080-Ti mit 12 GB ist ein anderer Fall (Chip abgedeckt, noch kein Bericht). Alle Details auf der Kompatibilitätsseite.