Intelligence embarquée : mon retour sur l'approche ultra-dense de PrismML
Le défi des grands modèles est connu : ils sont trop gourmands pour le smartphone et trop énergivores pour nos infrastructures actuelles. J'ai donc analysé l'approche de PrismML sur la densité d'intelligence.
.png&w=3840&q=75)
PrismML Bonsai 2 27B : mon retour d’expérience avec Claude Code sur une RTX 4070 Ti
Depuis quelque temps, je teste différentes solutions permettant de faire tourner des modèles de langage directement en local. Mon objectif n'est pas nécessairement de remplacer Claude ou les modèles les plus puissants du marché, mais plutôt de voir jusqu'où il est possible de déporter une partie de mon workflow de développement sur ma propre machine.
C'est dans ce contexte que j'ai commencé à tester PrismML avec le modèle Ternary-Bonsai-2-27B.
Et après plusieurs sessions de développement réelles, mon constat est assez simple : c'est beaucoup plus fonctionnel que ce à quoi je m'attendais.
Ma configuration de test
Je ne dispose pas d'une station équipée de plusieurs GPU professionnels. J'utilise une configuration relativement classique pour une machine de développement performante :
- GPU : NVIDIA RTX 4070 Ti avec 12 Go de VRAM
- RAM : 64 Go
- Environnement : Claude Code
- Modèle :
Ternary-Bonsai-2-27B
Il s'agit d'ailleurs d'une configuration volontairement assez minimale de mon setup Bonsai. Je cherche surtout à obtenir quelque chose de simple à démarrer, stable et directement exploitable lorsque j'en ai besoin.
Dans mon environnement, je peux lancer ma session avec une commande très simple :
claude --dangerously-skip-permissions --bonsai
Une fois la partie serveur démarrée, je peux donc basculer rapidement vers mon modèle local sans avoir à reconstruire tout mon environnement de travail.
Bonsai directement dans mon workflow Claude Code
C'est probablement le point le plus intéressant de mon test.
Je n'utilise pas Bonsai simplement dans une interface de chat pour lui poser quelques questions. Je l'utilise dans Claude Code, avec un environnement capable de lire mes fichiers, modifier du code, lancer des commandes et vérifier le résultat de ses propres modifications.
Pour certaines tâches bien définies, il fonctionne vraiment bien :
- correction de code existant ;
- petites modifications ciblées ;
- refactoring simple ;
- recherche d'une erreur dans plusieurs fichiers ;
- modification puis vérification du résultat ;
- exécution de tests après une modification ;
- petites tâches répétitives sur un projet.
Je trouve particulièrement intéressant de lui déléguer des tâches dont le périmètre est établi, vérifiable et relativement précis.
Dans ce contexte, le modèle n'a pas besoin d'être meilleur que les modèles frontier sur tous les domaines. Il doit surtout comprendre la demande, retrouver les bons fichiers, effectuer la modification et vérifier qu'il n'a rien cassé.
« Je n'ai pas besoin d'utiliser le modèle le plus puissant disponible pour modifier quelques lignes de code. Si un modèle local peut comprendre la tâche, l'exécuter correctement et vérifier son travail, il devient déjà extrêmement utile. »
Ce qui m'a surpris : sa capacité à vérifier son propre code
L'un des comportements qui m'a le plus surpris concerne justement la vérification après modification.
Sur plusieurs tâches, le modèle ne se contente pas de modifier un fichier. Il analyse ensuite le résultat, lance des commandes ou des tests et revient corriger son travail lorsque quelque chose ne fonctionne pas.
Il faut toutefois apporter une nuance importante : je pense qu'une partie de cette efficacité vient directement du harnais de Claude Code.
Claude Code fournit au modèle un environnement agentique particulièrement efficace : accès aux outils, lecture des fichiers, exécution de commandes, boucle de vérification, etc.
Bonsai bénéficie donc énormément de cette infrastructure.
Mais ce qui est intéressant, c'est qu'il arrive à suivre cette boucle correctement. Le modèle comprend les résultats des outils, revient dans le code et poursuit la tâche sans perdre immédiatement le fil.
Pour un modèle exécuté localement sur ma configuration, je trouve ce résultat particulièrement convaincant.
192 000 tokens de contexte : probablement le point le plus intéressant
L'autre élément qui change complètement l'expérience concerne la taille du contexte.
Dans mes tests, j'ai réussi à pousser le contexte jusqu'à environ 192 000 tokens.
À titre de comparaison, ma configuration habituelle de Claude Code tourne autour de 16 000 tokens.
Cette différence est énorme lorsqu'on travaille sur un véritable projet.
Avec davantage de contexte, je peux conserver beaucoup plus d'informations simultanément :
- instructions système ;
- outils disponibles ;
- historique de la session ;
- contenu de plusieurs fichiers ;
- résultats de commandes ;
- erreurs précédemment rencontrées ;
- modifications déjà réalisées.
Ce qui m'a surtout étonné, c'est que le modèle reste capable de retrouver les bonnes informations même lorsque le contexte commence à devenir très important.
Il ne suffit pas d'accepter théoriquement 100 000 ou 200 000 tokens. Encore faut-il réussir à récupérer une information pertinente perdue au milieu de cette quantité de données.
Et jusqu'à présent, Bonsai s'en sort plutôt bien sur mes tests.
« La taille du contexte est intéressante, mais sa capacité à retrouver une information précise plusieurs dizaines de milliers de tokens plus tard l'est encore davantage. »
Tout ne tient évidemment pas dans les 12 Go de VRAM
Il faut néanmoins préciser un point important : ma RTX 4070 Ti ne dispose que de 12 Go de VRAM.
Je ne fais donc pas fonctionner absolument tout sur le GPU.
Une partie du traitement est déportée vers la RAM. C'est notamment le cas de certains composants comme la partie vision dans ma configuration actuelle.
Et la différence de performances devient immédiatement visible lorsque cette partie est sollicitée.
Lorsque le système doit davantage travailler depuis la RAM, le CPU entre beaucoup plus en jeu et les temps de traitement augmentent sensiblement.
Pour mon utilisation principalement orientée texte et code, ce compromis reste parfaitement acceptable.
Mais il faut garder en tête qu'un modèle qui fonctionne sur une configuration de 12 Go de VRAM ne signifie pas nécessairement que l'intégralité du traitement est réalisée dans ces 12 Go.
« Sur le texte et le code, mon setup est très confortable. Dès que je sollicite des éléments déportés en RAM, notamment la vision, on ressent immédiatement le changement : davantage de CPU et une latence nettement supérieure. »
Un modèle local qui devient réellement utile
Ce qui change ma perception des modèles locaux avec cette expérience, c'est que je ne suis plus simplement en train de tester un modèle pour voir combien de tokens par seconde il produit.
Je commence réellement à pouvoir lui déléguer du travail.
C'est une différence importante.
Pour des corrections ou des modifications dont le résultat peut être facilement contrôlé, le modèle devient une sorte de worker local.
Je peux lui confier une tâche, le laisser analyser les fichiers concernés, effectuer les modifications et lancer les vérifications nécessaires.
Et pendant ce temps, je peux conserver les modèles plus puissants pour les problèmes qui nécessitent réellement davantage de raisonnement.
Vers une architecture hybride entre Bonsai et Claude ?
C'est d'ailleurs probablement la prochaine étape de mes tests.
Je n'ai pas encore expérimenté sérieusement la communication entre plusieurs instances ou sessions Claude Code, avec par exemple une instance utilisant Bonsai localement et une autre utilisant directement Claude.
Mais conceptuellement, c'est probablement l'une des pistes les plus intéressantes.
On pourrait imaginer un système dans lequel :
- Bonsai prend en charge les tâches simples ou répétitives ;
- il effectue les modifications locales et les vérifications ;
- les problèmes complexes sont transmis à Claude ;
- Claude intervient principalement pour l'architecture, le raisonnement ou les cas difficiles.
Le modèle local ne serait alors plus simplement une alternative au modèle distant, mais un agent complémentaire.
Je n'ai pas encore suffisamment testé cette architecture pour tirer des conclusions, mais c'est clairement quelque chose que je compte explorer.
Les limites actuelles
Je reste malgré tout prudent sur ce que je lui confie.
Pour une tâche clairement définie dont je peux contrôler le résultat, il fonctionne très bien.
En revanche, dès que la demande nécessite beaucoup d'abstraction, une décision architecturale importante ou un raisonnement particulièrement complexe, les modèles les plus avancés restent nettement plus confortables.
Et c'est finalement très logique.
Mon objectif n'est pas de démontrer qu'un modèle local de 27 milliards de paramètres remplace tous les modèles disponibles dans le cloud.
L'intérêt est plutôt de déterminer quelle proportion de mon travail n'a justement pas besoin d'un modèle frontier.
Mon avis après plusieurs utilisations réelles
À ce stade, mon expérience avec PrismML et Ternary-Bonsai-2-27B est clairement positive.
Avec une RTX 4070 Ti 12 Go et 64 Go de RAM, j'arrive à disposer d'un modèle local capable de participer réellement à mon workflow de développement.
Il peut lire mon projet, effectuer des modifications, utiliser les outils proposés par Claude Code, lancer des tests et conserver un contexte particulièrement important.
Évidemment, certaines opérations nécessitent un offload vers la RAM et deviennent alors nettement plus lentes. Tout n'est donc pas magique, et les limites matérielles restent présentes.
Mais ce qui m'intéresse ici n'est pas uniquement la performance brute.
C'est le fait d'arriver à une situation où un modèle local peut réellement devenir une ressource de calcul supplémentaire dans mon environnement de développement.
« Je ne cherche pas à savoir si Bonsai peut remplacer Claude. La question qui m'intéresse davantage est : combien de tâches puis-je arrêter d'envoyer à Claude parce que mon modèle local est déjà capable de les réaliser correctement ? »
Et après mes premiers tests, la réponse semble être : beaucoup plus que ce que j'imaginais.
Il me reste encore énormément de choses à tester, notamment la vision, les sessions longues, les cas de raisonnement plus complexes et surtout une éventuelle architecture dans laquelle Bonsai et Claude travailleraient ensemble.
Mais pour une technologie que je suis encore en train d'explorer, le niveau d'utilisabilité est déjà suffisamment élevé pour que je l'intègre réellement à mon workflow.
Article inspiré de prismml.com ↗

