# Hvorfor det er så vanskelig å trene MoEs Nylig har jeg funnet ut at jeg ønsker et lite, forskningsfokusert opplæringsrepo Som jeg kan gjøre små eksperimenter på raskt og enkelt. Disse eksperimentene varierer fra å prøve ut nye Attention-arkitekturer (MLA, SWA, NSA, KDA – alle pluggbare) til multipresisjonstrening til de fleste Nylig multioptimalisatoroppsett med 'nye' optimalisatorer. Jeg prøvde de tre store utfordrere (Nemo, Megatron og Torchtitan), men av mange og ulike grunner har de Det passet absolutt ikke for mine formål, og var alle ganske smertefulle å gjøre Sett opp, bruk og få i gang stabilt. Jeg savnet nok en gang verktøyene mine fra Google og omskrive produksjonstreningsstakken min for dette formålet (som er skreddersydd laget for stor infrastruktur, overvåking og stabilitet) føltes også som en fattig Bruk av tid og vil gjøre både det gamle og det nye repoet dårligere på grunn av det. Dette fikk meg imidlertid til å tenke: hvorfor var trening av grensekvalitet 'litt lite'? MoEs (si under 20 milliarder params totalt) så vanskelig? Hvorfor gjorde ikke Repo / Lib I ønsket allerede eksisterer? Etter å ha tenkt på det en stund, har det meste av Utfordringene jeg kunne komme opp med, handlet om tre forskjellige ting: - flops / flop-effektivitet - lastbalansering / ruterstabilitet - datakvalitet og -kvantitet Flops Å trene tette modeller er ganske enkelt nå til dags. Treningen Dynamikken er stort sett koblet, og hvis du har nok parametere i arkitekturen, Modellen vil stort sett lære til tross for dine mange feil (dette har bitt meg fast rumpa mer enn én gang). [DeepSeek-stil ultra-tynt]( MoEs er annerledes fordi treningsdynamikken din er annerledes noe frakoblet. Bare en del av MLP-ene dine er aktive for en gitt token, Og etter hvert som opplæringen pågår, endrer og utvikler de aktive ekspertene seg over tid. Dette er hva gjør multi-epoketrening og dataomformulering så effektiv for MoE-er (spesielt større). Du får store inferens-effektivitetsgevinster og små Treningseffektivitet vinner, men på bekostning av frakoblede treningsdynamikker (gjør det er vanskelig å trene forutsigbart og stabilt) og du må dumpe mange flere flopper For å sikre at du lærer en noenlunde optimal rutepolitikk og at ekspertene Involvert i de ulike politikkene er tilstrekkelig opplært. Vel, det er her Flops / flop-effektivitetsutfordring oppstår. Den første utfordringen er at, ved natur, ultra-sparsomme MoE-er tar opp en enorm mengde HBM for å fylle opp eksperter, men betyr at du har mange GPU-er som kreves, og dermed mange inaktive GPU-er Systemet ditt. FSDP (og de ulike andre sharding-topologiene) er stort sett en relikvie med tett opplæring, og gjør ikke en særlig god jobb med å utnytte alle tilstrekkelig de strandede floppene. Dette fører til (lave) ensifrede MFU-er for de fleste ultra-sparsom MoE-trening. Og selv om det finnes noen få måter å håndtere det på At (mye mer om dette i fremtiden) fokuserte jeg på to spesifikke ting: - ny sharding-topologi (et nytt ekspert-parallelt dispatch-system som holder GPU-er opptatt) - blandet presisjonstrening Lastbalansering / ruterstabilitet Jeg lar den nye sharding-topologien være en egen egen gjennomgang, men blandet presisjonstrening er en selvfølge. Du har alt dette strandede HBM, så reduser ekspertpresisjon og kutt det med 1/2 eller 1/4 (henholdsvis fp8 og nvfp4). Det er bra i teorien, men i praksis krever blandet presisjonstrening vanligvis MER HBM siden du må holde mastervektene og gradene dine i høyere presisjon, deretter kvantisere mastervektene ned til lavere presisjon og cache dem for neste fremoverpass. Så det hjelper på inferenseffektiviteten (noe som er en stor seier etter hvert som flere flopper går til RL og inferens), men på bekostning av enda mer HBM og flere flopper under treningen. Å redusere overhead med blandet presisjon bør være et spesifikt fokusområde. Men alt du berører som reduserer presisjon og nøyaktighet på vektene, fører til slutt til ustabilitet i resten av treningsdynamikken. For MoE er det første stedet dette vanligvis viser seg ruterstabilitet. DeepSeek-V3 tekniske rapport beskriver et veldig elegant aux tapsfritt treningsoppsett hvor det er svært få knotter og dynamikken er veldig tydelig. Dette er tydeligvis verktøy designet for den erfarne brukeren, da det er utrolig vanskelig å få dynamikken riktig med bare noen få knotter. Avgjørende er det at DeepSeek i stor grad er avhengig av enorme batch-størrelser for å stabilisere ruterene sine – en luksus vi ikke har når vi forsker på begrenset maskinvare. Så vi må jobbe ekstra hardt for å gjøre våre små oppdrag stabile, effektive og informative. Da jeg begynte å eksperimentere med å replikere oppsettet deres, spesielt for eksperter med blandet presisjon, ble det veldig tydelig at kandidatene var altfor små for fp8 eller nvfp4, noe som gjorde at ruterne ikke lærte og ekspertene sultet. Jeg prøvde alt mulig for å få dette til å fungere først med redusert presisjon bakover, og til slutt til og med med fp32 master weights og grads, men freserkollapsen vedvarte. En godt timet artikkel var Character AI-blogginnlegget som beskrev deres ulike int8-stabilitetsintervensjoner. Jeg prøvde alle, men de endte opp med å gjøre systemet mye, mye mindre stabilt. Så jeg gikk gjennom dem én om gangen. Den første var muP-embedding-skalering på 10,66 og logits-skalering på 0,125. Det var mange åpenbare fordeler her utover ruterstabilitet, men én klar ting disse skaleringene gjorde, var å ta de veldig, veldig små fp8- og nvfp4-ekspertkandidatene og skalere dem til det punktet hvor RUTEREN ENDELIG LÆRTE! Disse seirene førte imidlertid også til at bf16-gradnormen eksploderte fullstendig, og den 'normale beste praksisen' for gradklipping og grad-skalering hindret læring i å skje. Så, løsningen? Fjern all klipping og YOLO! Til slutt hadde vi stabil opplæring i blandet presisjonsrutere. Den andre Kaiju-intervensjonen som viste seg å være utrolig nyttig, var en enkelt bungee-virtuell skalar på utgangen av ekspertens pre-output-norm, initialisert ved 2,0 for å matche BF16-gradskalaen, og dermed treningsdynamikk slik at nvfp4 og fp8 mer eller mindre presenterte de samme tapkurvene som baseline BF16-treningsløpene (FP8-BF16-gapet redusert fra ~0,8 til <0,1 på 3 000 steg). Det finnes mange flere triks og 'beste praksiser' som brukes her (mer om alle disse i fremtidige innlegg også), men overskriftene var: - legge til muP-skalering - fjerne all annen klipping og leve på villsiden - Bungee virtuell skalar pre-output norm - Hold aux tapsfrie og tokenvalg-ruting (fordi vi vet forskjellen på rett og galt i dette huset) Data Nå som vi hadde rimelig stabile treningsdynamikker, ble det klart at hvis jeg noen gang ville dele dette repoet med noen, ville vi trenge bedre data for virkelig å få mest mulig ut av denne treningsbiblioteket. En annen godt timet utgivelse var [OLMo-3]( med sin åpne kildekode datablandingsoppskrift (shout out Ai2!!). Men da jeg prøvde å bruke OLMo-3-blandingen direkte fra huggingface, fikk jeg ganske dårlige resultater (sammenlignet med mitt vanlige FineWeb-Edu-utgangspunkt). Så begynte datautforskingen og ... Datasettene var ganske skitne. Så jeg gjorde det enhver gal person ville gjort, og satte meg fore å bygge en grenseinspirert datapipeline slik at jeg virkelig kunne få mest mulig ut av dette treningsarkivet. Rørledningen har noen få nøkkelkomponenter: - **Heuristiske pre-filtre**: Språk-ID, lengdefiltre, MinHash-dedup, n-gram repetisjon, perplexitetsutbrudd, toksisitet – standard for å fjerne åpenbart søppel før GPU-sykluser brukes - **SeqIO-lignende dynamiske blandinger**: Deterministisk, gjenopptatt sampling som opprettholder målforholdene dine (40 % CC, 20 % kode, osv.) uavhengig av totalt tokenbudsjett – kritisk for proxy-kjøringer hvor du ikke trener på 6,7T-tokens - **Modellbasert kvalitetsscore**: Her blir det interessant For kvalitetsvurderingen fulgte jeg [Seed-Coder](-mønsteret: bruk store orakelmodeller for å generere treningsetiketter, og destillerer deretter til en rask klassifikator. Jeg eksperimenterte først med noen orakelmodeller (Kimi-K2, DeepSeek-V3.2 og [gpt-oss](120B)), men endte opp med å beholde kun 120B-klassen som orakler – de var konsekvent best til nyanserte kvalitetsvurderinger. Oraklene scoret et utvalg av data på tvers av fem dimensjoner for generelt innhold (hjelpsomhet, korrekthet, sammenheng, kompleksitet, ordrikdom – hver 0-4) og fire dimensjoner for kode (lesbarhet, modularitet, klarhet, gjenbruk – hver 0-10). Deretter tok jeg en frossen GPT-kast 20B ryggrad og festet to små hoder: - **Probehode** på lag 18: Mean-pooled skjulte tilstander → lineær(2880→5). Ultra billig, fanger åpenbart søppel tidlig - **Judge head** på lag 24: Full sekvensoppmerksomhet → liten transformator-encoder → Linear(512→5). Dyrere, men fanger opp nyanserte kvalitetsproblemer Designet for tidlig utgang er nøkkelen – hvis Probe scorer under terskelen, hopper vi over Judge helt. I stor skala sparer dette ~15 % beregning samtidig som kvaliteten opprettholdes. Tersklene (τ_drop, τ_keep) kalibreres på et holdt ut-satt sett for å nå målets lagringshastigheter. Til min overraskelse var min beholdningsrate for OLMo-3-datasettet omtrent 30 % for CC og internettkilder, og 50 % for kode, matematikk og naturfag. Det er mye filtrering, men proxy-modellvurderingene viste tydelige forbedringer sammenlignet med det ufiltrerte utgangspunktet. Vi hadde endelig et rimelig funksjonelt system som tilnærmet alt jeg elsket med min storskala treningsinfrastruktur og de flotte verktøyene jeg hadde brukt før, men som var spesiallaget for å trene små MoE-er til forskning og små modellproduksjoner. Imidlertid hadde repoet blitt ødelagt som følge av konstant eksperimentering og feilsøking. I tillegg består utviklingsteamet mitt av meg og en flåte av AI-agenter. Som Vik nylig sa: «Lev etter sloppet, dø etter sloppet», og selv om jeg vanligvis er veldig flittig og streng på 'INGEN SLAM I DETTE HUSET', lå restene fra hele nattens feilsøking og lik av ulike forlatte eksperimenter strødd rundt i repoet mitt. Konfigurasjons- og bootstrapping-kompleksiteten hadde også eksplodert. Det som startet inspirert av [nanochat]( så nå mye mer ut som Megatron (ingen fornærmelse). Resultatet? Vi kan nå gjøre meningsfull MoE-forskning på begrenset maskinvare – en 7B2A-proxy på en enkelt B200-GPU, en 16B4A på en enkelt 8×B200-node – begge når 30-40k tokens/sek/GPU. Enda viktigere er at skaleringen er forutsigbar: våre 1→8 GPU-kjøringer viser konsistent oppførsel, noe som gir oss tillit til at forskning gjort på små proxyer vil overføres til større løp. Vi skal validere skalering av 32 og 64 GPU neste gang. Løsningen? Start på nytt og skriv alt på nytt fra bunnen av, med motivasjon til å dele det med det større fellesskapet. Så det er det jeg gjør nå. I løpet av de neste ukene vil jeg slippe ulike treningsarkiver, blogginnlegg, datavurderingsmodellvekter og w&b-lignende visualiserings- og eksperimentsporingssystemer til fellesskapet. Det finnes også en veikart med fullstendige inferensmotorer osv. på horisonten. Det kommer til å ta litt lengre tid enn jeg hadde håpet, både på grunn av ambisjonen og full omskriving, men jeg håper fellesskapet finner dette like nyttig som jeg har gjort. --- Referanser: - [DeepSeek-V3 teknisk rapport]( - [Inside Kaiju: Bygging av samtalemodeller i stor skala]( - [Moonlight: Et beregningseffektivt MoE-treningsrammeverk]( - [Teknisk rapport for frøkoder]( - [OLMo-3: Den beste fullt åpne modellen i sin klasse]( (bilde av en tidlig FP8-treningskjøring fra NVIZ-dashbordet)

Du kan nå laste opp filer til Ramp Sheets. Se agenten lese inn en pitch-presentasjon, undersøke konkurrenter på nettet, og reverse-engineere en fullstendig driftsmodell og verdivurdering fra én enkelt PDF.