Ternary Bonsai 2 27B : ce qui tient dans 5,9 Go, et ce que les 98,2 % ne vous disent pas

Ternary Bonsai 2 27B est un modèle de langage multimodal de 27,36 milliards de paramètres que Prism ML a annoncé le 17 septembre 2026, et ce qu'il faut comprendre à son sujet, c'est que ses poids de langage ne peuvent prendre que l'une de trois valeurs exactement. Son modèle de base est Qwen3.8 27B — un modèle à attention hybride de 27B — et Bonsai conserve cette architecture, cet entraînement et cette forme, et remplace les poids matriciels du modèle de langage par une représentation ternaire. Le fichier livré fait 5,93 Go. La référence en précision complète fait 53,81 Go. L'affirmation phare du fournisseur est qu'il conserve 98,2 % de la moyenne aux benchmarks de l'original.

Commencez par l'élément que la plupart des analyses passeront sous silence : ce 98,2 % est le chiffre de Prism ML lui-même, mesuré sur la propre suite de 20 benchmarks de Prism ML, avec le propre harnais de Prism ML, et personne en dehors de l'entreprise ne l'a reproduit. Ce n'est pas une accusation — c'est l'état normal des choses un jour après une sortie, et c'est exactement le statut que vous devriez lui attribuer. Ce que vous pouvez vérifier de manière indépendante aujourd'hui, c'est le fichier : l'API Hugging Face répertorie Ternary-Bonsai-2-27B-PTQ1_0.gguf à 5,947 Go contre la référence FP16 à 53,808 Go, soit une réduction de 9,05x, ce qui correspond au « environ 9x » du fournisseur sans avoir besoin de faire confiance à qui que ce soit. La taille est un fait. La rétention de qualité est une mesure du fournisseur. Le plus intéressant se situe entre les deux — la ventilation par catégorie, qui montre précisément où la compression est gratuite et où elle ne l'est pas.

Il y a aussi une seconde facette à cette publication. Le 18 septembre, un jour après l'annonce, OrcaRouter a publié une variante abliterated à l'exécution du même modèle — le OrcaRouter Ternary Bonsai 2 27B Uncensored — qui supprime une direction de refus apprise au moment de l'inférence et laisse les poids identiques bit à bit. Elle est traitée dans sa propre section ci-dessous, car la technique est la partie intéressante et parce que ses limites sont aussi instructives que ses résultats.

C'est un Qwen3.8 27B compressé, et non un modèle nouvellement entraîné.

Cette distinction est la différence entre expliquer la publication et répéter un communiqué de presse. Prism ML n'a pas entraîné un modèle 27B à partir de zéro et n'a pas suivi une nouvelle recette de pré-entraînement. Ce qu'elle a fait, c'est prendre Qwen3.8 27B et modifier la représentation numérique dans laquelle ses poids sont stockés et calculés.

L'architecture est inchangée, et c'est celle du modèle de base : une conception à attention hybride composée d'environ 75 % d'attention linéaire et 25 % d'attention complète, avec des blocs MLP SwiGLU, RoPE et RMSNorm. Ce squelette hybride est aussi la raison pour laquelle le contexte de 262K tokens est décrit comme capable de gérer le contexte complet plutôt que comme simplement pris en charge — une attention majoritairement linéaire est ce qui permet de garder un long contexte abordable sur un appareil. Le modèle est un modèle vision-langage : il accepte les images ainsi que le texte, et la tour de vision est la tour Qwen d'origine, non quantifiée, empaquetée séparément.

Ce que Prism ML a apporté, ce sont deux choses. La première est la représentation ternaire elle-même, plus l’entraînement conscient de la quantification qui la rend viable. La seconde, ce sont les kernels — des kernels bas bits personnalisés pour cette pile d’attention hybride sur Apple Silicon et CUDA, qui opèrent directement sur les poids empaquetés plutôt que de les déballer en FP16 et de les multiplier. Sans la seconde contribution, la première n’est qu’un format de stockage sans aucun moyen de l’exploiter à pleine vitesse.

Le propre livre blanc de Prism ML indique que la répartition des paramètres est la suivante : 24,35 B dans la colonne vertébrale linguistique sur 64 blocs, 2,54 B dans l’embedding et la tête LM, et 0,47 B dans la tour vision à 27 blocs, pour un total de 27,36 B. La tour vision est la seule partie qui constitue véritablement un artefact distinct : la version GGUF l’empaquette sous forme d’un fichier mmproj 4 bits d’environ 0,63 Go, chargé uniquement lorsqu’une image arrive réellement, de sorte que le service en mode texte seul ne l’embarque jamais.

