Artículo
En numerosas ocasiones, a las personas que nos dedicamos a empezar a enredar con modelos pequeños, en hardware barato nos dicen frases como:
Objetivo
Os traigo una demo generada, después de llevar semanas trabajando en afinar y comprender configuraciones de hardware, probar modelos, sistemas de trabajo entre ellos, limitaciones, etc...
Gracias a ello, he podido poner en práctica, las técnicas y configuraciones aprendidas en el taller anterior.
La tarea
La tarea consiste en programar un videojuego tipo Snake, el juego de la serpiente que nos volvía locos a los que vivimos la era de los primeros móviles de consumo, de Nokia, cuya histórica división de móviles acabó pasando por varias etapas y cuya marca continúa utilizándose en teléfonos fabricados por HMD. El reto es conseguir programar algo que fuera decente, no solo una demo, sino que implementase algo atractivo y por qué no, incluso con la esencia adictiva de los juegos arcade de los 90.
El resultado final ha sido:
El Stack
He usado el mencionado en el taller:
Empezamos
Como el objetivo de esta prueba no era usar un "agent harness" complejo como puede ser opencode, sino orquestar una colaboración entre modelos que pudieran impulsar el desarrollo con un hardware minimalista, una tarea que a priori solo debería estar reservada a un hardware más potente, comencé utilizando Gemma4-e4b para los primeros diseños, al principio, los resultados fueron algo terribles, como los programas de Alberto Chicote, "Pesadilla en la cocina", donde este modelo al recibir un prompt sencillo:
"Hazme un snake.html, un juego de snake que sea súper molón, pon en la cabeza ojos, y lengua, y haz algo en la comida divertido, que sea fruta por ejemplo."
Creaba código pero ni tan siguiera arrancaba. Esto fue el punto de partida. En este punto, muchas personas suelen descargarse el modelo en LM Studio o incluso hay quien usa ya Ollama, carga los parámetros por defecto del modelo, llegando a un paso más allá copiando los oficiales, "tiran ese prompt" y esperan magia. ¿Esto está mal? Para nada, pero este es solo el principio del camino, es el rendimiento de referencia, luego viene el bucle de iteración, prueba->ajuste.
Lo cierto es que he aprendido varias cosas sobre los modelos pequeños. Son rápidos, voluntariosos, pero son “machacas”. No puedes darles tareas que requieran una creatividad demasiado amplia ni esperar que organicen por sí solos cambios complejos. En el caso de los modelos de la familia Gemma4, no eran especialmente fiables programando con la configuración inicial, y además se publicaron parámetros como temperatura = 1.0. Esto puede encajar muy bien en un modelo excelente para resumen, redacción o tareas abiertas; digamos que sería un modelo ideal para ir por “letras”, como se decía en mi época. Pero para programación necesitas algo más cercano a “ciencias puras”: un muestreo más controlado, porque dispersarse demasiado puede aumentar la probabilidad de errores de sintaxis, referencias incoherentes o mal acoplamiento entre objetos y funciones.
Ten en cuenta que toquetear parámetros de un modelo, jugar con ellos, es buena idea para intentar afinar o exprimir más alguna capacidad, de hecho, podrías utilizar otro modelo de lenguaje más grande, para encargar en un proyecto agéntico vía opencode, codex, etc... con una batería de prompts, que pruebe varias configuraciones de parámetros, y emita una valoración. Tampoco hay que ser un genio, es lo que hacemos en Machine Learning cuando entrenamos un modelo con distintas combinaciones de hiper-parámetros, intentando saber cual es el que ofrece las métricas de rendimiento que estamos buscando. Estableces un bucle con los mismos datos de entrada, cambias parámetros, y anotas resultados, método científico.
Primera decisión
Usar un modelo comercial como consultor, para no tener que leer y probar el código, ya que estoy probando modelos para intentar dimensionar que hacen, como lo hacen, que les puedes pedir y que no, decido usar ChatGPT para en una conversación, proponer el mismo prompt a varios modelos con distintas cuantizaciones que estoy probando y "afilando" en mi Stack.
No pude en práctica el bucle agéntico anterior. Pero tenlo en cuenta, dado que salen "modelos milagro" cada dos por tres, que "literalmente lo cambian todo", y luego lo único que cambian es la cantidad de tiempo libre que tienes, contar con un desarrollo que testee el nuevo modelo puede ser algo a tener muy en cuenta.
Para probar entre configuraciones y modelos de similar tamaño en VRAM, que es lo que importa a la hora de ejecutar, que puedes ejecutar decentemente, decidí hacer un ranking para ver quien parecía desempeñar esta tarea de codificación mejor, ya que al final tienes que balancear calidad, con velocidad. Ya sabemos que un modelo más grande es más capaz, pero a menudo quizá un modelo más grande penaliza en tiempo. Si miráis las velocidades de lectura y generación de prompts de los modelos usados, comprenderéis que para tareas múltiples muy pequeñas, no tiene sentido usar modelos enormes, ya que puedes hacer más cosas en menos tiempo.
Terminado el ranking con varios modelos de distintos tamaños Gemma, Qwen, pensé que los resultados de Gema4-e4b eran especialmente terroríficos y desastrosos para su reputación y cantidad de parámetros, comparado con modelos similares. Lo normal es que modelos pequeños, por debajo de 9B, en tareas tan abiertas como estas, terminan cometiendo errores y no suelen al menos arrancar. Esto es una premisa importante, que una tarea que se encarga de programación tiene que compilar es decir, tiene que hacer algo. A un modelo 4B no vas a pedirle un gran resultado estético y/o de funcionalidad, pero si, que haga eso mismo, funcionar, ya que lo podrás ir evolucionando con el bucle de iteración.
Os diré por cierto que para mi modelos comerciales grandes como ChatGPT, Gemini, de pago, que son los que tengo acceso, bueno hay muchas capas gratuitas y seguramente sin mucho esfuerzo podría usar más modelos, me han demostrado que son bastante malos, para ajustar parámetros, auditar sistemas... Úsalos para analizar, pero sobre programación agéntica, en mi opinión van muy atrasados, no ajustan bien parámetros a detalle, miden mal las predicciones sobre que hará o no un modelo... Es decir no os fiéis, es mejor que vosotros mismos probéis.
El resultado del ranking no viene a cuento en este artículo, en resumen, los modelos Qwen los mejores, un Qwen3.5-4b-mpt-Q8_0 fue el más equilibrado en rendimiento y resultados para mi hardware, sobre esto ten en cuenta estos detalles que he aprendido trasteando:
Modelos QAT, en tamaños Q4-K-XL funcionan muy cerca de cuantizaciones tipo Q8_0, si puedes ejecutarla decentemente es mejor opción que Q4-K-M, y suele ser suficiente para programar.
Para programar, aquello de ciencias exactas mientras menos cuantizado mejor, lo ideal Q8_0.
Eso si la KV caché poco negociable, mejor en q8.
Para el resto de usos un modelo en Q4-K-M con KV caché en Q4_0, Q4_1, es perfectamente capaz.
Si no encontráis un modelo QAT en Q4-K-XL, es decir una cuantización en 4 bits, pero entrenado para estar cerca del modelo original, no lo uséis para programar, un Q4-K-M, cometerá errores de sintaxis al tener 4 bits menos de precisión, pero en el caso de modelos QAT, han sido entrenado expresamente para ser precisos aun a 4bits.
Sino hay versión QAT, mejor usar un modelo Q8_0.
La KV caché también en q8.
Restringir en el muestreo valores de temperatura, top_k, top_p, etc... para evitar que se sientan creativos.
Los modelos QAT en tamaños Q4-K-XL pueden funcionar muy cerca de cuantizaciones tipo Q8_0. Si puedes ejecutarlos con buen rendimiento, suelen ser una opción mejor que Q4-K-M y, en mis pruebas, suficiente para programar.
Para programación, aquello de las ciencias exactas: cuanto menos cuantizado, mejor. Lo ideal es Q8_0 cuando el hardware lo permita.
En tareas de programación, la KV caché es poco negociable: mejor empezar con Q8_0, especialmente si necesitas conservar nombres, sintaxis y relaciones precisas dentro de contextos largos.
Para usos menos sensibles a la precisión exacta, un modelo en Q4-K-M con la KV caché en Q4_0 o Q4_1 puede ser perfectamente capaz.
Modelos en FP16, si vas "sobrado" de VRAM o usas un sistema de memoria unificada tipo MAC con Apple Silicon o AMD, teniendo en cuenta que para el común de los mortales y el común de las tareas domésticas, no lo vas a notar. Es más, ni con tu cuñado podrás presumir, es raro que encuentres gente fuera de la pantalla que pueda seguirte en una conversación sobre cuantizaciones y kv cachés.
Segunda decisión
Como Gemma4-e4b dio unos resultados terribles, pero es un modelo rapidísimo y, tiene suficientes parámetros como para hacerlo mucho mejor, en lugar de usar los parámetros oficiales "para todo", (quien mucho aprieta...), decidí probar a restringirlo a valores donde coarto su libertad de expresión, sobre todo temperatura=0.2, "stop-inventing" que diría "Carlos Sainz Junior", y top-k:20 para no darle opción a escoger muchas alternativas para el siguiente token, veríamos si al menos conseguimos que terminen una tarea que pueda compilar, y así fue, "compiló", con un diseño la verdad chulo para su tamaño, pero poco creativo. Un diseño honesto, como hablamos, de "machaca", no esperes que añada, que sume, solo que haga.
Cuando indico que compiló, tengo muy claro que es un lenguaje interpretado, es una forma de ejemplificar que, al darle al botón para probarlo, se podía jugar, y funcionaba sin errores de consola, o problemas de diseño como, que la serpiente se estrellase sola contra la pared, había serpiente, había comida, etc... Había unos mínimos.
Si, lo que estás pensando es cierto, no he subido los parámetros completos, y no lo haré, si has seguido el taller completo, deberías aprender a gestionar los mismos por tu cuenta. En mi caso ajusto parámetros a mi hardware. Si me los pides en un comentario, y compartes mi taller, te los haré llegar ;).
Tercera decisión
Iterar. Como me gustaba lo que veía, lo iba comentado con ChatGPT en modo "vieja del visillo". Estaba sorprendido, porque le iba dando cambios en prompts sencillos, llanos, sin usar técnica alguna de promping, a "vuela pluma", haciendo eso que hacen los maestros del "vibe-coding", y el modelo iba tolerando bien cambios, haciendo mejoras, parecíamos un buen equipo. Todo lo que le indicaba terminaba devolviendo un código ejecutable, sin romperse.
Recuerdo que en mis primeras experiencias con codex en modo agente, no hace más de unos meses, cuando construí la landing page y el blog sobre el que lees este artículo, que, le daba ordenes sencillas y concretas para que revisase maquetación, hablamos de GPT-5.2-GPT-5.4, no recuerdo bien, y me costó su tiempo. Yo encantado, porque jamás pensé ver funcionar tal magnifica "magnificencia", en base a eso escribí los primeros blogs. Ahora, me sorprendo a mi mismo enfadado, porque un modelo, GRATIS Y LOCAL no hace los cambios como ni la mismísima arquitectura de OpenAi era capaz, tan solo 6 meses o 1 año atrás... Hay que pensar que los modelos locales reducen su tamaño bastante porque no son enciclopedias. Contener tantísima información aumenta el tamaño de un modelo, para eso están las herramientas.
Decidí venirme arriba y pedirle una serie de cambios estéticos y funcionalidad grandes. En ese momento, Gemma4-e4b optó por su derecho a romperse, ya entregaba código roto. ¿Que ha pasado?, pues para haceros el resumen corto (para mi fue pruebas e investigación larga...) donde el modelo comenzó a "alucinar", cuando le pasaba los errores en lenguaje natural, analizaba y respondía que había localizado los errores inventando código inexistente, etc... confirmé 2 limitaciones importantes en este tipo de modelos:
El modelo declara una ventana de contexto máxima de 128k, pero mi modelo estaba configurado en el servidor a menos, a unos 96K, estaba por debajo. Bueno, mis pruebas dicen que si el contexto de modelos pequeños se acerca a la cifra mágica de 40k, comienzan a surgir las alucinaciones, y problemas para contextualizar (nunca mejor dicho) los nuevos requerimientos. Esto es peligroso, porque se puede meter en un bucle infinito en el cual nos convence con sus palabras, que está haciendo cosas y que entiende las instrucciones, pero o bien no está haciendo nada, o bien "la está liando parda"... (Dicen, "fíate de lo que hago y no de lo que digo"...)
Este modelo, tiene serias dificultades para poder organizar ficheros de código al menos (me baso en estas pruebas) que tienen más de 500-700 líneas de código (Esta métrica con calma, porque no he tomado 30 muestras, sacado media, desviación típica...). En realidad el problema se genera, porque mi modelo gestiona pocos parámetros activos por token, llega un momento, como pasaba con los primeros modelos de lenguaje, que son incapaces de controlar una densidad elevada de relaciones entre tokens como son en este tipo de tarea objetos, funciones, capas, el DOM (árbol de jerarquía de etiquetas html), etc... Es decir, en realidad no es tanto que tu contexto esté en el límite, o que tu fichero tenga 500, 1500 líneas. Esa no es la verdadera métrica. Seguramente podría manejar un contexto de sus 128k cuando hay pocos conceptos que relacionar, lo veo un poco más por ahí.
Esto para mi es el santo grial para conseguir entender como funcionan los modelos de lenguaje. Por eso estoy haciendo este blog, es la "p.... madre del cordero", y siento enfatizar de forma tan coloquial. Entender que, básicamente, un modelo de lenguaje recibe un texto (prompt), lo parte en trozos o piezas pequeñas por palabras o trozos de palabras, y empieza a jugar con las relaciones de esos trozos, por ejemplo, si describe a un animal, si es plural, si es una etiqueta de código, luego ir subiendo la complejidad de relaciones, si ese animal, pertenece a una manada, si ese animal es el macho alfa, así podemos ir subiendo el nivel y refinando tanto, como parámetros por token tiene el modelo. Por ello cuando un modelo está bien entrenado, y es inteligente, puede que consiga entender más relaciones o centrarse en relaciones más importantes, y no atender relaciones superfluas. Por ejemplo, si el usuario pregunta, ¿de qué color es la cebra?, el modelo tendría que saber centrarse en identificar si hay un animal, además este animal es una cebra y además que color tiene, le va a dar igual saber si era cebra macho, y además alfa, o si estaba enfadada. Quizá este es un resumen demasiado esquemático, pero espero que genere en ti al menos una noción básica de por qué importan los parámetros activos por token, pero tampoco te vuelvas loco, porque meter muchos parámetros no te garantiza mejores resultados, si las relaciones que identifican son más ruido que útiles. Este es un fundamento de los modelos Moe que usamos y por qué nos permiten que el modelo centrado y afilado rinda cerca de modelos muy "enormes". ¿El modelo local es mejor? No, para nada, solo que en determinadas tareas, el 90% de las que podemos demandar casi todos, rinden parecido. ¿Un Ibiza y un Ferrari son iguales, o el Ibiza es mejor? Pues, si los vas a usar para ir por autovía a velocidades legales, puede que el primero tenga mas almacenamiento, mejor consumo, aunque pierdas en aceleración, pero ambos irán a 120 kms/h como máximo, luego con ambos te desplazas, y deberías llegar en un tiempo aproximado similar. La tarea de transportarte se cumple, con más o menos "glamour".
Por este motivo, una de las decisiones mejores que puedes tomar cuando trabajas con "codificadores humanos" (personas), o modelos de lenguaje, es optar por un patrón que prime muchos ficheros con poco código. Esto ayuda mucho a que modelos pequeños solo tengan que entrar "a matar". Por ejemplo, en mi desarrollo, pedirle al modelo un solo fichero, en lugar de usar el patrón code behind, habría ayudado bastante más.
Si le decimos a nuestro modelo, que cuando la serpiente se choca con la pared, se congela el juego, el modelo tendrá que empezar a pensar y trazar el código, como lo harías tu o yo, relacionando conceptos, llega un momento que no hay tanto parámetro para contextualizar tanta información.
Esto en si mismo para mi, para otras personas que hubieran llegado hasta aquí, habría supuesto el final del taller, ya que incluso iniciando una conversación nueva, con el código último programado, y el prompt de las correcciones funcionales, seguía ocurriendo lo mismo. Llegamos al límite de líneas asumibles. Y es una auténtica pena, porque el modelo se estaba comportando fenomenal. Os diría que, solo "fine-tuneando" los 4 parámetros de muestreo que toqueteé, parecía que estaba delante de un modelo diferente.
También para los defensores de los grandes modelos comerciales, al todo poderoso ChatGPT 5.6-Sol-medium le pedí soluciones, y lo que hizo fue acusar al pequeño y "pavonearse" diciendo que él sabía donde estaban los errores, dándome el código arreglado. (Que al ejecutarlo tenía algún error también)
Cuarta decisión
Ayer hice otra prueba, con el modelo Qwen3.6-35B-A3B en mi equipo. Recuerda que este modelo en una cuantización medio normal, ocupa casi 22GB. Pero al igual que el Gemma4-e4b, es mezcla de expertos Moe. Mi equipo tiene 6GB de VRAM y 16GB de DDR4, luego, "tenemos un problema serio"... En una cuantización de 4 bits Q4-K-M lo puedo desplegar gracias a dos trucos:
Esta técnica me permite cargar el para mi al menos, mejor modelo para para hardware de hogar, a velocidades de CPU sobre todo la lectura de prompt es terrible, no lee más de 10-20 tokens/segundo, y genera a 5-7 tokens/segundo, evidentemente no un Q8 que nii sueño con él, mi hardware me permite cargar como mucho Q4 y dejarlo trabajar. Además apenas pude cargar 16k de contexto.
Bien pues buscando algo de información vi como alguien probaba este modelo en cuantización IQ2, es decir, en ... 2 bits (aprox)!!, siempre he leído, visto y escuchado que por debajo de 4 bits los modelos no sirven. Mi sorpresa fue que este modelo, con una ventana de contexto de solo 16k (reutilicé la configuración del modelo de 4bits) funcionaba sorprendentemente rápido, en torno a unos 40 tokens/segundo, hablamos de un contexto muy pequeño, me permitía meter todos los expertos en RAM y todas las capas en VRAM. ¡¡El consumo de VRAM no llegaba a 3 GB!!
"Moraleja", que lo que te digan, o puedas leer sirva para orientarte, pero prueba cosas. Seguramente en otros modelos, una cuantización tan agresiva nos habría dado un modelo no usable para programación, pero la sorpresa es grande. Prueba.
Me animé a probarlo, porque recientemente en la comunidad se han escuchado ejemplos de modelos nuevos como Bonsai a 1 bit y Bonsai ternario a 2 bits, los cuales codifican sus pesos solo con [0,1] en el caso del primero y [-1,0,1] en el caso del segundo. Los he probado y la verdad el resultado fue bastante decepcionante, por este motivo, no tenía nada de fe en usar un modelo de solo 2 bits, pero partían de modelos Qwen y pensé que si una empresa, o alguien mucho más listo que yo, se atrevía a intentar hacer algo decente con solo 2 bits, usando como base esta familia de modelos, lo mismo se podría hacer algo. Bueno, salió bien. No creo que sepa más que nadie. Seguramente en un Gemma4-26B-a4b, esta cuantización, si existe, no daría tan buen resultado.
Hice varias pruebas con este modelo, y lo vi sorprendentemente capaz y muy por encima de modelos de 4 a 8 mil millones de parámetros, es decir, realmente parecía mantener la esencia del modelo grande, pero cuando ayer lo hice diseñar un tetris.html y snake.html, el modelo no conseguía hacer un código que "compilase" a la primera. Lo que entregaba no arracaba pero era sorprendentemente bueno analizando código. Bueno, viendo que tenia terriblemente desocupada mi VRAM, decidí sin tocar nada mas, ir aumentando la ventana de contexto, y más o menos llegué a ajustar la cifra astronómica de 200k de contexto, salvaje. Hablamos de una tarjeta con arquitectura de portátil. Bajó el rendimiento de tasa tokens/segundo pero a una escritura de 25 tokens/segundo el modelo es muy capaz para hacer informes y revisiones en tiempos aceptables. Hace 5 años, esto sería magia negra...
Recuerda algo muy importante, la velocidad de escritura de prompt entre 20-30 tokens/segundo es aceptable, pero fíjate en la velocidad de lectura, que esté por encima de los 100 tokens/segundo, sino será una tortura su uso. Además, por lento que sea un modelo escribiendo, si lo usas en modo chat, y vas viendo generar tokens, se hace más ameno, sabes que está haciendo algo, si está procesando un prompt y no ves nada, desespera.
Recordando lo anterior, pensé:
¿Estás pensando lo mismo que yo? Y si... probamos una metodología agéntica, "¿Y si Qwen3.6 le da un informe tan detallado a Gemma4, que incluya las piezas de código que tiene que sustituir, para que Qwen3.6 no tenga que genera todo el Snake.html, con el consiguiente ahorro de tokens/tiempo?".
En este ejemplo en concreto, el mismo Qwen3.6 podría haber implementado la escritura del fichero de salida, con sus cambios propuestos, pero, esto implica aumentar el consumo de tokens, es decir la respuesta tardará más, gastará más contexto, y, si hacemos funcionar a Gemma4-e4b en otro equipo, podrían paralelizar bien el patrón de productor-consumidor.
En realidad un modelo en línea es muy capaz de asumir la tarea de Qwen3.6, pero la idea es poder ser razonablemente lentos pero autosuficientes.
La arquitectura fue la siguiente:
"El Señor Miyagi le dice al pequeño Daniel San que tiene que pulir el coche, le enseña como, pero el que lo pule entero es el pequeño Daniel San. El señor Miyagi seguramente sería más lento, pero conoce la técnica.."
El resultado fue sensacional, nos permitió poder terminar el desarrollo asumiendo un trabajo basado en roles:
Es bastante probable además que si reducimos la ventana de contexto a unos 64k o menos para Qwen3.6, ya que usamos los modelos como sub-agentes en opencode, podemos indicar que cada llamada use el mismo formato, acceso al fichero a revisar, y prompt de cambios, para no acumular basura contextual, podríamos conseguir ubicar más expertos en VRAM aumentando la velocidad, no solo en escritura sino, en lectura de prompt.
La otra mejora importante, es ahorrar y comprar una tarjeta gráfica algo más potente para poder usar Qwen3.6-35B-A3B con un contexto decente en Q8...
Si quieres probar el juego te dejo la dirección: Ver la demo de Snake -> https://demos.etani.es/snake.html