--- type: "BlogPosting" title: "Ternary Bonsai 2 : 27B sous 6 Go — le premier modèle navigateur pour le quotidien 16 Go" description: "Ternary Bonsai 2 réduit Qwen3.8-27B à 5,95 Go — 98,2 % de la qualité. Ce que cela change pour les setups 16 et 8 Go, avec notre mesure cluster." resource: "https://www.contextstudios.ai/fr/blog/ternary-bonsai-2-27b-browser-16gb-fr" language: "fr" tags: ["Local AI", "Open Weights", "Quantization", "LLM"] generated: by: "process:contextstudios-md/1" at: "2026-10-23T04:02:04.384Z" status: "stable" --- # Ternary Bonsai 2 : 27B sous 6 Go — le premier modèle navigateur pour le quotidien 16 Go Published: 2026-10-20 Tags: Local AI, Open Weights, Quantization, LLM ![Ternary Bonsai 2 : 27B sous 6 Go — le premier modèle navigateur pour le quotidien 16 Go](https://wary-platypus-754.convex.cloud/api/storage/1e4c138c-4860-40d4-b2e4-c462f706f0db) Ternary Bonsai 2 réduit Qwen3.8-27B d'environ 54 Go à 5,95 Go — en conservant 98,2 % du score benchmark du modèle FP16. Pour la première fois, un modèle de raisonnement 27B complet tient dans la RAM restante d'une machine classique de 16 Go et, selon la démo de Prism ML, tourne même dans le navigateur via WebGPU. Nous avons confronté ces chiffres d'emprise mémoire à notre propre mesure sur cluster et à la pile 16 Go. **TL;DR :** les poids ternaires ({−1, 0, +1} plus une échelle FP16) compressent Qwen3.8-27B à 5,95 Go au lieu de 53,8 Go — 9,2× plus petit avec 84,78 points sur 86,32. Sur un Mac Studio M4 Max, le modèle décode à 10,6 tok/s en usage courant (34,5 tok/s en pointe, limité par la bande mémoire) ; sur RTX 3090, Qwen3.8-27B en Q4 reste à 39,7 tok/s. La contrepartie : il faut le fork Prism ML de llama.cpp, le chemin WebGPU est une démo et non un produit — et l'avantage de vitesse des poids plus petits est en partie repris par le dépacking ternaire lent au prefill. ## Ce que sont réellement les poids ternaires Au lieu de stocker chaque poids en flottant 16 bits, le format ternaire g128 n'autorise que trois valeurs : −1, 0 et +1. Par groupe de 128 poids, il existe exactement un facteur d'échelle FP16 partagé. Une valeur ternaire transporte log₂3 ≈ 1,585 bit d'information ; avec le facteur d'échelle amorti, le format se situe en pratique à 1,72 bit par poids — une réduction idéalisée de 9,3× par rapport aux 16 bits du FP16. Trois détails séparent le marketing de la pratique : - **Ternaire de bout en bout :** embeddings, projections d'attention, projections MLP et tête LM sont tous dans le même format. Pas de sortie de secours FP16 cachée — les 26,2 M de paramètres au-dessus du ternaire (chemin d'état récurrent de l'attention linéaire plus normalisations) sont déclarés et inclus dans le calcul à 1,72 bit. - **Rotation de Hadamard intégrée :** avant l'affectation ternaire, chaque matrice est tournée par blocs via une transformation orthogonale ; la rotation est pliée dans les poids hors ligne et ne coûte ni bits ni bande de lecture supplémentaire. - **Packed, pas expansé :** les variantes GGUF PTQ1_0 (1,75 bit/poids, 5,95 Go) et PQ2_0 (2,13 bit/poids, 7,21 Go) sont consommées directement — les poids ne sont jamais réexpandus en FP16 à l'exécution. ## L'emprise mémoire en comparaison | Variante | Taille | Moyenne benchmark (14 tests) | Densité d'intelligence | |---|---|---|---| | Qwen3.8-27B FP16 | 54,66 Go | 86,32 | 0,053 | | Qwen3.8-27B UD-Q4_K_XL | 17,56 Go | 85,18 | 0,157 | | Qwen3.8-27B IQ2_XXS | 7,27 Go | 72,59 | 0,257 | | **Bonsai 2 27B (PTQ1_0)** | **5,95 Go** | **84,78** | **0,457** | | Ternary Bonsai 27B (précédent) | 5,75 Go | 80,98 | 0,416 | Ce tableau vient tel quel de la model card officielle [^1]. La colonne intéressante est celle de droite : Prism ML divise la capacité par la taille déployée. Bonsai 2 atteint 0,457 — presque le double de la densité d'IQ2_XXS (0,257) à taille similaire, et bien plus que le Q4 (0,157). La comparaison avec IQ2_XXS est la vraie histoire : la quantification 2 bits classique s'effondre à 72,59 points, la représentation ternaire tient 84,78 — avec 82 % de l'emprise de la build IQ2. [^1] : prism-ml/Ternary-Bonsai-2-27B-gguf, model card Hugging Face, consultée le 20.10.2026. ## Notre mesure : 37,6 tok/s sur le cluster DGX Spark Pour ancrer les chiffres de Bonsai, notre propre point de référence issu de la production — le même backbone Qwen3.8-27B en NVFP4 sur vLLM : | Métrique | Valeur | |---|---| | Modèle | qwen3.8-flash-next-nvfp4 (vLLM) | | Décode, 1 flux (médiane) | 37,6 tok/s | | Time to first token (médiane) | 0,495 s | | Agrégat à 8 flux parallèles | 64,3 tok/s | | Tokens de sortie max. par requête | 256 | Source : notre propre exécution contre http://127.0.0.1:8212 (vLLM compatible OpenAI), mesurée le 20.10.2026 à 16:04 CEST. Le endpoint sert aussi les crons de production ; ce sont des valeurs d'exploitation, pas de laboratoire. ## Ce que vaut Bonsai 2 sur du matériel grand public — et ce qui le ralentit Trois questions pratiques : est-ce que ça tient, à quelle vitesse, sous quelles conditions ? **Est-ce que ça tient.** 5,95 Go de modèle de langue plus le cache KV : à 32K de contexte avec KV q4_0, une exécution PTQ1_0 arrive à 7,1 Go selon les calculs de la communauté — territoire carte 8 Go, et confortable réalité 16 Go. Sur une RTX 2060 Super 8 Go, 16,8 tok/s à 32K ont été rapportés. Pour la classe 16 Go (RTX 4060 Ti 16G, SoC portables), il reste de la marge pour des contextes plus longs ou la vision mmproj (0,63 Go, Q8_0, chargée seulement pour l'entrée image). **La vitesse — deux faces.** Le décode est une pure affaire de bande passante : moins de bits par poids, moins d'octets déplacés par token. Prism ML annonce 47 tok/s sur un M5 Max (Metal) ; sur Mac Studio M4 Max (recette communautaire, PQ2_0), nous relevons **10,6 tok/s en usage courant et 34,5 tok/s en pointe** — la pointe dans les mêmes conditions que la nôtre (thinking off, temp 0). Fait notable : le fait que la pointe soit limitée par la bande sur Apple Silicon teste directement la thèse « moins de bits = plus de tokens par Go/s ». L'envers est dans la recette : le dépacking ternaire rend le prefill plus lent que les checkpoints 4-bit-affines (242 contre 274 tok/s sur le même GPU) — une partie de l'économie de lecture se paie au dépacking. **Les conditions.** Trois, et elles comptent : 1. **Pas de llama.cpp stock.** Les tensor types 142/143 (PTQ1_0/PQ2_0) ne sont pas fusionnés dans le mainline — Ollama et LM Studio ne chargent pas les fichiers aujourd'hui. Il faut le [fork Prism ML](https://github.com/PrismML-Eng/llama.cpp) avec les kernels ternaires dédiés à l'attention hybride. 2. **CUDA, Metal, CPU — pas de voie ROCm.** Setups AMD : attendre ou compiler le fork soi-même. 3. **Défauts de raisonnement :** xhigh actif ; medium raccourcit les réponses. low n'est pas pris en charge. ## La question 16 Go : navigateur, WebGPU et retour à la réalité Le [chemin démo WebGPU](https://x.com/xenovacom/status/2110825606254391577) (Xenova, 15.10.2026) charge les petites variantes de Bonsai 2 entièrement dans le navigateur — 2B jusqu'à 500 tok/s sur M4 Max, sans serveur. Pour la 27B, cela signifie : téléchargement comme un film, exécution dans un onglet. C'est l'angle européen de cette histoire : 16 Go de RAM sont la norme de fait des setups solo, et un raisonneur 27B qui tourne dans un onglet sans GPU dédié ni installation change la réponse par défaut à « ai-je besoin d'un GPU ? ». Le retour à la réalité se dit dans la même phrase : la démo WebGPU est un démonstrateur, pas un produit. Les backends testés sont llama.cpp (CUDA/Metal/CPU) et MLX. En production : figer le fork, budgéter le cache KV, charger la mmproj seulement à l'arrivée des images. La queue 2B/4B/9B de la famille est prête pour le navigateur ; la 27B est la frontière. ## Verdict : quand Bonsai 2, quand Q4 ? | Situation | Choix | |---|---| | 8 Go de VRAM, la 27B doit tenir | Bonsai 2 PTQ1_0 — la seule classe 27B qui tient avec le KV dans 8 Go | | 16 Go, quotidien + vision | Bonsai 2 + mmproj Q8_0 ; la classe Q4 tient aussi, avec moins de marge de contexte | | Tok/s max sur 3090, qualité | Qwen3.8-27B Q4_K_M/EXL3 — 39,7–42,8 tok/s, paths llama.cpp/vLLM établis, AA intelligence 33,7 | | Apple Silicon sans fork à maintenir | Qwen3.8-27B oQ4e/MLX — 53,3 tok/s (M4 Max, avec MTP), aucun kernel custom | | Produit navigateur | Bonsai 2 2B/4B/9B aujourd'hui ; 27B en démo | La AA intelligence de 33,7 concerne Qwen3.8-27B (Artificial Analysis Index v4.3.2, au 26.09.2026) ; en tant que modèle dérivé, Bonsai 2 n'a pas de valeur AA propre — la moyenne benchmark 84,78/86,32 de la model card est le meilleur proxy. ## Conclusion Ternary Bonsai 2 est la preuve la plus convaincante à ce jour que le sub-4-bit ne rime pas avec perte de qualité quand la représentation est appliquée avec constance. 84,78 points sur 86,32 au neuvième de l'emprise, c'est une classe à part. Le prix est la friction de l'écosystème : fork llama.cpp dédié, pas d'intégration Ollama/LM Studio, ROCm ouvert. Pour les classes 16 et 8 Go, ce n'est pas un défaut mais le ticket d'entrée — là, l'alternative restait « la 27B ne tient pas ». ## Sources - [Prism ML : Introducing Bonsai 2 27B](https://prismml.com/news/bonsai-2-27b) — annonce officielle avec empreinte et rétention - [Model card prism-ml/Ternary-Bonsai-2-27B-gguf](https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf) — représentation des poids, tableaux tailles/benchmark, formats de packing - [Docs Bonsai : introduction](https://docs.prismml.com/get-started/introduction) — gamme de modèles, tailles 1-bit/ternaires - [Fork PrismML-Eng/llama.cpp](https://github.com/PrismML-Eng/llama.cpp) — kernels custom requis (CUDA/Metal) - [PrismML-Eng/Bonsai-demo](https://github.com/PrismML-Eng/Bonsai-demo) — setups testés par backend, lien whitepaper - [Discussion ggml-org/llama.cpp #29263](https://github.com/ggml-org/llama.cpp/discussions/29263) — calculs VRAM de la communauté (run 8 Go, chiffres KV 32K) - [Weschera : Bonsai-2-27B-Mac](https://github.com/Weschera/Bonsai-2-27B-Mac) — mesures Mac Studio M4 Max (base de la recette du hub) - [Xenova sur X, 15.10.2026](https://x.com/xenovacom/status/2110825606254391577) — démo WebGPU, tok/s navigateur des petites variantes - Artificial Analysis Intelligence Index v4.3.2 (26.09.2026) — AA intelligence 33,7 pour Qwen3.8-27B - [16 Go suffisent : la table de mesure GGUF de Qwen3.8-27B](https://www.contextstudios.ai/de/blog/16-gb-sind-genug-die-qwen3-8-27b-gguf-mess-tabelle-11-8-gb-40-tok-s) — notre référence 16 Go - [RTX 3090 d'occasion pour LLM locaux](https://www.contextstudios.ai/de/blog/gebrauchte-rtx-3090-lokale-llms-tok-s-kosten-contre-dgx-spark) — référence 3090 Q4 - [Hub Local AI : Bonsai-2-27B sur Mac](https://www.contextstudios.ai/de/lokale-ki/weschera--bonsai-2-27b-pq2_0-prism-llamacpp-mac-studio-m4-max) et [Qwen3.8-27B Mirai-S 16 Go sur 3090](https://www.contextstudios.ai/de/lokale-ki/alesha-pro--qwen38-27b-mirai-s-mtp3-16gb-1x3090) — nos lignes avec sources ## FAQ **Ternary Bonsai 2 27B fonctionne-t-il avec Ollama ou LM Studio ?** Pas avec les versions stock. Les fichiers GGUF utilisent les tensor types 142 et 143 (PTQ1_0/PQ2_0) pas encore fusionnés dans le mainline llama.cpp ; Ollama et LM Studio refusent donc ces fichiers. Il faut le fork Prism ML de llama.cpp avec les kernels ternaires dédiés. La model card et le dépôt démo restent les sources de référence pour l'installation. **Quelle RAM/VRAM faut-il réellement pour Bonsai 2 27B ?** Le modèle de langue occupe 5,95 Go (PTQ1_0) ou 7,21 Go (PQ2_0). S'ajoute le cache KV : à 32K de contexte avec KV q4_0, une exécution complète arrive à environ 7,1 Go selon les calculs communautaires, 7,6 Go en KV q8_0. Une carte 8 Go suffit donc pour 32K de contexte ; à 16 Go il reste de la marge pour des contextes plus longs ou la vision mmproj de 0,63 Go. **Quelle vitesse en usage courant ?** Cela dépend fortement du matériel et du packing. Sur Mac Studio M4 Max (PQ2_0), nous mesurons 10,6 tok/s en usage courant et 34,5 en pointe thinking désactivé ; Prism ML annonce 47 tok/s sur M5 Max. Chez NVIDIA, PQ2_0 gagne sur H100/A100/Blackwell, PTQ1_0 sur les cartes Ada — le choix du packing est lui-même une décision de performance. Le prefill est plus lent qu'en 4-bit car le dépackage ternaire coûte du temps. **Garde-t-il vraiment 98 % de la qualité ?** Selon la model card, Bonsai 2 27B tient 84,78 points sur 86,32 en moyenne sur 14 benchmarks — 98,2 %. L'écart de 1,54 point est réparti de façon inégale : les maths à un demi-point, le coding à niveau, l'agentic tool calling à 74,92. À titre de comparaison, le classique IQ2_XXS plafonne à 72,59 points. Les 98 % valent pour la moyenne, pas pour chaque tâche. **Peut-on le faire tourner dans le navigateur ?** Les petites variantes (2B/4B/9B) tournent aujourd'hui dans le navigateur via WebGPU — la 2B atteint 500 tok/s sur M4 Max selon la démo de Xenova. La 27B existe en démo WebGPU, mais les chemins de production testés sont llama.cpp (CUDA/Metal/CPU) et MLX. Pour un usage navigateur de la 27B, budgétez les ~6 Go de téléchargement, la mémoire de l'onglet et le support WebGPU des GPU cibles. **Bonsai 2 vaut-il mieux que la quantification Q4 ?** À 16 Go et plus : oui, si vous cherchez une capacité 27B sur du petit matériel ou si la marge de contexte compte — la qualité dépasse mesurablement les builds IQ2 et frôle la Q4. Sur une carte 24 Go complète avec une stack llama.cpp/vLLM établie, la classe Q4 reste le choix confortable : même ligue AA (33,7), 39,7–42,8 tok/s, aucun fork à maintenir. La décision est budget matériel contre simplicité opérationnelle. ## Related - [Developpement LLM](https://www.contextstudios.ai/fr/developpement-llm.md) - [Developpement IA](https://www.contextstudios.ai/fr/developpement-ia.md) - [Integration LLM](https://www.contextstudios.ai/fr/integration-llm.md) - [Conseil en IA](https://www.contextstudios.ai/fr/conseil-ia.md)