# GeForce « débridées » pour l’IA : dossier technique

Ce document rassemble les détails techniques et les sources du décryptage consacré aux gains annoncés sur les GeForce.

## Annexe technique facultative

Les détails qui suivent précisent les cartes, les protocoles et les limites des résultats cités. Ils ne constituent pas une procédure d’installation ou de contournement.

### Ce qui est modifié, et d’où viennent ces projets

Les livres blancs NVIDIA distinguent plusieurs débits pour un même GPU selon le format d’entrée et l’accumulateur, qui additionne les produits successifs. Pour la RTX 2080 Ti, le livre blanc Turing donne 113,8 TFLOPS Tensor en FP16 avec accumulation FP16, contre 56,9 avec accumulation FP32. Un TFLOPS représente mille milliards d’opérations flottantes par seconde. Les chemins INT8 et INT4, exprimés en TOPS pour les opérations entières, sont distincts.[7]

Le livre blanc Ampere GA102 ajoute BF16 et TF32 aux formats Tensor. Son tableau RTX 3080 distingue notamment FP16 avec accumulation FP16 (119 TFLOPS, ou 238 avec sparsité), FP16/BF16 avec accumulation FP32 (59,5/119), TF32 (29,8/59,5), INT8 (238/476 TOPS) et INT4 (476/952 TOPS). Les valeurs avec sparsité concernent le calcul sur des données répondant à cette condition ; elles ne sont pas interchangeables avec les valeurs denses.[8]

Zagitta/gpu-unlock décrit un changement de « speed selectors », les sélecteurs de cadence SS0/SS1, avant la prise en charge par le pilote NVIDIA non modifié. Son flux Linux passe par l’initramfs, l’environnement minimal du démarrage, et inclut un FLR, une réinitialisation de la fonction PCIe. Il revendique un doublement de la cadence d’émission des instructions FP16/BF16 vers accumulation FP32 sur GA102, GA103, GA104 et GA106. Les identifiants acceptés par ce code ne prouvent pas que chaque carte a été testée.[1]

Le projet Ada décrit lui aussi une intervention avant le pilote standard. Pour son chemin RTX 4090, il déclare un firmware signé, un payload (le code exécuté par ce mécanisme) avec contrôles de permissions, des écritures de sélecteurs et un FLR. Sur Turing, nlzy décrit un module TU102 qui modifie SS0/SS1 avant de reprendre la finalisation normale du programme de démarrage du GPU. Les résultats dépendent de cette initialisation précoce ; charger le mécanisme après la prise en charge par le pilote n’est pas équivalent selon les README. Les chemins initramfs et UEFI, le logiciel d’initialisation de la machine, restent propres aux implémentations.[3][4]

Les attributions sont collectives, et diffèrent selon les projets :

- Zagitta présente son travail Ampere comme combinant la technique V67/PLM issue des recherches CMP avec le timing pré-pilote de l’approche UEFI. Il ne s’agit pas d’une attribution exclusive de la découverte.[1]
- KohakUnlock crédite haohervchb/Turing-unlock, xrip/cmp50hx-unlock, les travaux CMP40HX, les recherches V67 de Jon Pry et les interfaces NVIDIA. nlzy/turing-unlock adapte l’approche de gpu-unlock à Turing.[2][4]
- JustAResearcher/gpu-unlock-ada attribue le payload AD102 et l’analyse du programme de démarrage à TOTORONG/AD103_win_unlocker, et le module ainsi que l’empaquetage Linux au projet de Zagitta.[3][6]
- xrip/cmp50hx-unlock apporte un contexte de recherche sur CMP/TU102. Son README décrit des modules NVIDIA modifiés et un chemin UEFI spécifique CMP50HX. Ce n’est ni une preuve de compatibilité GeForce, ni un cas à englober dans la mention « pilote non modifié ».[5]

### Cartes : admission logicielle, essai physique et reproduction

« Avant/après » désigne une comparaison sur une même carte. Une mesure d’auteur, un rapport de propriétaire et une reproduction indépendante n’ont pas le même statut. Aucune ligne ne vaut certification de compatibilité ou de stabilité pour toutes les variantes du modèle. Une version de pilote absente du dossier est laissée non précisée, pas déduite d’un autre essai.

