Le modèle de dessin RP2040 exécute des programmes exacts, mais l’IA reste sur l’hôte

Le modèle de dessin RP2040 a généré des programmes compacts pour 12 670 tests matériels, mais son transformeur de 825 344 paramètres n’a jamais été exécuté sur le microcontrôleur. À la place, un ordinateur hôte produisait du bytecode de dessin et l’envoyait à un Raspberry Pi Pico pour une exécution déterministe.

Cette distinction définit à la fois la valeur et les limites du projet. Il ne s’agit pas d’une nouvelle affirmation selon laquelle un petit appareil peut exécuter localement un modèle génératif utile. C’est une expérience qui sépare la génération neuronale incertaine d’une exécution exacte et contrainte.

Le système remet en question l’approche habituelle de génération de pixels. Il demande si un petit transformeur peut écrire une description exécutable, puis confier cette description à une machine minimale au comportement prévisible. Les résultats matériels paraissent remarquablement propres, tandis que la capacité du modèle à composer des structures inconnues reste bien moins certaine.

Le modèle de dessin RP2040 sépare la génération de l’exécution

Le résultat central est une répartition du travail, et non une inférence neuronale sur l’appareil.

Selon le dépôt public du projet, un transformeur autorégressif de 825 344 paramètres fonctionne sur un ordinateur hôte. Il génère environ 100 octets de bytecode de dessin pour chaque exemple.

Le bytecode est un format d’instructions compact interprété par un autre programme. Ici, il décrit des opérations telles que le déplacement d’un stylo virtuel, le tracé de lignes, l’évaluation de courbes, l’application de transformations entières et la répétition de séquences bornées.

L’hôte transfère ce programme à un Raspberry Pi Pico. Une petite machine virtuelle, ou VM, exécute les instructions sur le microcontrôleur RP2040 du Pico. Elle renvoie ensuite les coordonnées géométriques via UART, une interface standard de communication série.

L’image finale provient de ces coordonnées renvoyées. Le Pico ne stocke pas les poids du transformeur, n’exécute pas d’inférence neuronale intensive en calcul matriciel et ne nécessite pas de runtime de tenseurs. Il interprète uniquement le programme généré.

Cette frontière est importante, car l’expression « modèle sur un RP2040 » suggérerait une autre prouesse technique. Un modèle de 825 344 paramètres pourrait nécessiter plusieurs mégaoctets avec des formats numériques conventionnels, avant même de prendre en compte la mémoire d’exécution.

L’auteur du projet évite explicitement cette affirmation. La discussion originale indique que le transformeur reste sur l’hôte, tandis que le Pico stocke et exécute sa sortie.

Le modèle de démonstration publié couvre cinq catégories : des chats, des bus, des fleurs, des voiliers et des vélos. Il n’est pas présenté comme un système texte-vers-image ouvert.

Cette portée restreinte rend les résultats plus faciles à interpréter. L’expérience étudie la représentation, la génération de programmes et l’exécution contrainte sans prétendre à une vaste connaissance visuelle.

Le modèle produit des instructions plutôt qu’une grille de pixels colorés. Cela crée une interface utile entre l’IA probabiliste et les logiciels embarqués déterministes.

Un générateur de pixels s’engage directement sur le résultat visible. Un générateur de programmes propose plutôt une séquence qu’un autre système peut valider, limiter, exécuter ou rejeter.

Cette différence crée la tension principale de l’article. L’exécution matérielle semble exacte et économique, mais une exécution exacte ne garantit pas que le programme généré représente le dessin voulu.

Le Pico peut exécuter parfaitement un mauvais programme de vélo. Il peut aussi rejeter de manière fiable une séquence malformée ou trop longue si la VM impose des limites adaptées.

Autrement dit, la correction d’exécution et la correction générative sont des propriétés distinctes. Le projet mesure les deux, et leurs résultats vont dans des directions différentes.

L’exécution exacte est le résultat le plus solide

Le Pico a systématiquement correspondu à l’interpréteur de référence, bien que les mesures proviennent des propres artefacts de test du projet.

L’auteur indique que 12 670 programmes générés ont été exécutés lors d’une série de tests matériels. Chaque trace renvoyée correspondait exactement à la VM de référence en Python.

