VBIOS des RTX, Beam 501B, Dory1.0-4B, FLUX.3 : la semaine des poids ouverts

RTX 30, 40, 50 : le VBIOS sans passer par le flash

Un post de r/LocalLLaMA détaille trois outils pour modifier le VBIOS des cartes NVIDIA RTX 30, 40 et 50. Au menu : limites de puissance, tensions, offsets mémoire et canaux de ventilateurs. Le flash direct étant bloqué par Falcon, l'auteur propose une autre voie : des chargeurs qui patchent le registre sous Windows, ou qui s'attaquent au démarrage du firmware GSP sous Fedora.

Le point important, c'est que le VBIOS d'origine n'est jamais touché. La méthode se distingue donc d'un flash classique, avec l'argument qui va avec : de quoi descendre sous 400 W sur une RTX 5090, c'est-à-dire reprendre la main sur la courbe de consommation d'une carte qui impose sinon ses propres réglages.

Le reste du champ couvert — tensions, offsets mémoire, ventilation — relève du même geste : ajuster finement ce que le constructeur verrouille.

Beam et Dory : deux façons de réduire le calcul

Deux publications de poids, deux stratégies opposées pour alléger la facture de calcul.

Beam, de Reflection, est un modèle ouvert texte-texte en architecture mixture-of-experts sparse : 501 milliards de paramètres au total, mais 23 milliards activés, pour une fenêtre de contexte d'un million de tokens. La version instruction-tuned sort en BF16, FP8 et NVFP4. Développé surtout pour l'anglais, il vise un raisonnement économe en tokens, le génie logiciel et l'usage d'outils agentiques.

Dory1.0-4B, de NVIDIA, prend l'autre bout de l'échelle : 4 milliards de paramètres sous licence OpenMDW 1.1, ouverte à un usage commercial. Son architecture « bouclée » réapplique un même bloc de couches partagées, ce qui augmente le calcul par token. L'attention alterne fenêtres glissantes et couches complètes, avec un contexte jusqu'à 256K tokens en BF16. Anglais uniquement, pour du raisonnement généraliste sur une empreinte réduite.

D'un côté, un modèle massif qu'on n'active qu'en partie ; de l'autre, un petit modèle qu'on fait travailler plusieurs fois sur lui-même. Les deux répondent à la même contrainte, par des chemins inverses.

llama.cpp : un noyau CUDA pour les quantifications basses

La pull request #30517, signée am17an, propose un noyau MMVQ CUDA plus rapide pour llama.cpp, le projet open source porté par ggml-org. Le gain de vitesse annoncé est important, mais il ne vaut que pour certaines quantifications basses précision, comme Q2_K et Q3_K. L'info a été relayée sur r/LocalLLaMA par l'utilisateur jacek2023.

Le sujet rejoint les deux publications précédentes, vu depuis la couche du dessous. Un noyau plus rapide sur Q2_K ou Q3_K ne change pas l'architecture d'un modèle, mais il déplace le curseur de ce qu'on peut exécuter en basse précision — donc de ce qui tient dans une mémoire donnée.

FLUX.3 Image Klein : les poids sont sortis

Un utilisateur de r/LocalLLaMA signale la publication des poids de FLUX.3 Image Klein sur Hugging Face, sous le compte black-forest-labs. Le modèle de génération d'images devient ainsi accessible publiquement via la plateforme.

Le signalement relayé s'arrête à ce constat : pas de détail, dans la dépêche, sur la licence, la taille du modèle ou ses conditions d'usage. La publication des poids suffit en soi à changer le statut du modèle pour qui veut l'exécuter localement.

Et maintenant ?

Ce qui relie ces dépêches, c'est moins un acteur unique qu'un même terrain : la pile qu'on peut réellement contrôler, du firmware d'une carte graphique jusqu'au format de quantification des poids. D'un côté, des outils qui contournent un verrou constructeur sans le franchir ; de l'autre, des modèles publiés en plusieurs précisions pour épouser le matériel disponible. Entre les deux, la communauté open source rabote toujours les mêmes murs : la mémoire, la consommation, le débit.