# De ce este atât de greu să-l antrenezi pe MoEs Recent, am descoperit că îmi doresc un depozit mic, axat pe cercetare, pentru antrenament Pe care pot face experimente mici rapid și ușor. Aceste experimente variază De la testarea unor noi arhitecturi de atenție (MLA, SWA, NSA, KDA - toate plugable) până la antrenamente multi-precizie pentru majoritatea Recent, configurații multi-optimizatoare cu optimizatoare "noi". Am încercat cele 3 specializări concurenți (Nemo, Megatron și Torchtitan), dar din multe și diverse motive ei Nu se potriveau deloc pentru scopurile mele și au fost destul de dureroase Configurează, folosește-l și pune în funcțiune stabil. Din nou mi-a lipsit uneltele de pe Google și rescriu stack-ul de antrenament de producție pentru acest scop (care este tailor făcută pentru monitorizare și stabilitate a infrastructurii mari) s-a simțit, de asemenea, ca o soluție slabă Consum de timp și ar înrăutăți atât vechiul, cât și noul depozit. Totuși, asta m-a făcut să mă întreb: de ce antrenamentul de calitate frontieră era "destul de mic" MoE-uri (să zicem sub 20 miliarde parametri în total) sunt atât de dificile? De ce nu a făcut repo / lib i dorit deja există? După ce m-am gândit o vreme, majoritatea Provocările la care mă puteam gândi s-au redus la 3 lucruri diferite: - flops / eficiență flop - echilibrarea sarcinii / stabilitatea routerului - calitatea și cantitatea datelor Flops Antrenarea modelelor dense este destul de simplă în zilele noastre. Antrenamentul Dinamica este în mare parte cuplată, iar dacă ai suficienți parametri în arhitectură, Modelul va învăța practic în ciuda multor greșeli ale tale (asta m-a mușcat fundul de mai multe ori). [Ultra-spars în stil DeepSeek]( MoE-urile sunt diferite pentru că dinamica ta de antrenament este oarecum decuplat. Doar o parte din MLP-urile tale sunt active pentru un anumit token, Iar pe măsură ce instruirea avansează, experții activi se schimbă și evoluează în timp. Aceasta este ce face ca antrenamentul multi-epoch și reformularea datelor să fie atât de eficiente pentru MoE (mai ales cele mai mari). Obții câștiguri mari de eficiență de inferență și mici Eficiența antrenamentului câștigă, dar cu prețul dinamicii de antrenament decuplate (face este greu să te antrenezi previzibil și stabil) și trebuie să arunci mult mai multe eșecuri Pentru a te asigura că înveți o politică de rutare oarecum optimă și că experții implicați în diversele politici sunt pregătiți corespunzător. Ei bine, aici este locul unde Provocarea flop-urilor / eficienței flop-urilor apare. Prima provocare este că, prin natura, MoE-urile ultra-rare consumă o cantitate enormă de HBM pentru a încărca experți, dar înseamnă că ai nevoie de multe plăci video și, prin urmare, multe plăci video inactive în sistemul tău. FSDP (și diversele alte topologii de sharding) sunt în mare parte relicve de antrenament dens și nu fac o treabă foarte bună în a valorifica adecvat toate Acele eșecuri abandonate. Acest lucru duce la MFU-uri (mici) de o singură cifră pentru majoritatea oamenilor instruire extrem de rară de MoE. Și, deși există câteva moduri de a aborda asta Asta (mult mai multe despre asta pe viitor) m-am concentrat pe două lucruri specifice: - o nouă topologie de sharding (un sistem inovator de dispecerizare paralelă expert care ține GPU-urile ocupate) - antrenament mixt de precizie Echilibrarea sarcinii / Stabilitatea routerului Voi lăsa noua topologie de sharding pentru o explicație dedicată, dar antrenamentul de precizie mixtă este o alegere evidentă. Ai tot acest HBM cu șuruburi, așa că reduci precizia expertului și taie copilul cu jumătate sau 1/4 (fp8 și nvfp4, respectiv). Asta e bine în teorie, dar în practică antrenamentul de precizie mixtă necesită de obicei MAI mult HBM, deoarece trebuie să menții greutățile master și grads la o precizie mai mare, apoi să cuantifici greutățile master la reprezentarea lor de precizie mai mică și să le depozitezi pentru următoarea trecere înainte. Astfel, ajută la eficiența inferenței (ceea ce, pe măsură ce tot mai multe eșecuri ajung la RL și inferență, este un adevărat câștig), dar cu prețul și mai multor HBM și mai multe eșecuri în timpul antrenamentului. Reducerea costului de precizie mixtă este un domeniu specific de interes. Totuși, orice atingi care reduce precizia și acuratețea greutăților duce în cele din urmă la instabilitate în restul dinamicii de antrenament. Pentru MoE, primul loc unde apare de obicei acest lucru este stabilitatea routerului. Raportul tehnic DeepSeek-V3 descrie o configurație de antrenament foarte elegantă, fără pierdere auxiliară, unde există foarte puține butoane și dinamica este foarte clară. Acestea sunt clar unelte concepute pentru utilizatorii experimentați, deoarece a obține dinamica corectă cu doar câteva butoane este incredibil de dificil. Esențial, DeepSeek se bazează mult pe loturi masive pentru a-și stabiliza routerele – un lux pe care nu îl avem când facem cercetări pe hardware limitat. Așadar, trebuie să muncim din greu pentru ca serii noastre mici să fie stabile, eficiente și informative. Pe măsură ce am început să experimentez replicarea configurației lor, în special pentru experți de precizie mixtă, a devenit foarte clar că gradații erau mult prea mici pentru fp8 sau nvfp4, ceea ce făcea ca routerele să nu învețe și experții să moară de foame. Am încercat totul ca să funcționeze, mai întâi cu treceri înapoi cu precizie redusă și, în cele din urmă, chiar și cu greutăți și gradații master fp32, dar prăbușirea routerului a persistat. Un articol bine sincronizat a fost postarea de pe blogul Character AI, care descria diversele lor intervenții de stabilitate int8. Le-am încercat pe toate, dar până la urmă au făcut sistemul mult, mult mai puțin stabil. Așa că le-am parcurs pe rând. Primul a fost scalarea încorporată muP de 10,66 și scalarea logiturilor de 0,125. Au fost o mulțime de câștiguri foarte evidente aici, în afară de stabilitatea routerului, dar un lucru clar pe care l-au făcut aceste scale a fost să iau absolvenții experți fp8 și nvfp4 foarte, foarte mici și să-i scaleze până în punctul în care ROUTERUL ÎNCEPEA ÎN SFÂRȘIT SĂ ÎNVEȚE! Totuși, aceste victorii au făcut ca norma de absolvenți din bf16 să explodeze complet, iar "cele mai bune practici" de clipping și scalarea gradului împiedicau orice învățare. Deci, soluția? Îndepărtați toate decupările și YOLO! În cele din urmă, am avut instruire stabilă pentru routere mixte de precizie. Cealaltă intervenție Kaiju care s-a dovedit incredibil de utilă a fost un singur scalar virtual bungee la ieșirea normei pre-output a experților, inițializat la 2.0 pentru a corespunde scalei grad bf16 și astfel dinamica antrenamentului astfel încât nvfp4 și fp8 să prezinte mai mult sau mai puțin aceleași curbe de pierdere ca și rundele de antrenament de bază ale bf16 (diferența FP8-BF16 redusă de la ~0,8 la <0,1 la 3.000 de pași). Există multe alte trucuri și "bune practici" folosite aici (mai multe despre toate acestea în postări viitoare), dar titlurile au fost: - adăugarea scalării muP - elimină toate celelalte tăieri și trăiește pe partea sălbatică - Norma Bungee Virtual Scalar Pre Output - să păstrăm gratuit pierderea auxiliară și rutarea prin alegerea token-urilor (pentru că știm diferența dintre bine și rău în această casă) Date Acum că aveam dinamici de antrenament destul de stabile, a devenit clar că, dacă vreodată aș vrea să împărtășesc acest depozit cu cineva, am avea nevoie de date mai bune pentru a profita la maximum de această bibliotecă de antrenament. O altă lansare bine sincronizată a fost [OLMo-3]( cu rețeta sa open source de amestec de date (salutări Ai2!!). Totuși, când am încercat să folosesc amestecul OLMo-3 direct de la Huggingface, obțineam rezultate destul de slabe (comparativ cu standardul meu obișnuit FineWeb-Edu). Așadar, a început explorarea datelor și ... Seturile de date erau destul de murdare. Așa că am făcut ceea ce ar face orice nebun și m-am hotărât să construiesc un flux de date inspirat de Frontier, ca să pot profita la maximum de acest repository de antrenament. Conducta are câteva componente cheie: - **Pre-filtre euristice**: ID-ul limbajului, filtrele de lungime, deduplicarea MinHash, repetiția n-gramelor, excepții de perplexitate, toxicitate - elementele standard pentru eliminarea gunoiului evident înainte de a cheltui cicluri GPU - **Amestecuri dinamice în stil SeqIO**: Eșantionare deterministă, reluabilă, care menține rapoartele țintă (40% CC, 20% cod etc.) indiferent de bugetul total de tokenuri - critic pentru rulările de proxy unde nu te antrenezi pe tokenuri 6.7T - **Punctaj de calitate bazat pe model**: Aici devine interesant Pentru evaluarea calității, am urmat modelul [Seed-Coder](: folosesc modele oracolare mari pentru a genera etichete de antrenament, apoi le distilez într-un clasificator rapid. Inițial am experimentat cu câteva modele de oracol (Kimi-K2, DeepSeek-V3.2 și [gpt-oss](120B), dar până la urmă am păstrat doar modelele din clasa 120B ca oracole – erau constant cele mai bune la judecăți nuanțate de calitate. Oracolele au evaluat un eșantion de date pe cinci dimensiuni pentru conținutul general (utilitate, corectitudine, coerență, complexitate, verbozitate - fiecare 0-4) și patru dimensiuni pentru cod (lizibilitate, modularitate, claritate, reutilizare - fiecare 0-10). Apoi am luat o coloană vertebrală gpt-oss 20B congelată și am atașat două capete mici: - **Cap de sondă** la stratul 18: Stări ascunse mediate → liniare (2880→5). Ultra ieftin, prinde devreme gunoiul evident - **Cap de judecător** la stratul 24: Atenție completă la secvență → mic encoder transformator → Liniar(512→5). Mai scump, dar detectează probleme nuanțate de calitate Designul de ieșire anticipată este esențial - dacă Probe obține un scor sub prag, sărim complet peste Judge. La scară largă, acest lucru economisește ~15% din calcul, menținând în același timp calitatea. Pragurile (τ_drop, τ_keep) sunt calibrate pe un set de menținere a țintei pentru a atinge ratele de menținere a țintei. Spre surprinderea mea, rata mea de păstrare pentru setul de date OLMo-3 a fost de aproximativ 30% pentru CC și surse de internet, și 50% pentru cod, matematică și științe. Este multă filtrare, dar evaluările modelului proxy au arătat îmbunătățiri clare față de baza nefiltrată. În sfârșit aveam un sistem rezonabil funcțional care se apropia de toate lucrurile pe care le iubeam la infrastructura mea de instruire la scară largă și uneltele excelente pe care le folosisem anterior, dar era construit special pentru instruirea micilor MoE pentru cercetare și producții mici de modele. Totuși, depozitul a fost distrus din cauza experimentelor și depanării constante. De asemenea, echipa mea de dezvoltare este formată din mine și o flotă de agenți AI. Așa cum a spus recent Vik, "Trăiește din mizerie, mori din mizerie" și, deși de obicei sunt foarte studios și strict cu "FĂRĂ MIZERIE ÎN CASA ASTA", resturile de la depanarea toată noaptea și cadavrele diverselor experimente abandonate erau împrăștiate în depozitul meu. Configurația și complexitatea bootstrap-ului au explodat, de asemenea. Ceea ce începuse inspirat de [nanochat] (acum semăna mult mai mult cu Megatron (fără supărare). Rezultatul? Acum putem face cercetări semnificative MoE pe hardware limitat – un proxy 7B2A pe un singur GPU B200, un 16B4A pe un singur nod 8×B200 – ambele ajungând la 30-40k tokens/sec/GPU. Mai important, scalarea este previzibilă: rulările noastre de 1→8 GPU arată un comportament constant, ceea ce ne dă încredere că cercetările făcute pe proxy-uri mici se vor transfera la runde mai mari. Vom valida scalarea GPU-urilor 32 și 64 în continuare. Soluția? Începe de la zero și rescrie totul de la zero, cu motivația să împărtășești cu comunitatea mai largă. Deci, asta fac acum. În următoarele săptămâni, voi lansa diversele repo-uri de antrenament, postări pe blog, greutăți ale modelelor de notare a datelor și sisteme de vizualizare și urmărire a experimentelor în stil w&b către comunitate. Există și o foaie de parcurs cu motoare complete de inferență etc. la orizont. Va dura puțin mai mult decât speram, atât din cauza ambiției, cât și a rescrierii complete, dar sper ca comunitatea să găsească asta la fel de util ca mine. --- Referinţe: - [Raportul tehnic DeepSeek-V3]( - [Inside Kaiju: Construirea modelelor conversaționale la scară]( - [Moonlight: Un cadru de antrenament MoE eficient din punct de vedere al calculului]( - [Raport tehnic Seed-Coder]( - [OLMo-3: Cel mai bun model complet deschis din clasa sa]( (Imagine a unui antrenament timpuriu FP8 de pe panoul de bord al NVIZ)

Acum poți încărca fișiere în Ramp Sheets. Urmărește agentul cum preia un pitch deck, cercetează concurenții pe internet și descoperă un Model de Operare și Evaluare complet dintr-un singur PDF.