Effektiv og bærbar mixture-of-experts-kommunikation

Vi præsenterer et højtydende, bærbar, open-source-bibliotek til Mixture-of-Experts (MoE)-kommunikation, der opnår 10x hurtigere ydeevne sammenlignet med standard All-to-All-kommunikationsprimitiver.

Vores implementering indeholder flere vigtige tekniske innovationer, der leverer overlegen effektivitet i MoE-kommunikation:

GPU-initieret kommunikation (IBGDA): Understøtter direkte GPU-til-NIC-kommunikation, hvilket reducerer latensen væsentligt ved at omgå CPU-involvering

Overlap mellem kommunikation og beregning: Opdelt kernearkitektur med separate afsendelses- og modtagelsestrin gør det muligt at udføre beregninger samtidigt med netværksoverførsler

Hurtigste ydeevne på enkeltnode: 2,5x lavere latens end den tidligere hurtigste implementering på enkeltnodekonfigurationer

Effektiv og bærbar ydeevne på flernoder: Vores implementering opnår hastigheder op til 10x hurtigere end standard all-to-all-kommunikation. Selvom vores tilgang er ca. 2x langsommere end meget specialiserede implementeringer, tilbyder den bedre portabilitet på tværs af NVSHMEM-versioner og netværksmiljøer (NVLink, CX-7 og EFA)

Biblioteket er fuldstændig open-source og tilgængeligt på https://github.com/ppl-ai/pplx-kernels.

I denne artikel udforsker vi udfordringerne ved ekspertparallelisme i store MoE-modeller og beskriver vores tilgang til effektiv tokendispatching og -kombination på tværs af distribuerede GPU-miljøer.

Mixture-of-Experts (MoE)-modeller, såsom DeepSeek R1 og Mixtral 8x7B, forbedrer tætte modeller ved at begrænse antallet af vægte, der aktiveres for hvert token. I stedet for at opnå høje parametertal ved at øge antallet af lag eller øge størrelsen af de lineære lag i Multi-Layer Perceptron (MLP) for hvert decoder-lag, erstatter MoE-modeller den traditionelle MLP med flere eksperter og en router. For eksempel bliver der ud af DeepSeek R1s 671 milliarder parametre kun ganget 37 milliarder med et givet token under inferens. Dette reducerer i høj grad mængden af beregninger, der kræves for at afkode et token, og forbedrer latensen sammenlignet med en tæt model.

MoE-modeller præsenterer nogle yderligere udfordringer for inferens sammenlignet med tætte modeller. Selvom eksperterne i sig selv er små MLP-lag, indeholder hvert decoder-lag en router, der beslutter, hvilke eksperter et token sendes til, idet hvert token sendes til flere eksperter. Routeren er typisk et lille lineært lag, der producerer en sandsynlighedsfordeling. Normalt vælges eksperterne med de højeste K-scores, og den endelige aktivering beregnes som et vægtet gennemsnit, hvor ekspertresultaterne summeres ganget med en vægt afledt af routerens sandsynlighedsfordeling.

For at minimere latensen i distribuerede MoE-systemer kan parallelisme udnyttes på tværs af flere enheder, men dette introducerer kommunikationsudfordringer. Modeller som Mixtral 8x7B eller Llama-70B kan være inden for 8 enheder på en enkelt node og drager fordel af hurtige NVLink-forbindelser med lav latens (op til 900 Gbps). Større modeller kræver dog sharding af eksperter på tværs af flere noder ved hjælp af InfiniBand (med et peak på 400 Gbps), hvilket introducerer yderligere udfordringer med hensyn til latens.

Tokenrouting, ekspertberegning og outputindsamling i et mixture-of-experts-lag.

