Bis zu doppelte Tensor-Rechenleistung auf einer RTX 4090: Berichten zufolge kann die Freischaltung bestimmter KI-Berechnungen auf Nvidia-Grafikkarten einen erheblichen Leistungsgewinn bringen. Der Weg dorthin führt allerdings über eine Schwachstelle. Die beschriebenen Modifikationen sollen einen Stack-Pufferüberlauf in Nvidias signierter SEC2-„Booter“-Firmware nutzen, um eine von Nvidia gesetzte Rechengrenze zu umgehen.
Die genannten Unlock-Projekte richten sich an Karten der RTX-20-, RTX-30- und RTX-40-Serien. Für Nutzer solcher GPUs ist das zunächst eine zusätzliche Nutzungsmöglichkeit vorhandener Hardware. Wer die Freischaltung einsetzen will, muss aber zwei Fragen getrennt beantworten: Beschleunigt sie den eigenen Workload überhaupt? Und lässt sich der Eingriff in einen sicherheitsrelevanten Teil der GPU-Software im eigenen Betrieb verantworten?
Welche Rechenleistung freigeschaltet wird
Die Begrenzung betrifft bestimmte Berechnungen auf den Tensor-Kernen. Bei FP16- und BF16-Operationen können Zwischenresultate mit FP32-Genauigkeit akkumuliert werden. Vereinfacht gesagt: Die Multiplikation arbeitet mit geringerer Genauigkeit, während die Ergebnisse mit höherer Genauigkeit aufsummiert werden. Diese Kombination ist für zahlreiche KI-Berechnungen relevant.
Auf den betroffenen GeForce-Karten war die FP32-Akkumulationsleistung auf die Hälfte der FP16-Akkumulationsrate begrenzt. Die Freischaltung setzt an dieser Einschränkung an. Sie verdoppelt weder pauschal die Geschwindigkeit der Grafikkarte noch deren Speicherbandbreite. Auch der verfügbare Grafikspeicher wächst dadurch nicht.
In den Berichten und Projektangaben werden für die RTX 4090 im betroffenen FP16-/BF16-Tensor-Rechenpfad Spitzenwerte von 165,6 auf 331,6 TFLOPS genannt. Bei der RTX 3090 Ti soll die gemessene BF16-Matrixmultiplikationsleistung von 87,5 auf 157,4 TFLOPS steigen, also um rund 80 Prozent. Das sind erhebliche Unterschiede, aber zunächst Kennzahlen bestimmter Rechenoperationen. Eine entsprechend kürzere Laufzeit einer vollständigen Anwendung ist damit nicht belegt.
Die Signatur verhindert keinen Speicherfehler
Der sicherheitsrelevante Befund liegt im Einstiegspunkt: Der Exploit soll einen Stack-Pufferüberlauf in signierter GPU-Firmware nutzen. Eine digitale Signatur kann die Herkunft und Unverändertheit eines Firmware-Abbilds absichern. Sie garantiert nicht, dass dessen Code frei von Fehlern bei der Speicherverarbeitung ist.
Wo die Freischaltung ansetzt
Laut den Berichten nutzt der Exploit einen Speicherfehler innerhalb signierter SEC2-Firmware, um die Begrenzung bestimmter Tensor-Berechnungen zu umgehen. Eine Signatur schließt Programmierfehler nicht aus.
Genau diese Unterscheidung ist hier entscheidend. Die Freischaltung beruht nach der vorliegenden Beschreibung auf der Ausnutzung eines Fehlers innerhalb einer vertrauenswürdigen Komponente. Dass die Firmware signiert ist, verhindert diesen Weg nicht.
Die beschriebenen Projekte nutzen die Schwachstelle, um die Leistungsbeschränkung zu umgehen. Daraus lässt sich jedoch nicht automatisch ableiten, dass Angreifer beliebige Rechner aus der Ferne übernehmen können. Für eine solche Bewertung müssten unter anderem Zugriffsweg, erforderliche Rechte und erreichbare Funktionen bekannt sein. Ebenso wenig belegt die Freischaltung einen laufenden Missbrauch gegen Nutzer.
Der nachgewiesene Eingriff bleibt dennoch relevant: Eine vorgesehene Einschränkung lässt sich über einen Firmware-Fehler verändern. Welche weiteren Sicherheitsfolgen dieselbe Schwachstelle haben könnte, muss gesondert untersucht werden. Leistungsgewinn und vollständige Sicherheitsbewertung sind unterschiedliche Ergebnisse.
Zusätzlicher Code im GPU-Softwarestack
Für Ampere-Karten existiert das Projekt „gpu-unlock“, für Ada Lovelace „gpu-unlock-ada“ und für Turing „turing-unlock“. Zu den genannten Modellen gehören etwa die RTX 3090 Ti, RTX 4090 und RTX 2080 Ti. Die Projekte bieten entsprechende Linux-Module an. Daraus folgt keine pauschale Zusage, dass jede Karte mit jeder Treiber- und Systemkonfiguration funktioniert.
Wer solche Module einsetzt, nimmt zusätzlichen Code in einen ohnehin komplexen Softwarestack auf. Vor einem Test sollten deshalb Herkunft und Quellcode, benötigte Berechtigungen sowie die dokumentierte Kompatibilität geprüft werden. Ein Leistungsdiagramm ersetzt diese Prüfung nicht. Auch die Frage, wie sich die Änderung wieder entfernen lässt, gehört vor die Installation.
Für einen isolierten Versuchsrechner kann ein solcher Test vertretbar sein. Auf einem gemeinsam genutzten KI-Server oder einem produktiven Arbeitsplatz gelten andere Anforderungen. Dort sollten weder vertrauliche Daten noch laufende Aufträge als Testmaterial dienen. Ein separater Testaufbau, gesicherte Konfigurationen und ein nachvollziehbarer Rückweg reduzieren die betrieblichen Folgen möglicher Fehler.
Treiber- und Firmware-Updates müssen anschließend erneut geprüft werden, weil die Freischaltung von konkreten Implementierungsdetails abhängt. Die hier beschriebenen Informationen belegen keinen aktuellen Patch-Status für sämtliche betroffenen Modelle. Eine belastbare Empfehlung sollte deshalb weder von dauerhafter Funktionsfähigkeit noch von bereits geschlossenen Lücken ausgehen.
Der eigene Workload entscheidet über den Nutzen
Besonders wichtig ist eine Messung der tatsächlichen Anwendung. Bei der Token-Generierung eines Chatbots kann die Speicherbandbreite den Durchsatz begrenzen. Mehr verfügbare Tensor-Rechenleistung beseitigt diesen Engpass nicht. Die realen Verbesserungen fallen dort geringer aus als die genannten Spitzenwerte.
Rechenintensive Abschnitte wie die Verarbeitung umfangreicher Prompts oder bestimmte Bildgenerierungsaufgaben können stärker profitieren. Wie groß der Gewinn ist, hängt jedoch von Modell, Datentypen und verwendeten Rechenkernen der Software ab. Sinnvoll ist deshalb ein Vergleich identischer Aufgaben mit unveränderter Modellkonfiguration, einschließlich Laufzeit, Ergebnisqualität und Stabilität.
Die praktische Entscheidung fällt damit enger aus, als es die Verdopplung eines Spitzenwerts vermuten lässt. Der Exploit erschließt zusätzliche Rechenleistung für bestimmte Operationen. Ob sich dafür ein nicht regulär vorgesehener Eingriff in den GPU-Softwarestack lohnt, muss am konkreten System geprüft werden. Für produktive Rechner bleibt eine offiziell unterstützte Umsetzung die besser kontrollierbare Option.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