Une trace est la géométrie ordonnée produite par un programme. Une correspondance exacte signifie que l’appareil et la référence ont renvoyé des coordonnées identiques, plutôt que de simplement produire des images visuellement similaires.

Le compte rendu d’expérience du projet rapporte une égalité à tolérance nulle sur les 12 670 traces. Il mentionne également que les 120 programmes de conformité sur 120 ont réussi face à une référence QEMU.

Il s’agit de résultats de première main, et non d’une réplication indépendante. Le dépôt inclut néanmoins l’interpréteur, la structure des tests, les traces capturées et la documentation nécessaires à une inspection technique.

L’interpréteur C occuperait 1 862 octets de mémoire flash. Ce chiffre couvre la VM seule, à l’exclusion du stockage du bytecode et du harnais de transport environnant.

L’implémentation n’utilise aucune RAM allouée statiquement pour l’état de la VM. L’utilisation maximale de la pile a atteint 492 octets dans la configuration mesurée.

À une fréquence RP2040 volontairement réduite à 12 MHz, la moyenne rapportée était de 7 334 cycles par dessin. Cela correspond à environ 0,611 milliseconde pour les programmes QuickDraw mesurés.

L’auteur rapporte également 1,959 cycle par instruction exécutée. Ces mesures concernent le travail de l’interpréteur, et non le temps nécessaire à la génération d’un programme sur l’hôte.

Elles excluent également le temps de transfert entre l’hôte et l’appareil, ainsi que le travail d’affichage. Les lecteurs ne devraient pas considérer 0,611 milliseconde comme une latence générative de bout en bout.

Le RP2040 est un microcontrôleur Arm Cortex-M0+ double cœur doté de 264 kB de SRAM embarquée. Raspberry Pi indique une fréquence maximale de 133 MHz dans sa documentation RP2040.

La puce ne possède pas d’unité matérielle de calcul en virgule flottante. Cette limitation complique souvent le code graphique, car les courbes et les transformations utilisent couramment des coordonnées fractionnaires.

Cette VM évite l’arithmétique en virgule flottante grâce à une représentation à virgule fixe. La virgule fixe stocke les valeurs fractionnaires sous forme d’entiers mis à l’échelle, ce qui produit des résultats prévisibles entre implémentations.

L’évaluateur de courbes tire parti de nombres de pas qui sont des puissances de deux. Sous cette contrainte, les coefficients cubiques de Bézier pertinents peuvent être représentés sous forme de fractions binaires à dénominateur connu.

L’implémentation sélectionne suffisamment de bits fractionnaires pour préserver ces valeurs pendant le calcul entier. Cette conception élimine les différences d’arrondi entre plateformes du chemin géométrique mesuré.

L’arithmétique déterministe rend également la comparaison inhabituellement stricte. Le test n’a pas besoin d’un score de similarité d’image ni d’une tolérance autour de chaque sommet.

La référence et l’appareil émettent soit la même trace, soit ils ne le font pas. Ce résultat binaire est plus facile à auditer qu’une appréciation subjective de la similarité visuelle.

Les tests physiques ont révélé au moins une catégorie de problèmes que la simulation sur l’hôte n’avait pas détectée. La documentation du projet décrit des conditions de course lors de l’initialisation des horloges des périphériques au démarrage bare metal.

Cette observation soutient la décision de tester sur silicium. Un interpréteur peut être mathématiquement correct tout en conservant une séquence de transport ou de démarrage peu fiable sur une carte réelle.

Les preuves actuelles ont néanmoins des limites claires. L’auteur n’a pas mesuré l’énergie consommée par dessin, car le banc de test ne disposait pas de l’équipement approprié pour mesurer le courant.

Le dépôt n’inclut pas non plus le checkpoint entraîné. Les utilisateurs peuvent exécuter la VM et rejouer les captures enregistrées, mais la génération en direct par le modèle nécessite un checkpoint obtenu séparément.

Ces limites n’effacent pas le résultat d’exécution. Elles définissent ce que les évaluateurs externes peuvent reproduire immédiatement et ce qui dépend encore des ressources de l’auteur.

Les programmes offrent un contrôle que les pixels ne permettent pas

Une sortie exécutable transforme le comportement du modèle en un objet qu’un runtime contraint peut inspecter et régir.