I denne artikel udforsker vi problemet med ekspertparallelisme og beskriver vores implementering af GPU-kerner, der effektivt dispatches tokens til enheder, som indeholder de tildelte eksperter, og samler dem igen ved at beregne det vægtede gennemsnit af ekspertresultaterne. Selvom der findes aggressivt optimerede implementeringer, der retter sig mod specifikken netværkshardware, præsenterer vi en yderst bærbar implementering, der er afhængig af et minimalt sæt NVSHMEM-primitiver, men som alligevel leverer en ydeevne, der er 10x hurtigere end standard all-to-all-kommunikation. Vores implementering opnår state-of-the-art-ydeevne på enkeltnodekonfigurationer, samtidig med at den opretholder fremragende portabilitet på tværs af forskellige netværksmiljøer.

For at opnå effektiv inferens skal en models vægte holdes i enhedens hukommelse, samtidig med at der er tilstrækkelig Space til aktiveringer, KV-cacher og andre buffere, der kræves til fremadrettet gennemløb (forward pass) gennem modellen. De mest kapable modeller overstiger kapaciteten på selv de mest kapable GPU'er, og derfor skal inferens spredes ud over flere enheder, som kollektivt kan lagre modellens vægte. Baseret på sharding-skemaerne for vægte skal der anvendes forskellige kommunikations- og beregningsskemaer til at aflaste beregninger og synkronisere enheder.

Ekspertparallelisme på tværs af to GPU'er.

Expert Parallelism (EP), illustreret i den første figur, paralleliserer kun ekspertberegningen. Forskellige eksperter tildeles forskellige enheder, som indeholder deres vægte. Efter routing sendes tokens til den tilsvarende enhed, hvorefter resultaterne indsamles og akkumuleres. Kompleksiteten af routing afhænger af graden af parallelisme i de andre dele af modellen: replikering af andre lag kan fjerne behovet for routing fuldstændigt, da hver rank kan vælge tokens fra en lokalt replikeret routingtabel. Men hvis det kun er én af rankene, der udfører routing, kræves der en udsendelse (broadcast) for at udsende tokens, indekser og vægte til deres respektive eksperter. Endelig synkroniserer en all-gather eller en all-to-all broadcast output-tokens med den rank, der fortsætter udførelsen af modellen. En sådan implementering er relativt simpel, da torch allerede eksponerer de nødvendige primitiver, omend der kan opnås nogle fordele ved at fusionere akkumulering med gather-operationen, der indsamler tokens fra eksperterne.

Kombination af ekspertparallelisme med tensorparallelisme på tværs af to GPU'er.

Ekspert-enkelparallelisme skalerer ikke ideelt, da noder i en kluster kan være inaktive, mens modellen kører ikke-ekspertlag som attention, norm og sampling. Beregningen af disse lag, primært attention, kan dog også drage fordel af Tensor Parallelism (TP). De fleste modeller er afhængige af multi-head attention, hvilket betyder, at attention-hovederne og deres tilsvarende Q-, K- og V-projektioner også kan shardes på tværs af enheder, idet skiverne mellem forskellige lag replikeres eller indsamles. Hvis attention er spredt ud over alle enheder, kan en all-gather synkronisere aktiveringerne, hvilket gør det muligt at replikere routing, hvilket kræver synkroniseringsprimitiver svarende til tilfældet med ekspertparallelisme for at opnå en effektiv implementering. Der er dog grænser for parallelisme på dette niveau, da en reduktion af antallet af attention-hoveder under en vis tærskel vil give faldende udbytte.

Kombination af ekspertparallelisme med dataparallelisme for separate forespørgsler på tværs af to GPU'er.

