NETBYTE
Iniciar um projeto

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.

Por Marcus Weitschat 8 min de leitura

Matriz de pontos mostrando no que cada token do Helix pode prestar atenção: uma faixa azul para a janela local, pontos amarelos para o próprio bloco e pontos laranja espalhados para a recuperação a longa distância.

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.

Figura 1 Recuperação a longa distância Porcentagem de respostas certas em uma tarefa de recuperação cuja pista fica fora da janela local. Pequeno modelo de referência, mesmo orçamento para cada variante.
  1. Só janela local 23,1%
  2. + atenção linear, plano e loops 23,1%
  3. + 2 cabeças globais exatas 49,4%
  4. Atenção completa (controle) 49,0%
Mostrar os dados
VarianteCertas
Só janela local23,1%
+ atenção linear, plano e loops23,1%
+ 2 cabeças globais exatas49,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.

Figura 2 Para onde cada camada olha Dez cabeças de atenção por camada, doze camadas. Cada camada tem oito cabeças locais; as camadas ímpares adicionam duas cabeças globais exatas, e as pares, duas cabeças de atenção linear com gate.
  • Local, janela de 256 tokens
  • Atenção global exata
  • Atenção linear com gate
Mostrar os dados
Tipo de cabeçaCamadasCabeças por camada
Local, janela de 256 tokens1–128
Atenção global exata1, 3, 5, 7, 9, 112
Atenção linear com gate2, 4, 6, 8, 10, 122

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.

Figura 3 O que ajudou – e o que era ruído Variação da perda de validação em relação à referência com AdamW. Modelo de 94 mi de parâmetros, 29,5 milhões de tokens por execução. Abaixo de zero é melhor; a faixa cinza é o ruído entre execuções (±0,03).
  1. Muon + cronograma WSD -0,587
  2. Otimizador Muon -0,347
  3. Rede mais profunda e estreita -0,099
  4. Cronograma WSD -0,080
  5. Residual de valores -0,007
  6. z-loss +0,029
  7. Atenção com consultas agrupadas +0,088
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.

Figura 4 O que o Helix lê Porcentagem dos tokens de treino por grupo de fontes. Corpus de 6,5 bilhões de tokens em 34 fluxos; código e marcação abrange Python, JavaScript, C, C++, Java, HTML, CSS e Markdown.
  1. Outros 23 idiomas da UE 51,6%
  2. Inglês 33,0%
  3. Código e marcação 10,0%
  4. Matemática 3,0%
  5. Chat e ferramentas sintéticos 2,4%
Mostrar os dados
FontePorcentagem
Outros 23 idiomas da UE51,6%
Inglês33,0%
Código e marcação10,0%
Matemática3,0%
Chat e ferramentas sintéticos2,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.

Figura 5 Velocidade de treino Tokens por segundo do modelo de 320 mi com comprimento de sequência de 1.024 (mediana). Local: uma AMD Radeon RX 7800 XT. Alugado: duas NVIDIA RTX 4070 Ti Super.
  1. Local, antes da otimização 8.319
  2. Local, compilado 11.830
  3. Alugado, 2 GPUs 41.367
Mostrar os dados
ConfiguraçãoTokens/s
Local, antes da otimização8.319
Local, compilado11.830
Alugado, 2 GPUs41.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

Figura 6 O treino até agora Perda em nats por token; quanto menor, melhor. Reservado: texto em que o modelo nunca treina. Treino: média a cada 50 milhões de tokens; cai mais rápido no resfriamento, em parte porque a mistura de dados muda. O eixo termina nos 6,5 bilhões de tokens previstos.
  • Reservado
  • Treino

Perda (nats por token)

Bilhões de tokens lidos

Mostrar os dados
Bilhões de tokens lidosReservadoTreino
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

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.

Figura 7 Onde cada idioma está Bits por byte em texto reservado depois de 5,35 bilhões de tokens; quanto menor, melhor. Grego e búlgaro parecem melhores em parte porque cada letra deles ocupa dois bytes.
  1. grego 0,721
  2. búlgaro 0,844
  3. francês 1,065
  4. inglês 1,086
  5. espanhol 1,135
  6. português 1,219
  7. alemão 1,257
  8. holandês 1,268
  9. italiano 1,277
  10. polonês 1,355
  11. dinamarquês 1,364
  12. húngaro 1,407
  13. eslovaco 1,412
  14. maltês 1,415
  15. romeno 1,416
  16. sueco 1,418
  17. irlandês 1,422
  18. esloveno 1,431
  19. tcheco 1,444
  20. lituano 1,450
  21. letão 1,451
  22. croata 1,507
  23. finlandês 1,508
  24. estoniano 1,727
Mostrar os dados
IdiomaBits por byte
grego0,721
búlgaro0,844
francês1,065
inglês1,086
espanhol1,135
português1,219
alemão1,257
holandês1,268
italiano1,277
polonês1,355
dinamarquês1,364
húngaro1,407
eslovaco1,412
maltês1,415
romeno1,416
sueco1,418
irlandês1,422
esloveno1,431
tcheco1,444
lituano1,450
letão1,451
croata1,507
finlandês1,508
estoniano1,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:

Amostra em inglês, checkpoint com 4,9 bilhões de tokens, sem edição

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.

Voltar para todos os artigos

Próximo passo

O que deve existir a seguir?

Conte para nós sobre seu jogo, seu aplicativo, seu site ou seu projeto de IA. Uma mensagem curta já basta para começar.