Un programme de dessin expose les opérations, le flux de contrôle et la structure géométrique. Une image matricielle n’expose que l’arrangement final des pixels.

Cette différence importe sur les petits appareils. Un runtime peut imposer une limite de carburant, c’est-à-dire un nombre maximal d’instructions autorisées avant l’arrêt.

Il peut également borner l’imbrication des boucles, la profondeur des appels, la profondeur des transformations, les plages de coordonnées et le volume de sortie. Ces contraintes rendent le comportement généré fini même lorsque le modèle produit une séquence défectueuse.

La VM du projet diffuse les sommets au lieu de stocker un dessin complet. Cela réduit la pression sur la mémoire de travail et correspond au comportement d’un appareil conçu pour le contrôle en temps réel.

L’approche ressemble à d’autres systèmes qui séparent la planification de l’exécution. Une machine plus grande effectue l’inférence coûteuse, tandis qu’un contrôleur plus petit suit une représentation intermédiaire compacte.

Ce modèle existe déjà en robotique, en commande numérique par ordinateur, dans les traceurs et les interfaces embarquées. L’élément inhabituel ici est l’utilisation d’un transformeur de moins d’un million de paramètres pour produire le programme intermédiaire.

Le bytecode de dessin convient particulièrement à l’expérience. Les lignes, les courbes et les motifs répétés ont des résultats visibles, mais leur exécution reste plus simple que celle d’un langage de programmation généraliste.

Une prédiction d’image malformée produit une image peu attrayante. Un programme malformé soulève d’autres questions relatives à l’arrêt, à la validité et à la sûreté d’exécution.

La VM répond à certaines de ces questions grâce à un jeu d’instructions délibérément restreint. Elle n’offre ni accès arbitraire à la mémoire ni services généraux de système d’exploitation.

Le système se rapproche ainsi davantage d’un langage spécifique à un domaine que du code généré ordinaire. Un langage spécifique à un domaine prend en charge une tâche étroite avec moins d’opérations dangereuses ou ambiguës.

Le résultat est un contrat contraint. Le modèle propose un dessin, tandis que l’interpréteur décide de la signification de ces octets selon des règles fixes.

Ce contrat ouvre des possibilités au-delà des croquis. Une disposition similaire pourrait représenter des trajectoires d’outils, des commandes de traceur à stylo, des motifs LED, des animations simples ou des mises en page d’interface bornées.

Cependant, ces applications nécessiteraient leur propre validation. Une géométrie exacte sur un Pico ne démontre pas la sûreté d’un mouvement de moteur ni la fiabilité du contrôle de machines physiques.

Le domaine cible déterminerait également quelles erreurs importent. Une fleur légèrement malformée est inoffensive, tandis qu’une trajectoire d’actionneur malformée peut endommager un équipement.

L’idée la plus transférable du projet est donc architecturale. La génération probabiliste peut rester à l’extérieur de la frontière d’exécution de confiance.

Le composant embarqué peut rester petit, testable et déterministe. Il n’a pas besoin d’hériter de la complexité du modèle qui a proposé le programme.

Cette séparation modifie également la manière dont les développeurs peuvent déboguer les échecs. Ils peuvent inspecter les octets générés, les rejouer en Python, comparer les traces et isoler les comportements propres à l’appareil.

Un pipeline de pixels cache souvent la structure dans des activations neuronales. Un pipeline de programmes laisse un artefact doté d’une signification opérationnelle explicite.

Cet artefact peut être journalisé et versionné. Il peut aussi être vérifié par rapport à des règles connues avant qu’un appareil ne le reçoive.

Pour les équipes d’ingénierie, cela ressemble davantage à une chaîne de compilation qu’à un générateur d’images. Le modèle agit comme un front-end incertain, tandis que la VM agit comme un back-end d’exécution strict.

L’analogie ne doit pas être poussée trop loin. Les compilateurs traditionnels traduisent un texte source bien défini, tandis que ce transformeur échantillonne des programmes à partir d’une distribution apprise.

La frontière reste néanmoins précieuse. Elle donne à un composant logiciel conventionnel l’autorité sur ce que la sortie générée peut faire.

La génération de programmes par de petits modèles échoue encore sur la composition