For bedst muligt at udnytte alle enheder og understøtte en meget høj grad af ekspertparallelisme på op til 128 eller 256 GPU'er kræves Data Parallelism (DP). Under dette skema er de enheder, som en model er opdelt på, grupperet til at håndtere forespørgsler samtidigt, hvor de beregner attention og vedligeholder KV-cacher, der er shardet på tværs af deres lokale gruppe. Flere instanser af disse parallelle grupper samarbejder om ekspertvurdering, hvor hver især er vært for en anden delmængde af ekspertvægtene. Baseret på antallet af attention-hoveder kan en gruppe typisk spænde over op til størrelsen af en hel node, da kommunikation inden for en node er hurtigere. For eksempel betjener det ene DP-rank i figuren ovenfor uafhængigt to forespørgsler, A og B, og håndterer attention, norm og al anden bogføring for forespørgslerne. Det andet DP-rank behandler en særskilt forespørgsel C. Den første node er dog vært for halvdelen af eksperterne, mens den anden node er vært for den anden halvdel, og derfor kan tokens fra A og B efter routing blive sendt til den anden node og omvendt. Dette fører til et sparsomt kommunikationsproblem: hver enhed kan sende et forskelligt antal tokens til en vilkårlig anden destinationsrank. Eksisterende primitiver fra torch, primært all_to_all, er ikke særlig velegnede, da de kan kræve en form for padding eller GPU-til-CPU-synkronisering og udsendelse af metadata. For at implementere kommunikation effektivt kræves der tilpassede kerner til at behandle routinginformationen og initiere kommunikation fra enhederne uden CPU-indgriben. Efter routing skal en dispatch-kerne sende tokens til de ranks, de blev routet til, mens aktiveringerne, der hører til forespørgslerne i den aktuelle DP-gruppe, skal indsamles på kombinationssiden. Derudover skal arbejdet balanceres inden for en DP-gruppe, som kan have flere enheder, for at minimere udsendelse og korrekt replikere tokens på alle ranks til de efterfølgende lag.

NVSHMEM er en NVIDIA-specifik OpenSHMEM-implementering, der leverer bærbare faciliteter til kommunikation mellem enheder, som abstraherer kompleksiteten af den underliggende hardware væk. API'et kan udtrykke læsninger og skrivninger fra enhed til enhed, som knyttes til primitiverne for individuelle transportlag. Både NVLink og RDMA understøttes, hvilket giver en vis grad af portabilitet og gør det muligt for NVSHMEM-kerner at fungere inden for en node eller på tværs af et klynger af flere noder. I vores kerner bruger vi fjernhukommelsesskrivninger og signaleringsemner til at overføre data og synkronisere de deltagende enheder.

NVSHMEM-operationer er opbygget omkring begrebet symmetrisk hukommelse: de opererer på buffere, der er blevet allokeret på alle de enheder, der deltager i kommunikationen mellem enheder. En lokal enhed kan bruge en adresse, der er afledt i dens egen lokale buffer sammen med indekset for målenhederne, til at angive destinationen for en operation. Figuren nedenfor illustrerer dette koncept: begge GPU'er allokerer symmetriske buffere af samme størrelse, der bevarer src-pointere til dem. Det første rank vil sende 3 heltal til det andet og placere dem i starten af bufferen: nvshmem_int_put_nbi udleder startadressen fra den lokale buffer og angiver destinationenheden. Det andet rank udleder en forskydning (offset) fra sin egen buffer og sender et element til den første enhed med en forskydning på én. Mens destinationsadresser altid skal være symmetriske buffere allokeret ved hjælp af nvshmem_alloc, kan kildebuffere være vilkårlige områder af enhedshukommelsen, forudsat at de er præ-registreret hos NVSHMEM.

Selvom NVSHMEM leverer en bred vifte af primitiver, er vores kerner afhængige af kun 3 funktioner, hvor al synkronisering og indhegning (fencing) er bygget oven på dem.

Symmetrisk hukommelse og fjernskrivninger mellem to GPU'er ved hjælp af NVSHMEM.

nvshmemx_putmem_signal_nbi_warp: Overfører en datablok fra en enhed til en anden, samtidig med at der sættes et flag på fjernenheden. Operationen sætter enten (NVSHMEM_SIGNAL_SET) eller forøger (NVSHMEM_SIGNAL_ADD) en 64-bit placering. Flaget opdateres, når hele hukommelsesblokken er blevet overført. Hvis fjernenheden observerer en ændring i flaget, kan den sikkert få adgang til bufferen i sin egen hukommelse. Denne funktion er nyttig til at sammenstøbe dataoverførsel og synkronisering.

