Des GeForce « débridées » pour l’IA : ce que les gains annoncés changent vraiment
Des développeurs ont réussi à accélérer des calculs d’IA sur certaines GeForce RTX 20, 30 et 40. Les résultats peuvent approcher un doublement dans un test ciblé. Pour qui utilise un chatbot local ou génère des images, le bénéfice reste toutefois à établir : les logiciels ne sollicitent pas tous les calculs concernés de la même façon.
Ces travaux portent sur les Tensor Cores, les unités spécialisées des GPU NVIDIA dans les multiplications de matrices, une opération très utilisée en IA. Plusieurs projets communautaires ont trouvé comment lever une limitation de débit sur certains de leurs calculs. Ils n’ajoutent ni mémoire vidéo ni unités de calcul à la carte, et ne consistent pas à augmenter sa fréquence. Ils modifient un réglage appliqué avant que le pilote graphique ne prenne la main.[1][2][3]
La découverte ouvre une piste pour mieux exploiter des GeForce déjà en circulation. Mais le bénéfice éventuel dans votre logiciel dépend de la carte, des formats de calcul et des conditions d’utilisation, qui diffèrent selon les projets. TekBrut n’a pas essayé ces modifications sur du matériel ; les résultats ci-dessous viennent des sources citées.
Une RTX 4090 montre où le gain se réduit
Dans un essai indépendant avant/après publié par le projet gpu-unlock-ada, une RTX 4090 approche le double de son débit initial sur les instructions visées. Le test concentre le travail sur ces opérations pour mesurer la vitesse à laquelle le GPU peut les enchaîner, avec la même limite de puissance de 450 W avant et après.[3]
Mais lorsqu’on passe à une multiplication de matrices avec cuBLAS, la bibliothèque de calcul de NVIDIA, le gain est moins élevé : de 12 à 34 % en FP16 et de 16 à 20 % en BF16 sur deux tailles testées. FP16 et BF16 sont deux formats de nombres sur 16 bits employés en IA ; dans ces essais, les résultats sont additionnés en 32 bits. Un autre cas BF16, avec des matrices de taille 4096, reste presque inchangé.
Ce n’est pas une contradiction. Enchaîner une instruction à son débit maximal ne suffit pas à accélérer dans les mêmes proportions un calcul qui doit aussi déplacer des données et composer avec l’organisation du logiciel. Une application ajoute encore d’autres opérations. Si l’attente se situe ailleurs, calculer plus vite sur cette seule partie ne raccourcit pas tous les temps.
Les progrès mesurés sont donc réels, mais leur portée se resserre dès qu’on s’éloigne du test ciblé. Même le gain d’une multiplication de matrices ne donne pas celui d’un chatbot complet.
Votre chatbot ne fait pas le même travail à chaque étape
Quand vous envoyez un prompt, le modèle traite d’abord le texte reçu. Cette phase peut mobiliser beaucoup de calcul matriciel, notamment avec un long prompt ou plusieurs requêtes traitées ensemble. Elle fait partie des situations où les modifications pourraient être utiles, si le logiciel utilise les opérations accélérées.
Puis le modèle produit la réponse, un fragment de texte après l’autre. Pour une seule conversation, cette étape peut être davantage limitée par la lecture des poids du modèle en mémoire et par leur reconversion avant le calcul que par la vitesse des opérations concernées. Les poids sont les valeurs numériques qui encodent ce que le modèle a appris.
Une réponse qui commence plus tôt et une réponse qui s’écrit plus vite sont donc deux améliorations différentes. Un modèle pourrait profiter du réglage pendant le traitement initial sans accélérer autant pendant la rédaction.[1]
Un modèle Q4 n’est ni automatiquement exclu, ni automatiquement accéléré
L’étiquette Q4 décrit une façon de stocker les poids du modèle sur environ quatre bits. Elle ne signifie pas que tous les calculs sont effectués sur quatre bits. Le logiciel peut reconvertir ces poids vers un autre format avant de les utiliser.
Cette distinction compte ici : les gains démontrés concernent notamment des entrées en FP16 ou BF16 avec addition des résultats en FP32, donc sur 32 bits. Si une partie du calcul d’un modèle quantifié utilise ce chemin, elle pourrait en bénéficier. Si elle reste sur les instructions entières INT4 ou INT8, les contrôles disponibles ne montrent pas le même déblocage. Et si le temps est surtout pris par la mémoire ou la déquantification, c’est-à-dire la reconversion des poids, accélérer les multiplications ne résout pas cette limite.[2][3]
Le nom d’un fichier de modèle quantifié ne suffit donc pas à annoncer un bénéfice. Sans avant/après sur le logiciel et le modèle utilisés, le gain reste inconnu.
Passer à Q8 ne donne pas davantage de certitude. Les instructions INT8 testées restent pratiquement inchangées, sans que cela constitue une mesure de tous les calculs d’un modèle Q8. Pour le FP8, un format flottant sur huit bits, l’essai de multiplication de matrices publié par gpu-unlock-ada sur une seule RTX 4070 Ti SUPER ne montre pas de gain significatif. Ce résultat ne tranche pas le cas de tous les logiciels FP8.[3]
Les images et l’entraînement attendent aussi leurs mesures
Les calculs denses mesurés rendent ces travaux intéressants au-delà des chatbots. Un entraînement qui passe beaucoup de temps dans les multiplications concernées pourrait en profiter. Le projet Zagitta cite aussi la diffusion, utilisée pour générer des images, et FlashAttention, une optimisation du calcul d’attention des modèles, parmi les charges susceptibles d’accélérer.[1]
Les résultats cités ne comprennent cependant pas de mesures de bout en bout permettant de traduire ces pistes en temps d’entraînement ou en secondes par image. Ils ne donnent pas non plus d’avant/après dédié pour llama.cpp avec des modèles Q4, ExLlamaV2/V3, vLLM, TensorRT-LLM, Marlin/PyTorch quantifié ou la bibliothèque bitsandbytes, ni de mesure isolée de la diffusion quantifiée ou de FlashAttention. Rien ne permet d’en déduire que ces logiciels ne gagneront rien, mais on ne peut pas annoncer combien ils gagneraient.
Ces travaux n’établissent pas non plus de gain dans les jeux, le rendu classique, le ray tracing ou la mise à l’échelle de NVIDIA. Le mod n’augmente pas la quantité de mémoire vidéo disponible pour charger un modèle.
Essayer aujourd’hui reste une expérimentation à risque
Ces projets exécutent du code privilégié très tôt au démarrage. Leurs auteurs avertissent de blocages du GPU ou de la machine, d’un démarrage impossible, de corruption ou perte de données et de dommages matériels potentiels. Pouvoir récupérer la machine par une console physique ou une interface de gestion à distance n’est pas un détail.[1][2][3]
Le comportement dépend de la carte, de son état au démarrage et de la séquence de chargement. Une mise à jour du noyau ou du pilote peut casser le mécanisme. La consommation et la température peuvent augmenter lorsque les unités de calcul sont davantage sollicitées. La stabilité sur la durée, le fonctionnement multi-GPU général et les conséquences sur la garantie ne sont pas établis de façon universelle. Le réglage n’est pas présenté comme permanent après une coupure d’alimentation ; cela ne garantit pas une récupération sans difficulté.
Pour une machine dont vous dépendez au quotidien, mieux vaut attendre : le bénéfice dans votre application reste inconnu, les risques de démarrage et de perte de données sont réels. Une mesure avant/après du délai avant la réponse, de la vitesse de génération ou du temps par image, sur la même carte et dans des conditions comparables, aiderait à décider. D’ici là, l’essai garde un intérêt expérimental sur un banc dédié, pour des personnes capables d’en assumer les risques et d’en gérer la récupération, sans garantie de remise en état.
Informations vérifiées le 25 octobre 2026.
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.