I trained an 825k-parameter model to generate drawing programs that execute exactly on an RP2040 [P]
Our take
![I trained an 825k-parameter model to generate drawing programs that execute exactly on an RP2040 [P]](https://preview.redd.it/57901ltt3aph1.jpg?width=140&height=140&crop=1:1,smart&auto=webp&s=a1dfb415841d9cece2281b29bc9eaeeab99a6421)
The recent demonstration of an 825k-parameter model generating executable drawing programs for a Raspberry Pi Pico is a fascinating glimpse into the potential of constrained AI. It’s easy to get caught up in the escalating scale of large language models, but this project, detailed on Reddit by u/Rozuzo, highlights a different, equally compelling trajectory: efficient, targeted AI capable of delivering tangible results on resource-limited hardware. While Meta’s recent Muse Spark 1.3 release [Meta says Muse Spark 1.3 has frontier performance — but its best results come from a model developers can’t broadly use yet] showcases impressive performance, it's also constrained by accessibility—requiring specialized infrastructure. This Pico project, in contrast, emphasizes a different kind of power: the ability to achieve meaningful computation within a remarkably small footprint. The meticulous verification—12,670 out of 12,670 generated traces matching a Python reference VM—underscores the rigor and reliability of this approach, a refreshing contrast to the often-unverified claims surrounding larger AI models. We've also seen discussions around the challenges of citing preprints and subsequent works [How to cite/talk about preprint-subsequent works for a camera-ready version? [R]], which this project elegantly sidesteps by producing directly executable code.
What’s particularly intriguing is the exploration of representation formats. The finding that the optimal representation (bit-level vs. byte-level) depends on the corpus highlights a crucial point about AI: there’s no one-size-fits-all solution. The project’s investigation into hierarchical stroke planning and relational context also speaks to the ongoing challenge of enabling AI to understand and leverage structure within data. The model’s preference for relational context under teacher forcing, while struggling with free sampling, reveals a common tension in AI development: achieving consistency and control versus enabling genuine creativity and generalization. This resonates with the growing concerns surrounding LLM-generated peer reviews [The Downsides of LLM-Generated Peer Reviews [D]], where controlled outputs can lack the nuance and critical thinking of human analysis. The project's open-source nature and the explicit request for feedback on novelty and memorization evaluation are a testament to the collaborative spirit driving progress in this field.
The implications of this work extend beyond simply generating simple drawings. It demonstrates the feasibility of offloading computation to microcontrollers, potentially enabling a new generation of embedded devices with sophisticated AI capabilities. Imagine smart sensors, personalized wearables, or even low-cost robotics, all powered by AI models that run directly on the device, without relying on cloud connectivity. The minimal resource requirements – 1,862 bytes of flash, 0 bytes of static RAM, and 492 bytes of peak stack – are particularly striking, showcasing the potential for highly efficient AI deployment. The fact that no floating-point hardware or tensor runtime is needed on the Pico is a significant advantage, simplifying both hardware and software requirements and reducing power consumption. This is a move away from the computationally intensive behemoths that dominate current AI headlines and towards a more distributed, edge-computing paradigm.
Looking ahead, the focus on explicit source-span and affine-relation actions is a promising avenue for improving generation accuracy. The question remains: can we build AI models that not only generate code but also understand and reason about its structure, allowing them to adapt and generalize to unseen scenarios with greater fidelity? The ability to move beyond memorization and towards genuine understanding will be key to unlocking the full potential of this approach. Furthermore, the call for better evaluation methods—particularly for assessing novelty and memorization—underscores the ongoing need for more rigorous and nuanced metrics in AI research. It’s a space ripe for innovation, and this project provides a compelling proof-of-concept for a more efficient, accessible, and ultimately, more empowering future for AI.
| I’ve been working on a small research project about whether sub-million-parameter models can learn to generate executable drawing programs for constrained hardware. The current system is an 825k-parameter autoregressive transformer which generates ~100 bytes of drawing bytecode rather than pixels. The bytecode is then transferred to a Raspberry Pi Pico, where a small fixed-point virtual machine executes it and streams the resulting geometry back over UART. The model runs on the host. The Pico only stores and executes the generated program, so this is not a claim that the transformer itself runs on the microcontroller. The execution side is currently the most solid part of the project: 12,670/12,670 generated traces matched the Python reference VM exactly, 1,862 bytes of flash for the interpreter, 0 bytes of static RAM and 492 bytes of peak stack, 7,334 cycles per drawing at 12 MHz, or about 0.61 ms for the measured QuickDraw programs and no floating-point hardware or tensor runtime is needed on the Pico. I have been comparing token, byte, bit, typed-token, and delta-coordinate representations while keeping the underlying drawing information equivalent. so far, perhaps trivially, the conclusion is that the answer depends strongly on the corpus: on a synthetic program corpus, a bit-level representation was essentially equivalent to bytes at the converged budget, while on real QuickDraw sketches it incurred an approximately 11.6-bit penalty per drawing. I’ve also tested whether a model can discover repeated structure such as loops from flat bytecode, and whether hierarchical stroke planning helps at this scale. The planner did not improve likelihood, although it substantially improved termination and generated-length behavior. Another experiment found that the model can show a strong preference for compatible relational context under teacher forcing, while still struggling to produce the exact compatible continuation when sampling freely. The project is still very much a work in progress. The current direction is to add an explicit source-span / affine-relation / copy-or-emit action while keeping the final output as ordinary flat drawing bytecode. The goal is to test whether making relations explicit helps with exact generation on unseen combinations. The repository, demo instructions, figures, captured RP2040 traces, and experiment details are here: https://github.com/roodriigoooo/drawing-machine I would especially appreciate feedback on 1) how to evaluate novelty and memorization more convincingly 2) better ways to measure exact program generation rather than only teacher-forced likelihood and 3) experiments that would make the microcontroller result more meaningful [link] [comments] |
Read on the original site
Open the publisher's page for the full experience