nvshmemx_signal_op opererer på en enkelt hukommelsesplacering, typisk et 64-bit flag, og indstiller eller forøger det atomisk. Det er nyttigt til at sende metadata og synkronisere enheder.

nvshmem_uint64_wait_until bruges i modtagerenden af et signal til at afpolle et flag, indtil fjernenheden opdaterer det.

Det er omkostningstungt at sikre en hvilken som helst form for rækkefølge mellem operationer gennem nvshmem_quiet eller nvshmem_fence, og derfor undgår vores implementering af kernerne brugen af andre NVSHMEM-primitiver og minimerer eventuelle andre afhængigheder end individuelle send-modtag-par. Når vi sender data, bruger vi altid den ikke-blokerende version af funktioner uden at vente på, at dataene overhovedet bliver sendt ud af den lokale rank. Anden implicit synkronisering på tværs af kernegruppen sikrer, at disse buffere ikke bliver destruktivt overskrevet, mens NIC'erne har brug for adgang til dem.

NVSHMEM bruger GPUDirect RDMA, så NIC'en direkte kan læse og skrive GPU-hukommelse til dataudveksling uden at involvere CPU'er. Derudover understøtter NVSHMEM på ConnectX NIC'er GPU-initieret kommunikation (også kendt som InfiniBand GPUDirect Async eller IBGDA), hvilket gør det muligt for GPU'en at sende RDMA-operationer direkte til NIC'en og afpolle NIC'ens fuldførelseskø direkte. På platforme, der ikke understøtter GPU-initieret kommunikation, opretter NVSHMEM en "proxy"-tråd på vært-CPU'en for at initiere kommunikation og afpolle fuldførelse på vegne af GPU'en. NVSHMEM-programmet er bærbart uanset om GPU-initieret kommunikation understøttes eller ej. GPU-initieret kommunikation reducerer dog latensen væsentligt, fordi den fuldstændigt omgår omvejen til CPU'en.

Vi implementerer MoE-kommunikation gennem et par af dispatch- og combine-kerner. Dispatch-kernerne er ansvarlige for at læse tokens og routinginformation på hvert rank og dispatche dem til de relevante eksperter. Combine-kernerne indsamler aktiveringerne produceret af eksperterne og sender dem tilbage til deres kilderanks, samtidig med at de beregner det vægtede gennemsnit fra de udvalgte eksperter baseret på de vægte, der er beregnet af routeren. Kernerne er desuden opdelt i en sende- og en modtagekomponent for at gøre det muligt at overlappe dataoverførsler med beregninger. Sende-kernerne er alle ikke-blokerende og ikke-synkroniserende: de dispatches blot alle skrivninger til fjernenhederne. I den anden ende læser combine-kernerne kun fra hukommelsen og venter, indtil alle nødvendige data er blevet overført. Efter afsendelse af arbejde til NIC'erne, mens dataene overføres asynkront over kablet, kan GPU'erne udføre andet nyttigt arbejde lokalt, såsom at anvende delte eksperter eller beregne attention.

Hvert par af kerner har sine egne symmetriske hukommelsesbuffere, hvor hvert rank allokerer privat lager til at modtage data fra alle andre ranks. Det maksimale antal tokens, der kan dispatches fra en DP-gruppe, er fastsat på tværs af rankene, hvilket også sætter den øvre grænse for, hvad hvert rank kan modtage for hver lokal ekspert fra hvert DP-rank. Dette gør det muligt for afsendende ranks at udlede en unikt adresse på destinationsranken, der skal skrives til, uden at det kræver synkronisering mellem dem. Når data er modtaget, blander kernerne tokens rundt for at placere dem i hukommelsen i det optimale format, der kræves af de modtagende kerner. Selvom bufferne har en betydelig størrelse, genbruges de på tværs af alle sekventielle lag i en model.

Separate sende- og modtagekerner til dispatch- og combine-operationer.

