NETBYTE
Iniciar un proyecto

Investigación

Helix, parte 1: entrenamos un modelo de lenguaje europeo

Estamos entrenando nuestro propio modelo de lenguaje. Es pequeño –320 millones de parámetros–, pero lee los 24 idiomas oficiales de la Unión Europea y se entrena en tarjetas gráficas hechas para videojuegos. Esta primera parte cuenta cómo llegamos hasta aquí; la segunda llegará cuando termine el entrenamiento.

Por Marcus Weitschat 8 min de lectura

Matriz de puntos de aquello a lo que cada token de Helix puede prestar atención: una franja azul para la ventana local, puntos amarillos para su propio bloque y puntos naranjas dispersos para el recuerdo a larga distancia.

Por qué un estudio de videojuegos entrena un modelo de lenguaje

NETBYTE crea videojuegos, aplicaciones y sitios web. Cada vez más, esos productos llevan modelos de lenguaje adentro: personajes que responden, ayuda que entiende una pregunta, herramientas que hacen algo. La mayoría de los modelos abiertos piensan primero en inglés; el estonio, el irlandés o el maltés quedan para después. Queríamos entender toda la cadena por nuestra cuenta –datos, tokenizador, arquitectura, entrenamiento– y averiguar a dónde se va realmente el dinero.

parámetros
320 M
idiomas oficiales de la UE
24
tokens de entrenamiento
6,500 M
por las GPU rentadas
≈ US$12

Helix nació como prototipo de investigación. Todo lo que sigue es una decisión que le dio forma, cada una respaldada por una medición, además de los errores que más tiempo nos costaron.

Cuatro ideas, una sobreviviente

El prototipo atacaba cuatro debilidades conocidas de los generadores de texto actuales. Escribe en bloques de 16 tokens en vez de token por token, puede recorrer varias veces un núcleo compartido de capas, predice un “plan” compacto para cada bloque y combina una atención local económica con atención lineal para las distancias largas.

La escritura por bloques funcionó de inmediato: un pequeño modelo de prueba escribió 64 tokens en 13 pasadas por la red, donde un modelo convencional necesita una pasada por token, más o menos la quinta parte del trabajo. Las otras tres ideas fallaron en una prueba más exigente. Armamos tareas en las que la respuesta está muy fuera de la ventana local, de modo que el modelo tiene que mirar hacia atrás en todo el texto.

Figura 1 Recuerdo a larga distancia Porcentaje de respuestas correctas en una tarea de recuerdo cuya pista está fuera de la ventana local. Modelo de referencia pequeño, mismo presupuesto para cada variante.
  1. Solo ventana local 23.1%
  2. + atención lineal, plan y bucles 23.1%
  3. + 2 cabezas globales exactas 49.4%
  4. Atención completa (control) 49.0%
Mostrar los datos
VarianteCorrectas
Solo ventana local23.1%
+ atención lineal, plan y bucles23.1%
+ 2 cabezas globales exactas49.4%
Atención completa (control)49.0%
Azar (25 %)25.0%

Solo la atención exacta a toda la distancia las resolvió. La atención lineal, el plan y los bucles se quedaron al nivel del azar; el optimizador incluso había reducido la memoria lineal a una vida media de menos de un token. Dos cabezas globales exactas alcanzaron para igualar a la atención completa.

Por eso el modelo final mantiene en cada capa ocho cabezas locales con una ventana de 256 tokens y agrega dos cabezas globales exactas en una de cada dos capas; las capas intermedias conservan dos cabezas de atención lineal con compuerta. El plan y los bucles están desactivados. Siguen en el código y están probados, pero en texto real no justificaron su costo.

Figura 2 Qué mira cada capa Diez cabezas de atención por capa, doce capas. Cada capa tiene ocho cabezas locales; las capas impares agregan dos cabezas globales exactas, y las pares, dos cabezas de atención lineal con compuerta.
  • Local, ventana de 256 tokens
  • Atención global exacta
  • Atención lineal con compuerta
Mostrar los datos
Tipo de cabezaCapasCabezas por capa
Local, ventana de 256 tokens1–128
Atención global exacta1, 3, 5, 7, 9, 112
Atención lineal con compuerta2, 4, 6, 8, 10, 122

Medir, no suponer

Probamos cada truco de entrenamiento en un modelo de 94 millones de parámetros con el mismo presupuesto por corrida: 29.5 millones de tokens, la misma semilla, el mismo orden de datos. Dos corridas de la misma configuración difieren en ±0.03, así que todo lo que sea menor es ruido.

