Helix, del 1: vi trener en europeisk språkmodell

Hvorfor et spillstudio trener en språkmodell

NETBYTE lager spill, apper og nettsteder. Språkmodeller sitter stadig oftere inne i slike produkter: som figurer som svarer, som hjelp som forstår et spørsmål, som verktøy som gjør noe. De fleste åpne modeller tenker engelsk først; estisk, irsk eller maltesisk havner i utkanten. Vi ville forstå hele kjeden selv – data, tokenizer, arkitektur, trening – og finne ut hvor pengene egentlig går.

parametere

320 mill.

offisielle EU-språk

24

treningstokens

6,5 mrd.

for de leide GPU-ene

≈ 12 $

Helix begynte som en forskningsprototype. Alt nedenfor er en beslutning som formet den, hver av dem støttet av en måling – pluss feilene som kostet oss mest tid.

Fire ideer, én overlevde

Prototypen gikk etter fire kjente svakheter ved dagens tekstgeneratorer. Den skriver i blokker på 16 tokens i stedet for ett token om gangen, den kan kjøre en felles kjerne av lag flere ganger, den forutsier en kompakt «plan» for hver blokk, og den blander billig lokal attention med lineær attention over lange avstander.

Blokkskrivingen virket med en gang: En liten testmodell skrev 64 tokens på 13 gjennomløp av nettverket, der en vanlig modell trenger ett gjennomløp per token – omtrent en femdel av arbeidet. De tre andre ideene strøk på en hardere test. Vi bygde oppgaver der svaret ligger langt utenfor det lokale vinduet, slik at modellen må se tilbake gjennom hele teksten.

Bare eksakt attention over hele avstanden løste dem. Lineær attention, plan og løkker ble liggende på tilfeldighetsnivå; optimalisereren hadde til og med skrudd det lineære minnet ned til en halveringstid på under ett token. To eksakte globale hoder var nok til å ta igjen full attention.

Den endelige modellen beholder derfor åtte lokale hoder med et vindu på 256 tokens i hvert lag og legger til to eksakte globale hoder i annethvert lag; lagene imellom beholder to hoder med portstyrt lineær attention. Plan og løkker er slått av. De ligger fortsatt i koden og er testet, men på ekte tekst tjente de ikke inn kostnaden.

Mål, ikke gjett

Vi testet hvert treningstriks på en modell med 94 millioner parametere og samme budsjett per kjøring: 29,5 millioner tokens, samme seed, samme datarekkefølge. To kjøringer av samme konfigurasjon skiller seg med ±0,03, så alt mindre er støy.

Muon-optimalisereren var den eneste store spaken, og den lar seg kombinere med en warmup-stable-decay-plan for læringsraten. Å flytte embedding og utdatalag tilbake til AdamW, slik Muon-forfatterne anbefaler, ga ytterligere 0,12 og gjorde treningen 5 % raskere. Kombinasjoner legges ikke bare sammen: Et dypere, smalere nettverk hjalp under AdamW og skadet under Muon. Derfor fikk hver lovende kombinasjon sin egen kjøring.

24 språk, 6,5 milliarder tokens

Helix leser nettekst fra FineWeb-Edu for engelsk og fra FineWeb-2 for de øvrige 23 språkene – for de største fra dens kvalitetsfiltrerte øverste tidel. Kode, matematikk og en liten syntetisk chattestrøm fullfører blandingen. Engelsk får en tredjedel. De andre språkene vektes etter hvor mye tekst som finnes, utjevnet slik at irsk og maltesisk ikke drukner, og ingen kilde gjentas mer enn fire ganger – fram til da er gjentakelse nesten like bra som ferske data.

Chattestrømmen er ekstraktiv: Svarene er kopiert fra ekte avsnitt, og verktøyresultater regnes ut i stedet for å bli funnet på. Den lærer bort format, ikke kunnskap. Tokenizeren er en BPE på bytenivå med 64 000 oppføringer; den pakker mellom 3,3 og 4 byte tekst inn i ett token for hvert språk med latinsk skrift.

Tre feil verdt å fortelle om

• Modellen som leste svaret. I én kodesti ignorerte de globale hodene den kausale masken og kunne se fremtidige tokens. Tapet falt fra 6,85 til 1,71 på 75 steg, og en kjøring på 16 timer var verdiløs. Et mistenkelig godt tap er en feilrapport; nå vokter en regresjonstest akkurat dette.
• Tegn er ikke byte. Komprimeringen ble talt i tegn i stedet for UTF-8-byte. Det fant opp en «svakhet» i kinesisk og fikk gresk og bulgarsk til å se nesten dobbelt så dårlige ut som de er.
• Dokumenter brutt ved hver tomme linje. Koderen delte dokumenter ved hver tomme linje – og tomme linjer står midt i nesten hver kildefil. Opptil 35 % av kode- og matematikkteksten gikk tapt. Vi rettet skilletegnet og bygde hele korpuset på nytt 31. oktober; det tok 2 timer og 12 minutter.

Fra skrivebordet til en leid maskin

De første 1,66 milliardene tokens kjørte på ett enkelt AMD Radeon RX 7800 XT. To ting gjorde det brukbart: et kjerneflagg for attention som er slått av som standard – uten det var attention 12 ganger tregere – og kompilering av hvert lag med torch.compile. Med en median på 11 800 tokens i sekundet ville resten ha tatt nesten fem dager til.

Så vi skrev en autopilot. Den leier GPU-er på Vast.ai, laster opp kode, korpus og sjekkpunkt, trener, henter et sjekkpunkt hjem hver tredje time og stopper før kreditten går tom. Den 2. november gikk den gjennom tre maskiner som leverandørene aldri startet, og landet så på to RTX 4070 Ti Super i Tyskland for 0,363 $ i timen. Opplastingen på 15,4 GiB tok 40 minutter.

41 400 tokens i sekundet er 3,5 ganger skrivebordet. Den leide delen – 4,8 milliarder tokens på rundt 33 timer – koster omkring 12 $.

Hvor Helix står i dag

Per 3. november 2026 har Helix lest 5,35 av sine 6,5 milliarder tokens. Siden 5,2 milliarder har den vært i nedkjølingsfasen: Læringsraten synker, og blandingen forskyves mot matematikk, kode og chat. På tilbakeholdt tekst fra alle strømmer ligger den på 3,12 nats per token.

Hva det betyr i praksis, ser man best i en uredigert prøve fra et sjekkpunkt ved omtrent 4,9 milliarder tokens. Begynnelsen er vår, resten er fra Helix:

Grammatikk, ordvalg og emne holder; fakta gjør det ikke. Det er omtrent det man kan vente seg av 320 millioner parametere og 6,5 milliarder tokens: en flytende modell som finner på ting.

Hva som skjer videre

Fortreningen er ferdig om noen timer. Deretter følger en fase med lang kontekst med bøker fra Project Gutenberg og EU-rettstekster fra EUR-Lex, finjustering for samtale og verktøybruk og en liten utkastmodell som gjør genereringen raskere.

Tilbake til alle innlegg