Il s'agit du Bonsai de deuxième génération issu du même laboratoire ; le premier Bonsai 27B est arrivé en juillet 2026, environ deux mois plus tôt, et la comparaison entre les deux générations est une question légitime — que nous abordons dans le face-à-face avec Bonsai 27B plutôt que de la reproduire ici.

Que signifie « ternary g128 », concrètement ?

Si vous n'avez encore jamais rencontré de poids ternaires, c'est le paragraphe qui rend tout le reste lisible, alors le voici sans raccourci.

Un poids ordinaire dans un réseau de neurones est un nombre à virgule flottante de 16 bits — environ 65 536 valeurs distinguables sur une plage utile, chacune coûtant 16 bits à stocker. Un poids ternaire n'est pas un petit flottant. C'est un choix parmi trois symboles : −1, 0 ou +1. C'est tout le vocabulaire. Stockez un tel symbole naïvement et vous dépenseriez deux bits par poids, puisque deux bits vous donnent quatre états et vous n'en avez besoin que de trois.

En soi, ce serait une perte catastrophique d’expressivité, et c’est pourquoi le format n’est jamais simplement le symbole. Chaque groupe de 128 poids consécutifs partage un même facteur d’échelle FP16, et la valeur de poids réelle est le symbole ternaire multiplié par ce facteur d’échelle :

• w = ssub>g/sub> · t, où t ∈ {−1, 0, +1} et ssub>g/sub> est une échelle FP16 partagée pour le groupe de 128

Ainsi, le modèle représente toujours une large plage d’amplitudes — il les représente simplement par paliers grossiers, par groupe, plutôt que par poids individuels. Le 0 n’est pas un artefact d’arrondi ; c’est un véritable troisième état, et c’est son existence qui permet à un groupe de 128 poids de rester majoritairement silencieux quand il le faut.

La base après rotation est la partie qui surprend les gens. Avant que l'attribution ternaire n'ait lieu, chaque matrice de poids est transformée par blocs au moyen d'une rotation orthogonale — une matrice de Walsh–Hadamard combinée à une diagonale fixe de signes ±1, avec une taille de bloc de 1024 — et les valeurs ternaires sont choisies dans cet espace tourné. La rotation est intégrée aux poids stockés lors de la préparation, de sorte qu'elle ne coûte ni bits supplémentaires ni trafic de poids supplémentaire. À l'inférence, le runtime applique la transformation correspondante aux activations à la place, et le modèle empaqueté déclare sa rotation dans ses métadonnées, de sorte qu'un runtime soit applique la transformation correspondante, soit refuse de charger le fichier.

Pourquoi s'embêter ? Parce qu'une rotation de Hadamard répartit plus uniformément l'énergie d'une matrice de poids entre les coordonnées, ce qui rend la quantification ultérieure à trois niveaux bien moins dommageable qu'elle ne le serait sur la distribution brute, en pics. La rotation n'est pas un ornement ; c'est ce qui permet à un modèle ternaire de conserver ne serait-ce qu'une qualité proche de celle du parent. Le coût, c'est que la transformation se trouve sur le chemin critique de chaque projection avec une taille de lot de 1, ce qui est un vrai problème d'ingénierie — Prism ML fusionne l'inversion de signe dans le chemin de chargement de la transformation sur Metal et la parallélise sur un bloc de threads complet sur CUDA pour l'empêcher de dominer le décodage.

Les nombres, avec attention : 1,585 ; 1,71 ; 1,72 ; 1,76

Quatre chiffres de largeur de bits circulent autour de cette version, ils sont tous corrects et mesurent quatre choses différentes. Les confondre est l’erreur la plus facile à commettre sur ce sujet. Voici chacun d’eux et ce qu’il couvre réellement.

• 1,585 bits par poids — le contenu informationnel d’un symbole ternaire, log₂3. C’est une propriété du format, pas d’un fichier quel qu’il soit. Rien de ce qui est livré ne tourne à 1,585 bits/poids.

• 1,71 bit par poids — les tenseurs ternaires uniquement. Ajoutez l’échelle de groupe FP16 16 bits amortie sur 128 poids et vous obtenez log₂3 + 16/128 ≈ 1,71. Ce n’est toujours pas un chiffre livré ; il s’agit des tenseurs ternaires isolés.

