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.

Contenido
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.
Mostrar los datos
| Variante | Correctas |
|---|---|
| Solo ventana local | 23,1 % |
| + atención lineal, plan y bucles | 23,1 % |
| + 2 cabezas globales exactas | 49,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.
- Local, ventana de 256 tokens
- Atención global exacta
- Atención lineal con compuerta
Mostrar los datos
| Tipo de cabeza | Capas | Cabezas por capa |
|---|---|---|
| Local, ventana de 256 tokens | 1–12 | 8 |
| Atención global exacta | 1, 3, 5, 7, 9, 11 | 2 |
| Atención lineal con compuerta | 2, 4, 6, 8, 10, 12 | 2 |
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.
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.
Mostrar los datos
| Fuente | Porcentaje |
|---|---|
| Otras 23 lenguas de la UE | 51,6 % |
| Inglés | 33,0 % |
| Código y marcado | 10,0 % |
| Matemáticas | 3,0 % |
| Chat y herramientas sintéticos | 2,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.
Mostrar los datos
| Configuración | Tokens/s |
|---|---|
| Local, antes de optimizar | 8319 |
| Local, compilado | 11.830 |
| Alquilado, 2 GPU | 41.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
- Reservado
- Entrenamiento
Pérdida (nats por token)
Miles de millones de tokens leídos
Mostrar los datos
| Miles de millones de tokens leídos | Reservado | Entrenamiento |
|---|---|---|
| 0,06 | 4,571 | 4,261 |
| 0,55 | 3,776 | 3,574 |
| 1,04 | 3,694 | 3,469 |
| 1,54 | 3,596 | 3,421 |
| 2,03 | 3,426 | 3,238 |
| 2,52 | 3,329 | 3,143 |
| 3,01 | 3,291 | 3,113 |
| 3,50 | 3,263 | 3,076 |
| 3,99 | 3,225 | 3,079 |
| 4,49 | 3,244 | 3,076 |
| 4,98 | 3,218 | 3,036 |
| 5,35 | 3,123 | 2,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.
Mostrar los datos
| Lengua | Bits por byte |
|---|---|
| griego | 0,721 |
| búlgaro | 0,844 |
| francés | 1,065 |
| inglés | 1,086 |
| español | 1,135 |
| portugués | 1,219 |
| alemán | 1,257 |
| neerlandés | 1,268 |
| italiano | 1,277 |
| polaco | 1,355 |
| danés | 1,364 |
| húngaro | 1,407 |
| eslovaco | 1,412 |
| maltés | 1,415 |
| rumano | 1,416 |
| sueco | 1,418 |
| irlandés | 1,422 |
| esloveno | 1,431 |
| checo | 1,444 |
| lituano | 1,450 |
| letón | 1,451 |
| croata | 1,507 |
| finés | 1,508 |
| estonio | 1,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:
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.