Qwenputer : un processeur RISC-V dans une IA
Qwenputer intègre un processeur RISC-V aux poids de Qwen 3.5. Découvrez son fonctionnement, ses résultats en calcul, ses limites et les enjeux pour l’IA.
Qwenputer : quand un modèle d'IA embarque son propre processeur
Un modèle de langage peut expliquer une multiplication sans toujours la calculer correctement. Pour obtenir un résultat fiable, on lui donne généralement accès à un outil externe, par exemple un interpréteur Python. Qwenputer propose une approche différente : intégrer un processeur RISC-V directement dans les poids d'un modèle Qwen 3.5 4B, puis utiliser certaines de ses couches récurrentes comme mémoire vive.
Le processeur exécute ses instructions pendant les passes avant du modèle. Il peut faire des opérations arithmétiques et lancer du code C ou MicroPython, sans serveur d'outils et sans bac à sable externe dédié aux calculs. Ce n'est pas qu'une simple démo : l'expérience s'appuie sur un cœur qui passe des tests RISC-V, et dont les sorties sont comparées à celles d'une machine de référence.
Cela reste expérimental. Le modèle devient beaucoup plus gros, les calculs ralentissent, et il faut un pilote spécifique. Mais l'idée soulève une question qui revient souvent dans les équipes IA : et si certaines fonctions qu'on confie aujourd'hui à des outils externes pouvaient, elles aussi, être compilées directement dans le modèle ? Voyons comment Qwenputer fonctionne, ce que ses essais montrent, et ce qu'il ne faut pas en déduire.
Ce que Qwenputer intègre réellement dans le modèle
Qwenputer part de Qwen 3.5 4B. Le modèle garde ses poids d'origine : on ajoute un processeur dans des couches et des dimensions supplémentaires. On n'est donc pas sur un outil « appelé » par une API, ni sur un programme lancé hors du modèle. Le calcul passe par des composants ajoutés au réseau et activés pendant la génération.
C'est une distinction importante. Dans une architecture classique, le modèle formule une demande, un environnement externe exécute le calcul, puis renvoie le résultat. Ici, les opérations du processeur sont encodées dans les poids du modèle et produites via l'exécution du modèle. Un pilote, RvChat, reste toutefois nécessaire : il charge le microprogramme et gère le déroulement. Donc « sans outil externe » ne veut pas dire « sans aucune brique logicielle ».
Un processeur, pas une métaphore
Le cœur intégré est un processeur RISC-V 32 bits de type RV32IM, avec l'extension Zba et une unité expérimentale pour des calculs sur de grands nombres. Il occupe 11 couches placées avant les 32 couches de Qwen. Le fonctionnement est décrit comme un circuit : lire un registre, faire une addition, tester une condition ou modifier le compteur ordinal.
Un compilateur transforme ces étapes en paramètres de modèle. Les têtes d'attention servent à lire certaines valeurs, les unités de calcul font les opérations, et les couches Gated DeltaNet gardent l'état mémoire. Il n'y a pas d'entraînement « pour obtenir ce processeur » : ses poids sont fixés par compilation.
Une exécution matérialisée par des jetons
Le processeur communique via des jetons. À chaque instruction, on obtient des traces avec, par exemple, l'adresse mémoire à écrire, la valeur à enregistrer, puis un jeton qui clôt l'étape. Ces jetons ne sont pas seulement une explication en langage naturel : ils participent à l'exécution.
Pour que le modèle les utilise de façon fiable, l'expérience reprend un format proche de celui des appels d'outils que les modèles savent déjà produire. Cela facilite l'interface entre Qwen et le processeur, sans confier le calcul à un outil externe. RvChat gère le démarrage du microprogramme et évite que les jetons de trace se mélangent au texte généré « normalement » par Qwen.
Au final, on a donc un système hybride : un modèle de langage préentraîné, auquel on adjoint un composant déterministe. Cette séparation aide à raisonner sur ce qui se passe : Qwen comprend la demande et choisit quand utiliser le processeur, tandis que le cœur RISC-V exécute les opérations définies par son jeu d'instructions.
Comment le processeur s'exécute dans les passes du modèle
À chaque instruction, le modèle fait avancer l'état du processeur à travers ses couches. Les registres, les données et le compteur ordinal sont maintenus dans les lignes de mémoire prévues à cet effet. Les unités de calcul appliquent les opérations demandées, puis une nouvelle trace décrit l'étape suivante. Le processeur avance donc pendant la génération, sans qu'un système d'exploitation distinct le lance.
La différence entre « exécution » et « récit » compte ici. Un modèle de langage peut produire une suite de chiffres qui sonne juste sans effectuer la bonne opération. Dans Qwenputer, le résultat arithmétique provient d'un cœur RISC-V conçu pour exécuter des instructions. Le modèle peut ensuite présenter ce résultat à l'utilisateur, mais la fiabilité dépend du processeur compilé, pas de la capacité du modèle à improviser une réponse convaincante.
C, MicroPython et calculs exacts
Le cœur implémente RV32IM et peut exécuter du C ainsi que MicroPython dans les passes du modèle. Ce n'est pas un processeur conçu pour faire tourner un système généraliste comme Linux : l'expérience ne revendique pas cette portée. L'objectif est plutôt de couvrir un ensemble précis d'opérations et de programmes que le microprogramme sait exécuter.
Cette capacité ouvre une piste au-delà de « quelques opérations intégrées ». Le projet évoque notamment l'idée de laisser Qwen écrire du Python, puis l'exécuter via un environnement MicroPython inclus dans les poids. Ce serait une interface plus flexible pour certains calculs, mais ça ne supprimerait ni les contraintes d'exécution, ni les questions de sécurité, ni le coût. Un interpréteur embarqué doit forcément être limité et évalué selon ce qu'on lui autorise à traiter.
Un système de fichiers expérimental
Une extension ajoute aussi du stockage de fichiers dans l'état Gated DeltaNet. Le modèle peut alors faire, en interne, des opérations de création, ajout, lecture, liste et suppression, sans appeler un outil externe. Les noms sont répartis dans 1 024 emplacements ; s'il y a collision, le système passe à l'emplacement suivant. Le contenu, lui, est stocké dans d'autres têtes, sous forme de blocs chaînés.
La capacité annoncée va jusqu'à 512 fichiers et environ 53 000 jetons de texte. L'état peut être sauvegardé à la fin d'une conversation puis rechargé dans une autre, ce qui rend les fichiers persistants entre sessions, à condition de conserver et de restaurer cet état. Dans les essais décrits, la mémoire « retrouve » correctement des faits qui ont changé entre conversations dans 90 % des cas, contre 30 % quand on recopie simplement les anciennes conversations. Le résultat est présenté comme comparable à une mémoire gérée par des outils Python.
Cela dit, cette fonction reste expérimentale et s'appuie sur une branche de développement distincte. Elle montre bien le potentiel d'un état récurrent structuré, mais on n'est pas encore à un niveau où on pourrait l'utiliser sereinement pour des données sensibles ou dans un système de production.
Quels résultats Qwenputer obtient-il, et à quel coût
Les évaluations publiées portent surtout sur l'arithmétique. Sur plusieurs jeux de calculs de DeepMind, Qwenputer obtient des résultats proches d'un Qwen 3.5 4B auquel on ajoute un outil Python, et dépasse souvent le modèle de base. Pour les divisions de grands nombres, le score rapporté est de 97,5 %, contre 95 % avec l'outil Python et 72,5 % sans outil. Pour les multiplications longues, Qwenputer est à 97,5 %, contre 100 % avec Python et 55 % pour le modèle de base.
Sur une tâche combinant des multiplications, des divisions et des calculs plus longs, Qwenputer atteint 100 %, contre 97,5 % avec Python et 90 % pour Qwen seul. Pour les additions ou soustractions de grands nombres, il obtient 97,5 %, à égalité avec la configuration utilisant Python, tandis que le modèle de base tombe à 87,5 %. Sur les calculs d'entiers longs de NUPA, le résultat annoncé passe de 48,6 % pour Qwen seul à 100 % avec Qwenputer, un score aussi atteint avec l'outil Python.
La précision du calcul n'est pas la fiabilité globale
L'auteur indique avoir comparé environ 230 000 positions de sortie du processeur à une machine de référence et n'avoir observé aucun écart. Le cœur passe aussi des tests RISC-V cités, et les programmes correspondent à ceux exécutés avec QEMU. En mode autonome, sans correction par une machine de référence entre les étapes, il aurait exécuté 18 millions d'instructions sans erreur.
Ces résultats sont encourageants, mais il faut en rester là : ils décrivent le comportement dans les essais faits, sans prouver que « tout sera fiable » pour n'importe quel programme, n'importe quel benchmark, ou n'importe quelle configuration matérielle. Le choix des benchmarks, le périmètre des instructions testées et la reproductibilité de l'environnement jouent un rôle autant que le score final. Pour un usage pro, il faudrait aussi mesurer les erreurs liées à la sélection d'outil, les pannes du pilote et ce qui arrive en cas d'interruption pendant la génération.
Par ailleurs, l'ajout du processeur semble peu changer le texte généré « normalement » selon les mesures rapportées : la divergence KL est de 6 × 10−4, proche du bruit de référence de 5 × 10−4. C'est un bon signe pour vérifier qu'on n'a pas dégradé visiblement la conversation, mais ça ne remplace pas une évaluation métier ou linguistique complète.
Le coût pratique est encore élevé
Le point le plus concret, c'est la taille : le modèle modifié fait 18,8 Go, soit environ deux fois la taille du modèle Qwen de base. Même si une partie correspond à du remplissage nul, le coût de stockage et de déploiement n'est pas « gratuit ». L'expérience requiert une carte graphique de 24 Go et un pilote spécifique ; elle ne se branche pas encore comme un simple appel standard à generate().
La vitesse est le deuxième compromis. Une instruction du processeur demande plusieurs jetons de génération, donc un calcul lourd prend des secondes là où un CPU classique pourrait prendre des millisecondes. L'exécuteur groupé utilisé dans les benchmarks atteint environ 3 200 jetons de processeur par seconde sur une carte L4, mais ce chiffre ne doit pas être confondu avec la vitesse d'un processeur classique.
Ce que cette expérience change pour les usages de l'IA
Pour une entreprise, la vraie question n'est pas « est-ce qu'un modèle peut embarquer un ordinateur ? » C'est de comparer le système complet à une solution externe : un modèle qui appelle un calculateur, une base de données ou un environnement de code. Une approche intégrée peut réduire certaines dépendances à des outils séparés et rendre plus facilement exploitables des états persistants directement dans le modèle. En contrepartie, elle alourdit le checkpoint, impose un pilote et peut rendre le comportement plus difficile à inspecter.
Dans les cas où l'exactitude compte vraiment (calcul financier, traitement de données, vérification de cohérence), séparer génération et calcul reste souvent plus simple à tester. Un outil externe peut être versionné indépendamment, journalisé et remplacé sans reconstruire tout le modèle. À l'inverse, un composant compilé dans les poids peut être utile si l'on explore des systèmes plus autonomes ou de nouvelles formes de mémoire interne. Le choix dépend surtout du coût opérationnel et du niveau d'auditabilité exigé.
Les implications pour la sécurité et la gouvernance
Le projet intéresse aussi la recherche en sécurité. Si un état récurrent peut contenir des valeurs exactes et structurées, il peut aussi conserver des éléments de raisonnement qui ne se reflètent pas forcément dans le texte produit. Dans ce contexte, se fier uniquement à la « chaîne de pensée » explicitée par le modèle n'est pas une garantie : l'état interne peut faire plus que ce que dit le texte.
L'autre piste est presque à l'inverse : des composants compilés dans les poids pourraient servir à des fonctions de contrôle difficiles à désactiver via une simple instruction en langage naturel. Mais ça ne prouve pas, pour autant, qu'on a un mécanisme inviolable. Pour le savoir, il faut examiner ce que le modèle peut influencer, quelles entrées modifient l'état, et comment le système réagit à des erreurs ou à des sollicitations malveillantes.
Dans un contexte européen, ces sujets recoupent aussi les exigences de traçabilité, de gestion des risques et de protection des données. Une mémoire persistante implique de clarifier ce qui est conservé, pendant combien de temps, qui peut restaurer l'état, et comment supprimer les informations. Que la mémoire soit intégrée aux poids ou logée dans un état récurrent ne dispense pas d'une politique de conservation.
Une piste de recherche, pas un remplacement immédiat des outils
Qwenputer montre qu'on peut intégrer un calcul directement dans l'exécution d'un modèle, sans serveur d'outils « classique ». C'est une démonstration technique intéressante, et un bon terrain pour tester mémoire, interprétabilité et sécurité. Mais ce n'est pas, en l'état, une raison suffisante pour remplacer les outils externes dans un produit d'entreprise.
Pour décider si une approche comparable mérite un essai, quatre questions reviennent souvent :
- Le besoin impose-t-il une exécution déterministe ? Si oui, comparez l'intégration à un outil spécialisé qu'on peut valider.
- La latence est-elle acceptable ? Une exécution basée sur plusieurs jetons par instruction peut rendre l'interaction pénible.
- L'état doit-il survivre d'une session à l'autre ? Dans ce cas, il faut gérer sauvegarde, restauration, contrôle d'accès et suppression.
- Pouvez-vous auditer tout le système ? Les poids, le pilote, les traces et la mémoire doivent être évalués ensemble.
Ces critères évitent de confondre « nouvelle architecture » et « vrai avantage opérationnel ». Le bon choix, c'est celui qui réduit les erreurs et le coût total, sans rendre la maintenance et l'audit plus compliqués que le problème initial.
Conclusion
Qwenputer montre qu'une architecture récurrente comme Gated DeltaNet peut être configurée en mémoire adressable, puis servir de base à un processeur RISC-V intégré aux poids d'un modèle. Les résultats arithmétiques rapportés sont solides et proposent une alternative aux appels d'outils externes, mais taille, latence et intégration restent des obstacles.
La leçon la plus utile n'est pas que les modèles de langage vont remplacer les processeurs ou les outils spécialisés. C'est plutôt que leurs états internes peuvent être structurés pour exécuter des fonctions déterministes, avec des implications pratiques et de sécurité. Pour un projet réel, l'approche pertinente consiste à comparer : exactitude, coût d'exécution et capacité d'audit. C'est cette comparaison - pas le côté spectaculaire - qui dira si ça vaut le coup.
Comment Gated DeltaNet devient une mémoire adressable
Le point central de Qwenputer repose sur Gated DeltaNet, une architecture récurrente présente dans Qwen 3.5. Dans les couches concernées, chaque tête conserve une matrice d'état mise à jour à mesure que les jetons passent. En usage « normal », cette matrice sert de mémoire pour un traitement séquentiel. Ici, l'expérience montre qu'on peut aussi la faire se comporter comme une mémoire vive plus explicite.
Dans la configuration habituelle, l'état change au rythme de portes et de mises à jour successives. Si une porte inférieure à 1 atténue ce qui a été stocké, le modèle finit par oublier une partie de son état. Pour avoir une mémoire stable, Qwenputer règle la porte à 1, de sorte que les valeurs ne s'effacent pas au fil des jetons. La force d'écriture, appelée bêta, est aussi mise à 1.
Adresser une ligne plutôt que retrouver une information
Ici, une clé one-hot joue le rôle d'une adresse : c'est un vecteur rempli de zéros, sauf à une position. Cette clé pointe une ligne précise de la matrice d'état, un peu comme une adresse mémoire pointe une cellule. En écrivant avec une telle clé, le système remplace exactement une ligne. En interrogeant la même adresse, il récupère la valeur associée.
Ce réglage transforme une mémoire récurrente en mémoire adressable. L'enjeu n'est pas juste de « garder du contexte » ou d'entretenir une association. Pour que le processeur fonctionne, il doit pouvoir déposer une valeur à un endroit précis, la retrouver plus tard, puis la modifier de façon contrôlée. C'est ce niveau de précision qui rend possibles le stockage de registres, de données et d'éléments utiles au déroulement d'un programme.
Il y a aussi une question de capacité. Une mémoire Gated DeltaNet conserve un état de taille fixe, indépendamment de la longueur de la conversation. À l'inverse, un cache clé-valeur d'attention classique grossit avec les jetons traités. Attention toutefois : dire « plus stable » ne veut pas dire « automatiquement mieux », puisque la capacité reste bornée par la taille de l'état et la manière dont il est organisé.
Une idée connue, une mise en œuvre plus stricte
L'idée de mémoire associative pour des modèles à attention linéaire et règle delta a déjà été étudiée, notamment dans les travaux sur les « fast weights » (Imanol Schlag, Kazuki Irie, Jürgen Schmidhuber). Ce que fait Qwenputer, c'est rendre cette mémoire adressable et suffisamment fidèle pour y faire tourner un processeur complet.
Il faut distinguer cette configuration expérimentale du fonctionnement standard de Qwen 3.5. Sans ces réglages, le modèle de base ne garantit pas, à lui seul, un stockage exact de valeurs numériques dans son état Gated DeltaNet. Si la mémoire devient exploitable ici, c'est parce que les paramètres, les portes et les clés sont configurés précisément pour cet usage. Autrement dit : ce n'est pas « un modèle de langage a déjà une mémoire vive fiable », c'est plutôt « certaines de ses structures peuvent être détournées pour ça ».