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.

Contenido
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.
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 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.
- 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 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.
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.
Mostrar los datos
| Fuente | Porcentaje |
|---|---|
| Otros 23 idiomas 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 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.
Mostrar los datos
| Configuración | Tokens/s |
|---|---|
| Local, antes de optimizar | 8,319 |
| Local, compilado | 11,830 |
| Rentado, 2 GPU | 41,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
- 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 |
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.
Mostrar los datos
| Idioma | 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 4,900 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 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.