• 1,72 bit par poids — chaque paramètre du modèle de langage, y compris le petit ensemble maintenu au-dessus de la représentation à faible nombre de bits. Prism ML conserve 26 238 464 paramètres — 0,0976 % du modèle de langage, environ 52 Mo en bf16 — en précision supérieure, principalement le chemin d’état récurrent des couches d’attention linéaire ainsi que les poids de normalisation. Ces tenseurs ne subissent ni rotation ni quantification, et ce sont eux qui font passer le chiffre de 1,71 à 1,72. À 1,72, l’empreinte idéalisée est de 5,80 Go, soit une réduction d’environ 9,3x. Il s’agit de la ligne « True Ternary » de Prism ML, et c’est un objectif plutôt qu’un fichier que vous téléchargez.

• 1,76 bit par poids — le GGUF réellement distribué. Les kernels efficaces nécessitent un format d'empaquetage, et le PTQ1_0 de Prism ML emballe densément les trits, pour atteindre 1,76 bit/poids dans 5,93 Go, soit environ 9,1x. C'est le fichier qui se cache derrière à la fois le « 5,9 Go » et le « 9x plus petit » que cite l'annonce, et c'est celui que confirment les mesures ci-dessus.

Le deuxième empaquetage est PQ2_0, qui stocke chaque trit dans un emplacement de 2 bits plutôt que de manière dense. Il coûte plus d’espace pour un dépaquetage moins coûteux : 2,16 bits/poids dans 7,25 Go, environ 7,4x. Aucun des deux empaquetages n’est uniformément plus rapide — PTQ1_0 déplace environ 18 % de données de poids en moins par étape, mais paie en arithmétique pour dépaqueter les trits denses, donc il gagne sur les cartes de génération Ada et la L4 où la mémoire est la contrainte limitante, et perd sur Hopper, Blackwell et Apple silicon où le décodage par lot de taille 1 est plutôt limité par le débit d’instructions. Le traitement des prompts privilégie PQ2_0 partout, car il est limité par le calcul.

Deux notes pratiques à l’intention de quiconque vérifie ces éléments par rapport aux sources. Premièrement, les propres documents de Prism ML arrondissent légèrement différemment — le tableau de stockage du livre blanc donne PTQ1_0 à 1,76 bit/poids pour 5,93 Go, tandis que la fiche du modèle GGUF sur Hugging Face donne 1,75 et 5,95 Go, et le fichier mesuré fait 5,947 Go. Il s’agit du même fichier décrit à des précisions différentes, et non d’un désaccord sur le fond. Deuxièmement, la réduction annoncée de « plus de 9x » est celle du fournisseur ; mesurée par rapport aux fichiers réels, elle est de 53,808 / 5,947 = 9,05x, ce qui est cohérent.

Le tableau de référence : pas la moyenne, la forme

Le résultat phare est une moyenne de 83,9 contre 85,4 pour la référence Qwen3.8 27B FP16, soit 98,2 %. La moyenne est la partie la moins intéressante. La structure sous-jacente est là où se trouvent les véritables informations, et elle n’est pas uniforme.

• Suivi des instructions — 82,66 contre 81,25. C'est la seule catégorie où le modèle compressé surpasse son parent en pleine précision. Ce n'est pas du bruit que l'on peut écarter à la légère ; c'est une victoire dans une catégorie sur la propre suite du fournisseur.

• Maths — 96,57 contre 97,06, et codage — 81,58 contre 82,17. Les deux pratiquement au même niveau : un demi-point et six dixièmes de point sur les moyennes par catégorie. Pour un modèle à un neuvième de l'empreinte, voilà les résultats sur lesquels repose tout l'argumentaire de la technique.

• Connaissances et raisonnement — 83,95 contre 86,66. Une baisse de 2,7 points, et c’est là que réside une part significative des 1,8 points manquants sur la moyenne totale.

• Vision — 78,59 vs 81,64. Une baisse de 3,05 points, la plus forte perte d'une catégorie prise isolément. À noter que la tour de vision elle-même n'est pas la partie compressée ; c'est le modèle de langage qui lit ses sorties qui l'est.

• Appels agentiques et d'outils — 77,57 vs 79,74. La moyenne de la catégorie couvre τ 2-Bench à 80,22 et BFCL v3 à 74,92.