| GPU, puce et identifiant PCI | Admission et essai physique documentés | Mesure ou résultat retenu | Reproduction, système et limite |
|---|---|---|---|
| RTX 2080 Ti, TU102 ; 10de:1e07 chez nlzy ; 10de:1e04/107d:1e04 chez Kohak | nlzy : une Dell 22 Go modifiée ; Kohak : une Leadtek TU102 a1, 22 Gio modifiée | mmapeak Kohak FP16→FP32 : 59,9→111,0 TFLOPS ; témoin FP16→FP16 : 119,5→118,5 | Profils matériels particuliers, pas de reproduction indépendante retenue. Linux, pilote 575.51.03 propriétaire et open chez nlzy. La modification logicielle n’ajoute pas la VRAM de ces cartes modifiées.[2][4] |
| RTX 3060 12 Go, GA106, 10de:2504 | Listée par Zagitta, rapport de propriétaire | Environ +80 % sur un GEMM BF16, selon ce rapport | Chemin Linux Zagitta, version de pilote non précisée ; protocole de rapport utilisateur, pas de reproduction indépendante retenue.[1] |
| RTX 3070, GA104, 10de:2484 | Listée, rapports de propriétaires | +73 à +81 % sur leurs GEMM BF16 | Linux Zagitta, pilote non précisé ; pas de reproduction indépendante retenue.[1] |
| RTX 3080 10 Go, GA102, 10de:2206 | Listée, rapports de propriétaires | +70 à +73 % sur leurs GEMM BF16 | Linux Zagitta, pilote non précisé ; pas de reproduction indépendante retenue. Une RTX 3080 Ti OEM 20 Go, 10de:2205, termine l’opération mais reste à demi-débit BF16 : exception explicite.[1] |
| RTX 3090, GA102, 10de:2204 | Listée ; Kohak dit avoir exécuté le projet amont sur quatre cartes ; comparaison chiffrée sur une carte | PyTorch, GEMM FP16→FP32 8192³ : 73,03→122,76 TFLOPS ; 370 W avant, 360 W après | Mesure Kohak, sans reproduction indépendante retenue pour ce GEMM ; pilote non précisé. Pas de conclusion sur toutes les variantes.[1][2] |
| RTX 3090 Ti, GA102, 10de:2203 | Listée et mesurée par Zagitta | GEMM dense 8192³, médiane de cinq mesures à 450 W : FP16 87,46→118,39 ; BF16 87,50→157,41 ; TF32 42,58→82,61 TFLOPS | Rapport du projet, Linux, pilote non précisé ; pas de reproduction indépendante retenue. Ce protocole n’est pas directement comparable aux autres lignes.[1] |
| RTX 4090, AD102, 10de:2684 | Cible automatique du module Ada ; essais physiques | Essai indépendant apparié, révision 8855e7b, limite 450 W : débit d’instructions FP16→FP32 160,4→320,4 ; BF16→FP32 159,7→320,2 TF/s | Linux, pilote standard après le payload, version non précisée. GEMM cuBLAS : +12–34 % FP16 et +16–20 % BF16 sur deux tailles ; quasi plat en BF16 à 4096³. Ni mesure applicative ni validation de stabilité longue durée.[3] |
| RTX 4070 Ti SUPER, AD103, 10de:2705 | Cible expérimentale à activation explicite, non sélectionnée par « all » ; une carte, deux démarrages à froid | À 240 W : instructions FP16→FP32 95,0→189,9 ; BF16→FP32 95,0→189,7 TF/s. Second test TF32→FP32 : 47,49→94,51 | Mesures du projet, pas de reproduction indépendante ; pilote non précisé. Ces gains portent sur le débit d’instructions, pas l’inférence. Contrôles INT8/INT4 plats ; FP8 détaillé ci-dessous.[3] |
| RTX 4060 Ti 16 Go, AD106, 10de:2805 | Cible expérimentale ; une carte validée pour transactions et prise en charge par le pilote | Les lectures de contrôle RM FMLA32/IMLA2/IMLA4 passent de demi à plein débit | Aucun avant/après de débit sur la même carte. Aucun gain de performance ne peut être annoncé ; pilote non précisé.[3] |

