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 las 24 lenguas oficiales de la Unión Europea y se entrena en tarjetas gráficas pensadas para videojuegos. Esta primera parte cuenta cómo hemos llegado hasta aquí; la segunda llegará cuando termine el entrenamiento.

Por Marcus Weitschat 8 min de lectura

Matriz de puntos de aquello en lo que cada token de Helix puede fijarse: 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, estos productos llevan dentro modelos de lenguaje: 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 llegan después. Queríamos entender toda la cadena por nosotros mismos –datos, tokenizador, arquitectura, entrenamiento– y averiguar adónde va realmente el dinero.

parámetros
320 M
lenguas oficiales de la UE
24
tokens de entrenamiento
6500 M
por las GPU alquiladas
≈ 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, y también los errores que más tiempo nos costaron.

Cuatro ideas, una superviviente

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

La escritura por bloques funcionó a la primera: 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 una quinta parte del trabajo. Las otras tres ideas fracasaron en una prueba más dura. Construimos tareas en las que la respuesta está muy fuera de la ventana local, de modo que el modelo tiene que mirar 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 bastaron 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 añade 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 compensaron su coste.

Figura 2 Qué mira cada capa Diez cabezas de atención por capa, doce capas. Cada capa tiene ocho cabezas locales; las capas impares añaden 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 ejecución: 29,5 millones de tokens, la misma semilla, el mismo orden de datos. Dos ejecuciones 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 ejecución. Por debajo de cero es mejor; la franja gris es el ruido entre ejecuciones (±0,03).
  1. Muon + calendario WSD -0,587
  2. Optimizador Muon -0,347
  3. Red más profunda y estrecha -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 estrecha-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. Devolver el embedding y la capa de salida a AdamW, como recomiendan los autores de Muon, aportó otro 0,12 y aceleró el entrenamiento un 5 %. Las combinaciones no se suman sin más: una red más profunda y estrecha ayudaba con AdamW y perjudicaba con Muon. Por eso cada combinación prometedora tuvo su propia ejecución.

24 lenguas, 6500 millones de tokens

Helix lee texto web de FineWeb-Edu para el inglés y de FineWeb-2 para las otras 23 lenguas; en las 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. Las demás lenguas se ponderan según cuánto texto existe, suavizado para que el irlandés y el maltés no queden ahogados, 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 6500 millones de tokens en 34 flujos; código y marcado abarca Python, JavaScript, C, C++, Java, HTML, CSS y Markdown.
  1. Otras 23 lenguas 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
Otras 23 lenguas 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 lugar 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 lengua 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 ejecución de 16 horas no sirvió de nada. Una pérdida sospechosamente buena es un informe de error; ahora una prueba de regresión vigila exactamente esto.
  • Los caracteres no son bytes. La compresión se contaba en caracteres en lugar 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 rotos 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 un 35 % del texto de código y matemáticas. Corregimos el separador y reconstruimos todo el corpus el 31 de octubre; tardó 2 horas y 12 minutos.

Del escritorio a una máquina alquilada

Los primeros 1660 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 desactivada –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.

Así que escribimos un piloto automático. Alquila 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 arrancar y luego se quedó con dos RTX 4070 Ti Super en Alemania por 0,363 $ la hora. La subida 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 1024 (mediana). Local: una AMD Radeon RX 7800 XT. Alquilado: dos NVIDIA RTX 4070 Ti Super.
  1. Local, antes de optimizar 8319
  2. Local, compilado 11.830
  3. Alquilado, 2 GPU 41.367
Mostrar los datos
ConfiguraciónTokens/s
Local, antes de optimizar8319
Local, compilado11.830
Alquilado, 2 GPU41.367

41 400 tokens por segundo son 3,5 veces lo del escritorio. La parte alquilada –4800 millones de tokens en unas 33 horas– cuesta unos 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: media 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 6500 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

A 3 de noviembre de 2026, Helix ha leído 5350 de sus 6500 millones de tokens. Desde los 5200 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 lengua Bits por byte en texto reservado tras 5350 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
LenguaBits 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 4900 millones de tokens. El comienzo es nuestro; el resto, de Helix:

Muestra en inglés, checkpoint con 4900 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 cabe esperar de 320 millones de parámetros y 6500 millones de tokens: un modelo fluido que se inventa cosas.

Lo que viene

El preentrenamiento termina en unas horas. Después vendrán 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é creamos a continuación?

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