RTX 20, 30 et 40 : les moddeurs libèrent la puissance IA cachée

Les projets gpu-unlock, gpu-unlock-ada et Turing-unlock s’attaquent à une limitation du débit de certaines instructions Tensor sur les GeForce. Les cas les mieux documentés concernent les calculs FP16 ou BF16 avec accumulation en FP32, ainsi que le TF32 sur les architectures compatibles. L’accumulation désigne la précision utilisée pour additionner les résultats intermédiaires : deux calculs qui utilisent des données FP16 ne suivent donc pas nécessairement le même chemin matériel.

Le déverrouillage intervient avant le chargement du pilote NVIDIA et modifie des réglages internes du GPU. Il ne rajoute ni cœurs ni mémoire vidéo et n’impose pas de flasher le VBIOS. Son effet est volatil : une perte d’alimentation du GPU peut l’effacer. Les projets reprennent des travaux menés sur les cartes de minage CMP, adaptés notamment par Zagitta et, pour Ada, à partir des travaux de TOTORONG.

Les résultats ci-dessous proviennent des développeurs et de leurs contributeurs. Hardware Reference a recoupé les publications et les protocoles ; nous n’avons pas reproduit ces essais sur notre propre banc.

Le dépôt gpu-unlock de Zagitta rassemble les mesures suivantes en multiplication de matrices dense, avec accumulation FP32. Les chiffres sont arrondis dans sa synthèse ; les pourcentages sont ceux annoncés par le projet à partir des mesures d’origine.

Ces retours utilisent des configurations différentes : ils illustrent le gain avant/après sur chaque carte et ne constituent pas un classement réalisé avec un protocole commun. Les TFLOPS expriment ici un débit de calcul, pas des images par seconde dans un jeu.

Le rapport apparié de gpu-unlock-ada est particulièrement instructif. Une même RTX 4090 a été comparée avant et après activation, avec le pilote NVIDIA 615.78.08, CUDA 13.4.92 et une limite de 450 W. Le débit d’instructions passe de 160,4 à 320,4 TFLOPS en FP16/FP32, et de 159,7 à 320,2 TFLOPS en BF16/FP32.

Agrandir

Les multiplications de matrices cuBLAS de cette même comparaison donnent des écarts plus modestes. Toutes utilisent une accumulation FP32 ; N désigne la taille de matrices carrées N × N. Les valeurs sont les médianes publiées et les écarts ci-dessous sont calculés à partir de ces valeurs.

Le cas BF16 en 4 096³ reste donc pratiquement inchangé. Le rapport porte sur une seule paire de mesures, avec le bureau actif, et ne vaut pas validation de stabilité prolongée. Le FP16 avec accumulation FP16 et les contrôles INT8 restent, eux aussi, proches de leur niveau initial.

Le dépôt Turing-unlock documente un essai sur une ASUS RTX 2080 Ti de 11 Gio, réalisé le 22 octobre. Le débit d’instructions FP16 avec accumulation FP32 passe de 46,9361 à 93,6649 TFLOPS, soit presque un doublement. En multiplication cuBLAS 8 192³, la progression est de 48,1488 à 85,1705 TFLOPS, soit environ 77 %. Le FP16 avec accumulation FP16 reste inchangé.

Cette démonstration concerne une carte et une plateforme précisément identifiées. Son chargeur expérimental n’est pas un installateur universel. Elle montre aussi que le déverrouillage du calcul ne nécessite pas d’augmenter la capacité mémoire : les 11 Gio de cette carte sont restés 11 Gio.

Le test de Cryptolab apporte un contrepoint utile. Il compare 18 requêtes au total avec Qwen3.8 27B Q4_K_M et MTP dans Ollama 0.33.2, sur une RTX 3090 de 24 Gio limitée à 350 W. Chaque profil compte trois essais par état, pour une sortie de 256 tokens. Les débits ci-dessous sont des médianes, en tokens par seconde.

