El modelo de dibujo RP2040 ejecuta programas exactos, pero la IA permanece en el host
El modelo de dibujo RP2040 generó programas compactos para 12.670 pruebas de hardware, pero su transformer de 825.344 parámetros nunca se ejecutó en el microcontrolador. En su lugar, un ordenador host produjo bytecode de dibujo y lo envió a una Raspberry Pi Pico para una ejecución determinista.
Esa distinción define tanto el valor como los límites del proyecto. No es otra afirmación de que un dispositivo diminuto pueda ejecutar localmente un modelo generativo útil. Es un experimento para separar la generación neuronal incierta de la ejecución exacta y limitada.
El sistema cuestiona la ruta habitual de generación de píxeles. Se pregunta si un transformer pequeño puede escribir una descripción ejecutable y luego entregársela a una máquina mínima con un comportamiento predecible. Los resultados de hardware parecen inusualmente limpios, mientras que la capacidad del modelo para componer estructuras desconocidas sigue siendo mucho menos segura.
El modelo de dibujo RP2040 separa la generación de la ejecución
El resultado central es una división del trabajo, no inferencia neuronal en el dispositivo.
Según el repositorio público del proyecto, un transformer autorregresivo con 825.344 parámetros se ejecuta en un ordenador host. Genera aproximadamente 100 bytes de bytecode de dibujo para cada ejemplo.
El bytecode es un formato de instrucciones compacto interpretado por otro programa. Aquí describe operaciones como mover un lápiz virtual, dibujar líneas, evaluar curvas, aplicar transformaciones enteras y repetir secuencias acotadas.
El host transfiere ese programa a una Raspberry Pi Pico. Una pequeña máquina virtual, o VM, ejecuta las instrucciones en el microcontrolador RP2040 de la Pico. Después transmite las coordenadas geométricas de vuelta mediante UART, una interfaz estándar de comunicación serie.
La imagen final procede de esas coordenadas devueltas. La Pico no almacena pesos del transformer, no ejecuta inferencia neuronal intensiva en matrices ni requiere un runtime de tensores. Solo interpreta el programa generado.
Ese límite importa porque la expresión "modelo en un RP2040" sugeriría un logro técnico distinto. Un modelo con 825.344 parámetros podría necesitar varios megabytes con formatos numéricos convencionales, antes incluso de considerar la memoria de ejecución.
El autor del proyecto evita explícitamente esa afirmación. La discusión original señala que el transformer permanece en el host, mientras que la Pico almacena y ejecuta su salida.
El modelo de demostración publicado cubre cinco categorías: gatos, autobuses, flores, veleros y bicicletas. No se presenta como un sistema abierto de texto a imagen.
Ese alcance limitado facilita la interpretación de los resultados. El experimento estudia la representación, la generación de programas y la ejecución limitada sin afirmar un conocimiento visual amplio.
El modelo genera instrucciones en lugar de una cuadrícula de píxeles de colores. Esto crea una interfaz útil entre la IA probabilística y el software embebido determinista.
Un generador de píxeles se compromete directamente con el resultado visible. En cambio, un generador de programas propone una secuencia que otro sistema puede validar, limitar, ejecutar o rechazar.
Esa diferencia crea la tensión principal del artículo. La ejecución en hardware parece exacta y económica, pero una ejecución exacta no garantiza que el programa generado represente el dibujo previsto.
La Pico puede ejecutar perfectamente un mal programa de bicicleta. También puede rechazar de forma fiable una secuencia malformada o demasiado larga si la VM aplica límites adecuados.
En otras palabras, la corrección de ejecución y la corrección generativa son propiedades independientes. El proyecto mide ambas, y sus resultados apuntan en direcciones diferentes.
La ejecución exacta es el resultado más sólido
La Pico coincidió de forma consistente con el intérprete de referencia, aunque las mediciones proceden de los propios artefactos de prueba del proyecto.
El autor informa de que se ejecutaron 12.670 programas generados durante una prueba exhaustiva de hardware. Cada traza devuelta coincidió exactamente con la VM de referencia en Python.
Una traza es la geometría ordenada que produce un programa. La coincidencia exacta significa que el dispositivo y la referencia devolvieron coordenadas idénticas, en lugar de limitarse a producir imágenes de aspecto similar.
El registro de experimentos del proyecto informa de igualdad con tolerancia cero en las 12.670 trazas. También enumera 120 de 120 programas de conformidad aprobados frente a una línea base de QEMU.
Estos son resultados de primera parte, no una réplica independiente. Aun así, el repositorio incluye el intérprete, la estructura de pruebas, las trazas capturadas y la documentación necesarios para una inspección técnica.
El intérprete en C ocupa, según se informa, 1.862 bytes de flash. Esa cifra cubre únicamente la VM, excluidos el almacenamiento de bytecode y el arnés de transporte circundante.
La implementación no utiliza RAM asignada estáticamente para el estado de la VM. El uso máximo de pila alcanzó 492 bytes bajo la configuración medida.
Con un reloj RP2040 reducido deliberadamente a 12 MHz, el promedio informado fue de 7.334 ciclos por dibujo. Esto equivale a aproximadamente 0,611 milisegundos para los programas QuickDraw medidos.
El autor también informa de 1,959 ciclos por instrucción ejecutada. Estas mediciones se refieren al trabajo del intérprete, no al tiempo necesario para generar un programa en el host.
También excluyen el tiempo de transferencia del host al dispositivo y el trabajo de visualización. Los lectores no deberían interpretar 0,611 milisegundos como latencia generativa de extremo a extremo.
El RP2040 es un microcontrolador Arm Cortex-M0+ de doble núcleo con 264 kB de SRAM integrada. Raspberry Pi indica una velocidad máxima de reloj de 133 MHz en su documentación del RP2040.
El chip no tiene una unidad de punto flotante por hardware. Esta limitación suele complicar el código gráfico porque las curvas y las transformaciones emplean habitualmente coordenadas fraccionarias.
Esta VM evita la aritmética de punto flotante mediante una representación de punto fijo. El punto fijo almacena valores fraccionarios como enteros escalados, lo que produce resultados predecibles entre implementaciones.
El evaluador de curvas aprovecha recuentos de pasos que son potencias de dos. Bajo esa restricción, los coeficientes cúbicos de Bézier relevantes pueden representarse como fracciones binarias con un denominador conocido.
La implementación selecciona suficientes bits fraccionarios para preservar esos valores durante el cálculo entero. Este diseño elimina las diferencias de redondeo entre plataformas de la ruta geométrica medida.
La aritmética determinista también hace que la comparación sea inusualmente estricta. La prueba no necesita una puntuación de similitud de imagen ni una tolerancia alrededor de cada vértice.
La referencia y el dispositivo emiten la misma traza o no lo hacen. Ese resultado binario es más fácil de auditar que una evaluación subjetiva de similitud visual.
Las pruebas físicas revelaron al menos una clase de problema que la simulación en el host no detectó. La documentación del proyecto describe condiciones de carrera en la inicialización de relojes periféricos durante el arranque bare-metal.
Esa observación respalda la decisión de probar en silicio. Un intérprete puede ser matemáticamente correcto mientras su transporte o su secuencia de arranque sigue siendo poco fiable en una placa real.
No obstante, la evidencia actual tiene límites claros. El autor no midió la energía por dibujo porque el banco de pruebas carecía de equipo adecuado para medir corriente.
El repositorio tampoco incluye el checkpoint entrenado. Los usuarios pueden ejecutar la VM y reproducir capturas registradas, pero la generación en vivo del modelo requiere un checkpoint obtenido por separado.
Estas limitaciones no eliminan el resultado de ejecución. Definen qué pueden reproducir de inmediato los revisores externos y qué sigue dependiendo de los materiales del autor.
Los programas ofrecen un control que los píxeles no pueden proporcionar
Una salida ejecutable convierte el comportamiento del modelo en algo que un runtime limitado puede inspeccionar y gobernar.
Un programa de dibujo expone operaciones, flujo de control y estructura geométrica. Una imagen rasterizada solo expone la disposición final de los píxeles.
Esa diferencia importa en dispositivos pequeños. Un runtime puede imponer un límite de combustible, es decir, un número máximo de instrucciones permitidas antes de la terminación.
También puede limitar el anidamiento de bucles, la profundidad de llamadas, la profundidad de transformaciones, los rangos de coordenadas y el volumen de salida. Estas restricciones hacen que el comportamiento generado sea finito incluso cuando el modelo produce una secuencia defectuosa.
La VM del proyecto transmite vértices en lugar de almacenar un dibujo completo. Esto reduce la presión sobre la memoria de trabajo y se ajusta al comportamiento de un dispositivo diseñado para el control en tiempo real.
El enfoque se parece a otros sistemas que separan la planificación de la ejecución. Una máquina más grande realiza la inferencia costosa, mientras un controlador más pequeño sigue una representación intermedia compacta.
Ese patrón ya aparece en robótica, control numérico computarizado, plotters e interfaces embebidas. El elemento inusual aquí es utilizar un transformer de menos de un millón de parámetros para producir el programa intermedio.
El bytecode de dibujo es especialmente adecuado para el experimento. Las líneas, curvas y motivos repetidos tienen resultados visibles, pero su ejecución sigue siendo más sencilla que la de un lenguaje de programación de propósito general.
Una predicción de imagen malformada produce una imagen poco atractiva. Un programa malformado plantea preguntas adicionales sobre terminación, validez y seguridad en tiempo de ejecución.
La VM responde a algunas de esas preguntas mediante un conjunto de instrucciones deliberadamente restringido. No ofrece acceso arbitrario a memoria ni servicios generales de sistema operativo.
Esto acerca el sistema más a un lenguaje específico de dominio que al código generado convencional. Un lenguaje específico de dominio admite una tarea limitada con menos operaciones peligrosas o ambiguas.
El resultado es un contrato limitado. El modelo propone un dibujo, mientras el intérprete decide qué significan esos bytes bajo reglas fijas.
Ese contrato crea oportunidades más allá de los bocetos. Una disposición similar podría representar trayectorias de herramientas, comandos para plotters de pluma, patrones LED, animaciones simples o diseños de interfaz acotados.
Sin embargo, esas aplicaciones requerirían su propia validación. Una geometría exacta en una Pico no demuestra un movimiento seguro de motores ni un control fiable de maquinaria física.
El dominio objetivo también determinaría qué errores importan. Una flor ligeramente malformada es inofensiva, mientras que una trayectoria de actuador malformada puede dañar equipos.
La idea más transferible del proyecto es, por tanto, arquitectónica. La generación probabilística puede situarse fuera del límite de ejecución de confianza.
El componente embebido puede seguir siendo pequeño, comprobable y determinista. No necesita heredar la complejidad del modelo que propuso el programa.
Esta separación también cambia cómo los desarrolladores pueden depurar fallos. Pueden inspeccionar los bytes generados, reproducirlos en Python, comparar trazas y aislar el comportamiento específico del dispositivo.
Una canalización de píxeles suele ocultar la estructura dentro de activaciones neuronales. Una canalización de programas deja un artefacto con significado operativo explícito.
Ese artefacto puede registrarse y versionarse. También puede verificarse frente a reglas conocidas antes de que un dispositivo lo reciba.
Para los equipos de ingeniería, esto se parece más a una canalización de compilador que a un generador de imágenes. El modelo actúa como un front end incierto, mientras que la VM actúa como un back end de ejecución estricto.
La analogía no debe llevarse demasiado lejos. Los compiladores tradicionales traducen texto fuente bien definido, mientras que este transformer muestrea programas de una distribución aprendida.
Aun así, el límite es valioso. Otorga a un componente de software convencional autoridad sobre lo que puede hacer la salida generada.
La generación de programas con modelos pequeños sigue fallando en la composición
El intérprete ejecuta exactamente, pero el transformer no genera de forma fiable relaciones desconocidas exactas.
Los experimentos del proyecto muestran que una baja pérdida de predicción no produce automáticamente programas generados fiables. Esta brecha es la principal razón para tratar el trabajo como investigación y no como un sistema terminado.
El modelo autoregresivo plano de referencia informa una pérdida de prueba convergida de 489,2 bits por dibujo. La pérdida de prueba mide la incertidumbre predictiva, no si un dibujo generado satisface una relación geométrica deseada.
El autor probó varias representaciones con el mismo presupuesto general de parámetros. Entre ellas había bytes, bits individuales, tokens tipados y deltas de coordenadas relativas.
En un corpus de programas sintéticos, la representación en bits rindió aproximadamente igual que los bytes. La diferencia reportada fue de menos 0,67 bits por dibujo, con una incertidumbre de más o menos 0,77 bits.
El resultado cambió con bocetos humanos extraídos de los datos Quick, Draw de Google. Allí, el modelado a nivel de bits incurrió en una penalización reportada de 11,58 bits por dibujo, con una incertidumbre de más o menos 0,60 bits.
Los bits también expandieron las secuencias de evaluación por un factor de ocho. El experimento procesó 254 millones de tokens de bits, frente a 32 millones de tokens de bytes.
El tiempo de evaluación reportado aumentó de cuatro minutos para bytes a 48 minutos para bits. Eso supone una ralentización superior a ocho veces en la configuración documentada.
El contraste debilita cualquier afirmación simple de que un vocabulario más pequeño siempre ayuda a un modelo diminuto. Un alfabeto de dos símbolos reduce los costes de embedding, pero obliga a la red a reconstruir los límites de bytes y la estructura de los campos.
Los patrones sintéticos aparentemente hicieron manejable esa reconstrucción. Los bocetos humanos más variados no produjeron el mismo resultado.
Los tokens tipados introdujeron otra disyuntiva. Vinculan opcodes y roles de operandos de forma más explícita, pero su vocabulario mayor consume una parte sustancial de un presupuesto reducido de parámetros.
En un modelo ancho, la tabla de embeddings ocupaba el 22 por ciento de todos los parámetros. Esa configuración rindió 4,87 bits por dibujo peor que la rama de comparación.
Un modelo profundo y estrecho absorbió el coste del vocabulario de manera más efectiva. Esto sugiere que la representación y la arquitectura interactúan fuertemente a escala submillón.
Los fallos más reveladores involucraron geometría repetida. El modelo aprendió repeticiones predecibles dentro del rango presente durante el entrenamiento.
Su sorpresa cayó un 74 por ciento al encontrar la segunda copia de un motivo conocido. Una métrica de recuperación alcanzó 0,807 en una configuración reportada.
Sin embargo, el rendimiento colapsó en la quinta copia, exactamente una repetición más allá del máximo de entrenamiento. El modelo pareció aprender una distribución de conteos en lugar de una regla abstracta de bucle.
El proyecto también probó compatibilidad geométrica mediante teacher forcing. El teacher forcing evalúa el siguiente elemento correcto después de proporcionar la secuencia precedente real.
Con esa configuración, las continuaciones compatibles recibieron una fuerte ventaja de 4,28 bits por byte objetivo. El nivel de significación corregido reportado fue de 0,001.
El muestreo libre produjo un resultado muy distinto. La finalización exacta solo tuvo éxito aproximadamente el uno por ciento de las veces en las formas compuestas evaluadas.
El éxito en casos más simples de pasos planos osciló entre el siete y el 13 por ciento. El modelo podía reconocer una continuación compatible al recibir contexto, pero rara vez construía por sí mismo la continuación completa.
Esa desconexión es central en el modelado generativo contemporáneo. La preferencia a nivel de token puede parecer convincente mientras pequeños errores locales se acumulan durante el muestreo autónomo.
Cada salida generada pasa a formar parte del contexto de la siguiente predicción. Una coordenada, opcode o decisión de longitud incorrectos pueden alejar la secuencia de las condiciones encontradas durante el entrenamiento.
El RP2040 no puede reparar ese fallo semántico. Puede ejecutar el programa resultante exactamente, pero la ejecución exacta conserva el error.
La planificación jerárquica corrige mejor la longitud que la verosimilitud
Añadir estructura explícita mejoró la terminación, pero hizo que los dibujos fueran menos probables según la métrica principal de pérdida del proyecto.
El autor comparó el transformer plano con diseños jerárquicos bajo el mismo presupuesto de 825.344 parámetros. Estos sistemas primero predijeron resúmenes de trazos y luego generaron bytecode detallado para cada trazo.
Un planificador utilizó autoregresión. Otro utilizó difusión, que convierte gradualmente el ruido en una predicción estructurada mediante pasos repetidos de eliminación de ruido.
Ambas variantes jerárquicas perdieron aproximadamente entre 40 y 55 bits por dibujo frente al modelo plano. La penalización exacta varió según el tipo de planificador y el presupuesto de cómputo.
Por tanto, el experimento rechazó la hipótesis de que la planificación jerárquica mejoraría la verosimilitud a escala equivalente. Una estructura más explícita conllevó un coste de modelado medible.
Sin embargo, los planificadores controlaron la longitud de salida con mayor precisión. Su error de distribución de longitudes osciló entre 1,8 y 3,5 bytes, según la configuración.
La brecha correspondiente del modelo plano osciló entre 7,0 y 13,6 bytes. Era más propenso a detenerse prematuramente o a continuar hacia la longitud máxima permitida.
Esto no es un detalle menor de implementación. Los programas generados deben terminar en límites razonables antes de poder convertirse en comandos útiles.
Un modelo con mejor verosimilitud promedio aún puede producir muestras incómodas si asigna demasiada probabilidad a la terminación temprana. También puede generar colas largas y repetitivas.
La jerarquía separó el número de trazos de la construcción local de cada trazo. Esa decisión explícita mejoró la distribución de las longitudes generadas, aunque la verosimilitud total disminuyó.
La difusión no ofreció una ventaja clara frente a un planificador autoregresivo en la representación de resumen compartida. La mejora de terminación procedió de la jerarquía, no de la eliminación de ruido.
Experimentos posteriores con el conjunto de instrucciones produjeron un patrón similar. Las operaciones explícitas de repetir y transformar ofrecieron una compresión directa limitada porque el modelo ya predecía geometría repetida con baja sorpresa.
Sin embargo, las secuencias más cortas mejoraron el uso del contexto y la terminación. Los errores reportados de longitud generada cayeron a un rango de entre nueve y 11 por ciento.
Los modelos planos comparables mostraron errores de entre 41 y 112 por ciento. Son mediciones experimentales de primera parte, pero ilustran una tensión de diseño significativa.
Una representación puede ayudar a la generación sin ganar en la pérdida de prueba convencional. A la inversa, una pérdida menor no garantiza programas bien formados durante el muestreo.
Esa tensión debería orientar la evaluación futura. Los investigadores necesitan métricas de validez, finalización relacional exacta, terminación, novedad y comportamiento de ejecución.
La calidad visual sigue siendo relevante, pero no puede sostenerse por sí sola. Dos dibujos pueden parecer similares mientras sus programas difieren sustancialmente en longitud, estructura o reutilización.
La memorización es otra cuestión sin resolver. Un modelo pequeño puede reproducir motivos familiares sin aprender las transformaciones que los generan.
El repositorio documenta controles de posición, proximidad, frecuencia y conjuntos de coordenadas. Esas comprobaciones fortalecen el experimento relacional, pero no resuelven la novedad en todo el corpus de entrenamiento.
Una publicación más sólida incluiría checkpoints, manifiestos de entrenamiento, muestras generadas, análisis de vecinos más cercanos y scripts reproducibles de extremo a extremo.
Múltiples semillas de entrenamiento independientes también aclararían qué comportamientos sobreviven a cambios de inicialización. Algunos resultados de repetición fuera de distribución ya divergieron notablemente entre semillas.
El proyecto actual informa resultados negativos en lugar de ocultarlos. Eso resulta útil porque los fallos identifican dónde los modelos compactos dejan de comportarse como razonadores simbólicos.
Qué debería verificarse a continuación
El próximo hito no es una galería más grande; es evidencia de que las relaciones explícitas mejoran la generación de programas no vistos.
La dirección actual del proyecto añade una acción de copiar o emitir. El modelo puede producir bytes ordinarios o hacer referencia a un segmento fuente anterior con una transformación afín.
Una transformación afín puede trasladar, rotar, reflejar o escalar geometría manteniendo líneas rectas. En este sistema, las operaciones compatibles seguirían basándose en enteros y serían ejecutables mediante el estilo existente de VM.
Esta propuesta apunta directamente a la brecha del teacher forcing. El modelo ya parece sensible al contexto relacional compatible, pero el muestreo libre rara vez completa esa relación con exactitud.
Una acción explícita podría reducir el número de decisiones independientes necesarias para reproducir un motivo transformado. Una relación correcta podría sustituir muchas predicciones frágiles de coordenadas.
La primera señal que conviene observar es el rendimiento en combinaciones no vistas. El modelo debería generar relaciones exactas excluidas del entrenamiento, no limitarse a comprimir formas repetidas familiares.
La evaluación debería comparar la emisión plana con el comportamiento de copiar o emitir bajo presupuestos equivalentes de parámetros y entrenamiento. El éxito exacto de generación libre importa más que la preferencia bajo teacher forcing por sí sola.
Si la finalización relacional no vista aumenta de forma significativa por encima del nivel reportado del uno por ciento, el mecanismo gana credibilidad. Si solo mejora la verosimilitud, el problema central de generación permanece.
La segunda señal es la reproducción independiente del barrido de hardware. El proyecto proporciona código fuente y artefactos capturados, pero actualmente no incluye el checkpoint del modelo.
Un desarrollador externo debería poder reconstruir el intérprete, ejecutar la suite de conformidad, enviar programas generados a un Pico y reproducir trazas idénticas a nivel de bits.
Ese proceso debería informar de la configuración del compilador, la configuración del reloj, la sobrecarga de transporte y el desglose completo de memoria. Debería distinguir la flash del intérprete del tamaño total del firmware.
Una reproducción satisfactoria reforzaría la afirmación de ejecución. Una discrepancia ayudaría a identificar si el resultado depende de la toolchain, la revisión de la placa o detalles de configuración no documentados.
La tercera señal es una medición de recursos de extremo a extremo. La cifra actual de 0,611 milisegundos cubre la ejecución de la VM a 12 MHz, no la inferencia del host ni la transferencia serie.
Una demostración práctica debería separar el tiempo de generación, validación, transferencia, ejecución y renderizado. Las mediciones de energía también aclararían el coste de la etapa embebida.
Estas mediciones no convertirían el proyecto en IA en el dispositivo. Mostrarían si la arquitectura dividida ofrece una disyuntiva de sistemas útil.
La lección más amplia ya parece creíble, incluso antes de esas pruebas. Los modelos generativos pequeños pueden producir representaciones intermedias ejecutables, mientras que los runtimes deterministas diminutos imponen reglas operativas estrechas.
Lo que sigue sin estar claro es si el modelo puede generar la estructura correcta fuera de combinaciones familiares. La exactitud del hardware solo resuelve la última etapa de ese problema.
Por tanto, los desarrolladores que evalúen el modelo de dibujo para RP2040 deberían plantear dos preguntas separadas. ¿El Pico ejecuta exactamente cada instrucción válida, y el transformer escribe de forma fiable el programa previsto?
La evidencia disponible ofrece una respuesta sólida de primera parte a la primera pregunta. Proporciona una respuesta mucho más cautelosa a la segunda.
Observe el experimento de copiar o emitir, la publicación de checkpoints reproducibles y una ejecución independiente en Pico. Esas tres pruebas determinarán si esto se convierte en un patrón de diseño reutilizable o permanece como un prototipo de investigación instructivo.