Figura 3 Qué ayudó y qué era ruido Cambio en la pérdida de validación frente a la referencia con AdamW. Modelo de 94 M de parámetros, 29.5 millones de tokens por corrida. Por debajo de cero es mejor; la franja gris es el ruido entre corridas (±0.03).
  1. Muon + calendario WSD -0.587
  2. Optimizador Muon -0.347
  3. Red más profunda y angosta -0.099
  4. Calendario WSD -0.080
  5. Residual de valores -0.007
  6. z-loss +0.029
  7. Atención con consultas agrupadas +0.088
Mostrar los datos
CambioΔ pérdida (nats)
Muon + calendario WSD-0.587
Optimizador Muon-0.347
Red más profunda y angosta-0.099
Calendario WSD-0.080
Residual de valores-0.007
z-loss+0.029
Atención con consultas agrupadas+0.088

El optimizador Muon fue la única gran palanca, y se combina con un calendario de tasa de aprendizaje warmup-stable-decay. Regresar el embedding y la capa de salida a AdamW, como recomiendan los autores de Muon, aportó otros 0.12 y aceleró el entrenamiento un 5 %. Las combinaciones no se suman así nomás: una red más profunda y angosta ayudaba con AdamW y perjudicaba con Muon. Por eso cada combinación prometedora tuvo su propia corrida.

24 idiomas, 6,500 millones de tokens

Helix lee texto web de FineWeb-Edu para el inglés y de FineWeb-2 para los otros 23 idiomas; en los más grandes, de su décima parte superior filtrada por calidad. Código, matemáticas y un pequeño flujo de chat sintético completan la mezcla. El inglés recibe un tercio. Los demás idiomas se ponderan según cuánto texto existe, suavizado para que el irlandés y el maltés no queden tapados, y ninguna fuente se repite más de cuatro veces: hasta ese punto, repetir es casi tan bueno como tener datos nuevos.

Figura 4 Qué lee Helix Porcentaje de tokens de entrenamiento por grupo de fuentes. Corpus de 6,500 millones de tokens en 34 flujos; código y marcado abarca Python, JavaScript, C, C++, Java, HTML, CSS y Markdown.
  1. Otros 23 idiomas de la UE 51.6%
  2. Inglés 33.0%
  3. Código y marcado 10.0%
  4. Matemáticas 3.0%
  5. Chat y herramientas sintéticos 2.4%
Mostrar los datos
FuentePorcentaje
Otros 23 idiomas de la UE51.6%
Inglés33.0%
Código y marcado10.0%
Matemáticas3.0%
Chat y herramientas sintéticos2.4%

El flujo de chat es extractivo: las respuestas se copian de párrafos reales y los resultados de las herramientas se calculan en vez de inventarse. Enseña formato, no conocimiento. El tokenizador es un BPE a nivel de byte con 64,000 entradas; mete entre 3.3 y 4 bytes de texto en un token para cada idioma de escritura latina.

Tres errores que vale la pena contar

  • El modelo que leía la respuesta. En una ruta del código, las cabezas globales ignoraban la máscara causal y podían ver tokens futuros. La pérdida cayó de 6.85 a 1.71 en 75 pasos, y una corrida de 16 horas no sirvió para nada. Una pérdida sospechosamente buena es un reporte de error; ahora una prueba de regresión vigila exactamente esto.
  • Los caracteres no son bytes. La compresión se contaba en caracteres en vez de bytes UTF-8. Eso inventaba una “debilidad” en chino y hacía que el griego y el búlgaro parecieran casi el doble de malos de lo que son.
  • Documentos cortados en cada línea vacía. El codificador separaba los documentos en cada línea vacía, y hay líneas vacías en medio de casi cualquier archivo de código. Se perdió hasta el 35 % del texto de código y matemáticas. Corregimos el separador y reconstruimos todo el corpus el 31 de octubre; tomó 2 horas y 12 minutos.

Del escritorio a una máquina rentada

Los primeros 1,660 millones de tokens se entrenaron en una sola AMD Radeon RX 7800 XT. Dos cosas lo hicieron viable: una opción del kernel de atención que viene apagada –sin ella, la atención era 12 veces más lenta– y compilar cada capa con torch.compile. Con una mediana de 11,800 tokens por segundo, el resto habría tardado casi cinco días más.

Entonces escribimos un piloto automático. Renta GPU en Vast.ai, sube código, corpus y checkpoint, entrena, se trae un checkpoint cada tres horas y se detiene antes de que se acabe el saldo. El 2 de noviembre pasó por tres máquinas que sus proveedores nunca llegaron a encender y luego se quedó con dos RTX 4070 Ti Super en Alemania por US$0.363 la hora. La carga de 15.4 GiB tardó 40 minutos.

