RTX 20, 30 e 40: i modder liberano la potenza IA nascosta

I progetti gpu-unlock, gpu-unlock-ada e Turing-unlock intervengono su una limitazione del throughput di alcune istruzioni Tensor sulle GeForce. I casi meglio documentati riguardano i calcoli FP16 o BF16 con accumulo in FP32, oltre al TF32 sulle architetture compatibili. L'accumulo indica la precisione usata per sommare i risultati intermedi: due calcoli che usano dati FP16 non seguono quindi necessariamente lo stesso percorso hardware.

Lo sblocco avviene prima del caricamento del driver NVIDIA e modifica impostazioni interne della GPU. Non aggiunge core né memoria video e non richiede di effettuare il flash del VBIOS. Il suo effetto è volatile: l'interruzione dell'alimentazione della GPU può annullarlo. I progetti riprendono lavori svolti sulle schede da mining CMP, adattati in particolare da Zagitta e, per Ada, a partire dal lavoro di TOTORONG.

I risultati riportati di seguito provengono dagli sviluppatori e dai loro collaboratori. Hardware Reference ha confrontato le pubblicazioni e i protocolli; non abbiamo riprodotto queste prove sul nostro banco di test.

Il repository gpu-unlock di Zagitta raccoglie le seguenti misurazioni di moltiplicazione di matrici dense con accumulo FP32. I valori sono arrotondati nella sintesi; le percentuali sono quelle dichiarate dal progetto a partire dalle misurazioni originali.

Questi risultati usano configurazioni diverse: illustrano il guadagno prima/dopo su ciascuna scheda e non costituiscono una classifica ottenuta con un protocollo comune. I TFLOPS esprimono qui il throughput di calcolo, non i fotogrammi al secondo in un gioco.

Il confronto abbinato prima/dopo di gpu-unlock-ada è particolarmente istruttivo. La stessa RTX 4090 è stata confrontata prima e dopo l'attivazione, con il driver NVIDIA 615.78.08, CUDA 13.4.92 e un limite di 450 W. Il throughput delle istruzioni passa da 160,4 a 320,4 TFLOPS in FP16/FP32 e da 159,7 a 320,2 TFLOPS in BF16/FP32.

Ingrandisci

Le moltiplicazioni di matrici cuBLAS nello stesso confronto mostrano differenze più modeste. Tutte usano accumulo FP32; N indica la dimensione di matrici quadrate N × N. I valori sono le mediane pubblicate e le differenze riportate di seguito sono calcolate a partire da questi valori.

Il caso BF16 a 4 096³ resta quindi praticamente invariato. Il rapporto riguarda una sola coppia di misurazioni, con il desktop attivo, e non costituisce una verifica di stabilità prolungata. Anche FP16 con accumulo FP16 e i test di controllo INT8 restano vicini al livello iniziale.

Il repository Turing-unlock documenta una prova su una ASUS RTX 2080 Ti da 11 GiB, eseguita il 22 ottobre. Il throughput delle istruzioni FP16 con accumulo FP32 passa da 46,9361 a 93,6649 TFLOPS, quasi raddoppiando. Nella moltiplicazione cuBLAS a 8 192³, il valore sale da 48,1488 a 85,1705 TFLOPS, circa il 77% in più. FP16 con accumulo FP16 resta invariato.

Questa dimostrazione riguarda una scheda e una piattaforma identificate con precisione. Il suo loader sperimentale non è un programma di installazione universale. Mostra inoltre che sbloccare il calcolo non richiede di aumentare la capacità di memoria: gli 11 GiB della scheda sono rimasti 11 GiB.

Il test di Cryptolab offre un utile contrappunto. Confronta 18 richieste in totale con Qwen3.8 27B Q4_K_M e MTP in Ollama 0.33.2, su una RTX 3090 da 24 GiB limitata a 350 W. Ogni profilo comprende tre prove per stato, con un output di 256 token. I valori di throughput riportati di seguito sono mediane, in token al secondo.

