Hur förändrar Mixture-of-Experts-routing beräkningsarbetet för lokala modeller?
Mixture-of-Experts-routing förändrar beräkningsarbetet för lokala modeller genom att skicka varje token genom endast en liten delmängd av experternas feedforward-nätverk i stället för att aktivera alla experter.
Det gör att en stor MoE-modell uppför sig annorlunda på en hemmaserver: den totala checkpoint-filen kan vara enorm, medan expertberäkningen för en enskild token kan motsvara den hos en mycket mindre aktiv modell. Fördelen är gles aritmetik, inte kostnadsfritt minne. Expertvikterna måste fortfarande lagras, och routning mellan flera enheter kan omvandla en del av den sparade beräkningskapaciteten till kommunikation.
En tät transformer aktiverar samma feedforward-parametrar för varje token
I ett vanligt tätt transformerlager passerar varje token genom samma feedforward-nätverk. Om antalet feedforward-parametrar ökar, ökar därför både modellstorleken och mängden beräkningar som utförs för varje token.
Switch Transformer kontrasterar detta med glesaktiverade Mixture-of-Experts-lager, där olika token kan välja olika parameterdelmängder.
För lokal inferens skapar detta den första MoE-skillnaden: det totala antalet parametrar avgör hur mycket modellstatus som måste lagras, medan antalet aktiverade parametrar i stor utsträckning avgör expertberäkningen per token.
En router bedömer varje token mot de tillgängliga experterna
I ett MoE-lager analyserar en liten router tokenrepresentationen och producerar poäng eller sannolikheter för möjliga experter. Körningen väljer sedan ett begränsat antal, vanligtvis top-1 eller top-k beroende på arkitekturen.
NVIDIA Megatron Core tillhandahåller en router som avgör vilka experter varje token skickas till. Routningsbeslutet ändrar vilka expertmatriser som bearbetar token.
Två token i samma prompt kan därför aktivera olika expertvikter, trots att de delar uppmärksamhetslagret och andra täta delar av modellen.
Gles aktivering minskar expertberäkningen men inte den totala viktlagringen
Om ett lager innehåller åtta experter men skickar varje token till två av dem, körs endast beräkningarna för de valda experterna för den token. De återstående expertmatriserna är inaktiva under det steget.
Forskning om Expert Choice beskriver MoE som ett sätt att öka antalet parametrar samtidigt som beräkningen per token hålls relativt begränsad. Därför kan en MoE-checkpoint ange ett mycket stort totalt parameterantal men ett betydligt mindre antal aktiva parametrar.
En hemmaserver behöver fortfarande ha hela uppsättningen expertvikter tillgänglig någonstans, såvida körningen inte strömmar eller avlastar dem. Gles beräkning är inte samma sak som gles lagring.
Expertplacering kan omvandla routning till enhetskommunikation
På ett enda GPU ändrar valet av expert främst vilka lokala viktblock som läses. På flera GPU:er kan experterna vara distribuerade, så att en tokenrepresentation måste skickas till den enhet som äger den valda experten och sedan återvända till det huvudsakliga lagerflödet.
DeepSpeeds MoE-design för inferens tilldelar expertgrupper med hjälp av expertparallellism över flera GPU:er. Routningen omfattar då både kommunikation och matrismultiplikation.
En liten hemmaserver med flera GPU:er kan därför bli begränsad av sammankopplingen även när beräkningen för varje token är gles. PCIe-topologi och stöd för peer-to-peer-kommunikation spelar större roll än antalet aktiva parametrar ensamt antyder.
Obalanserad routning skapar överbelastade experter och outnyttjad kapacitet
Verkliga promptar fördelar inte nödvändigtvis token jämnt. Om många token väljer samma expert blir den enheten eller kärnan en flaskhals medan andra experter väntar.
MoETuner identifierar obalanserad tokenroutning och expertaktivering som praktiska flaskhalsar vid serverdrift, eftersom vissa enheter kan få mer routat arbete och mer kommunikation än andra.
Vid lokal inferens kan ojämn routning visa sig som varierande tokenlatens mellan promptar, även när kontextlängd och modellstorlek är likartade. Modellen väljer dynamiskt en annan beräkningsväg.
Planera lokal MoE-kapacitet utifrån totala vikter och aktiv väg separat
En användbar hårdvaruuppskattning dokumenterar modellens totala viktstorlek, antalet aktiva experter per token, kostnaden för täta lager, KV-cache, kvantisering samt om experterna finns på en accelerator, flera GPU:er, CPU-RAM eller lagring.
ZimaSpaces genomgång av minnes- och acceleratorplanering för lokal AI ger det bredare kapacitetssammanhanget för hemmaservrar. MoE tillför ytterligare en uppdelning mellan permanent kapacitet och aktiv beräkning.
Benchmarka med promptar från olika uppgifter eftersom routningsmönstren kan variera. Mät token per sekund, användning per enhet, expertbelastning, kommunikationstrafik och minnesnärvaro i stället för att anta att det angivna antalet aktiva parametrar förutsäger hela systemets prestanda.
För särskilt stora lokala checkpoint-filer är ZimaSpaces analys av driftsättning av stora modeller den närliggande kapacitetsfrågan. Routning förändrar den aktiva beräkningen, men den totala viktmängden i minnet och placeringen mellan enheter avgör fortfarande om modellen är praktiskt användbar.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan en lokal AI-gateway tillämpa en strikt kontextgräns innan GPU-allokering?
En mekanismförst-förklaring av en hård kontextgrind, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
Kan en AI-server för hemmet minnesmappa modellvikter från en fjärransluten NAS över 2,5 GbE?
En mekanismfokuserad förklaring av minnesmappning för modeller i fjärr-NAS, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
Kan flera containrar dela på en integrerad GPU utan att läcka arbetsbelastningar?
En mekanismfokuserad förklaring av isolering av delad iGPU i containrar, dess kompromisser med delade resurser, tre frågor och svar om frågefanout samt ett praktiskt...