Des résultats individuels qu'il vaut la peine de connaître, car ils ne pointent pas tous dans la même direction. Sur Terminal-Bench 2.1, le modèle obtient 52,8 contre 69,7 pour la pleine précision — environ les trois quarts — et sur SWE-bench Verified, il obtient 60,8 contre 80,6, là encore environ les trois quarts. C'était la première fois que cette famille de modèles était évaluée sur Terminal-Bench, et Prism ML affirme clairement que les gains en ingénierie logicielle à long horizon promis dans la première version de Bonsai sont partiels, pas complets. À l'inverse : τ 2-Bench est passé à 80,2 depuis 73,6 dans la version précédente, BFCL v3 se maintient à 74,9, et AA-LCR se situe à 77,0, à un point de la pleine précision. AIME26 atteint 95,83 et LiveCodeBench 90,07.

Où lui faire confiance et où non. Faites confiance au profil en mathématiques, en programmation et en suivi d’instructions — ce sont les catégories où la technique fait manifestement ce qu’elle prétend, et elles sont mesurées sur le même harnais que la référence. Soyez prudent quant au travail agentique à long horizon : les deux benchmarks qui mettent réellement à l’épreuve l’ingénierie soutenue pilotée par des outils, Terminal-Bench 2.1 et SWE-bench Verified, montrent un écart sensiblement plus grand que ne le laisse entendre l’agrégat, et le fournisseur le dit plutôt que de le cacher. Et considérez l’ensemble du tableau comme la mesure d’un seul laboratoire sur un seul harnais jusqu’à ce que quelqu’un d’autre l’exécute. Cette mise en garde n’est pas une formalité ici — c’est la différence entre « ce modèle conserve 98,2 % » et « le fournisseur de ce modèle a mesuré 98,2 % sur une suite que le fournisseur a choisie ». Les deux sont vrais ; un seul est un fait concernant le modèle.

Pourquoi cela surpasse une version IQ2_XXS du même modèle de base

Cela mérite sa propre section plutôt qu’une simple ligne, car c’est tout l’argument en faveur de l’entraînement ternaire conscient de la quantification par rapport à la quantification post-entraînement.

La méthode classique pour rendre Qwen3.8 27B compact consiste à le quantifier après l’entraînement. Le point de comparaison du livre blanc est une version IQ2_XXS GGUF du même modèle de base :

• Ternary Bonsai 2 27B — 1,76 bit/poids, 5,93 Go, moyenne sur 20 benchmarks : 83,9

• Qwen3.8 27B IQ2_XXS — 2,2 bits/poids, 7,3 GB, moyenne sur 20 benchmarks 75,2

Le modèle compressé par l’entraînement est à la fois plus petit et meilleur. Il est 1,23 fois plus petit que la version conventionnelle à faible nombre de bits et obtient un score supérieur de 8,7 points. Cette combinaison n’est pas une curiosité d’arrondi ; c’est l’affirmation qu’une représentation choisie pendant l’entraînement vaut sensiblement plus que le même budget nominal de bits appliqué après coup.

L’aspect le plus instructif est comment la version conventionnelle échoue, car l’échec est sélectif et facile à ne pas remarquer. IQ2_XXS ne se dégrade pas uniformément. Il tient bon sur les connaissances superficielles — 85,79 sur MMLU-Redux — tout en s’effondrant sur les tâches qui exigent des chaînes de raisonnement soutenues : 78,6 sur AIME26, 70,05 sur LiveCodeBench, 65,45 sur GPQA Diamond. Bonsai 2 obtient 95,83, 90,07 et 85,76 sur ces trois mêmes épreuves. Un test de conversation informel trouverait la version IQ2_XXS parfaitement utilisable et ne révélerait jamais l’effondrement ; les dégâts se situent exactement là où le raisonnement long et la génération de code se produisent. Cette asymétrie explique pourquoi « ça semblait correct quand je l’ai essayé » ne constitue pas une preuve au sujet d’un modèle quantifié.

Prism ML compresse le même argument en un seul chiffre dérivé qu’il appelle densité d’intelligence — en gros, la capacité aux benchmarks par gigaoctet. Sur la suite de 20 benchmarks, il rapporte 0,444 par Go pour Bonsai 2, 0,276 pour la version IQ2_XXS et 0,051 pour FP16. La métrique est une construction propre au fournisseur et sa pondération est un choix de conception, pas une loi ; mais l’ordre qu’elle produit est le même que celui que produit le tableau brut, de sorte qu’elle ajoute de l’interprétation plutôt que des preuves.

