Prism ML vient de sortir un modèle de classe 27B qui tient dans 3,9 Go. C'est la première fois qu'un modèle de cette taille rentre dans le budget mémoire d'un téléphone. Et c'est assez inhabituel pour que je prenne le temps de regarder comment c'est fait.
Bonsai 27B est un dérivé de Qwen3.6-27B dont les poids ont été réduits à un seul bit de signe. Prism ML annonce 89,5 % de la qualité du modèle d'origine sur 15 benchmarks en mode thinking, pour un septième de la taille.
Je préviens tout de suite : tous les chiffres qui suivent sont auto-reportés. Je n'ai rien testé moi-même. Je relaie, je décortique la méthode, et je garde mon avis tranché pour ce que j'aurai vérifié en vrai.
Ce que "1 bit" veut vraiment dire ici
Le format s'appelle binary g128. Chaque poids est un bit de signe : 0 vaut moins scale, 1 vaut plus scale. Chaque groupe de 128 poids partage un facteur d'échelle en FP16.
Le coût réel n'est donc pas de 1bit, mais de 1,125bit par poids (1bit, plus 16bits amortis sur 128). Soit une réduction idéale d'environ 14,2 fois par rapport au FP16.
Et le point vraiment important est là. C'est même le meilleur passage de la model card : le label correspond à la réalité mesurée.
Les builds low-bit conventionnels vous vendent une largeur de bits qu'ils ne tiennent pas. Je m'explique.
Un IQ2_XXS de Qwen3.6-27B, vendu comme du 2bits, pèse en pratique 2.8bits par poids pour 9.4Go.
Un "4 bits" Q4_K_XL est en réalité à 5.2bits pour 17.6Go.
La raison est toujours la même. Les couches sensibles (embeddings, LM head, certaines projections d'attention) sont laissées en précision plus haute.
Bonsai revendique une couverture binaire de bout en bout : embeddings, projections d'attention, projections MLP, LM head. Sans échappatoire haute précision.
Seule la tour vision reste en HQQ 4bits, dans un pack optionnel de 0.63Go chargé uniquement quand une image arrive.
Petit bémol honnête, signalé par Prism ML eux-mêmes :
le pack MLX pèse 5.13 Go, pas 3.9. MLX stocke un scale et un bias par groupe. Bonsai n'a besoin que d'un scale, donc l'encodage gaspille un FP16 par groupe et le taux effectif monte à 1.25bit par poids.
C'est une limite du format MLX, pas de la méthode. La version GGUF, elle, se déploie à son layout natif.
Binaire ou ternaire : pourquoi une troisième valeur change tout
Bonsai existe en deux versions : binaire à 3.9Go et ternaire à 5.9Go. Ce n'est pas un hasard de packaging. C'est le cœur d'un compromis, et il vaut la peine de comprendre le mécanisme derrière.
Commençons par la théorie de l'information brute.
Un poids binaire ne peut prendre que deux états, moins 1 ou plus 1. Il transporte donc 1 bit d'information (log2 de 2). Un poids ternaire en prend trois : moins 1, 0, plus 1. Soit environ 1.58bit (log2 de 3).
C'est très exactement de là que vient le fameux "1.58bit" de BitNet b1.58, le papier de Microsoft qui a popularisé l'approche en 2024. Le nom n'est pas un chiffre marketing. C'est le logarithme en base 2 de 3.
Mais réduire le ternaire à "plus de bits par valeur", c'est passer à côté de l'essentiel. Le vrai levier, c'est le zéro lui-même.
En binaire pur, chaque poids est forcé à plus ou moins scale. Y compris un poids réellement négligeable, qu'on pousse artificiellement à une valeur non nulle. On injecte donc de l'erreur à chaque poids qui aurait dû rester proche de zéro.
Or les distributions de poids d'un réseau de neurones sont centrées autour de zéro, avec une masse énorme de petites valeurs. Le ternaire peut dire "ce poids vaut exactement 0", c'est-à-dire créer de la sparsité. Il colle donc bien mieux à la réalité statistique du modèle.
Et c'est ça qui fait gagner les points de qualité, bien plus que le comptage de bits.
Le résultat se lit directement dans les chiffres de Bonsai :
| États | bpw réel | Taille | % FP16 | |
|---|---|---|---|---|
| Binaire (−1, +1) | 2 | 1.125 | 3.9 Go | 89.5 % |
| Ternaire (−1, 0, +1) | 3 | 1.71 | 5.9 Go | 94.6 % |
Le point à ne pas rater : ce n'est pas gratuit. La troisième valeur porte plus d'information, mais elle coûte aussi plus cher à stocker.
Un ternaire ne rentre pas proprement dans 1bit. Le packing efficace met 5 valeurs dans un octet (3 puissance 5 égale 243, donc inférieur à 256), soit 1.6bit par valeur. Et les scales FP16 par groupe montent le taux réel à 1.71.
On paie donc 2Go de plus pour gagner 5 points de qualité. C'est exactement le compromis que Prism ML assume : le binaire pour tenir dans le budget mémoire d'un téléphone, le ternaire dès que la cible est un laptop ou un GPU et que ces 2Go ne sont plus un obstacle.
L'effondrement sélectif, c'est ça le vrai sujet
C'est l'argument le plus intéressant du papier. Et celui qui devrait changer la façon dont on évalue les quantifications agressives.
Quand un modèle passe sous les 4bits avec les méthodes classiques, il ne se dégrade pas uniformément. Il continue à répondre correctement aux QCM de connaissances, tout en perdant sa capacité à tenir une chaîne de raisonnement.
Les chiffres sont éloquents. IQ2_XXS conserve 88.93 sur MMLU-Redux, un score qui donne l'illusion que tout va bien. Mais il tombe à 57.5 sur AIME26 et 56.4 sur LiveCodeBench.
Autrement dit : un test rapide en discutant avec le modèle ne détecte pas le problème. Vous ne le voyez qu'en production, sur les tâches longues.
Bonsai 1-bit tient précisément ces benchmarks-là : AIME26 à 87.08, maths à 91.66 de moyenne, code à 81,88. Avec un tiers du footprint d'IQ2_XXS. La moyenne globale ressort à 76.11 contre 85,07 en FP16.
| Variante | bpw réel | Taille | Moy. thinking | vs FP16 |
|---|---|---|---|---|
| Qwen3.6-27B FP16 | 16.0 | 54 Go | 85.07 | 100 % |
| Qwen3.6-27B Q4_K_XL | 5.2 | 17.6 Go | 84.99 | 99.9 % |
| Qwen3.6-27B IQ2_XXS | 2.8 | 9.4 Go | 72.73 | 85.5 % |
| Ternary Bonsai 27B | 1.71 | 5.9 Go | 80.49 | 94.6 % |
| Bonsai 27B 1-bit | 1.125 | 3.9 Go | 76.11 | 89.5 % |
Là où ça fait mal, en revanche, c'est ailleurs :
- instruction following : 65.74 contre 78.47
- agentique et tool calling : 66.03 contre 80.00, avec un τ²-Bench qui s'effondre de 82.90 à 61.34
- vision : 59.57 contre 72.61
Prism ML l'assume : le coding agentique multi-fichiers n'est pas la cible de cette release.
Les chiffres de débit
| Plateforme | TG128 (tok/s) | PP512 (tok/s) |
|---|---|---|
| Apple M5 Max (Metal) | 66.4 | 874 |
| Apple M5 Pro (Metal) | 44.2 | 421 |
| Apple M4 Pro (Metal) | 26.0 | 133 |
| iPhone 17 Pro Max (A19 Pro) | 11.0 | 111 |
| H100 (CUDA) | 104.8 | 2755 |
Sur téléphone, on est à 11 tok/s à froid, 10.8 tok/s en soutenu (limité thermiquement). Soit 672 tokens par 1% de batterie, environ 67 000 tokens sur une charge complète. C'est utilisable.
La ligne H100 mérite un commentaire. À batch 1, un GPU datacenter est limité par la latence de lancement de kernels, pas par la bande passante mémoire. Les variantes binaire et ternaire convergent donc (104,8 contre 98 tok/s) malgré un facteur 1,9 sur les octets lus par étape.
L'intérêt du 1-bit n'est donc pas la vitesse sur gros GPU. C'est le fait que le modèle existe sur des machines où il ne rentrait pas.
Et sur ce point, la comparaison en mémoire de pic est plus parlante que le débit.
Avec un contexte de 100K tokens et sans aucune compression du KV cache, le build 1-bit demande 11.6 à 12.2Go. Le Q4_K_XL classique en demande 25,6.
Avec le KV cache 4bits activé, le pic à 100K tombe à environ 6.8Go, et la fenêtre complète de 262K tient dans environ 9.4Go.
Le reste de la boîte à outils
Deux éléments valent d'être notés, au-delà de la quantification elle-même :
- Kernels 1-bit dédiés sur MLX (Python et Swift) et CUDA, forkés depuis les projets amont. Les poids packés sont consommés directement dans le GEMM, jamais réexpandus en tenseur FP16 dense. Sans ces kernels, le gain mémoire s'évapore à l'exécution.
- DSpark, une couche de speculative decoding entraînée contre la cible low-bit. Un drafter semi-autorégressif de six couches, conditionné sur les états cachés de cinq couches du modèle cible. Gain mesuré de 1.37 fois sur H100 (de 104.8 à 143.8 tok/s), avec une longueur acceptée τ d'environ 3.6. Sur Apple Silicon, la passe de vérification ne s'amortit pas à batch 1 : le drafter n'est pas activé par défaut.
Prism ML publie aussi une métrique maison, la densité d'intelligence :
D = -log2(1 - score/100) / taille_GB
Bonsai 1-bit sort à 0.530, contre 0.199 pour le meilleur build conventionnel et 0.051 pour le FP16. La formule est manifestement construite pour flatter le résultat. Mais l'ordre de grandeur du classement ne dépend pas beaucoup du choix de la fonction.
Ce qui est important
Quelques réserves d'usage :
- Tous les benchmarks sont auto-reportés. Le whitepaper est public sur GitHub, la licence est Apache 2.0, les kernels sont ouverts. C'est vérifiable, mais ça n'a pas encore été vérifié par des tiers.
- Le modèle vient de sortir : 23 téléchargements au moment où j'écris ces lignes. Aucun retour terrain.
- La version ternaire est probablement le bon choix si votre cible est un laptop ou un GPU. 5.9 Go, 94.6% du FP16, contre 89.5% pour le binaire. Les 2Go économisés ne se justifient que si vous visez réellement le téléphone.
- Le pack MLX à 5.13 Go annule une partie de l'argument sur Mac, tant que MLX ne supporte pas les formats scale-only.
Pourquoi ça compte, si les chiffres tiennent
Si les chiffres tiennent, l'implication dépasse largement « un modèle sur un téléphone ». Le vrai déplacement, c'est le passage du raisonnement de classe 27B sur du matériel banal : un MacBook, un GPU 24Go, un appareil hors ligne.
Le coût énergétique mesuré dit la même chose sous un autre angle : 0.275 mWh par token sur M5 Pro, contre 0.63 à 1.32 mWh par token sur GPU datacenter.
Et pour un dev qui construit des produits avec des LLM, il y a une leçon immédiate, indépendante de Bonsai. Arrêtez d'évaluer vos quantifications sur des QCM de connaissances.
MMLU ne détecte pas l'effondrement du raisonnement. Il vous faut des benchmarks à chaîne longue : AIME, LiveCodeBench, τ²-Bench. Sinon, vous validez un modèle qui échouera exactement là où vous comptiez sur lui.
Liens : Model card · Whitepaper et démos · Version ternaire · Version GGUF
