Pesquisa
Helix, parte 1: treinando um modelo de linguagem europeu
Estamos treinando nosso próprio modelo de linguagem. Ele é pequeno – 320 milhões de parâmetros –, mas lê os 24 idiomas oficiais da União Europeia e treina em placas de vídeo feitas para games. Esta primeira parte conta como chegamos até aqui; a segunda sai quando o treino terminar.

Sumário
Por que um estúdio de games treina um modelo de linguagem
A NETBYTE cria games, aplicativos e sites. Cada vez mais, esses produtos trazem modelos de linguagem dentro deles: personagens que respondem, ajuda que entende uma pergunta, ferramentas que fazem alguma coisa. A maioria dos modelos abertos pensa primeiro em inglês; estoniano, irlandês ou maltês ficam para depois. Queríamos entender a cadeia inteira por conta própria – dados, tokenizador, arquitetura, treino – e descobrir para onde o dinheiro vai de verdade.
- parâmetros
- 320 mi
- idiomas oficiais da UE
- 24
- tokens de treino
- 6,5 bi
- pelas GPUs alugadas
- ≈ US$ 12
O Helix nasceu como protótipo de pesquisa. Tudo o que vem a seguir é uma decisão que deu forma a ele, cada uma apoiada em uma medição – e os erros que mais nos custaram tempo.
Quatro ideias, uma sobrevivente
O protótipo atacava quatro fraquezas conhecidas dos geradores de texto atuais. Ele escreve em blocos de 16 tokens em vez de um token por vez, pode percorrer várias vezes um núcleo compartilhado de camadas, prevê um “plano” compacto para cada bloco e combina atenção local barata com atenção linear para longas distâncias.
A escrita em blocos funcionou de cara: um pequeno modelo de teste escreveu 64 tokens em 13 passagens pela rede, enquanto um modelo convencional precisa de uma passagem por token – cerca de um quinto do trabalho. As outras três ideias falharam em um teste mais difícil. Montamos tarefas em que a resposta fica muito além da janela local, então o modelo precisa olhar para trás no texto inteiro.
Mostrar os dados
| Variante | Certas |
|---|---|
| Só janela local | 23,1% |
| + atenção linear, plano e loops | 23,1% |
| + 2 cabeças globais exatas | 49,4% |
| Atenção completa (controle) | 49,0% |
| Acaso (25 %) | 25,0% |
Só a atenção exata por toda a distância resolveu essas tarefas. Atenção linear, plano e loops ficaram no nível do acaso; o otimizador chegou a reduzir a memória linear a uma meia-vida de menos de um token. Duas cabeças globais exatas bastaram para empatar com a atenção completa.
Por isso, o modelo final mantém em cada camada oito cabeças locais com janela de 256 tokens e adiciona duas cabeças globais exatas a cada duas camadas; as camadas intermediárias mantêm duas cabeças de atenção linear com gate. Plano e loops estão desligados. Eles continuam no código e testados, mas em texto real não compensaram o custo.
- Local, janela de 256 tokens
- Atenção global exata
- Atenção linear com gate
Mostrar os dados
| Tipo de cabeça | Camadas | Cabeças por camada |
|---|---|---|
| Local, janela de 256 tokens | 1–12 | 8 |
| Atenção global exata | 1, 3, 5, 7, 9, 11 | 2 |
| Atenção linear com gate | 2, 4, 6, 8, 10, 12 | 2 |
Medir em vez de supor
Testamos cada truque de treino em um modelo de 94 milhões de parâmetros com o mesmo orçamento por execução: 29,5 milhões de tokens, a mesma seed, a mesma ordem dos dados. Duas execuções da mesma configuração diferem em ±0,03, então qualquer coisa menor que isso é ruído.
Mostrar os dados
| Mudança | Δ perda (nats) |
|---|---|
| Muon + cronograma WSD | -0,587 |
| Otimizador Muon | -0,347 |
| Rede mais profunda e estreita | -0,099 |
| Cronograma WSD | -0,080 |
| Residual de valores | -0,007 |
| z-loss | +0,029 |
| Atenção com consultas agrupadas | +0,088 |
O otimizador Muon foi a única grande alavanca, e ele se combina com um cronograma de taxa de aprendizado warmup-stable-decay. Devolver o embedding e a camada de saída ao AdamW, como recomendam os autores do Muon, trouxe mais 0,12 e deixou o treino 5 % mais rápido. Combinações não simplesmente se somam: uma rede mais profunda e estreita ajudava com AdamW e atrapalhava com Muon. Por isso cada combinação promissora ganhou sua própria execução.
24 idiomas, 6,5 bilhões de tokens
O Helix lê texto da web do FineWeb-Edu para o inglês e do FineWeb-2 para os outros 23 idiomas – nos maiores, do décimo superior filtrado por qualidade. Código, matemática e um pequeno fluxo de chat sintético completam a mistura. O inglês fica com um terço. Os outros idiomas são ponderados pela quantidade de texto disponível, suavizada para que irlandês e maltês não sejam engolidos, e nenhuma fonte se repete mais de quatro vezes – até esse ponto, repetir vale quase tanto quanto dados novos.
Mostrar os dados
| Fonte | Porcentagem |
|---|---|
| Outros 23 idiomas da UE | 51,6% |
| Inglês | 33,0% |
| Código e marcação | 10,0% |
| Matemática | 3,0% |
| Chat e ferramentas sintéticos | 2,4% |
O fluxo de chat é extrativo: as respostas são copiadas de parágrafos reais, e os resultados das ferramentas são calculados em vez de inventados. Ele ensina formato, não conhecimento. O tokenizador é um BPE em nível de byte com 64.000 entradas; ele coloca entre 3,3 e 4 bytes de texto em um token para todo idioma de escrita latina.
Três bugs que valem a história
- O modelo que lia a resposta. Em um caminho do código, as cabeças globais ignoravam a máscara causal e conseguiam ver tokens futuros. A perda caiu de 6,85 para 1,71 em 75 passos, e uma execução de 16 horas foi jogada fora. Uma perda suspeitamente boa é um relatório de bug; agora um teste de regressão vigia exatamente isso.
- Caracteres não são bytes. A compressão era contada em caracteres em vez de bytes UTF-8. Isso inventou uma “fraqueza” no chinês e fez grego e búlgaro parecerem quase duas vezes piores do que são.
- Documentos quebrados em cada linha em branco. O codificador separava os documentos em cada linha vazia – e há linhas vazias no meio de quase todo arquivo de código. Até 35 % do texto de código e matemática se perdeu. Corrigimos o separador e reconstruímos o corpus inteiro em 31 de outubro; levou 2 horas e 12 minutos.
Da mesa para uma máquina alugada
Os primeiros 1,66 bilhão de tokens rodaram em uma única AMD Radeon RX 7800 XT. Duas coisas tornaram isso viável: uma flag do kernel de atenção que vem desligada – sem ela, a atenção era 12 vezes mais lenta – e compilar cada camada com torch.compile. Com uma mediana de 11.800 tokens por segundo, o resto ainda levaria quase cinco dias.
Então escrevemos um piloto automático. Ele aluga GPUs na Vast.ai, envia código, corpus e checkpoint, treina, traz um checkpoint para casa a cada três horas e para antes de o crédito acabar. Em 2 de novembro, passou por três máquinas que os provedores nunca chegaram a iniciar e depois ficou com duas RTX 4070 Ti Super na Alemanha por US$ 0,363 a hora. O upload de 15,4 GiB levou 40 minutos.
Mostrar os dados
| Configuração | Tokens/s |
|---|---|
| Local, antes da otimização | 8.319 |
| Local, compilado | 11.830 |
| Alugado, 2 GPUs | 41.367 |
41.400 tokens por segundo são 3,5 vezes o que a mesa fazia. A parte alugada – 4,8 bilhões de tokens em cerca de 33 horas – custa por volta de US$ 12.
Onde o Helix está hoje
- Reservado
- Treino
Perda (nats por token)
Bilhões de tokens lidos
Mostrar os dados
| Bilhões de tokens lidos | Reservado | Treino |
|---|---|---|
| 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 |
Em 3 de novembro de 2026, o Helix já leu 5,35 dos seus 6,5 bilhões de tokens. Desde 5,2 bilhões ele está na fase de resfriamento: a taxa de aprendizado cai e a mistura se desloca para matemática, código e chat. Em texto reservado de todos os fluxos, está em 3,12 nats por token.
Mostrar os dados
| Idioma | Bits por byte |
|---|---|
| grego | 0,721 |
| búlgaro | 0,844 |
| francês | 1,065 |
| inglês | 1,086 |
| espanhol | 1,135 |
| português | 1,219 |
| alemão | 1,257 |
| holandês | 1,268 |
| italiano | 1,277 |
| polonês | 1,355 |
| dinamarquês | 1,364 |
| húngaro | 1,407 |
| eslovaco | 1,412 |
| maltês | 1,415 |
| romeno | 1,416 |
| sueco | 1,418 |
| irlandês | 1,422 |
| esloveno | 1,431 |
| tcheco | 1,444 |
| lituano | 1,450 |
| letão | 1,451 |
| croata | 1,507 |
| finlandês | 1,508 |
| estoniano | 1,727 |
O que isso quer dizer na prática aparece melhor em uma amostra sem edição de um checkpoint com cerca de 4,9 bilhões de tokens. O começo é nosso, o resto é do Helix:
Início: The history of the printing press begins in the fifteenth century, when Johannes Gutenberg introduced movable type to Europe. Before that, books
Saída do 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.
Gramática, escolha de palavras e tema se sustentam; os fatos, não. É mais ou menos o que se pode esperar de 320 milhões de parâmetros e 6,5 bilhões de tokens: um modelo fluente que inventa coisas.
O que vem por aí
O pré-treino termina em poucas horas. Depois vêm uma fase de contexto longo com livros do Project Gutenberg e textos jurídicos europeus do EUR-Lex, um ajuste fino para conversa e uso de ferramentas, e um pequeno modelo de rascunho que acelera a geração.