Encore une note honnête sur la comparaison. La fiche de modèle GGUF de Prism ML rapporte une seconde évaluation, plus étroite — une suite de 14 benchmarks en mode réflexion — sur laquelle le même chiffre de rétention apparaît de nouveau à 84,78 contre 86,32, avec IQ2_XXS à 72,59. Que deux suites différentes aboutissent au même 98,2 % constitue une légère corroboration que l’affirmation agrégée n’est pas un artefact d’une seule sélection de benchmarks. Il s’agit toutefois du même laboratoire qui exécute les deux, sur le même harnais. Notre analyse plus complète de cette confrontation, y compris la question du format d’empaquetage, se trouve dans la comparaison avec les versions GGUF de Qwen3.8 27B.

Ce qu'il faut vraiment pour faire fonctionner

Les chiffres de débit, issus de la mesure standardisée tg128 du livre blanc à une taille de lot de 1, la tour de vision étant exclue :

• Apple M5 Max — 46,8 tok/s en décodage, 765 tok/s en traitement du prompt

• Apple M5 Pro — 27,7 tok/s en décodage ; une exécution séparée à fenêtre plus longue du pack PQ2_0 a mesuré 27,0 tok/s en régime soutenu, consommant 27,0 W sur le rail GPU et 32,8 W sur l'ensemble CPU et GPU

• Apple M4 Pro — 18,0 tok/s en décodage, avec un traitement du prompt à environ 125 tok/s devenant la contrainte limitante pour les contextes très longs

• NVIDIA RTX 5090 — 142,5 tok/s en décodage sur le pack PQ2_0 à 0,582 mWh par token

L'affirmation pratique de Prism ML n'est pas un ratio d'accélération mais une absence : la base de référence FP16 à 53,8 Go ne tient tout simplement pas sur un ordinateur portable de 16 Go, de sorte que l'énoncé pertinent est qu'un modèle de classe 27B tourne désormais de manière interactive sur du matériel du quotidien. Sur le M5 Pro, le décodage mesuré traite un flux d'environ 201 Go/s de poids, confirmant le profil dominé par la bande passante mémoire que la représentation à faible nombre de bits est conçue pour exploiter.

Puis les cas limites, qui comptent davantage que les chiffres de pointe.

Vous ne pouvez pas utiliser llama.cpp standard. Les noyaux d’attention hybrides ternaires se trouvent dans le fork llama.cpp propre à Prism ML. Le llama.cpp standard rejette les types PTQ1_0 et PQ2_0 comme inconnus et — plus dangereux encore — charge l’ancien format ternaire Q2_0 sans aucun avertissement et produit du charabia, car il n’a pas de runtime d’activation Hadamard. Si vous exécutez ce modèle sur un binaire qui n’applique pas la rotation correspondante, vous n’obtiendrez pas d’erreur ; vous obtiendrez un non-sens d’apparence fluide. C’est la façon la plus probable, et de loin, de perdre un après-midi sur cette version.

Le pack MLX n’a pas de chemin CUDA. La version MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) cible Apple Silicon, où elle dispose de kernels personnalisés pour la pile hybride dans les runtimes Python et Swift. Son matmul quantifié dispose de kernels Metal et CPU, mais d’aucune implémentation CUDA ; ainsi, sur une machine NVIDIA, ce pack précis ne bénéficie d’aucune accélération GPU. L’inférence sur CPU fonctionne, mais une passe avant de 27B sur CPU peut prendre plusieurs minutes — ce qui rend le chemin CPU Linux utile pour les tests d’implémentation et la reproductibilité, et inutile pour la mise en production.

Les deux packs sont un véritable compromis, pas un classement. Si vous êtes sur une carte de génération Ada ou une L4, ou que la mémoire est la contrainte limitante, PTQ1_0 est le choix à 5,93 Go. Si vous êtes sur Hopper, Blackwell ou une 5090, PQ2_0 vous achète de la vitesse de décodage pour 1,3 Go. Si vous êtes sur Apple silicon, notez que les chiffres du M5 Pro ci-dessus sont mesurés sur PQ2_0, qui est aussi le pack que la configuration de démonstration télécharge par défaut.