Le dossier distingue aussi une contribution Windows séparée sur une MSI RTX 4070 Ti AD104, avec démarrage manuel. Elle ne constitue pas une admission d’AD104 par le module Linux, et ne doit pas être confondue avec la RTX 4070.[3]

### Pourquoi ces chiffres ne forment pas un classement de GPU

Dans la notation GEMM 8192³, les trois dimensions de la multiplication de matrices valent 8192. La taille change la charge et le choix des routines de calcul. Le format d’entrée, l’accumulateur, la puissance disponible et le kernel (la routine exécutée sur le GPU) comptent aussi. Les mesures de cartes différentes ci-dessus ne permettent pas un classement à conditions égales.

Sur la RTX 2080 Ti de Kohak, le contraste entre FP16→FP32 et FP16→FP16 montre que l’accumulateur importe : le premier test progresse, le témoin voisin reste pratiquement plat. Ce témoin ne permet pas une conclusion sur tous les GPU.

Sur l’unique RTX 4070 Ti SUPER concernée, INT8 reste à 379,5 TOP/s et INT4 avec accumulation INT32 autour de 754,8 TOP/s, pratiquement inchangés. L’unique GEMM CUTLASS FP8 E4M3 avec accumulation FP32 passe de 59,326 à 59,495 TF/s, soit +0,3 %. E4M3 désigne ici le format FP8 précis du test. Ce résultat ne montre pas de gain significatif dans ce GEMM, sans trancher les autres kernels FP8. Les contrôles INT8, dp4a et FP32 scalaire rapportés sur la RTX 4090 restent proches de la référence.[3]

Le calcul FP32 scalaire, le rendu raster, les unités RT, la bande passante mémoire et la capacité de VRAM sont distincts des chemins Tensor concernés. Aucun gain jeu, raster, ray tracing ou DLSS n’est établi. Aucun temps d’entraînement complet avant/après n’est validé dans le dossier.

### Formats et logiciels : ce que l’on peut attendre, sous conditions

Le traitement initial du prompt est souvent nommé « prefill », et la génération successive « decode ». Un « batch » regroupe plusieurs travaux. Le bénéfice peut dépendre de leur part de calcul matriciel, de mémoire et de déquantification. Il n’est pas possible de remplir les formats d’entrée et d’accumulation manquants à partir du seul nom du logiciel.

| Format, logiciel ou opération | Chemin et conclusion autorisée | Preuve et limite |
|---|---|---|
| Calcul dense FP16/BF16 avec accumulation FP32, PyTorch/cuBLAS | Bénéfice démontré sur les GEMM cités, selon carte, taille et puissance | Kohak 3090 et Ada 4090 ; le test ciblé de la 2080 Ti établit séparément le chemin d’instructions. Ce n’est pas un gain d’entraînement complet.[2][3] |
| llama.cpp, GGUF Q4_K_M/Q4_K_S | Bénéfice plausible mais non mesuré si le calcul emprunte les opérations ciblées | Aucun avant/après public spécifique validé dans le corpus. L’étiquette Q4 ne fixe ni kernel ni accumulation ; génération mono-requête potentiellement limitée par mémoire/déquantification.[1] |
| GPTQ, AWQ, INT4 | Aucun bénéfice attendu de ce débridage si le kernel reste réellement INT4/INT8 natif ; bénéfice plausible mais non mesuré si reconversion FP16/BF16 avec accumulation FP32 | Conclusion conditionnelle fondée sur les chemins distincts et les contrôles INT plats, pas sur une mesure de tous les modèles GPTQ/AWQ.[3][7] |
| Q8/INT8 | Même réserve pour un chemin INT8 natif : pas de bénéfice attendu du réglage dans les contrôles disponibles | Ne pas assimiler tous les calculs d’un modèle Q8 à ces contrôles.[3] |
| EXL2, ExLlamaV2/ExLlamaV3 | Bénéfice plausible mais non mesuré | Aucun avant/après public vérifié ; rapport externe non revalidé exclu du dossier. |
| vLLM | Bénéfice plausible mais non mesuré | Kernel, format Tensor et accumulation non établis pour un cas précis ; aucun avant/après validé. |
| TensorRT-LLM | Bénéfice plausible mais non mesuré | Précision et kernel effectifs à établir ; aucun avant/après validé. |
| Marlin/PyTorch quantifié | Bénéfice plausible mais non mesuré si le chemin ciblé est utilisé | Poids 4 bits et instructions INT4 ne sont pas synonymes ; aucun avant/après validé. |
| bitsandbytes | Bénéfice plausible mais non mesuré | Déquantification, format de calcul et accumulation à établir ; aucun avant/après validé. |
| FlashAttention | Bénéfice plausible mais non mesuré isolément | Cité par Zagitta, mais sans protocole dédié vérifié dans le corpus.[1] |
| Diffusion quantifiée | Bénéfice plausible mais non mesuré | Aucun avant/après quantifié validé ; le format des poids ne donne pas celui du calcul. |
| FP8 sur Ada | Aucun bénéfice attendu pour le seul GEMM CUTLASS E4M3/FP32 testé, pratiquement plat | +0,3 % sur une 4070 Ti SUPER ; les autres kernels restent inconnus.[3] |
| FP16 avec accumulation FP16 | Chemin incompatible avec le gain démontré sur la 2080 Ti | Témoin Kohak plat ; ne pas généraliser aux autres GPU.[2] |
| Prompt initial, lots et entraînement dense | Gain plausible si une part suffisante du temps passe dans les opérations accélérées | Pas de gain applicatif général démontré pour les logiciels quantifiés listés. |
| Génération d’une seule réponse | Aucun gain général démontré | Lecture des poids et déquantification peuvent dominer ; absence d’avant/après dédié validé ici. |