Den eneste form for global synkronisering, som illustreret i figuren ovenfor, er implementeret i combine-receive-kernen. Når data er dispatchet fra send, vender et rank tilbage og fortsætter udførelsen, når det modtager alle de tokens, det har brug for fra de andre ranks, og går ind i combine-send-kernerne, så snart de er behandlet. Barrieren i combine-receive sikrer, at intet rank kan løbe for tit og starte dispatch-send, mens et andet rank stadig venter på at modtage data, hvilket potentielt kan forårsage destruktiv overlapning. Synkronisering udføres i combine-kernen for enkelheds skyld; som en optimering kan den samme barriere implementeres mellem dispatch-receive- og combine-send-kernerne, hvilket reducerer latensen yderligere ved at give NIC'erne mere tid til at afvikle overførslerne, mens GPU'en kører andre kerner.

Begge kerner er opdelt på tværs af alle tilgængelige SM'er på enhederne: mens dispatch-send- og combine-receive-kernerne skal parallelisere på tværs af et maksimalt tokental pr. rank (max_m), skal dispatch-receive- og combine-send-kernerne håndtere så mange tokens fra hvert rank og lokal ekspert, op til et maksimum på max_m * (num_experts // EP) * (EP // TP).

Dispatch-kernen er ansvarlig for at dispatche tokens og blokskaleringsfaktorer til peers, der er værter for de eksperter, som tokens blev routet til. Afsendersiden er afhængig af warp-specialisering til at parallelisere to opgaver: at aggregere routinginformation for at bestemme, hvor mange tokens der sendes fra hvert rank, og pakke tokens ind i meddelelser, der skal dispatches til fjernenheden. Modtagersiden venter først på, at alle tokentallene modtages, hvorefter den læser og pakker nyttelasterne (payloads) ud fra delt hukommelse til de tensorer, der sendes videre til de downstream Grouped GEMM-kerner. Den gemmer også information i buffere, der deles med combine-kernerne, for at indikere, hvor hvert token skal sendes tilbage til. Denne information er nødvendig, da modtagekernen blander tokens rundt i sammenhængende buffere i en ikke-deterministisk rækkefølge.

Dispatch af tokens og signalering af deres ankomst mellem kilde- og destinationsranks.

I afsenderdelen er en enkelt warp med 32 tråde på hver blok ansvarlig for at læse routinginformationen og tælle antallet af tokens, som hver destinationsekspert forventes at modtage fra dette rank, og sende antallet plus én ved hjælp af nvshmem_signal_op. Antallet forøges med én, da overgangen fra nul til ikke-nul i fjernenden angiver modtagelsen af tallene fra et kilderank. Parallelt hermed samarbejder de resterende warps om at kopiere tokens til symmetrisk hukommelse på tværs af alle blokke parallelt, hvor aktiveringer, skaleringsfaktorer og deres indeks på det lokale rank pakkes i et sammenhængende stykke. Indekset er påkrævet af combine-afsenderen for at bestemme den adresse, hvor tokenet vil blive skrevet til. Derefter, efter at det er sikret, at alle data er blevet kopieret gennem en barriere på tværs af warp-grupperne, opererer warps igen uafhængigt, hvor hver sender den samme buffer til en anden ekspert parallelt. Tokens sendes ved hjælp af nvshmemx_putmem_signal_nbi_warp, hvilket også atomisk øger antallet af sendte tokens fra det lokale rank på fjernenheden. Inden for en DP-gruppe, da hvert rank ejer en replika af det token, der skal sendes, balanceres dispatch jævnt, hvor hver enhed udsender en delmængde af tokens.