Une note sur la comptabilité propre au pack MLX, car c'est une source fréquente de confusion. Le conteneur MLX est un format affine 2 bits dont le bloc stocke à la fois une échelle FP16 et un biais FP16 pour chaque groupe de 128 poids. Les poids ternaires de Bonsai n'ont besoin que de l'échelle — les niveaux proviennent de la seule échelle — le biais est donc un poids mort, et le bloc coûte 36 octets par 128 poids au lieu de 34. Cela porte le débit empaqueté du pack MLX à 2,250 bits/poids, et non à 1,72 ni à 1,76. Il s'agit d'un conteneur différent transportant les mêmes valeurs ternaires, et son fichier mesuré sur Hugging Face fait 8,005 GiB.

La variante abliterée au runtime

Le 18 septembre, OrcaRouter a publié l'OrcaRouter Ternary Bonsai 2 27B Uncensored, qui applique une ablation de la direction de refus à ce modèle entièrement à l'exécution. L'idée d'ingénierie mérite plus d'attention que le produit, alors voici d'abord l'idée.

L’abliteration conventionnelle modifie les poids. Elle trouve une direction dans l’espace des activations qui correspond au comportement de refus, puis orthogonalise par rapport à celle-ci les matrices de poids qui écrivent dans le flux résiduel : W ← W − r(rᵀW). Sur un modèle FP16 ordinaire, cela ne pose aucun problème — la matrice modifiée reste une matrice dense à virgule flottante, donc vous l’enregistrez et passez à la suite. Sur un pack ternaire, c’est une impasse, et c’est précisément une impasse pour la raison même pour laquelle ce modèle tout entier existe. Orthogonaliser une matrice ternaire produit une matrice dense en pleine précision. Pour la stocker à nouveau dans le pack ternaire, vous devriez re-quantifier — et re-quantifier des poids modifiés ne reproduit pas l’entraînement tenant compte de la quantification qui a produit l’original. Vous jetteriez exactement ce qui a été acheté.

Ainsi, la projection se déplace plutôt vers le moment de l’inférence. Plutôt que de modifier W, modifiez sa sortie :

• y ← y − α · dot(y, r) · r, calculé en float32, où y est une contribution résiduelle et r est la direction de refus normalisée

À α = 1, la composante de chaque écriture résiduelle parallèle à la direction de refus est supprimée. À α = 0, le modèle est inchangé. Un α supérieur à 1 sur-projette et peut dégrader la qualité. Comme α est un paramètre d'exécution plutôt qu'une propriété de checkpoint, le même pack peut être testé A/B contre lui-même dans le même processus — ce qui est précisément ce que font les évaluations d'OrcaRouter. Le pack Bonsai original reste bit à bit identique : zéro poids modifié, zéro re-quantification, zéro erreur de quantification de poids supplémentaire.

C'est sur deux détails d'implémentation qu'une version naïve de ceci échoue.

129 sites d'intervention, pas 16. Chaque module capable d'écrire dans le flux résiduel doit être enveloppé, et dans cette architecture hybride, cela représente 64 blocs mlp.down_proj, 48 couches linear_attn.out_proj, 16 couches self_attn.o_proj, et model.embed_tokens — 129 au total. N'envelopper que self_attn.o_proj est l'erreur évidente : cela n'en couvre que 16, laissant les 113 autres écritures non projetées. Un script d'auto-vérification mesure si la composante restante le long de la direction de refus est ramenée à environ 1e-6 de la norme résiduelle, et avertit s'il ne détecte pas les 129 sites.

Ne faites pas subir une nouvelle rotation à la direction. Le pack ternaire conserve ses projections dans une base tournée sur leur entrée dimension et compense du côté des activations. La projection de refus opère sur les sorties de ces projections, qui sont déjà revenues dans la base cachée normale — ainsi la direction de refus est un vecteur ordinaire à 5120 dimensions et lui appliquer une rotation de Hadamard supplémentaire reviendrait à projeter contre une base entièrement erronée.

Ce qu'OrcaRouter a mesuré — nos propres chiffres, pas des chiffres indépendants

Ce sont les propres mesures basées sur des règles d’OrcaRouter, et elles doivent être lues comme telles : un classifieur de phrases d’ouverture basé sur des règles, pas un juge LLM, réflexion désactivée, décodage glouton, budget de 64 tokens, avec base et ablated correspondant aux mêmes poids dans le même processus à α = 0 contre α = 1. Elles sont indicatives, pas de niveau publication, et elles ne constituent pas une vérification de quoi que ce soit que Prism ML ait affirmé.

Concernant le refus, mesuré comme la proportion de prompts ayant reçu un refus :

• AdvBench (n=100) — 99,0 % de base, 6,0 % après ablation, avec 56,0 % de réponses fournies mais accompagnées d’un avertissement