Attention à l’interprétation : les fréquences n’étaient pas verrouillées et les états thermiques différaient entre les séries. La fréquence SM médiane relevée passe notamment de 1 470 à 1 545 MHz. Ces écarts décrivent les performances observées, sans isoler l’effet du seul déverrouillage. Les réponses appariées possèdent néanmoins les mêmes empreintes SHA-256.

Les tâches de diffusion peuvent profiter davantage des calculs concernés. Un contributeur de nv-uefi-unlocker rapporte les deux premiers résultats ci-dessous sur une RTX 3080 LHR, sous Windows, avec trois essais par état. Un autre rapport sur RTX 4090 mesure LTX-2.5 dans ComfyUI. Chaque ligne compare un même travail avant/après ; les machines et les modèles diffèrent entre les lignes.

Le pourcentage indique l’augmentation du débit à travail identique, calculée par durée avant / durée après − 1. Une hausse de débit de 28,8 % correspond ainsi à environ 22,3 % de temps en moins. Sur la RTX 4090, le bénéfice change avec la limite de puissance ; le seul déverrouillage ne supprime pas cette contrainte.

Un LLM commence par traiter le prompt, puis génère sa réponse token après token. La première phase peut être riche en multiplications de matrices. La seconde est souvent limitée par les transferts mémoire, surtout pour une requête isolée. Accélérer les Tensor Cores ne corrige pas ce second goulot d’étranglement.

Un retour publié le 31 octobre sur une RTX 3070 Ti illustre cette différence avec Qwen3-1.7B BF16 dans llama.cpp : le traitement de 4 096 tokens passe de 9 382 à 12 895 tokens/s, environ +37 %, tandis que la génération reste à 141,8 puis 141,7 tokens/s. Le même modèle en Q8_0 ne gagne qu’environ 2 % sur le traitement du prompt.

Dans la discussion LocalLLaMA fournie autour du projet, un utilisateur d’une RTX 3080 à mémoire modifiée rapporte également un résultat nul avec son modèle Q6_K. Ce témoignage ne remplace pas un protocole complet, mais rappelle un point essentiel : le format des poids ne suffit pas à prévoir le gain. Il faut connaître les opérations réellement utilisées par le moteur d’inférence.

L’INT8 et le calcul CUDA FP32 classique ne doublent pas dans les contrôles publiés. Le FP8 demande davantage de nuance : le dépôt Ada décrit des gains sur certains chemins FP8 avec accumulation FP32, mais aussi des tests pratiquement inchangés. Présenter tous les modèles INT8 ou FP8 comme automatiquement accélérés serait donc trompeur. Aucun gain de FPS en jeu n’est établi par ces résultats.

La nouveauté relayée par VideoCardz est nv-uefi-unlocker, développé par physicsdolphin. Cet outil s’exécute depuis une clé USB avant le système d’exploitation, applique la procédure puis redonne la main au chargeur de Windows ou de Linux. Il évite de reproduire manuellement une longue séquence à chaque essai, mais nécessite toujours une préparation et une vérification sur la machine cible.

Par défaut, son écran de démarrage demande une confirmation. La documentation prévoit un mode automatisé explicite et demande de rejouer l’opération après un démarrage à froid. Un test sur RTX 4060 Laptop mesure 29,89 à 49,02–49,33 TFLOPS en GEMM FP16 4 096, soit environ +65 %, avec ce déverrouillage seul.

Source : matrice détaillée de compatibilité, consultée le 31 octobre 2026.

La procédure UEFI standard nécessite Secure Boot désactivé, ou une application EFI signée avec une clé reconnue. Les portables peuvent perdre le déverrouillage quand le GPU dédié est mis hors tension. Les auteurs signalent aussi des échecs de démarrage sur certaines plateformes : l’automatisation ne transforme pas une modification expérimentale en fonction officiellement prise en charge par NVIDIA.

La publication de Mia du 24 octobre ci-dessous relayait les premiers résultats Ampere, alors surtout centrés sur Linux. Les projets ont depuis évolué, notamment avec l’outil UEFI.