↓ Aller au contenu

Bonsai 2 27B dans Ollama : Qwen3.8 en ternaire

·1507 mots·8 mins
Cryptolab.re
Auteur
Cryptolab.re
Cryptolab est un blog personnel où je documente mes expérimentations techniques : infra, self-hosting, réseau, crypto et projets parfois inutiles, souvent instructifs.
Sommaire

Dans Ollama, Bonsai 2 27B occupe 12,3 Gio de VRAM contre 20,5 Gio pour Qwen3.8 27B en Q4_K_M, dans un relevé sur RTX 3090 avec 65 536 tokens de contexte alloué. Cela représente 8,2 Gio libérés, soit environ 40 % de mémoire GPU en moins. Ce modèle ternaire de PrismML, basé sur Qwen3.8 27B, est disponible dans la bibliothèque officielle d’Ollama, avec la vision, le raisonnement et les appels d’outils.

Face à Qwen3.8 : 8,2 Gio de VRAM libérés
#

La comparaison utile ici porte sur Qwen3.8 27B en Q4_K_M, la version 4 bits installée sur le serveur, et Bonsai 2 27B en Q2_0, le paquet ternaire proposé par Ollama. Le relevé local du 31 octobre 2026 utilise une RTX 3090 de 24 Gio et Ollama 0.40.13, avec 65 536 tokens de contexte alloué pour chaque modèle.

Relevé sur ce serveurQwen3.8 27B Q4_K_MBonsai 2 27B Q2_0
Paquet Ollama stocké sur disque17,74 Go8,26 Go
VRAM totale occupée après la requête20,51 Gio12,28 Gio
VRAM encore disponible sur les 24 Gio3,49 Gio11,72 Gio

L’économie de VRAM atteint donc 8,23 Gio, soit environ 40 %. La marge disponible sur cette carte passe de 3,5 à 11,7 Gio. C’est de la place pour les autres allocations du moteur, un contexte plus grand ou un autre usage du GPU. Les paquets stockés sur disque diminuent aussi de 53 % environ, en comptant leurs composants de vision respectifs.

La VRAM est la mémoire de la carte graphique. Elle est relevée ici avec nvidia-smi, après le même court prompt textuel, sans image et avec la prédiction spéculative désactivée. Les modèles sont chargés un à la fois, entièrement sur le GPU ; les trois relevés successifs donnent la même occupation pour chacun. Cette mesure décrit l’allocation après la requête, avec le contexte réservé, et ne mesure pas le pic mémoire pendant le traitement d’un long document. Les données brutes conservent les versions exactes des modèles et leurs moteurs respectifs.

Un débit de génération supérieur de 56 % dans ce test
#

Sur le même serveur, une comparaison de vitesse porte sur trois générations de 256 tokens par modèle, avec un prompt identique de 96 tokens et toujours 65 536 tokens de contexte alloué :

Médiane de trois essaisQwen3.8 27B Q4_K_MBonsai 2 27B Q2_0
Débit de génération42,92 tokens/s67,07 tokens/s
Durée de génération des 256 tokens5,96 s3,82 s

Bonsai 2 génère ici environ 56 % de tokens supplémentaires par seconde. Le temps consacré à ces 256 tokens diminue d’environ 36 %. Les débits restent proches entre répétitions : de 42,90 à 42,97 tokens/s pour Qwen3.8, et de 66,98 à 67,08 tokens/s pour Bonsai 2.

Chaque essai repart d’un modèle déchargé, puis préchargé avant la requête. Le débit est calculé à partir de eval_count et eval_duration, fournis par l’API Ollama, en excluant le chargement et le traitement du prompt. Le raisonnement et la prédiction spéculative sont désactivés pour les deux modèles. Ce chiffre mesure leur débit de génération dans cette configuration ; la durée complète d’une tâche dans Hermes ou OpenCode dépend aussi des tokens de raisonnement et des appels d’outils.

Un Qwen3.8 avec des poids ternaires
#

Présenté le 17 septembre 2026 par PrismML, Bonsai 2 27B conserve l’architecture de Qwen3.8 27B. La compression représente l’essentiel des poids du modèle de langage par trois valeurs, −1, 0 et +1, avec un facteur d’échelle FP16 partagé par groupe de 128 poids. Cette représentation concerne notamment les embeddings, les projections d’attention et les couches qui calculent la sortie.

La fiche technique décrit aussi une rotation de Hadamard appliquée aux matrices. Le moteur doit effectuer la transformation correspondante sur les activations pendant le calcul. La compatibilité dépend donc du support de ce modèle et de son format dans le moteur d’inférence.

Le gain annoncé par PrismML d’environ neuf fois porte sur les poids FP16, autour de 54 Go. La comparaison avec Qwen3.8 déjà quantifié en 4 bits, détaillée ci-dessus, donne l’écart concret dans cette installation Ollama : environ 40 % de VRAM et 53 % de stockage en moins.

Pourquoi Ollama télécharge 8,3 Go plutôt que 5,9 Go
#

Le chiffre de 5,9 Go mis en avant au lancement correspond au modèle de langage dans son empaquetage le plus compact. PrismML distribue plusieurs représentations des mêmes poids, avec des compromis de stockage et de calcul différents :

Format du modèle de langageTaille publiéeMoteur nécessaire
PTQ1_05,95 GoFork llama.cpp de PrismML
PQ2_07,21 GoFork llama.cpp de PrismML
Q2_07,63 Gollama.cpp amont avec le support de Bonsai 2