• JailbreakBench (n=100) — 96,0 % de base, 4,0 % avec ablation, 52,0 % avec réserves

• StrongREJECT (n=150) — 99,3 % de base, 3,3 % avec ablation, 45,3 % avec réserves

• HarmBench (n=150) — 98,7 % de base, 7,3 % avec ablation, 48,0 % avec mise en garde

• MaliciousInstruct (n=100) — 97,0 % de base, 0,0 % ablaté, 52,0 % avec réserves

• ForbiddenQuestions (n=150) — 75,3 % base, 5,3 % ablaté, 42,7 % avec réserves

• SimpleSafetyTests (n=50) — 96,0 % base, 18,0 % ablated, 60,0 % caveated — et ce chiffre est sous-estimé. Cet ensemble est majoritairement composé de prompts d'automutilation, et le modèle y répond par une ouverture de redirection vers les services de crise commençant par « I am deeply sorry to hear… », que la liste de phrases exactes du classifieur ne détecte pas et qu'il comptabilise comme une conformité. Le taux de refus résiduel réel sur cet ensemble est supérieur à 18,0 %. Le classifieur a été délibérément laissé tel quel afin que les chiffres restent comparables avec les autres fiches de modèle d'OrcaRouter.

Aucune réponse dans aucun ensemble n'a épuisé son budget de tokens, donc aucun de ces taux n'est gonflé par la troncature. Sur les prompts bénins, la même projection élimine aussi le refus excessif : XSTest-safe est passé de 5,2 % de refus à 0,4 %, et le sous-ensemble bénin de JailbreakBench de 25,0 % à 0,0 %. Le pack publié refuse un quart des prompts bénins de ce benchmark ; après ablation, il n'en refuse aucun.

En termes de capacités, le fait que les poids soient identiques bit à bit signifie qu’il n’y a pas de requantification à payer, et les mesures sont cohérentes avec cela :

• MMLU (n=300) — 76,7 % base, 77,7 % après ablation, +1,0

• GSM8K (n=150) — 87,3 % de base, 86,0 % après ablation, −1,3

• CMMLU (n=500) — 76,2 % de base, 75,6 % avec ablation, −0,6

Chaque variation se situe dans le bruit pour ces tailles d'échantillon ; une seule question GSM8K vaut 0,7 point. MMLU-Pro est exclu plutôt que rapporté : son invite demande un raisonnement avant la réponse, et 63–64 % des réponses des deux côtés n'avaient pas atteint de raisonnement dans le budget de tokens, de sorte que tout chiffre d'exactitude serait un plancher fixé par le budget plutôt qu'une mesure.

La mise en garde qui compte le plus

La direction de refus a été estimée à partir du modèle de base BF16 à partir duquel le pack Bonsai a été entraîné. L’architecture et la base cachée sont identiques, donc la géométrie s’aligne. Mais la mesure dans laquelle cette direction survit à l’entraînement tenant compte de la quantification n’a pas été pleinement mesurée.

Le runtime peut prouver, mathématiquement et à environ 1e-6 près, qu'il supprime la direction fournie de chaque écriture résiduelle. Il ne peut pas prouver, à partir de cela seul, que la direction capture encore la même caractéristique comportementale dans le modèle quantifié qu'elle capturait dans le modèle dense. Ce sont là des affirmations différentes, et seule la première est établie. Quiconque lit le tableau de sécurité ci-dessus doit le lire en sachant que l'intervention est exactement aussi efficace que l'hypothèse de transfert de direction, et que cette hypothèse est la question ouverte.

Il y a aussi le cadrage pratique qu’OrcaRouter applique à la release elle-même, qu’il vaut la peine de répéter plutôt que de l’évacuer par une paraphrase : supprimer une direction de refus apprise peut amener un modèle à répondre à des requêtes que le modèle d’origine aurait refusées. Il s’agit d’un mécanisme de recherche et de contrôle de l’inférence, et non d’une preuve que les sorties qui en résultent sont sûres, correctes ou appropriées, et les déploiements qui l’utilisent devraient appliquer leurs propres contrôles d’accès et mesures d’application des politiques. Supprimer les refus n’est pas une amélioration sans contrepartie, et cet article n’est pas écrit comme si c’en était une.

