El Soul Player C64 transformer es un modelo de lenguaje con arquitectura transformer implementado completamente en assembly 6502 para la Commodore 64, corriendo en hardware de 1 MHz con solo 64 KB de RAM. El proyecto, disponible en GitHub bajo el usuario gizmo64k, logra ejecutar inferencia real de una red neuronal de 25.000 parámetros en una máquina de 1982 sin ningún coprocessador externo.
En 30 segundos
- Soul Player C64 corre un transformer decoder-only con 25K parámetros, 2 capas, embeddings de 32 dimensiones y 4 cabezas de atención, todo en 6502 assembly para la Commodore 64
- Los pesos del modelo ocupan 25 KB, el vocabulario tiene 128 tokens, y la ventana de contexto es de 20 tokens máximo
- Cuantización INT8 con aritmética de punto fijo Q8.8 y lookup tables para softmax permiten correr la red en hardware sin unidad de punto flotante
- La velocidad es de aproximadamente 60 segundos por token generado, con salida sonora vía chip SID de la C64
- El proyecto se suma a una tradición de IA en retro hardware: transformers en Mac 1989, generadores de sprites C64, Llama 2 en PowerBook G4
¿Qué es Soul Player C64 y por qué importa?
Soul Player C64 es un transformer real, no una simulación ni un API wrapper, que corre localmente en una Commodore 64 original de 1982. El código, escrito en assembly 6502/6510, implementa desde cero cada componente de la arquitectura transformer: embeddings, atención multi-cabeza, capas feed-forward y la lógica de generación token por token. No hay GPU, no hay librería, no hay sistema operativo moderno. Solo 1 MHz de clock y 64 KB de RAM.
Lo notable no es que “funcione” en el sentido de generar texto coherente (las expectativas hay que calibrarlas, como vamos a ver). Lo notable es que la arquitectura transformer, la misma base matemática de GPT y Claude, puede reducirse hasta caber en hardware de cuatro décadas atrás. Eso dice algo sobre la esencia de estas redes.
Arquitectura transformer en hardware miniaturizado
Ponele que tenés que implementar un transformer con los recursos de una calculadora de bolsillo avanzada. Ese es exactamente el problema que resolvió el autor de Soul Player C64.
La arquitectura es decoder-only con 2 capas, lo que la pone en la familia de modelos generativos tipo GPT (a diferencia de BERT, que usa encoder). Los embeddings tienen 32 dimensiones, la atención multi-cabeza usa 4 cabezas de 8 dimensiones cada una, y la red feed-forward tiene 64 unidades ocultas. La ventana de contexto máxima es de 20 tokens. Para ponerlo en perspectiva: GPT-2 small tiene 117 millones de parámetros, 12 capas, embeddings de 768 dimensiones y ventana de 1024 tokens. Soul Player C64 tiene 25.000 parámetros, es decir, 4.680 veces menos parámetros que el modelo más pequeño de GPT-2.
¿Sigue siendo un transformer? Sí. Tiene self-attention, tiene posicional encoding, tiene la estructura matemática que define a estos modelos. Es el esqueleto reducido a su mínima expresión. Sobre eso hablamos en técnicas avanzadas de prompting.
Especificaciones técnicas: el arte de la compresión extrema
Los números son lo más revelador del proyecto:
- Parámetros totales: 25.000
- Tamaño de los pesos: 25 KB
- Vocabulario: 128 tokens (básicamente ASCII estándar)
- Entrada máxima: 128 caracteres en minúscula
- Ventana de contexto: 20 tokens
- Velocidad: ~60 segundos por token generado
- Salida de audio: blips generados por el chip SID de la C64
Veinticinco kilobytes. El logo de un blog ocupa más que eso. Y en esos 25 KB están todos los pesos de una red neuronal que puede hacer inferencia.
La cuantización INT8 es clave: en lugar de usar números de punto flotante de 32 bits (que darían cuatro valores por byte), se trabaja con enteros de 8 bits, lo que reduce el espacio de representación a 256 valores posibles por peso. Eso es suficiente para preservar la estructura matemática de la red, aunque con pérdida de precisión. La Commodore 64 no tiene unidad de punto flotante en hardware, así que cualquier cálculo flotante requeriría emulación por software, algo prohibitivo a 1 MHz.
Cuantización INT8 y optimizaciones de punto fijo
Acá viene lo técnicamente más interesante del proyecto: cómo se adapta la matemática de los transformers a un procesador de 8 bits sin hardware de punto flotante.
La aritmética de punto fijo Q8.8 significa que cada número tiene 8 bits para la parte entera y 8 bits para la fraccionaria, usando un entero de 16 bits para representar decimales. Con esto se evita la emulación de float32 por software, que sería entre 10 y 100 veces más lenta. Para el cálculo de softmax, que requiere la función exponencial, se usan lookup tables precalculadas: en vez de computar e^x en tiempo de ejecución, se indexa una tabla con el resultado ya almacenado en ROM.
El truco más específico del proyecto es el desplazamiento de los attention scores en 14 bits para evitar “uniform attention”, el fenómeno donde todos los tokens reciben pesos de atención similares, haciendo que la cabeza de atención no aprenda a focalizarse en nada. Con aritmética de enteros de baja precisión, este problema aparece naturalmente, y la solución es amplificar los scores antes de pasar por softmax. Es el tipo de detalle que solo aparece cuando implementás un transformer en hardware donde cada bit importa.
¿Alguien más había resuelto esto antes en 6502? Los proyectos previos de C64AI y c64_gen_ai hacen chat con modelos externos vía conexión a internet, no inferencia local. Soul Player C64 es distinto: el modelo corre adentro de la máquina.
Implementación en 6502 assembly: el procesador de 1975 corriendo IA de 2026
El 6502 es un procesador de 8 bits diseñado en 1975 que equipó a la Apple II, el NES, el Atari 2600 y, en su variante 6510, la Commodore 64. Corre a 1 MHz (1 millón de ciclos por segundo) y tiene tres registros de uso general. Para que dimensiones la diferencia: un iPhone 15 tiene aproximadamente 3.400 millones de MHz equivalentes. Lo explicamos a fondo en automatización con recursos mínimos.
Implementar una red neuronal en assembly 6502 hand-written significa codificar cada operación de álgebra lineal a mano: multiplicaciones de matrices, sumas acumuladas, el pase forward completo de la red. No hay NumPy, no hay PyTorch, no hay ninguna abstracción. Cada instrucción del procesador tiene que justificarse porque los ciclos son un recurso escaso. El resultado: 60 segundos por token generado. No es rápido. Pero funciona.
La restricción de memoria de 64 KB es total: el código del programa, los pesos del modelo y el buffer de trabajo tienen que caber en ese espacio. Los 25 KB de pesos solos representan casi el 40% de la RAM disponible.
Limitaciones prácticas: qué esperar cuando lo usás
Las expectativas hay que plantearlas con honestidad, porque si llegaste acá esperando algo como ChatGPT en una C64, te vas a llevar una desilusión.
El flujo de uso es el siguiente: escribís un input de hasta 128 caracteres en minúscula, presionás RETURN, y esperás. Unos 60 segundos después, el modelo genera el primer token. Si el output tiene varios tokens, esperás varios minutos por el resultado completo. La salida también se emite como blips de audio vía el chip SID, lo que es un detalle bonito pero no agrega utilidad práctica.
Con 128 tokens de vocabulario (básicamente los 128 caracteres ASCII), el modelo no puede generar texto en mayúsculas ni usar caracteres especiales. Con 20 tokens de contexto máximo, olvídate de conversaciones con memoria. Con 25.000 parámetros entrenados en un corpus que no se documenta en detalle, la calidad del texto generado es, digamos, experimental (ponele). El valor del proyecto no está en lo que produce, sino en que demuestra que puede producirlo.
Contexto histórico: retro hardware corriendo IA moderna
Soul Player C64 no es el primer proyecto de este estilo. Existe una pequeña tradición de implementar modelos modernos en hardware antiguo, más como exploración técnica que como propuesta práctica. Para más detalles técnicos, mirá modelos de IA de última generación.
| Proyecto | Hardware | Modelo | Nota |
|---|---|---|---|
| Soul Player C64 | Commodore 64, 1 MHz, 64 KB | Transformer 25K params (local) | Inferencia 100% local en 6502 assembly |
| Transformers en Mac 1989 | Macintosh 68k, 8 MHz, 4 MB | Transformer pequeño | Cubierto en detalle acá |
| Llama 2 en PowerBook G4 | PowerPC G4, 1 GHz, 512 MB | Llama 2 7B cuantizado | Requiere cuantización agresiva, muy lento |
| C64AI | Commodore 64 + internet | Modelo externo vía API | No es inferencia local, es proxy |
| c64_gen_ai | Commodore 64 + internet | Modelo externo vía conexión | Mismo esquema de proxy |
| BitNet / TinyLlama | Hardware moderno | Modelos <1B params cuantizados | Apuntan a edge computing real |
La línea entre Soul Player C64 y proyectos como BitNet o TinyLlama es interesante: mientras los proyectos de retro hardware son experimentos culturales y educativos, los modelos ultra-compactos modernos tienen aplicaciones reales en IoT y dispositivos embebidos. Las técnicas que usa Soul Player (cuantización agresiva, aritmética de punto fijo, lookup tables) son las mismas que usa la industria para correr modelos en microcontroladores ARM de bajo consumo.
Qué nos enseña Soul Player sobre la arquitectura transformer
El valor real del proyecto es conceptual. Si un transformer puede correr con 25K parámetros en 25 KB de RAM en hardware de 1982, eso confirma algo sobre la arquitectura: el mecanismo de atención no requiere escala masiva para existir. Puede funcionar a escala microscópica.
Esto conecta con una discusión activa en investigación de IA: ¿cuánto del poder de los LLMs grandes viene de la arquitectura transformer en sí, y cuánto viene de la escala del entrenamiento y los datos? Soul Player no responde esa pregunta (con 25K parámetros y 128 tokens de vocab, las capacidades son mínimas), pero muestra que el esqueleto arquitectural es sorprendentemente liviano.
Para quienes trabajan en edge computing o IoT, hay algo más concreto: las técnicas que permiten correr un transformer en una C64 son las mismas que hoy se usan para meter modelos en microcontroladores STM32 o ESP32. Cuantización INT8 (y ahora INT4, INT2, incluso binaria con BitNet), aritmética de punto fijo, lookup tables para funciones costosas. El retro hardware es un caso extremo que ilustra perfectamente los principios. Si te interesa cómo funciona la cuantización de LLMs a fondo, esta guía de TheBlackboxLab sobre cuantización va al hueso.
Lo que no es Soul Player C64 es una propuesta para correr IA localmente en Latam con hardware viejo. Para eso, hoy hay opciones mucho más razonables: modelos cuantizados corriendo en una Raspberry Pi 5, un Mini PC con 16 GB de RAM, o directamente en cualquier servidor cloud. Si necesitás infraestructura para experimentar con modelos locales, donweb.com tiene VPS con buen ancho de banda local.
Errores comunes al interpretar este proyecto
Error 1: Confundir Soul Player C64 con los proyectos C64AI o c64_gen_ai. Esos dos proyectos conectan la Commodore 64 a internet y usan un modelo externo como proxy. No corren inferencia local. Soul Player C64 corre el modelo adentro de la máquina. Son proyectos completamente distintos.
Error 2: Esperar output de calidad comparable a un chatbot moderno. Con 25K parámetros, 128 tokens de vocabulario y 20 tokens de contexto, el modelo no puede generar texto coherente más allá de patrones muy simples que haya aprendido en entrenamiento. Si lo conectás esperando respuestas como las de GPT-4, vas a esperar 60 segundos por cada token de confusión.
Error 3: Pensar que esto es inútil porque es lento y limitado. El punto no es la utilidad práctica. Es que demuestra que la matemática de los transformers puede implementarse en cualquier procesador capaz de hacer aritmética entera de 16 bits. Eso tiene implicaciones reales para entender qué es lo que escala y qué no en estos modelos. Te puede servir nuestra cobertura de cómo trabajan los transformers modernos.
Preguntas Frecuentes
¿Qué es Soul Player C64 y cómo funciona?
Soul Player C64 es un modelo transformer de 25.000 parámetros implementado en assembly 6502 para la Commodore 64, que corre inferencia local sin conexión externa. El usuario escribe un input de hasta 128 caracteres, presiona RETURN, y el modelo genera tokens de respuesta a razón de uno cada 60 segundos aproximadamente, usando cuantización INT8 y aritmética de punto fijo para operar sin unidad de punto flotante.
¿Cómo se corre un transformer en una Commodore 64?
Mediante cuantización extrema (INT8 en lugar de float32), aritmética de punto fijo Q8.8 para representar decimales sin hardware de punto flotante, lookup tables precalculadas para operaciones costosas como softmax, y código assembly 6502 hand-written que implementa cada paso del forward pass de la red. Los 25 KB de pesos del modelo caben en la RAM de 64 KB junto al código del programa.
¿Cuáles son las especificaciones técnicas de Soul Player C64?
2 capas decoder-only, 4 cabezas de atención de 8 dimensiones cada una, embeddings de 32 dimensiones, FFN con 64 unidades ocultas, vocabulario de 128 tokens, ventana de contexto de 20 tokens, pesos de 25 KB totales, velocidad de ~60 segundos por token, entrada máxima de 128 caracteres en minúscula. Corre en hardware a 1 MHz con 64 KB de RAM sin coprocessador.
¿Es posible ejecutar IA en hardware de los años 80?
Sí, con las técnicas de compresión adecuadas. Soul Player C64 lo demuestra con un transformer real en Commodore 64. Existen también proyectos de transformers en Macintosh 68k de 1989 y Llama 2 en PowerBook G4. La clave es cuantización agresiva, aritmética de punto fijo y reducción drástica del tamaño del modelo. La limitación práctica es la velocidad: 60 segundos por token no es utilizable para aplicaciones reales.
¿Cómo se optimiza un modelo de lenguaje para hardware antiguo?
Las técnicas principales son: cuantización (reducir precisión de float32 a INT8 o menos), aritmética de punto fijo (representar decimales con enteros), lookup tables para funciones matemáticas costosas (exp, softmax), reducción de parámetros y dimensiones de embedding, y minimización de la ventana de contexto. Todas estas técnicas se usan también hoy para correr modelos en microcontroladores ARM de bajo consumo y dispositivos edge.
Conclusión
Soul Player C64 hace algo que vale la pena entender: reduce un transformer al hueso y lo corre en el hardware más limitado posible. El resultado práctico es modesto (60 segundos por token, 128 tokens de vocab, output experimental). El resultado conceptual es interesante: la arquitectura transformer sobrevive a una compresión de cuatro órdenes de magnitud y sigue siendo reconociblemente un transformer.
Para quienes trabajan en machine learning o desarrollo de software, el proyecto es una clase de compresión de modelos mejor que cualquier tutorial. Ves concretamente qué técnicas hacen posible lo imposible: cuantización INT8, punto fijo Q8.8, lookup tables, assembly hand-written. Las mismas técnicas que usa la industria para edge computing y modelos embebidos, aplicadas al caso extremo.
El código está disponible en GitHub bajo el usuario gizmo64k. Si tenés una C64 o un emulador, podés probarlo. Si no tenés ninguna de las dos cosas, el código en assembly 6502 igual vale leerlo para entender qué implica implementar una red neuronal sin ninguna abstracción de software.