Figura 5 Velocidad de entrenamiento Tokens por segundo del modelo de 320 M con una longitud de secuencia de 1,024 (mediana). Local: una AMD Radeon RX 7800 XT. Rentado: dos NVIDIA RTX 4070 Ti Super.
  1. Local, antes de optimizar 8,319
  2. Local, compilado 11,830
  3. Rentado, 2 GPU 41,367
Mostrar los datos
ConfiguraciónTokens/s
Local, antes de optimizar8,319
Local, compilado11,830
Rentado, 2 GPU41,367

41,400 tokens por segundo son 3.5 veces lo del escritorio. La parte rentada –4,800 millones de tokens en unas 33 horas– cuesta alrededor de US$12.

Dónde está Helix hoy

Figura 6 El entrenamiento hasta ahora Pérdida en nats por token; cuanto más baja, mejor. Reservado: texto con el que el modelo nunca se entrena. Entrenamiento: promedio por cada 50 millones de tokens; baja más rápido en el enfriamiento, en parte porque cambia la mezcla de datos. El eje termina en los 6,500 millones de tokens previstos.
  • Reservado
  • Entrenamiento

Pérdida (nats por token)

Miles de millones de tokens leídos

Mostrar los datos
Miles de millones de tokens leídosReservadoEntrenamiento
0.064.5714.261
0.553.7763.574
1.043.6943.469
1.543.5963.421
2.033.4263.238
2.523.3293.143
3.013.2913.113
3.503.2633.076
3.993.2253.079
4.493.2443.076
4.983.2183.036
5.353.1232.884

Al 3 de noviembre de 2026, Helix leyó 5,350 de sus 6,500 millones de tokens. Desde los 5,200 millones está en la fase de enfriamiento: la tasa de aprendizaje baja y la mezcla se desplaza hacia matemáticas, código y chat. En texto reservado de todos los flujos está en 3.12 nats por token.

Figura 7 Dónde está cada idioma Bits por byte en texto reservado después de 5,350 millones de tokens; cuanto más bajo, mejor. El griego y el búlgaro parecen mejores en parte porque cada una de sus letras ocupa dos bytes.
  1. griego 0.721
  2. búlgaro 0.844
  3. francés 1.065
  4. inglés 1.086
  5. español 1.135
  6. portugués 1.219
  7. alemán 1.257
  8. neerlandés 1.268
  9. italiano 1.277
  10. polaco 1.355
  11. danés 1.364
  12. húngaro 1.407
  13. eslovaco 1.412
  14. maltés 1.415
  15. rumano 1.416
  16. sueco 1.418
  17. irlandés 1.422
  18. esloveno 1.431
  19. checo 1.444
  20. lituano 1.450
  21. letón 1.451
  22. croata 1.507
  23. finés 1.508
  24. estonio 1.727
Mostrar los datos
IdiomaBits por byte
griego0.721
búlgaro0.844
francés1.065
inglés1.086
español1.135
portugués1.219
alemán1.257
neerlandés1.268
italiano1.277
polaco1.355
danés1.364
húngaro1.407
eslovaco1.412
maltés1.415
rumano1.416
sueco1.418
irlandés1.422
esloveno1.431
checo1.444
lituano1.450
letón1.451
croata1.507
finés1.508
estonio1.727

Lo que eso significa en la práctica se ve mejor en una muestra sin editar de un checkpoint de unos 4,900 millones de tokens. El comienzo es nuestro; el resto, de Helix:

Muestra en inglés, checkpoint con 4,900 millones de tokens, sin editar

Inicio: The history of the printing press begins in the fifteenth century, when Johannes Gutenberg introduced movable type to Europe. Before that, books Salida del modelo: for printing were usually in the form of texts, usually in the format of illustrations. In its introduction to the printing press, Gutenberg uses one line-of-action model to illustrate a series of printed pieces of a book.

La gramática, la elección de palabras y el tema se sostienen; los hechos, no. Es más o menos lo que se puede esperar de 320 millones de parámetros y 6,500 millones de tokens: un modelo fluido que inventa cosas.

Lo que sigue

El preentrenamiento termina en unas horas. Después vienen una fase de contexto largo con libros del Project Gutenberg y textos jurídicos europeos de EUR-Lex, un ajuste fino para conversación y uso de herramientas, y un pequeño modelo borrador que acelera la generación.

Volver a todos los artículos

Siguiente paso

¿Qué debería existir a continuación?

Cuéntenos sobre su juego, su aplicación, su sitio web o su proyecto de IA. Un mensaje breve basta para empezar.