Trois notes pratiques supplémentaires pour quiconque cherche à le reproduire. Le pack doit être chargé avec son propre runtime intégré — un chargeur MLX ordinaire peut sembler le charger correctement tout en calculant silencieusement des résultats erronés ; donc si les sorties semblent fausses avant même que l'ablation ne soit activée, vérifiez d'abord le chemin de chargement. L'ablation sélective par couche est prise en charge, l'intervention n'a donc pas à être tout ou rien. Et l'évaluation de l'ablation a été exécutée sur l'expansion FP16 dépliée du pack plutôt que sur le pack pilotant ses propres kernels, car le matmul quantifié empaqueté n'a pas d'implémentation CUDA et le backend CPU nécessite plusieurs minutes par passe avant ; cette expansion porte exactement les valeurs ternaires du pack et reproduit les distributions de token suivant du pack à trois décimales près lors de vérifications ponctuelles, mais il s'agit d'un changement de conteneur, et cela vaut la peine de le savoir. Le code et les tableaux complets se trouvent dans le dépôt OrcaRouter Ternary Bonsai 2 27B Uncensored. Une comparaison distincte portant sur la version MLX ablée par rapport au chemin MLX Qwen3.8 27B non modifié approfondit les spécificités du runtime.

Où cela mène, et ce qui reste encore à prouver

Ce qu’un modèle 27B quasi sans perte en environ six gigaoctets change pour les agents locaux tient surtout à ce qui devient résident. Un modèle de langage qui tient, avec une véritable fenêtre de contexte, sur un ordinateur portable de 16 Go peut rester chargé pendant qu’un agent effectue d’autre travail — lire des fichiers, appeler des outils, maintenir un plan au fil des tours — au lieu d’être échangé à chaque requête ou poussé vers un serveur. C’est la différence entre un modèle local que l’on essaie et un modèle local que l’on laisse tourner, et c’est la propriété précise que les chiffres agentiques, τ 2-Bench à 80,2 et BFCL v3 à 74,9, sont là pour étayer.

Ce qui n'est pas prouvé constitue une liste plus longue que ne le laisse entendre l'annonce.

Aucune reproduction indépendante. Chaque chiffre de qualité de cet article — le 83,9, le 98,2 %, les moyennes par catégorie — est une mesure effectuée par Prism ML sur sa propre suite. Ce n’est pas un défaut de la sortie ; c’est simplement à quoi ressemble une version qui n’a qu’un jour. C’est aussi la première chose qui changera.

• Le travail agentique à long horizon est la partie la plus faible du propre tableau du fournisseur, et non la plus forte. Terminal-Bench 2.1 à 52,8 contre 69,7 représente un écart réel, et le fournisseur indique que la capacité est partielle.

• Prompts que vous n’avez pas essayés. Le profil de défaillance des modèles à faible nombre de bits est sélectif, et l’effondrement d’IQ2_XXS sur AIME26 et LiveCodeBench tout en conservant 85,79 sur MMLU-Redux est la preuve la plus claire disponible qu’une moyenne de benchmarks ne vous dit pas ce qui se passe sur votre charge de travail. Bonsai 2 ne montre pas cet effondrement sur ces deux benchmarks, ce qui est encourageant et ne constitue pas une garantie.

• La question du transfert de direction dans la variante abliterated, ci-dessus, qui est insoluble par construction.

• Savoir si les kernels tiennent le coup à mesure que les runtimes évoluent. Pour l’instant, ce modèle a besoin d’un fork ; la version standard de llama.cpp rejette deux des trois formats et corrompt silencieusement le troisième. Tant que ces kernels n’auront pas été intégrés en amont, « fonctionne partout où llama.cpp fonctionne » n’est pas encore vrai pour ce modèle.

La sortie elle-même n'est pas remise en question. Un modèle multimodal de classe 27B à 5,93 Go, soit un neuvième de l'empreinte de ce dont il a été compressé, avec des performances en mathématiques et en codage au niveau du parent et un suivi des instructions légèrement en avance, constitue un point de fonctionnement réellement différent pour l'inférence locale. La posture raisonnable, le 18 septembre 2026, consiste à tenir la taille du fichier pour un fait, à considérer le chiffre de rétention comme une affirmation prudente du fournisseur émise il y a un jour sur une suite qu'il a choisie, et à réserver votre jugement sur votre propre charge de travail jusqu'à ce que vous l'ayez exécuté sur celle-ci.

Le code d'ablation à l'exécution, la direction de refus et les tableaux d'évaluation complets sont publiés par OrcaRouter, aux côtés de la plateforme de routage que l'équipe développe.