Attenzione all'interpretazione: le frequenze non erano bloccate e le condizioni termiche differivano tra le serie di test. In particolare, la frequenza SM mediana rilevata passa da 1 470 a 1 545 MHz. Queste differenze descrivono le prestazioni osservate senza isolare l'effetto del solo sblocco. Le risposte abbinate hanno comunque le stesse impronte SHA-256.

I carichi di diffusione possono beneficiare maggiormente dei calcoli interessati. Un collaboratore di nv-uefi-unlocker riporta i primi due risultati qui sotto su una RTX 3080 LHR con Windows, con tre prove per stato. Un altro rapporto su RTX 4090 misura LTX-2.5 in ComfyUI. Ogni riga confronta lo stesso lavoro prima e dopo lo sblocco; macchine e modelli differiscono tra le righe.

La percentuale indica l'aumento del throughput a parità di lavoro, calcolato come durata prima / durata dopo − 1. Un aumento del throughput del 28,8% corrisponde quindi a circa il 22,3% di tempo in meno. Sulla RTX 4090 il beneficio cambia con il limite di potenza; il solo sblocco non elimina questo vincolo.

Un LLM prima elabora il prompt, poi genera la risposta token dopo token. La prima fase può comportare molte moltiplicazioni di matrici. La seconda è spesso limitata dai trasferimenti di memoria, soprattutto per una singola richiesta. Accelerare i Tensor Core non risolve questo secondo collo di bottiglia.

Un resoconto pubblicato il 31 ottobre su una RTX 3070 Ti illustra questa differenza con Qwen3-1.7B BF16 in llama.cpp: l'elaborazione di 4 096 token passa da 9 382 a 12 895 token/s, circa il 37% in più, mentre la generazione resta a 141,8 e poi 141,7 token/s. Lo stesso modello in Q8_0 guadagna solo circa il 2% nell'elaborazione del prompt.

Nella discussione su LocalLLaMA segnalata a proposito del progetto, un utente con una RTX 3080 dalla memoria modificata riferisce anch'egli di non aver ottenuto guadagni con il proprio modello Q6_K. Questa testimonianza non sostituisce un protocollo completo, ma ricorda un punto essenziale: il formato dei pesi non basta a prevedere il guadagno. Occorre conoscere le operazioni realmente utilizzate dal motore di inferenza.

INT8 e il calcolo CUDA FP32 classico non raddoppiano nei test di controllo pubblicati. Per FP8 serve una valutazione più sfumata: il repository Ada descrive guadagni in alcuni percorsi FP8 con accumulo FP32, ma anche test praticamente invariati. Sarebbe quindi fuorviante presentare tutti i modelli INT8 o FP8 come automaticamente accelerati. Questi risultati non dimostrano alcun guadagno di FPS nei giochi.

La novità riportata da VideoCardz è nv-uefi-unlocker, sviluppato da physicsdolphin. Questo strumento viene eseguito da una chiavetta USB prima del sistema operativo, applica la procedura e poi restituisce il controllo al bootloader di Windows o Linux. Evita di ripetere manualmente una lunga sequenza a ogni prova, ma richiede comunque preparazione e verifica sulla macchina di destinazione.

Per impostazione predefinita, la schermata di avvio richiede una conferma. La documentazione prevede una modalità automatizzata esplicita e richiede di ripetere l'operazione dopo un avvio a freddo. Un test su RTX 4060 Laptop misura un aumento da 29,89 a 49,02–49,33 TFLOPS in GEMM FP16 a 4 096, circa il 65% in più, con il solo sblocco.

Fonte: matrice di compatibilità dettagliata, consultata il 31 ottobre 2026.

La procedura UEFI standard richiede Secure Boot disattivato oppure un'applicazione EFI firmata con una chiave riconosciuta. I portatili possono perdere lo sblocco quando la GPU dedicata viene spenta. Gli autori segnalano anche mancati avvii su alcune piattaforme: l'automazione non trasforma una modifica sperimentale in una funzione ufficialmente supportata da NVIDIA.

Il post di Mia del 24 ottobre riportato qui sotto condivideva i primi risultati Ampere, allora concentrati soprattutto su Linux. Da allora i progetti si sono evoluti, in particolare con lo strumento UEFI.