Les lignes sans référence numérotée propre décrivent les limites du corpus vérifié, pas des déclarations des éditeurs des logiciels. Le dossier ne permet pas de conclure pour Q5, Q6 ou NF4 ; aucune estimation n’en est déduite.

### Précautions liées au démarrage et au matériel

Le risque ne se limite pas au résultat du benchmark. L’exécution privilégiée, le firmware, l’initramfs ou l’UEFI, la réinitialisation PCIe et l’ordre de chargement du pilote font partie du mécanisme. Démarrage à froid, redémarrage et carte déjà prise en charge par le pilote ne sont pas des états équivalents selon les projets. Une console de récupération et un contrôle d’alimentation peuvent devenir nécessaires.[1][2][3]

Secure Boot était désactivé sur le banc Kohak ; le projet CMP évoque des modules non signés. Ces constats ne permettent pas d’écrire que tous les projets imposent de désactiver Secure Boot. Le réglage est lié au démarrage et au cycle d’alimentation, avec un comportement dépendant du projet et de la carte. Aucune garantie de réversibilité sans difficulté, d’absence de dommage ou de stabilité longue durée ne découle des essais. Une éventuelle non-prise en charge par le fabricant est un risque, pas une conclusion juridique générale.

## Sources

[1] Zagitta, gpu-unlock : https://github.com/Zagitta/gpu-unlock — mécanisme Ampere, filiation, rapports GPU, protocole 3090 Ti, réserves applicatives et risques.

[2] KohakuBlueleaf, KohakUnlock : https://github.com/KohakuBlueleaf/KohakUnlock — comparaisons 2080 Ti et 3090, configurations matérielles, attributions et précautions.

[3] JustAResearcher, gpu-unlock-ada : https://github.com/JustAResearcher/gpu-unlock-ada — RTX 4090, 4070 Ti SUPER, 4060 Ti, contribution Windows séparée et contrôles de formats.

[4] nlzy, turing-unlock : https://github.com/nlzy/turing-unlock — adaptation TU102, profil Dell 2080 Ti et pilote documenté.

[5] xrip, cmp50hx-unlock : https://github.com/xrip/cmp50hx-unlock — antécédent CMP spécifique, distinct des preuves GeForce.

[6] TOTORONG, AD103_win_unlocker : https://huggingface.co/TOTORONG/AD103_win_unlocker — artefact crédité par le projet Ada.

[7] NVIDIA, NVIDIA Turing GPU Architecture, livre blanc officiel — capacités Tensor selon précision et accumulation ; PDF du corpus validé.

[8] NVIDIA, NVIDIA Ampere GA102 GPU Architecture, livre blanc officiel — formats et plafonds GA10x ; PDF du corpus validé.