Un MoE ternaire de 30B tient sur 12 Go avec 368K de contexte

1,58 bit : le ternaire sort du labo

Le fichier s'appelle Ternary-Nemotron-3.5-Lightning-30B-A3B, au format GGUF. Derrière ce nom, un MoE de 30B paramètres dont 3B actifs, quantifié en ternaire sur 1,58 bit. D'après son auteur, il tient sur un GPU de 12 Go tout en conservant 368K de contexte. Les débits annoncés : 172 tok/s en décodage et plus de 7000 tok/s en prefill.

Le détail qui compte, c'est la compatibilité. Un seul et même fichier tourne sur llama.cpp standard comme sur le fork PrismML. Et il s'agit du deuxième MoE ternaire compatible avec llama.cpp standard, après maple-preview. Autrement dit, le ternaire n'est plus une curiosité réservée à des moteurs bricolés : il entre dans la chaîne d'outils courante, avec les débits qui vont avec.

Prefill : le goulot des longs contextes

Le prefill, c'est l'étape où le modèle avale tout le contexte avant de produire le premier token. C'est précisément ce qui plombe les longs contextes : plus la fenêtre est large, plus cette phase s'étire.

Des chercheurs de Stanford et de l'UC Berkeley présentent TokenGate, une approche d'attention dite « token-gated » qui, d'après le titre du fil posté sur r/LocalLLaMA, rend le prefill en contexte long jusqu'à 11,3x plus rapide. Le chiffre est séduisant, la prudence reste de mise : le seul extrait visible du fil se limite à un « i hope it's real ».

L'intuition reste solide : si le prefill devient bon marché, c'est tout l'usage des longs contextes qui se déplace — documents entiers, dépôts de code, historiques de conversation.

llama.cpp : une écriture hors bornes, corrigée

La CVE-2026-116096 vise llama.cpp, plus précisément la fonction `list_pockettts_state_slots` du fichier `pockettts-gen.cpp`, dans le composant Pocket-TTS. Une manipulation de l'argument `mmproj` y provoque une écriture hors bornes.

L'attaque exige un accès local, ce qui limite la portée. Mais l'exploit est public et peut resservir. La version b11796 corrige le problème, avec le patch 0a1ef309. Sur master comme en b11871, un `mmproj` malveillant déclenche désormais un `GGML_ASSERT` actif en release : l'exécution s'interrompt au lieu de laisser passer l'écriture.

Pour qui charge des poids et des adaptateurs venus de partout — le quotidien du local — la différence entre un plantage net et une corruption silencieuse vaut la mise à jour.

120 W au lieu de 70, et un accès qui se referme

Sur une RTX PRO 4000 Blackwell SFF (24 Go de GDDR7, 70 W d'usine, sans connecteur d'alimentation auxiliaire), un testeur charge un VBIOS modifié en mémoire et pousse la limite à 120 W. Sur 158 requêtes, Qwen3.8 27B continue de gagner jusqu'à 120 W : 35,04 → 58,53 tok/s, soit +67 %, avec 20 % de VRAM en plus et 180 MHz sur le cœur. Qwen3.6 35B A3B, lui, reste quasi plat entre 106 et 120 W. Le tout sans flash EEPROM ni soudure.

Ce bricolage dit une chose simple : le matériel grand public a de la marge. En face, le discours sur les poids ouverts se referme. Un membre de r/LocalLLaMA constate que les États-Unis et la Chine restreignent les modèles dotés de capacités cyber ; seuls des opérateurs travaillant sous l'œil de leur gouvernement et de leurs sponsors big tech y auraient accès. Il y voit un risque : les grandes entreprises et les États façonnent le numérique à leur guise, pendant que particuliers et petites entreprises perdent la capacité de défendre leurs propres actifs.

Et maintenant ?

Le fil commun, c'est le local : un modèle qui tient sur 12 Go, un prefill qui coûte moins cher, une carte de 70 W qui en accepte 120, une faille corrigée en b11796. Le matériel et les outils suivent, chacun à leur rythme et avec leurs réserves — les 11,3x de TokenGate restent à confirmer. La question ouverte n'est plus technique : elle porte sur qui garde la main sur les poids, et sur les modèles qu'on aura encore le droit de faire tourner chez soi.