Un desarrollador entrena desde cero un modelo de lenguaje de 260M en una RTX 4060 de 8 GB

La mayoría de las historias sobre «un modelo propio» son en realidad un fine-tuning de pesos ajenos. Aquí es distinto. El autor de la serie dpp-gpt lo hizo todo por su cuenta: tokenizador, preentrenamiento, SFT, RL y benchmarks. El hardware es una RTX 4060 doméstica con 8 GB de memoria. La versión más reciente, 2.2 Pro, con 259 millones de parámetros, no supera a los modelos pequeños profesionales, pero el proyecto muestra bien cómo es un ciclo completo de entrenamiento sin el presupuesto de un laboratorio.

Qué hay dentro y con qué se entrenó

La arquitectura es conocida por Llama: RMSNorm, RoPE, SwiGLU y GQA. El modelo tiene 20 capas, un ancho de 1024, un contexto de 8192 tokens y un vocabulario BPE propio de 16 384 tokens, en el que los dígitos van como tokens independientes. Idiomas: ruso, inglés y francés.

El preentrenamiento consumió unos 31.000 millones de tokens. La mezcla está cuidadosamente armada: Wikipedia en tres idiomas (23%), texto web de CulturaX, código en Python, matemáticas (14%), poemas, traducciones y datos sintéticos para trabajar con texto.

La parte más interesante son las matemáticas. Las genera un script y la respuesta se escribe por posiciones: centenas, decenas, unidades y, al final, el total. Python verifica cada ejemplo, así que los datos no contienen errores. De este modo el modelo aprende a operar con números de hasta 40 cifras: repite un algoritmo en lugar de adivinar la respuesta.

El conjunto de SFT creció hasta 60 millones de tokens (unos 122.000 diálogos). Casi todo lo generó DeepSeek a través de OpenRouter, y un código volvió a comprobar las respuestas con números. Los datos costaron aproximadamente 3000 rublos. En el entrenamiento se mezcló un 32% de datos de preentrenamiento para que el modelo no olvidara la base.

RL en 8 GB: qué funcionó y qué se rompió

La versión final se obtuvo con GRPO. Para cada consulta, el modelo escribe 8 respuestas, recibe una recompensa y aprende de la diferencia dentro del grupo. La recompensa la entrega un código (aritmética, tests para Python, JSON, llamadas a herramientas) o bien un juez local, Gemma 4 E4B, para redacciones, poemas y datos factuales.

Un truco útil es el ajuste de la dificultad. Si una tarea se resuelve siempre o no se resuelve nunca, las 8 respuestas reciben la misma recompensa y no hay gradiente. Por eso esos tipos de tareas se eligen con menor frecuencia, y aquellos en los que el modelo acierta más o menos la mitad, con mayor frecuencia.

No faltó el clásico reward hacking. En las primeras ejecuciones, un código calculaba la recompensa del texto a partir de indicios indirectos, y el modelo aprendió a responder corto. Las redacciones y las preguntas generales se rompieron. Hubo que añadir un juez y reequilibrar el entrenamiento.

Cuando se acabaron los problemas evidentes, el progreso se estancó: cada nuevo checkpoint ganaba en un aspecto y perdía en otro. Ayudó un simple promedio de pesos: 0,4 · GRPO8 + 0,3 · GRPO9 + 0,3 · GRPO5. Esa «sopa» resultó mejor que cualquiera de los checkpoints.

Otro contratiempo: el SFT hundió las matemáticas. En su benchmark propio, el modelo base tenía un 47,6%; tras el primer SFT bajó al 26%, y tras ajustar la mezcla subió al 36,8%.

Las cifras, sin adornos

En su conjunto propio de 2450 preguntas, la media subió de 8,3 (versión 2.15) a 24,2. El modelo lidera en aritmética y llamadas a herramientas, pero en promedio solo está al nivel de Falcon-H1-Tiny 100M y por detrás de Gemma 3 270M. El propio autor advierte de que el conjunto está hecho para sus formatos y le favorece.

En los tests habituales en inglés, el panorama es más débil. HellaSwag: 28,9%, frente al 39,3% de Gemma 3 270M y el 42,9% de SmolLM2 135M. GSM8K: 1,8%; IFEval: 14,1%. El modelo base sin SFT obtiene en HellaSwag el mismo 28,8%, lo que indica que el techo lo marca el preentrenamiento: 31.000 millones de tokens frente a billones. El RL no movió estos tests; su beneficio está en la aritmética, las herramientas, el JSON y las instrucciones.

También se señalan los puntos débiles: la multiplicación de números de 5–6 cifras sale bien en aproximadamente el 30% de los casos, el modelo pierde la cuenta entre mensajes, obedece mal órdenes como «responde con una sola palabra» y el modo «con razonamiento» todavía no ayuda. La llamada a herramientas funciona solo en el formato con el que se entrenó.

Qué conclusiones sacar

Primera: para tareas acotadas (salida estructurada, llamadas a funciones, aritmética), los datos sintéticos verificables y la recompensa por código dan una mejora notable incluso en un modelo diminuto. Segunda: si la recompensa de RL tiene un punto débil, el modelo lo encontrará, así que hacen falta comprobaciones variadas y un juez. Tercera: promediar los pesos de checkpoints cercanos cuesta casi nada y puede superar la búsqueda del «mejor». Y cuarta: en conocimiento general, un modelo pequeño con un presupuesto reducido de tokens no es competitivo. Los próximos pasos del autor son una versión flash de 140M con la proporción de Python corregida y un vocabulario ampliado con atención local para acelerar el modelo.