Ternaire, élagage, contexte géant : la compression au cœur des modèles locaux

OpenBonsai : le maillon manquant du ternaire

Prism ML avait diffusé les poids et le runtime de son Ternary Bonsai : un modèle 9B ramené à environ 2 Go, grâce à des poids valant -1, 0 ou +1. Manquait une pièce : le pipeline complet permettant de compresser ses propres modèles BF16 vers ce format. C'est ce vide que comble OpenBonsai, un framework sous licence Apache-2.0 publié par un développeur sur r/LocalLLaMA.

OpenBonsai pratique la quantification ternaire post-entraînement et se branche sur le format PTQ1_0 GGUF de Prism ML. Le projet s'appuie notamment sur un article d'Intel Labs China, « Attend to Your Own Thoughts » (Wang et al.).

L'origine est concrète : faire tourner WebBrain, un agent navigateur open source, au plus près de la machine — idéalement via WebGPU. Autrement dit, disposer du pipeline de bout en bout plutôt que de dépendre de poids déjà compressés par quelqu'un d'autre. La différence entre consommer un format et pouvoir le produire soi-même.

Élaguer plutôt que réentraîner

À côté du ternaire, l'élagage continue de faire des dégâts. Un utilisateur de r/LocalLLaMA a réduit le nouveau modèle vocal 30B de NVIDIA de 67,5 Go à 10 Go, sans aucun réentraînement. Le taux d'erreur de transcription passe de 4,12 % à 5,16 % : environ un point de WER en plus, pour une taille divisée par 6,7 environ. De quoi rendre un modèle vocal de cette taille utilisable sur du matériel bien plus modeste.

Sur le front de l'inférence, le fork Strata de Basalt annonce un record pour Qwen3.8 Flash Next en quantification IQ3_S, sur une seule RTX 5080 de 16 Go, épaulée par 64 Go de DDR5 6400 et un Core Ultra 9 285K. Le traitement de prompt atteint 5 500 tok/s ; la génération monte jusqu'à 275 tok/s sur le code et les appels d'outils, et 190 tok/s pour les traces de raisonnement, mesurés pendant une session live d'opencode.

Certaines pull requests d'optimisation sont encore en attente, mais l'amont bénéficie déjà de gains et d'optimisations mémoire. La quantification IQ3_S est jugée pleinement utilisable — c'est peut-être le point le plus intéressant du lot.

Qwen4 : un million de tokens, sur le papier

Un extrait publié sur r/LocalLLaMA indique que les modèles Qwen4 disposeront d'une fenêtre de contexte d'un million de tokens. À prendre avec les pincettes d'usage : le Qwen4-27B n'apparaît pas dans la capture, et une annonce est attendue à Apsara Netherlands.

Une date circule aussi pour Qwen4-max, le 1er novembre. La mention d'octobre à la place, dans le même document, suggère toutefois un simple placeholder. Une pull request sur le dépôt qwen-code est citée comme source — autrement dit, on parle d'indices, pas de spécifications.

Dots : l'agent devient un correspondant

Pendant que le local compresse, le cloud change d'interface. OpenAI permet à ses agents Dots de dialoguer avec leurs utilisateurs directement depuis Google Messages, en avant-première aux États-Unis, sur la base du protocole RCS.

Concrètement, les assistants peuvent envoyer des mises à jour sur leurs avancées ou demander des informations complémentaires dans un fil de conversation dédié. L'agent cesse d'être une destination à ouvrir : il devient un interlocuteur parmi les autres fils.

Et maintenant ?

Deux dynamiques se dessinent, sans se répondre. D'un côté, la compression sous toutes ses formes — ternaire chez OpenBonsai, élagage sans réentraînement chez NVIDIA, quantification IQ3_S chez Basalt — rapproche des modèles de taille respectable de machines à 16 Go de VRAM, au prix d'un point de WER ou d'un pipeline à écrire soi-même. De l'autre, les agents sortent des interfaces dédiées : Dots s'installe dans une messagerie, avec RCS pour socle. Entre les deux, le million de tokens de Qwen4 reste, pour l'instant, une capture d'écran et une pull request.