I modtagerenden synkroniserer alle kerner først med afsender-rankene ved at vente på, at de samlede tokental sendes over. Derefter venter de alle på, at de atomisk forøgede sendte tokental falder til ro ved de samlede tællinger, hvilket indikerer, at alle nyttelaster fra kilderankene også er blevet sendt over, takket være semantikken i putmem-kallet. Kernerne afpoller tællingerne ved hjælp af nvshmem_uint64_wait_until og paralleliserer operationen på tværs af alle blokke og tråde. Efterfølgende sikrer en tværblokbarriere, at ingen blok læser bufferne, medmindre alle data er blevet modtaget korrekt. Spredt ud over blokke og synkroniseret via en atomisk forøget tæller kopieres tokens fra symmetrisk hukommelse til almindelige sammenhængende buffere, som bliver input til de downstream-kerner, der implementerer eksperterne. Kilderanken, ekspertindekset og tokenindekset gemmes separat og fastslår præcist den placering, hvor combine-kernen skal sende aktiveringerne til. Selvom tokens fra en DP-gruppe sendes fra forskellige enheder, grupperes de alle sammen for at blive sendt videre til den tilsvarende ekspert.

Combine-kernerne er igen opdelt i sende- og modtagehalvdele: afsenderne kopierer de ukvantiserede 16-bit aktiveringer over til fjernenhederne, hvor modtagekernerne venter på, at dataene sendes over, og beregner det vægtede gennemsnit af alle ekspertbidrag lokalt. Derudover fungerer de også som en barriere for at synkronisere dispatch-combine-sekvensen: hvert rank sætter et flag på hver peer ved indgangen til sende-kernerne, og modtagekernerne må ikke vende tilbage, medmindre de observerer, at flaget er sat. Latensen ved synkronisering er minimal, da den overlapper med den faktiske kommunikation og beregning.

Kombination af ekspertoutput i tokensene på hver dataparallel rank.

På afsendersiden gennemløber kernerne listen af tokens tildelt alle lokale eksperter parallelt og skriver dem til en buffer på destinationsranken. Destinationsrank, ekspertindeks og tokenindeks læses fra de pr.-token-buffere, der udfyldes af scatter-kernerne ved modtagelse af tokens. Hver afsender har sit eget private hukommelsesområde pr. ekspert at skrive til, som vist i figuren ovenfor, hvilket undgår behovet for synkronisering. Ligesom ved dispatch forøger combine atomisk pr.-token-tællinger på destinationsranken for at indikere modtagelse af dataene: når tælleren matcher antallet af eksperter, som et token blev dispatchet til, kan der gives adgang til tokenets indhold.

I modtagekernen gennemløbes listen af tokens parallelt på tværs af flere blokke, mens der ventes på, at deres indhold ankommer ved at afpolle det flag, der blev sat af signaleringsemnerne. Ved ankomsten læses nyttelasterne fra de private buffere, hvor routingtabellen angiver, hvilken buffer der skal læses fra, og hvilken vægt der skal tildeles til hver ekspert. Resultaterne skrives derefter til eksternt allokerede tensorer, og kernen afslutter udførelsen, når alle enheder har passeret barrieren. På tværs af en DP-gruppe modtager alle ranks en kopi af hver ekspertaktivering for at beregne deres egne replikaer.

Vi evaluerer vores kerner på en klynge af 128 GPU'er fordelt på 16 noder forbundet via InfiniBand- og CX-7 NIC'er. Vi prøver både GPUDirect Async (IBGDA) og Reliable Connection (RC) med en CPU-proxy. Vi sammenligner dem med den stærkt optimerede DeepSeek-implementering samt de tætte primitiver leveret af PyTorch (gennem NCCL) eller NVSHMEM.

Kommunikationslatens for 128 tokens pr. GPU i en multi-node EP128-konfiguration.

Selvom ydeevnen for IBRC og IBGDA er ens på den tætte NVSHMEM all-to-all-operation (6378 µs vs 6180 µs), er IBGDA væsentligt hurtigere med de sparsomme kerner. Når man lægger Dispatch og Combine sammen, bruger IBGDA 902 µs, mens IBRC tager 3223 µs - en forbedring af latensen på 3,6x. Mens all-to-all er båndbreddebegrænset, udsender de sparsomme kerner størrelsesordener mindre data og er begrænset af latens. Ved at udløse netværksoverførsler direkte fra en GPU uden at kræve en CPU-proxy til at koordinere GPU'en og NIC'en reduceres end-to-end-latensen betydeligt.