L’interpréteur exécute exactement, mais le transformer ne génère pas de manière fiable des relations inédites exactes.

Les expériences du projet montrent qu’une faible perte de prédiction ne produit pas automatiquement des programmes échantillonnés fiables. Cet écart est la principale raison de considérer ce travail comme de la recherche plutôt que comme un système abouti.

Le modèle autoregressif plat de référence affiche une perte de test convergée de 489,2 bits par dessin. La perte de test mesure l’incertitude prédictive, et non la capacité d’un dessin échantillonné à satisfaire une relation géométrique souhaitée.

L’auteur a testé plusieurs représentations avec un budget de paramètres globalement identique. Elles incluaient les octets, les bits individuels, les jetons typés et les deltas de coordonnées relatives.

Sur un corpus de programmes synthétiques, la représentation en bits a obtenu des résultats comparables à ceux des octets. L’écart rapporté était de moins 0,67 bit par dessin, avec une incertitude de plus ou moins 0,77 bit.

Le résultat a changé avec les croquis humains issus des données Quick, Draw de Google. Dans ce cas, la modélisation au niveau des bits a entraîné une pénalité rapportée de 11,58 bits par dessin, avec une incertitude de plus ou moins 0,60 bit.

Les bits ont également multiplié par huit la longueur des séquences d’évaluation. L’expérience a traité 254 millions de jetons binaires, contre 32 millions de jetons d’octets.

Le temps d’évaluation rapporté est passé de quatre minutes pour les octets à 48 minutes pour les bits. Cela représente un ralentissement supérieur à huit fois dans la configuration documentée.

Ce contraste affaiblit toute affirmation simple selon laquelle un vocabulaire plus petit aide systématiquement un petit modèle. Un alphabet de deux symboles réduit le coût des embeddings, mais oblige le réseau à reconstruire les frontières entre octets et la structure des champs.

Les motifs synthétiques ont apparemment rendu cette reconstruction gérable. Les croquis humains plus variés n’ont pas produit le même résultat.

Les jetons typés ont introduit un autre compromis. Ils associent plus explicitement les opcodes et les rôles des opérandes, mais leur vocabulaire plus large consomme une part importante d’un petit budget de paramètres.

Dans un modèle large, la table d’embeddings représentait 22 % de l’ensemble des paramètres. Cette configuration a obtenu un résultat inférieur de 4,87 bits par dessin par rapport au bras de comparaison.

Un modèle profond et étroit a absorbé plus efficacement le coût du vocabulaire. Cela suggère que représentation et architecture interagissent fortement à une échelle inférieure au million de paramètres.

Les échecs les plus révélateurs concernaient la géométrie répétée. Le modèle a appris des répétitions prévisibles dans la plage observée pendant l’entraînement.

Sa surprise a chuté de 74 % lorsqu’il rencontrait la deuxième copie d’un motif connu. Une métrique de récupération a atteint 0,807 dans une configuration rapportée.

Pourtant, les performances se sont effondrées à la cinquième copie, soit exactement une répétition au-delà du nombre maximal observé à l’entraînement. Le modèle semblait avoir appris une distribution de comptage plutôt qu’une règle de boucle abstraite.

Le projet a également testé la compatibilité géométrique sous teacher forcing. Le teacher forcing évalue l’élément correct suivant après avoir fourni la séquence précédente réelle.

Dans cette configuration, les continuations compatibles ont bénéficié d’un fort avantage de 4,28 bits par octet cible. Le niveau de significativité corrigé rapporté était de 0,001.

L’échantillonnage libre a produit un résultat très différent. La complétion exacte n’a réussi qu’environ une fois sur cent sur les formes composées testées.

La réussite sur des cas plus simples à étapes plates se situait entre 7 et 13 %. Le modèle pouvait reconnaître une continuation compatible lorsque le contexte lui était présenté, mais construisait rarement lui-même l’intégralité de cette continuation.

Cette dissociation est centrale dans la modélisation générative contemporaine. Une préférence au niveau des jetons peut sembler convaincante, tandis que de petites erreurs locales s’accumulent lors de l’échantillonnage autonome.

Chaque sortie échantillonnée devient une partie du contexte de la prédiction suivante. Une coordonnée, un opcode ou une décision de longueur erronée peut éloigner la séquence des conditions rencontrées pendant l’entraînement.