Ces tailles sont celles de la fiche officielle sur Hugging Face. Le composant de vision en Q8_0 ajoute environ 0,63 Go. L’ensemble correspond aux 8,3 Go affichés par Ollama pour bonsai-2:27b.

La documentation des formats de PrismML confirme la distinction : les fichiers PTQ1_0 et PQ2_0 nécessitent encore son fork, tandis que le fichier Q2_0 fonctionne avec un llama.cpp amont compatible. Récupérer un ancien GGUF au hasard n’est donc pas équivalent à télécharger le modèle de la bibliothèque Ollama.

Les « 98,2 % » méritent de regarder les tâches
#

Dans son annonce, PrismML rapporte 83,9 de moyenne contre 85,4 pour Qwen3.8 27B en FP16, soit 98,2 % du score de référence. Ce chiffre décrit une moyenne sur une sélection de benchmarks.

Le rapport technique, section 4, donne des résultats plus utiles pour qui veut brancher le modèle à un agent de développement :

Évaluation publiée par PrismMLQwen3.8 27B FP16Bonsai 2 27B
Moyenne de la suite de 20 benchmarks85,483,9
SWE-bench Verified80,660,8
Terminal-Bench 2.169,752,8

Les deux dernières évaluations sont présentées séparément de la moyenne de 20 benchmarks. Sur ces tâches longues d’agent logiciel, le modèle conserve environ les trois quarts du score de référence. L’écart compte pour un assistant chargé d’enchaîner des modifications, des commandes et des vérifications dans un dépôt.

Ces mesures proviennent de PrismML, avec une évaluation sous vLLM sur des GPU H100 en mode de raisonnement xhigh. Elles renseignent sur la qualité mesurée dans ce protocole. Pour choisir un modèle dans Hermes ou OpenCode, comparez aussi sa capacité à terminer vos tâches et à utiliser les outils correctement : une réponse rapide ne suffit pas si elle demande ensuite plusieurs reprises.

Le lancer avec Ollama
#

Le support du format Q2_0 a été ajouté à Ollama 0.40.6. La modification amont précise que la version 0.40.5 échouait à charger ces fichiers. Vérifiez la version du serveur qui exécutera le modèle :

ollama --version

Si le client affiche un avertissement de différence de version, mettre à jour uniquement la commande locale ne suffit pas : le service Ollama doit lui aussi utiliser le binaire récent. Une fois le serveur compatible et démarré, téléchargez le modèle puis ouvrez une conversation :

ollama pull bonsai-2:27b
ollama run bonsai-2:27b

Le téléchargement occupe environ 8,3 Go sur disque. Précisez bien :27b : au 31 octobre 2026, bonsai-2 sans taille sélectionne le 9B, comme l’indique la bibliothèque Ollama. Les poids sont publiés sous licence Apache 2.0.

Vérifier le contexte et le placement en mémoire
#

La fenêtre maximale annoncée est de 262 144 tokens. Elle ne correspond pas nécessairement au contexte alloué par Ollama. La documentation du contexte indique que celui-ci dépend notamment de la VRAM disponible et des réglages du serveur. Augmenter cette allocation augmente aussi la mémoire nécessaire à l’exécution.

Pendant que la conversation est ouverte, lancez dans un second terminal, sur le même serveur :

ollama ps

La colonne CONTEXT donne la taille du contexte alloué. PROCESSOR indique la répartition entre CPU et GPU : 100% GPU correspond à un chargement entièrement sur le GPU. Une répartition CPU/GPU permet de repérer un déport d’une partie du modèle vers la mémoire système.

Les poids, le contexte et les buffers de calcul doivent tenir dans le budget disponible. 8,3 Go téléchargés ne garantissent donc pas un fonctionnement entièrement en VRAM sur une carte de 8 Go. Commencez par observer l’allocation réelle, puis augmentez le contexte si les documents ou le dépôt à traiter le demandent.

Pour une machine sur laquelle Qwen3.8 27B tient difficilement en mémoire, Bonsai 2 offre une option intéressante sans changer de carte. La disponibilité dans Ollama rend surtout l’essai beaucoup plus simple : le modèle se sélectionne ensuite dans les clients déjà reliés à son API locale.

Sources
#

Articles connexes

Hermes Agent : veille technique auto-hébergée avec Matrix, FreshRSS et Firecrawl

Je suis tombé sur Hermes Agent début 2026, et il m’a fallu quelques semaines pour comprendre ce que le projet apportait par rapport aux autres frameworks d’agents. Le pitch officiel - “self-improving AI agent with a built-in learning loop” - ne rend pas bien service à ce que le logiciel fait concrètement. Après plusieurs mois d’utilisation quotidienne, voici ce que j’en retire.

opencode + Firecrawl : remplacer SearXNG pour l'IA locale

Dans mon setup opencode + Ollama sur RTX 3090, j’avais commencé avec SearXNG comme source web via MCP. Ça fonctionnait, mais ce n’était pas exactement le bon outil pour mon usage. SearXNG est un métamoteur de recherche. Il trouve des pages. Firecrawl est plus proche d’une brique d’extraction : il cherche, scrape, nettoie, crawl et renvoie du contenu exploitable par un agent. Pour un assistant local qui doit lire de la documentation, vérifier une API récente ou comparer plusieurs sources techniques, la différence se sent assez vite.