# Varför det är så svårt att träna MoEs Nyligen har jag märkt att jag vill ha ett litet, forskningsfokuserat träningsrepo Som jag snabbt och enkelt kan göra små experiment på. Dessa experiment är av hela området från att prova nya uppmärksamhetsarkitekturer (MLA, SWA, NSA, KDA – alla pluggbara) till multiprecisionsträning för de flesta Nyligen har flera optimerare installerats med 'nya' optimerare. Jag testade de tre stora utmanare (Nemo, Megatron och Torchtitan) men av många och olika anledningar är de Det passade verkligen inte mina behov och var alla ganska smärtsamma att göra Ställ upp, använd och få igång stabilt. Jag missade återigen mina verktyg från Google och skriver om min produktionsutbildningsstack för detta ändamål (som är skräddarsydd gjord för stor infrastrukturövervakning och stabilitet) kändes också som en fattig Användning av tid och skulle göra både det gamla och det nya repoet sämre för det. Detta fick mig dock att fundera på varför utbildning av frontier-kvalitet var 'ganska liten' MoEs (säg under 20 miljarder params totalt) så svårt? Varför gjorde inte repoet / lib i vill redan existera? Efter att ha tänkt på det ett tag, de flesta av Utmaningar jag kunde komma på handlade om tre olika saker: - flops / flop-effektivitet - lastbalansering / routerstabilitet - datakvalitet och kvantitet Flops Att träna täta modeller är ganska enkelt nuförtiden. Utbildningen Dynamiken är mestadels kopplad, och om du har tillräckligt med parametrar i arkitekturen, Modellen lär sig i princip trots dina många misstag (detta har bitit mig i det rumpan mer än en gång). [DeepSeek-stil ultra-gles]( MoEs är annorlunda eftersom dina träningsdynamiker är något frikopplade. Endast en del av dina MLP:er är aktiva för en given token, Och när utbildningen fortskrider förändras och utvecklas de aktiva experterna över tid. Det här är vad gör multi-epokträning och dataomformulering så effektiv för MoEs (särskilt större). Du får stora vinster i inferenseffektivitet och små Träningseffektivitet vinner men på bekostnad av frikopplad träningsdynamik (gör det är svårt att träna förutsägbart och stabilt) och du måste dumpa många fler floppar För att se till att du lär dig en någorlunda optimal routningspolicy och att experterna Involverade i de olika policyerna är tillräckligt utbildade. Det är här Flops / Flop-effektivitetsutmaning uppstår. Den första utmaningen är att, genom natur, ultra-gles MoE:er tar upp en enorm mängd HBM för att fylla på experter men det innebär att du har många GPU:er som krävs och därmed många idle-GPU:er i ditt system. FSDP (och de olika andra sharding-topologierna) är mestadels en relik av tät träning, och gör inte ett särskilt bra jobb med att utnyttja alla på ett tillfredsställande sätt de där strandade flopparna. Detta leder till (låga) ensiffriga MFU för de flesta ultra-sparsam MoE-träning. Och även om det finns ett fåtal sätt att hantera det Att (mycket mer om detta i framtiden) fokuserade jag på två specifika saker: - ny sharding-topologi (ett nytt expert-parallellt dispatchsystem som håller GPU:er sysselsatta) - blandad precisionsträning Lastbalansering / Routerstabilitet Jag lämnar den nya sharding-topologin för en egen dedikerad genomgång, men mixed precision-träning är självklart. Du har allt detta strandade HBM, så minska expertprecisionen och skär ner det med 1/2 eller 1/4 (fp8 respektive nvfp4). Det är bra i teorin, men i praktiken kräver mixed precision-träning oftast MER HBM eftersom du måste hålla dina mastervikter och grads i högre precision, sedan kvantisera mastervikterna till dess lägre precisionsrepresentation och cachelagra dem för nästa framåtpass. Så det hjälper inferenseffektiviteten (vilket är en riktig vinst när fler flops går över till RL och inferens) men till priset av ännu mer HBM och fler flops under träningen. Att minska den blandade precisionsöverhuvudet är något som bör vara ett specifikt fokusområde. Men allt du rör vid som minskar vikternas precision och precision leder i slutändan till instabilitet i resten av träningsdynamiken. För MoE är det oftast först att detta syns routerstabilitet. DeepSeek-V3:s tekniska rapport beskriver en mycket elegant aux-förlustfri träningsuppställning där det finns väldigt få rattar och dynamiken är mycket tydlig. Detta är tydligt verktyg designade för den erfarna användaren eftersom det är otroligt svårt att få dynamiken rätt med bara några få rattar. Avgörande är att DeepSeek är starkt beroende av massiva batchstorlekar för att stabilisera sina routrar – en lyx vi inte har när vi forskar om begränsad hårdvara. Så vi måste arbeta extra hårt för att göra våra små löpningar stabila, effektiva och informativa. När jag började experimentera med att replikera deras setup, specifikt för experter med blandad precision, blev det väldigt tydligt att graderna var alldeles för små för fp8 eller nvfp4, vilket gjorde att routrarna inte lärde sig och experterna svalt ut. Jag försökte allt jag kunde för att få detta att fungera först med reducerad precision bakåtpassningar och till slut även med fp32 master weights och grads, men routerkollapsen fortsatte. En väl tajmad artikel var blogginlägget Character AI som beskrev deras olika int8-stabilitetsinterventioner. Jag testade alla men de gjorde systemet mycket, mycket mindre stabilt. Så jag gick igenom dem en i taget. Den första var muP-inbäddningsskalning på 10,66 och logitskalningen på 0,125. Det fanns en massa väldigt uppenbara fördelar här förutom routerstabilitet, men en tydlig sak dessa skalningar gjorde var att ta de väldigt, väldigt små fp8- och nvfp4-experterna och skala dem till den punkt där ROUTERN ÄNTLIGEN LÄRDE SIG! Men dessa vinster gjorde också att bf16-gradnormen exploderade fullständigt och den 'normala bästa praxis' för gradklippning och gradskalning hindrade all inlärning från att ske. Så, lösningen? Ta bort all klippning och Yolo! Slutligen hade vi stabil utbildning med blandade precisionsroutrar. Den andra Kaiju-interventionen som visade sig vara otroligt användbar var en enda bungee-virtuell skalär vid utdata från experternas pre-outputnorm, initierad vid 2,0 för att matcha bf16-gradskalan och därmed träna dynamiken så att nvfp4 och fp8 mer eller mindre visade samma förlustkurvor som baslinje-bf16-träningsrundorna (FP8-BF16-gapet minskat från ~0,8 till <0,1 vid 3 000 steg). Det finns många fler knep och 'bästa praxis' som används här (mer om alla dessa i framtida inlägg också), men rubrikerna var: - lägga till muP-skalning - ta bort all annan klippning och leva på vildsidan - bungee-virtuell skalär pre-output-norm - hålla Aux förlustfria och tokens val-routing (eftersom vi vet skillnaden mellan rätt och fel i detta hus) Data Nu när vi hade någorlunda stabila träningsdynamiker blev det tydligt att om jag någonsin ville dela detta repo med någon, skulle vi behöva bättre data för att verkligen få ut det mesta av denna träningsbibliotek. En annan väl tajmad release var [OLMo-3]( med sitt recept för öppen källkodsdatablandning (höll ut Ai2!!). Men när jag försökte använda OLMo-3-blandningen direkt från huggingface fick jag ganska dåliga resultat (jämfört med min typiska FineWeb-Edu-baslinje). Så började datautforskningen och ... Dataseten var ganska smutsiga. Så jag gjorde vad vilken galning som helst skulle göra och satte igång med att bygga en Frontier-inspirerad datapipeline för att verkligen få ut det mesta av detta träningsrepo. Pipelinen har några nyckelkomponenter: - **Heuristiska förfilter**: Språk-ID, längdfilter, MinHash-dedup, n-gram-upprepning, perplexitetsavvikare, toxicitet – standardgrejer för att ta bort uppenbart skräp innan GPU-cykler spenderas - **SeqIO-liknande dynamiska blandningar**: Deterministisk, återupptagbar sampling som bibehåller dina målkvoter (40 % CC, 20 % kod, etc) oavsett total tokenbudget – avgörande för proxykörningar där du inte tränar på 6,7T-tokens - **Modellbaserad kvalitetspoängsättning**: Här blir det intressant För kvalitetspoängsättningen följde jag [Seed-Coder](-mönstret: använd stora orakelmodeller för att generera träningsetiketter, destillera sedan till en snabb klassificerare. Jag experimenterade initialt med några orakelmodeller (Kimi-K2, DeepSeek-V3.2 och [gpt-oss](120B)) men slutade med att bara behålla 120B-klassmodellerna som orakler – de var konsekvent bäst på nyanserade kvalitetsbedömningar. Oraklen gav poäng åt ett urval av data över fem dimensioner för allmänt innehåll (hjälpsamhet, korrekthet, koherens, komplexitet, ordrikedom – varje 0–4) och fyra dimensioner för kod (läsbarhet, modularitet, klarhet, återanvändbarhet – varje 0–10). Jag tog sedan en fryst gpt-kast 20B ryggrad och fäste två små huvuden: - **Probehuvud** på lager 18: Medelpoolade dolda tillstånd → linjär(2880→5). Ultrabilligt, fångar uppenbart skräp tidigt - **Judge head** på lager 24: Full sekvensuppmärksamhet → liten transformatorkodare → linjär(512→5). Dyrare men fångar nyanserade kvalitetsproblem Designen för tidig utgång är avgörande – om Probe får poäng under tröskeln hoppar vi över Judge helt. I stor skala sparar detta ~15 % beräkning samtidigt som kvaliteten bibehålls. Trösklarna (τ_drop, τ_keep) kalibreras på en hållen inställd inställning för att nå målets behållningshastigheter. Till min förvåning var min samlingsgrad för OLMo-3-datasetet cirka 30 % för CC och internetkällor, och 50 % för kod, matematik och naturvetenskap. Det är mycket filtrering, men proxymodellutvärderingarna visade tydliga förbättringar jämfört med den ofiltrerade baslinjen. Vi hade äntligen ett någorlunda fungerande system som liknade allt jag älskade med min storskaliga utbildningsinfrastruktur och de fantastiska verktyg jag använt tidigare, men som var specialbyggt för att träna små MoE:er för forskning och små modellproduktioner. Men repoet hade blivit förstört på grund av det ständiga experimenterandet och felsökningen. Dessutom består mitt utvecklingsteam av mig och en flotta av AI-agenter. Som Vik nyligen sa, "Lev efter sörjan, dö efter sloppet" och även om jag normalt är mycket flitig och strikt med 'INGEN SÖRJA I DET HÄR HUSET', låg skräp från hela nattens felsökning och lik av olika övergivna experiment utspridda i mitt repo. Konfigurationen och bootstrapping-komplexiteten hade också exploderat. Det som började inspirerat av [nanochat]( såg nu mycket mer ut som Megatron (ingen förolämpning). Resultatet? Vi kan nu göra meningsfull MoE-forskning på begränsad hårdvara – en 7B2A-proxy på ett enda B200-grafikkort, en 16B4A på en enda 8×B200-nod – båda når 30–40 000 tokens/sek/GPU. Viktigare är att skalningen är förutsägbar: våra 1→8 GPU-körningar visar konsekvent beteende, vilket ger oss förtroende för att forskning på små proxyer kommer att överföras till större körningar. Vi kommer att validera GPU-skalning 32 och 64 härnäst. Lösningen? Börja om och skriva om allt från grunden med motivationen att dela det med den större gemenskapen. Så det är vad jag gör nu. Under de kommande veckorna kommer jag att släppa olika träningsarkiv, blogginlägg, vikter för datagradering av modeller samt visualiserings- och experimentspårningssystem i w&b-stil till communityn. Det finns också en färdplan med fullständiga inferensmotorer osv. på horisonten. Det kommer att ta lite längre tid än jag hoppats på grund av både ambitionens omfattning och full omskrivning, men jag hoppas att communityn finner detta lika användbart som jag har gjort. --- Referenser: - [DeepSeek-V3 teknisk rapport]( - [Inside Kaiju: Bygga konversationsmodeller i stor skala]( - [Moonlight: Ett beräkningseffektivt MoE-träningsramverk]( - [Teknisk rapport för frökodare]( - [OLMo-3: Den bästa helt öppna modellen i sin klass]( (bild på en tidig FP8-träningskörning från NVIZ-instrumentpanelen)

Breakpoint-innehållet är förvånansvärt S-tier Mycket substans, lag gör stora tillkännagivanden, klipp publiceras snabbt Det är nästan 2026 och ingen gör det riktigt som Solana, inte ens i närheten