Le RP2040 ne peut pas réparer cet échec sémantique. Il peut exécuter exactement le programme obtenu, mais cette exécution exacte préserve l’erreur.

La planification hiérarchique améliore davantage la longueur que la vraisemblance

L’ajout d’une structure explicite a amélioré la terminaison, mais a rendu les dessins moins probables selon la métrique de perte principale du projet.

L’auteur a comparé le transformer plat à des conceptions hiérarchiques avec le même budget de 825 344 paramètres. Ces systèmes prédisaient d’abord des résumés de traits, puis généraient le bytecode détaillé de chaque trait.

Un planificateur utilisait l’autoregression. Un autre utilisait la diffusion, qui convertit progressivement le bruit en une prédiction structurée au moyen d’étapes répétées de débruitage.

Les deux variantes hiérarchiques ont perdu environ 40 à 55 bits par dessin par rapport au modèle plat. La pénalité exacte variait selon le type de planificateur et le budget de calcul.

L’expérience a donc rejeté l’hypothèse selon laquelle une planification hiérarchique améliorerait la vraisemblance à échelle comparable. Une structure plus explicite entraînait un coût de modélisation mesurable.

Les planificateurs contrôlaient néanmoins plus précisément la longueur des sorties. Leur erreur de distribution des longueurs allait de 1,8 à 3,5 octets, selon la configuration.

L’écart correspondant du modèle plat allait de 7,0 à 13,6 octets. Il était plus susceptible de s’arrêter prématurément ou de poursuivre jusqu’à la longueur maximale autorisée.

Ce n’est pas un détail mineur d’implémentation. Les programmes générés doivent se terminer à des limites raisonnables avant de pouvoir devenir des commandes utiles.

Un modèle doté d’une meilleure vraisemblance moyenne peut encore produire des échantillons peu pratiques s’il attribue trop de probabilité à une terminaison précoce. Il peut également générer de longues queues répétitives.

La hiérarchie séparait le nombre de traits de la construction locale des traits. Cette décision explicite a amélioré la distribution des longueurs générées, même si la vraisemblance totale diminuait.

La diffusion n’a pas offert d’avantage clair sur un planificateur autoregressif pour la représentation de résumé partagée. Le gain de terminaison venait de la hiérarchie plutôt que du débruitage.

Des expériences ultérieures sur le jeu d’instructions ont produit une tendance similaire. Les opérations explicites de répétition et de transformation ont apporté une compression directe limitée, car le modèle prédisait déjà la géométrie répétée avec une faible surprise.

Cependant, des séquences plus courtes ont amélioré l’utilisation du contexte et la terminaison. Les erreurs de longueur générée rapportées sont tombées dans une plage de 9 à 11 %.

Des modèles plats comparables ont affiché des erreurs allant de 41 à 112 %. Il s’agit de mesures expérimentales de première partie, mais elles illustrent une tension de conception significative.

Une représentation peut aider la génération sans l’emporter sur la perte de test conventionnelle. À l’inverse, une perte plus faible ne garantit pas des programmes bien formés lors de l’échantillonnage.

Cette tension devrait orienter les évaluations futures. Les chercheurs ont besoin de métriques de validité, de complétion relationnelle exacte, de terminaison, de nouveauté et de comportement d’exécution.

La qualité visuelle reste pertinente, mais elle ne peut pas suffire à elle seule. Deux dessins peuvent sembler similaires alors que leurs programmes diffèrent fortement en longueur, en structure ou en réutilisation.

La mémorisation demeure un autre problème non résolu. Un petit modèle peut reproduire des motifs familiers sans apprendre les transformations qui les génèrent.

Le dépôt documente des contrôles portant sur la position, la proximité, la fréquence et les ensembles de coordonnées. Ces vérifications renforcent l’expérience relationnelle, mais ne règlent pas la question de la nouveauté dans l’ensemble du corpus d’entraînement.

Une publication plus robuste inclurait des checkpoints, des manifestes d’entraînement, des échantillons générés, des analyses des plus proches voisins et des scripts reproductibles de bout en bout.

Plusieurs graines d’entraînement indépendantes permettraient également de clarifier quels comportements résistent aux changements d’initialisation. Certains résultats de répétition hors distribution divergeaient déjà sensiblement selon les graines.