Selvom vores bærbare kerner er ca. 2x langsommere end de stærkt optimerede DeepSeek-kerner, forbedrer de latensen med 10x sammenlignet med de tætte kerner (902 µs vs 9944 µs).

Derudover gør opdelingen i afsender-modtager-komponenter det også muligt at skjule noget af latensen, i ulighed med biblioteksprimitiverne.

Kommunikationslatens for 128 tokens pr. GPU i en single-node EP8-konfiguration.

På en enkelt node (EP8) bruger NVSHMEM NVLINK til transport, hvilket leverer lavere latens og højere gennemnemsnit end netværk mellem noder. Vores bærbare kerner er ca. 2,5x hurtigere end DeepEP på en enkelt node (186 µs vs 481 µs).

De kerner, der beskrives her, overgår de indbyggede primitiver i ML-frameworks og tilbyder anstændig ydeevne uden overspecialisering til særlige enhedstransporter som NVLink eller InfiniBand. Ud over de allerede nævnte muligheder kan der opnås yderligere ydeevnegevinster ved at erstatte kommunikationsprimitiverne med mere specialiserede versioner. På tværs af NVLink kan brugen af symmetrisk hukommelse f.eks. erstattes af buffere, der deles på tværs af enhederne, hvilket fjerner noget kopiering og muliggør finere synkroniseringsskemaer på tværs af individuelle tokens i stedet for token-batcher. På tværs af InfiniBand kan en implementering få direkte adgang til de underliggende køpar (queue pairs), hvilket fjerner behovet for at overføre både de forventede og sendte tokental samt tømme tokens fra køerne til outputbuffere, når de ankommer. Sådanne implementeringer koster dog på portabiliteten, hvorimod vores implementering gør det muligt at evaluere klynger med specifikke konfigurationer, før man forpligter sig til udviklingsarbejde for at optimere til bestemt hardware.

Vi har præsenteret et højtydende, bærbar bibliotek til MoE-kommunikation, der opnår 10x hurtigere ydeevne sammenlignet med standard all-to-all-kommunikation, samtidig med at kompatibiliteten på tværs af forskellige hardwarekonfigurationer opretholdes. På implementeringer på en enkelt node med NVLink viser vores løsning 2,5x lavere latens end tidligere implementeringer.

Vores tilgang balancerer ydeevne med portabilitet gennem vigtige innovationer, herunder understøttelse af GPU-initieret kommunikation, en opdelt kernearkitektur, der muliggør overlap mellem beregning og kommunikation, og effektiv tokendispatching ved hjælp af minimale NVSHMEM-primitiver. Selvom vores bibliotek er ca. 2x langsommere end stærkt specialiserede implementeringer på opsætninger med flere noder, tilbyder det overlegen fleksibilitet på tværs af forskellige netværksmiljøer (NVLink, CX-7 og EFA).

Efterhånden som MoE-modeller fortsætter med at skalere, vil effektive kommunikationsstrategier som vores blive stadig vigtigere for praktisk implementering. Vores fuldstændig open-source-implementering er tilgængelig på https://github.com/ppl-ai/pplx-kernels.

DeepEP

DeepSeek-V3 Teknisk rapport

NVIDIA NVSHMEM

BibTeX

@online{perplexity2025EfficientAndPortableMixtureOfExpertsCommunication,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Phi Hoang},
  title = {{Efficient and portable mixture-of-experts communication}},
  date = {2025-04-02},
  url = {https://www.perplexity.ai/hub/blog/efficient-and-portable-mixture-of-experts-communication}
}

Introduktion

Sharding og parallelisme

NVSHMEM

Bærbare kerner

Dispatch

Combine

Benchmarks

Yderligere forbedringer

Konklusion

Referencer

Citering