La révolution 2-bit : Ternary-Bonsai-2 et les GGUF 27B font tourner des modèles multimodaux sur un GPU consumer
🔎 Une semaine qui a basculé
Pendant que la plupart des observateurs scrutaient les scores des géants du cloud, HuggingFace a vécu une autre histoire cette semaine : celle de la compression extrême. Ternary-Bonsai-2-27B, un modèle multimodal de 27 milliards de paramètres distribué en 2 bits, a dépassé les 4 millions de téléchargements (octobre 2026, agents-radar). Dans la même fenêtre, ISTA-DASLab a publié quatre quantizations GSQ-RCO en sept jours, et un GGUF uncensored a franchi le million et demi de downloads.
Trois chiffres, un signal : l'IA locale sur hardware consumer n'est plus l'exception réservée aux possesseurs de RTX 4090. C'est la norme qui se dessine, semaine après semaine, dans les classements de téléchargement.
Ce qui rend cette vague différente des précédentes, ce n'est pas le marketing. C'est l'ingénierie : pour la première fois, un 2-bit natif affiche 98,2 % de la qualité de sa base FP16, là où une quantization 2-bit classique plafonne à 84,1 %. On décortique pourquoi, ce que ça change concrètement, et ce qu'on perd vraiment.
L'essentiel
- Ternary-Bonsai-2-27B : 27,36 Md de paramètres multimodaux dans 5,95 Go (PTQ1_0, 1,75 bit/poids), contre ~54 Go en FP16 — 9,3× de réduction.
- 98,2 % de la qualité FP16 (84,78 vs 86,32 sur la moyenne thinking), quasiment au niveau d'un 4-bit UD et très loin devant une quant 2-bit classique (84,1 %).
- Deux packings : PTQ1_0 (trits denses, roi du prompt processing) et PQ2_0 (slots 2-bit, plus rapide en décode sur Ada/L4 et en mémoire serrée).
- Fork obligatoire : les kernels ternaires vivent dans le fork PrismML-Eng de llama.cpp ; le binaire stock produit du garbage.
- Mac servi : variante MLX officielle, KV cache 4-bit, drafter DSpark pour le décodage spéculatif. Licence Apache 2.0, backends CUDA/Metal/CPU.
Outils recommandés
| Outil | Usage principal | Prix (octobre 2026) | Idéal pour |
|---|---|---|---|
| Ternary-Bonsai-2-27B GGUF (PTQ1_0) | Multimodal 27B, contexte 262K | Gratuit (Apache 2.0) | GPU 8 Go+, décode max sur H100/A100/Blackwell |
| Ternary-Bonsai-2-27B GGUF (PQ2_0) | Variante slots 2-bit (7,21 Go) | Gratuit (Apache 2.0) | RTX Ada / L4, VRAM serrée |
| Version MLX 2-bit | Apple Silicon (Python/Swift) + CUDA | Gratuit | Mac M-series 32 Go |
| Fork llama.cpp PrismML-Eng | Kernels ternaires CUDA/Metal/CPU | Gratuit (open source) | Servir le modèle en local |
| Hostinger | Héberger l'interface ou l'API qui expose votre modèle | Dès ~3 €/mois (vérifiez sur hostinger.com) | Mettre votre instance en prod |
Pourquoi le 2-bit marche enfin
Le 2-bit fonctionne maintenant parce que la compression est conçue dans le modèle, pas appliquée dessus comme un pansement. Trois ingrédients, documentés sur la fiche officielle du modèle :
Des poids ternaires avec échelles FP16. Chaque groupe de 128 poids (g128) ne contient que trois valeurs — −1, 0, +1 — mais conserve son échelle en FP16. Le trit porte la direction, l'échelle porte la magnitude. C'est ce duo qui permet de descendre à 1,75 bit/poids sans assassiner l'information.
Des rotations de Hadamard par blocs de 1024. Les outliers, ennemis historiques de la quantization basse précision, sont dispersés avant compression au lieu d'être brutalement écrêtés. C'est la différence entre 98,2 % et 84,1 % de la qualité FP16.
Une attention hybride, ~75 % linéaire / ~25 % full. Seules 16 des 64 couches portent de la full attention. Moins de couches à mémoriser précieusement, donc un KV cache maîtrisé — et un contexte de 262K tokens qui devient réaliste sur une machine personnelle.
On avait tracé cette trajectoire dans notre dossier sur les LLM 1-bit, quand les modèles tiennent sur un smartphone. Ce qui change avec Bonsai 2, c'est la preuve à l'échelle : un 27B multimodal complet, benchmarks publiés à l'appui, pas une simple démo de laboratoire.
Un détail d'implémentation mérite d'être souligné : les poids ne sont jamais ré-expandus en FP16. Les kernels du fork calculent directement sur les trits packés. Or l'inférence en décode est limitée par la bande mémoire — diviser par neuf les données à déplacer, c'est mécaniquement diviser le goulot d'étranglement. C'est pour ça que les gains sont les plus visibles précisément là où la mémoire manque.
Ce qu'il y a vraiment dans Ternary-Bonsai-2-27B
Un modèle multimodal complet — backbone 27B, vision, 262K de contexte — dans l'encombrement d'un jeu vidéo AAA.
La base est Qwen3.8-27B, architecture inchangée. Ce point compte : il ne s'agit pas d'un modèle entraîné from scratch en ternaire, mais d'une conversion maîtrisée d'un socle dont la qualité est déjà établie. La quantization native s'applique aux poids, pas à l'architecture.
La facture détaillée (source : dépôt HuggingFace, octobre 2026) :
| Composant | Paramètres | Rôle |
|---|---|---|
| Backbone (64 blocs) | 24,35 Md | Langage et raisonnement, attention hybride |
| Embeddings + LM head | 2,54 Md | Vocabulaire |
| Vision tower | 0,46 Md | Compréhension d'images |
| Total | 27,36 Md | Base Qwen3.8-27B |
Deux packings GGUF sont proposés, et le choix n'est pas anodin :
| Packing | Bits/poids | Taille | Point fort |
|---|---|---|---|
| PTQ1_0 | 1,75 | 5,95 Go | Trits denses ; prompt processing le plus rapide sur tous les backends |
| PQ2_0 | 2,13 | 7,21 Go | Slots 2-bit ; décode le plus rapide sur Ada/L4 et en mémoire tendue |
Pour fixer les ordres de grandeur : le point idéal annoncé est de 1,72 bpw, soit 5,8 Go — environ 9,3× de réduction face aux ~54 Go du FP16. Un modèle qui exigeait un serveur datacenter tient désormais, contexte modéré inclus, sur une carte à 8 Go. Ce n'est pas un progrès incrémental, c'est un changement de palier.
Qualité : 98,2 % du FP16 en 1,72 bit
Sur la moyenne des benchmarks de raisonnement (thinking), Bonsai 2 abandonne 1,5 point par rapport au FP16 — et creuse un fossé de 12 points avec la quantization 2-bit classique.
Les mesures publiées sur le dépôt (octobre 2026) :
| Quantization | Bits/poids | Score thinking (moyenne) | % du FP16 |
|---|---|---|---|
| Qwen3.8-27B FP16 (référence) | 16 | 86,32 | 100 % |
| UD-Q4_K_XL | 4 | 85,18 | 98,7 % |
| Bonsai 2 27B (ternaire natif) | 1,72 | 84,78 | 98,2 % |
| IQ2_XXS (quant 2-bit classique) | 2,16 | 72,59 | 84,1 % |
Le point clé de toute cette actualité tient en une ligne : un 2-bit ternaire natif est quasiment équivalent à un 4-bit UD, et très loin devant une quantization 2-bit post-hoc. Concrètement, l'écart entre 84,78 et 72,59 sépare un modèle utilisable au quotidien d'un modèle qui décroche dès que la tâche sort du trivial.
Précision de méthode : ces chiffres viennent de l'éditeur du modèle. Ils sont détaillés et reproductibles, mais gardez le réflexe habituel — testez sur vos propres cas d'usage. L'écart avec IQ2_XXS est toutefois trop large pour être un artefact de benchmark.
Ma lecture : la leçon n'est pas « le 2-bit est bon ». Elle est que toutes les quantizations ne se valent pas, et que les comparatifs qui mélangent quant native et quant subie sont trompeurs. Exigez le bit/poids ET la méthode.
PTQ1_0 ou PQ2_0 : le bon packing pour votre GPU
H100, A100 ou Blackwell → PTQ1_0. RTX Ada ou L4 → PQ2_0. Et pour avaler de longs prompts, PTQ1_0 gagne partout.
Le dépôt publie des mesures par architecture (octobre 2026) :
| Votre matériel | Packing recommandé | Pourquoi |
|---|---|---|
| H100 / A100 / Blackwell | PTQ1_0 | Décode le plus rapide |
| RTX Ada / L4 | PQ2_0 | Décode le plus rapide |
| Mémoire la plus serrée | PQ2_0 | Meilleur débit en décode, d'après les mesures du dépôt |
| Longs prompts | PTQ1_0 | Prompt processing le plus rapide partout |
Le cas particulier du prompt processing
Détail qui compte pour le RAG et l'analyse de documents longs : le prompt processing favorise PTQ1_0 sur tous les backends testés. Si votre charge de travail consiste à ingérer de gros contextes, restez donc sur PTQ1_0 même sur une carte Ada, où PQ2_0 l'emporte pourtant en décode.
Les backends couvrent CUDA, Metal et CPU — le CPU est supporté, avec des débits honnêtes mais sans miracle. Côté serving, un lancement type llama.cpp ressemble à ceci (avec le fork PrismML-Eng, pas le binaire stock) :
# fork PrismML-Eng requis — le llama.cpp stock refuse ces packings
llama-server -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -c 65536
Ajustez la taille de contexte selon votre VRAM : les 5,95 Go de poids tiennent dans 8 Go, mais le KV cache s'ajoute par-dessus — voir la section erreurs plus bas.
Sur Mac : la variante MLX, le KV cache 4-bit et le décodage spéculatif
Oui, ça tourne sur Apple Silicon, et la variante MLX officielle est la livraison la plus aboutie de la gamme.
La version MLX cible Python et Swift, avec un backend CUDA en supplément. Trois détails font la différence en pratique :
- KV cache 4-bit quasi lossless, appliqué aux couches en full attention (16 sur 64) : environ 4,3 Go au plein contexte de 262K. C'est ce chiffre qui rend le très long contexte crédible sur une machine personnelle.
- DSpark, drafter de décodage spéculatif (1,95 Go en Q4_1) : un petit modèle propose les tokens, le 27B les valide. Sur un décode ternaire déjà véloce, le gain composé est substantiel.
- Vision tower HQQ 4-bit optionnel (~0,63 Go) : le multimodal ne se paie que si vous en avez l'usage.
Faisons le budget sur un Mac 32 Go : poids (~7 Go), KV cache au plein 262K (~4,3 Go), drafter (1,95 Go), vision (0,63 Go) — tout tient avec de la marge pour le système et l'application. Le 262K multimodal complet n'est plus un exercice théorique.
On avait déjà vu Qwen3-Coder-Next tourner sur un Mac 64 Go et battre DeepSeek en coding. Bonsai 2 pousse la logique un cran plus bas en mémoire, et ajoute la vision au tableau.
La semaine où le 2-bit a envahi HuggingFace
Cette semaine, la compression extrême n'est plus une niche — c'est la tendance dominante des téléchargements.
Les chiffres compilés par agents-radar (octobre 2026) donnent la mesure du phénomène :
- Ternary-Bonsai-2-27B : 4 M de téléchargements. Pour un format qui exige encore un fork spécifique de llama.cpp, c'est un vote de confiance massif de la communauté.
- ISTA-DASLab : quatre quantizations GSQ-RCO en une semaine. Un rythme de publication industriel, pas celui d'un hobbyiste isolé.
- Un GGUF uncensored : 1,6 M de downloads. Le segment « modèle local sans garde-fous » reste l'un des plus puissants moteurs de HuggingFace.
- Un miroir nesoai déjà en ligne. Quand un modèle est repris par des tiers dans les jours qui suivent sa sortie, la diffusion s'auto-entretient.
Ce que ces chiffres racontent, c'est un changement de posture. La communauté ne télécharge plus « le plus gros modèle qui passe », elle cherche « le meilleur modèle qui tient ». C'est un raisonnement d'ingénieur, et il structure désormais le classement.
Le mouvement est d'ailleurs cohérent des deux bouts de la chaîne. En amont, DeepSeek optimise la communication inter-GPU à l'échelle datacenter avec DeepEP, sa lib open source pour les modèles MoE. En aval, la compression extrême rapproche les modèles du GPU consumer. Même philosophie : moins de gaspillage, partout.
Pour ceux qui n'ont pas de GPU du tout, la porte d'entrée reste le cloud — notre guide sur utiliser des modèles gratuits sans sacrifier la qualité couvre OpenRouter et Groq. Les mastodontes ouverts comme DeepSeek V4 Pro (Max) (88 sur notre index) ou Kimi K2.6 (85) restent l'affaire du datacenter. Mais pour du local, la classe 27B quantée en natif devient difficile à battre — et la frénésie ne se limite pas aux quantizations, avec des modèles frugaux comme Naive N05 Flash qui confirment que l'efficacité est devenue le critère numéro un.
Ce qu'on perd réellement — et ce qu'on ne perd pas
On perd 1,5 point de score thinking, un peu de finesse en vision, et la compatibilité avec l'outillage stock. On ne perd pas l'usage.
Le mesurable. 86,32 → 84,78 sur la moyenne thinking : −1,5 point face au FP16, −0,4 face au 4-bit UD. En usage courant — rédaction, code, analyse de documents — c'est sous le seuil de perception. Sur des tâches de raisonnement en limite du modèle, ça peut se voir, et il faut l'assumer.
La vision. Le vision tower pèse 0,46 Md de paramètres : un module compact, pas un géant multimodal. Pour de l'OCR, du captioning, de l'analyse d'interface, l'essentiel est là. Pour de la compréhension visuelle fine — diagrammes denses, scènes complexes — calibrez vos attentes en conséquence.
L'architecture hybride. 75 % de l'attention est linéaire : c'est ce qui rend le 262K abordable, mais c'est un compromis assumé sur la restitution exacte d'informations très éloignées dans le contexte. Pour du RAG bien découpé, aucun problème. Pour retrouver une phrase précise noyée à 200 000 tokens, testez avant de promettre.
L'écosystème. Pas d'Ollama ni de LM Studio natifs pour ces packings, pas de llama.cpp stock : tant que les kernels ternaires ne sont pas remontés upstream, vous dépendez du fork PrismML-Eng. Historiquement, ce type de patch finit fusionné. Mais « historiquement » n'est pas une date, et en attendant, votre stack doit le savoir.
En face, le gain est net : 9,3× de compression, un 262K réaliste, la multimodalité incluse, une licence Apache 2.0 qui autorise tout — y compris le commercial. Le rapport coût/possibilités bascule clairement du côté de l'utilisateur.
❌ Erreurs courantes
Erreur 1 : charger PTQ1_0/PQ2_0 avec le llama.cpp stock
Le llama.cpp officiel rejette ces formats — et le cas piégeux est pire : il peut charger un PQ2_0 en le traitant comme du Q2_0 classique, produisant du garbage sans avertissement clair. Solution : le fork PrismML-Eng, ou la variante MLX sur Mac. Et vérifiez toujours la première réponse du modèle sur un prompt de contrôle avant toute conclusion.
Erreur 2 : comparer un 2-bit natif à une quantization 2-bit classique
84,78 contre 72,59 : l'écart dit tout. Quand on vous affirme que « le 2-bit détruit la qualité », on parle généralement de quant post-hoc sans rotations de Hadamard ni échelles par groupe. La bonne comparaison est famille contre famille — sinon le débat est biaisé avant même de commencer.
Erreur 3 : oublier le KV cache dans le budget VRAM
5,95 Go de poids ne signifient pas « ça tient dans 6 Go ». Au plein contexte 262K, le cache full-attention (16 couches sur 64, KV 4-bit) ajoute environ 4,3 Go, auxquels s'ajoutent drafter et vision tower si vous les chargez. Sur une carte 8 Go : contexte court à modéré, ou offload partiel — et là, le débit s'effondre. Calculez le budget complet avant de fixer la taille de contexte.
❓ Questions fréquentes
Quelle carte graphique faut-il pour Ternary-Bonsai-2-27B ?
Une carte 8 Go suffit en PTQ1_0 (5,95 Go de poids) avec un contexte modéré. Pour le plein 262K, ajoutez le KV cache (~4,3 Go) ou passez sur un Mac 32 Go. Les backends CUDA, Metal et CPU sont supportés, licence Apache 2.0.
Le 2-bit ternaire dégrade-t-il vraiment la qualité ?
Non, pas de façon perceptible : 84,78 contre 86,32 en FP16 sur la moyenne thinking, soit 98,2 %. C'est quasiment le niveau d'un 4-bit UD (98,7 %) et très loin devant une quant 2-bit classique (84,1 %). La perte se mesure, elle ne se voit presque pas en usage réel.
Est-ce que ça tourne sur Mac ?
Oui, via la variante MLX officielle (Python/Swift, backend CUDA inclus). KV cache 4-bit quasi lossless, drafter DSpark de 1,95 Go pour le décodage spéculatif, vision tower HQQ optionnel à 0,63 Go. Un Mac 32 Go tient l'ensemble, y compris le contexte 262K au complet.
Compatible avec Ollama ou LM Studio ?
Pas encore pour les packings PTQ1_0/PQ2_0 : le llama.cpp stock les refuse, et peut charger un PQ2_0 comme du Q2_0 en produisant du garbage. Il faut le fork PrismML-Eng. La remontée upstream et l'adoption par les front-ends grand public ne devraient pas tarder, mais rien n'est daté.
Combien coûte l'ensemble ?
0 € côté logiciel : poids Apache 2.0 sur HuggingFace, kernels open source dans le fork. Le coût réel, c'est le hardware — une carte 8 Go ou un Mac 32 Go — et l'électricité. Pour exposer le modèle derrière une interface en ligne, un hébergement dès ~3 €/mois (octobre 2026, Hostinger) suffit.
Je n'ai pas de GPU, quelle alternative ?
Trois options : le backend CPU du fork (utilisable, mais lent), un Mac Apple Silicon en mémoire unifiée, ou le cloud gratuit via OpenRouter et Groq — notre guide détaille les réglages pour ne pas sacrifier la qualité. La classe 27B en 2-bit rend aussi le CPU moins ridicule pour de l'inférence occasionnelle.
✅ Conclusion
En une semaine, le 2-bit est passé de curiosité technique à standard pratique : 98,2 % de la qualité FP16 dans 5,95 Go, c'est le nouveau rapport performance/encombrement à battre. Récupérez les GGUF sur HuggingFace, installez le fork PrismML-Eng — et pour voir où mène la compression extrême, notre dossier sur les LLM 1-bit trace la suite.