Le projet actuel rapporte ses résultats négatifs au lieu de les dissimuler. C’est utile, car ces échecs indiquent où les modèles compacts cessent de se comporter comme des raisonneurs symboliques.

Ce qu’il faut vérifier ensuite

La prochaine étape n’est pas une galerie plus vaste ; c’est la preuve que des relations explicites améliorent la génération de programmes inédits.

L’orientation actuelle du projet ajoute une action de copie ou d’émission. Le modèle peut soit produire des octets ordinaires, soit faire référence à une plage source antérieure avec une transformation affine.

Une transformation affine peut translater, faire pivoter, refléter ou mettre à l’échelle une géométrie tout en préservant les lignes droites. Dans ce système, les opérations prises en charge resteraient basées sur des entiers et exécutables par le style de VM existant.

Cette proposition cible directement l’écart observé sous teacher forcing. Le modèle semble déjà sensible à un contexte relationnel compatible, mais l’échantillonnage libre complète rarement cette relation avec exactitude.

Une action explicite pourrait réduire le nombre de décisions distinctes nécessaires pour reproduire un motif transformé. Une relation correcte pourrait remplacer de nombreuses prédictions de coordonnées fragiles.

Le premier signal à surveiller est la performance sur des combinaisons inédites. Le modèle devrait générer des relations exactes exclues de l’entraînement, et non simplement compresser des formes répétées familières.

L’évaluation devrait comparer l’émission plate et le comportement de copie ou d’émission avec des budgets de paramètres et d’entraînement identiques. La réussite exacte en génération libre compte davantage qu’une préférence sous teacher forcing seule.

Si la complétion relationnelle inédite dépasse sensiblement le niveau rapporté d’environ un pour cent, le mécanisme gagne en crédibilité. Si seule la vraisemblance s’améliore, le problème central de génération demeure.

Le deuxième signal est une reproduction indépendante du balayage matériel. Le projet fournit le code source et des artefacts capturés, mais n’inclut pas actuellement le checkpoint du modèle.

Un développeur externe devrait pouvoir reconstruire l’interpréteur, exécuter la suite de conformité, envoyer des programmes générés à un Pico et reproduire des traces bit à bit identiques.

Ce processus devrait rapporter les paramètres du compilateur, la configuration d’horloge, la surcharge de transport et une comptabilité mémoire complète. Il devrait distinguer la mémoire flash de l’interpréteur de la taille totale du firmware.

Une reproduction réussie renforcerait l’affirmation concernant l’exécution. Un écart aiderait à déterminer si le résultat dépend de la chaîne d’outils, de la révision de la carte ou de détails de configuration non documentés.

Le troisième signal est une mesure des ressources de bout en bout. Le chiffre actuel de 0,611 milliseconde couvre l’exécution de la VM à 12 MHz, et non l’inférence côté hôte ni le transfert série.

Une démonstration pratique devrait séparer le temps de génération, de validation, de transfert, d’exécution et de rendu. Des mesures d’énergie clarifieraient également le coût de l’étape embarquée.

Ces mesures ne transformeraient pas le projet en IA embarquée. Elles montreraient si l’architecture scindée offre un compromis systèmes utile.

La leçon plus large paraît déjà crédible, même avant ces tests. De petits modèles génératifs peuvent produire des représentations intermédiaires exécutables, tandis que de minuscules environnements d’exécution déterministes imposent des règles opérationnelles étroites.

Ce qui reste incertain est la capacité du modèle à générer la bonne structure hors des combinaisons familières. L’exactitude matérielle ne résout que la dernière étape de ce problème.

Les développeurs qui évaluent le modèle de dessin RP2040 devraient donc poser deux questions distinctes. Le Pico exécute-t-il exactement chaque instruction valide, et le transformer écrit-il de manière fiable le programme attendu ?

Les éléments disponibles apportent une réponse forte de première partie à la première question. Ils fournissent une réponse bien plus prudente à la seconde.

Surveillez l’expérience de copie ou d’émission, la publication de checkpoints reproductibles et une exécution Pico indépendante. Ces trois tests détermineront si cela devient un schéma de conception réutilisable ou reste un prototype de recherche instructif.