Gera billjóna-færibreytu líkön aðgengileg á AWS EFA

Hjá Perplexity notum við bestu líkönin fyrir vörur okkar, API-viðmót okkar og rannsóknarteymi okkar. Stór opnir Mixture-of-Experts líkön, eins og Kimi-K2, kalla á sérstakar áskoranir þar sem stærstu ályktunarhnútarnir með 8x NVIDIA H200 GPU geta ekki hýst þau á skilvirkan hátt, sem gerir útfærslur á mörgum hnútum nauðsynlegar. Við kynnum safn af kjörnum fyrir sérfræðinga-samhliðun sem ná framúrskarandi töfum á ConnectX-7 og fara fram úr afköstum DeepEP. Sömu kjarnar eru einnig þeir fyrstu til að ná raunhæfum töfum á AWS Elastic Fabric Adapter (EFA), sem gerir kleift að útfæra milljarða-til-billjóna færibreytu líkön.

Prófaðu kjarnana okkar á GitHub og lestu alla rannsóknarritgerðina á arXiv.

Inngangur

Mixture-of-Experts (MoE) er orðin staðlaða arkitektúrinn til að skýrbláa upp í hundruð milljarða eða billjóna færibreytum á sama tíma og hún býður upp á sanngjarnar tafir á ályktunartíma. MoE-líkön skipta út þéttualagi spennis (transformer) fyrir sett af sérfræðingum og lítið línulegt leiðalag sem ákveður hvaða sérfræðingum eigi að margfalda tákn (token) með. Með því að flokka saman táknin sem tengjast sama sérfræðingi verður vandamálið strjált og auðvelt að samhliða, þar sem hægt er að hýsa mismunandi sérfræðinga á mismunandi GPU-tækjum dreifðum yfir marga hnúta.

Ólíkt öðrum tegundum samhliðunar, svo sem Tensor Parallelism (TP) og Data Parallelism (DP) sem hægt er að útfæra auðveldlega með sameiginlegum samskiptasöfnum eins og torch.distributed og NCCL, felur MoE-leiðsögn í sér strjál jafningjasamskipti (peer-to-peer). Útsendingarkjarni (dispatch kernel) verður að skipta hópi innkominna tákna og senda þau til raða sem hýsa sérfræðingana, á meðan tvíhliða vandamál hans, samsetningarkjarninn (combine kernel), verður að taka á móti unnum hliðstæðum þeirra og reikna út vegið meðaltal þeirra. Þessir flutningar kortleggjast ekki í söfn og krefjast sérsniðinna kjarna til að ná lágum töfum.

Hjá Perplexity höfum við verið að þróa bæði færanlega kjarna á milli hnúta og sérhæfða kjarna innan hnúta, og kynnt vinnu okkar dýpra í fyrri grein um MoE-samskipti. Við sýndum einnig í annarri bloggfærslu að útfærsla á mörgum hnútum getur skilað minni töfum og meiri afköstum fyrir stór MoE-líkön.

Í þessari grein kafum við dýptina í útfærslu á nýjum kjörnum okkar á milli hnúta sem bætir verulega afköst fyrri vinnu okkar sem byggði á NVSHMEM. Fyrir utan að sýna framúrskarandi árangur á ConnectX-7 sýnum við einnig fram á að innan ályktunarkeyrslutíma okkar er hægt að nota kjarnana til að þjónusta stærstu opnu líkönin með árangursríkum hætti.

Ályktun yfir InfiniBand

Tensor-samhliðun og sérfræðinga-samhliðun geta skilað árangursríkum mælikvörðum innan eins hnútans, þar sem NVLink býður upp á mikil afköst (900 GB/s) á örsekúndna töfum. Þó að NVIDIA GB200 og GB300 kerfin séu búin nægilegu minni til að geyma þyngdir og KV-skyndimynni (caches) billjóna-færibreytu líkana, takmarkast útfærslur á AWS p5en tilvikum með allt að 8 H200 GPU við 1120 GB af HBM, sem þarf að skipta á milli bæði líkanþyngda og KV-skyndimynna. Þar af leiðandi krefjast ákveðin líkön útfærslna á milli hnúta yfir InfiniBand.

Þó að InfiniBand sé enn mjög hratt, býður það eingöngu upp á 400 Gbps (50 GB/s) afköst, sem bætir tugum til hundruðum örsekúndna við tafir vegna MoE-leiðsagnar. Lukkulega er hægt að fela viðbótartafirnar með því að nota deilda sérfræðinga, örlotuvinnslu (micro-batching) og útreikninga-samskipta skörun til að skila raunhæfum afköstum á samkeppnishæfum kostnaði. DeepSeek var frumkvöðull að þessari tækni í gegnum DeepSeek-R1, sem er útfært á klasa af H800 GPU og NVIDIA ConnectX-7 InfiniBand millistykkjum.

Á AWS-klösum er staðan önnur vegna notkunar á sérsniðnum Elastic Fabric Adapters (EFA). Jafnvel þó að þeir skili hámarksafköstum upp á 400 Gbps á þeim söfnum sem venjulega eru notuð í þjálfunarvinnuálagi, ná þeir ekki alveg ConnectX-7 á skilaboðastærðum sem skipt er á milli við MoE útsendingu og samsetningu. Að auki styður EFA ekki GPUDirect Async, sem krefst þess að CPU-gagnaþráður brúi GPU við netkortið (NIC) til að koma flutningum af stað. Fyrir utan aukna flækjustig bæta viðbótar PCIe-færslum við kostnað í örsekúndum fyrir alla flutninga. Rammar eins og NVSHMEM leyfa kjarnarithöfundum að bjóða upp á tækisháðar útfærslur, en almenn API-viðmót valda aukakostnaði sem gerir útfærslur óskilvirkar bæði hvað varðar kostnað og tafir.

NVSHMEM-undirstaða pplx-kjarnar

Fyrri kjarnar okkar dregu úr undirliggjandi flutningsútgáfu í gegnum NVSHMEM. Þeir reiddu sig á nvshmemx_putmem_signal_nbi_warp til að flytja tákn eitt af öðru, með því að nota frumeindateljara til að samstilla jafningja. Þó að þetta bauð upp á sanngjarna afköst á ConnectX-7 netkortum með IBGDA, var IBRC-útfærsla ConnectX-7 sem byggir á umboðsmanni (proxy) mun hægari, á meðan EFA-útfærslan tókst ekki að skila töfum undir millisekúndu.

Við notuðum kjarnana sem prófunarumhverfi fyrir undirliggjandi vélbúnað, á sama tíma og við ákváðum hentugasta viðmótið til að birta fyrir líkönin okkar. Við gerðum ráð fyrir að tíðir flutningar og samskipti milli kjarnanna og netkortanna eða proxy-þráðanna hindruðu afköst. Að auki reiddi útfærsla okkar sig ekki á neinar tryggingar frá vélbúnaðinum öðruvísi en áreiðanleika, sem bendir til þess að við gætum flýtt fyrir hlutunum með því að minnka kostnað við samstillingarfrumstæður.

Í kjölfar þessara athugana bjuggum við til EFA-undirstaða kjarna okkar sem bjóða upp á sama viðmót og fínstilltu samskipti tækjakjarna og hýsilumboðsmanns undir vélarhlífinni til að ná hámarksafköstum.

MoE all-to-all yfir EFA

Stækka

Nýju kjarnarnir fylgja tvinnarkitektúr CPU og GPU, þar sem GPU-kjarnar eiga í samskiptum við líkanið á tækinu og proxy-þráður sem keyrir á hýsil-CPU sér um samskipti við netkortið. Nýju kjarnarnir endurnota sama TransferEngine og við smíðuðum fyrir flutning á KV-skyndimynni.

MoE-leiðsögn er framkvæmd af útsendingarkjarna, sem tekur við táknunum og tákn-fyrir-tákn sérfræðingum til að beina þeim frá líkaninu, og sendir þau yfir netið til raða sem hýsa sérfræðingana. Eftir að hópaðir GEMM-kjarnar margfalda táknin með þyngdum sérfræðinganna, flytur samsetningarkjarninn táknin yfir á upprunaraðir sínar og reiknar út vegið meðaltal þeirra áður en þau eru skilað til baka í líkanið.

Bæði útsendingar- og samsetningarkjarnarnir eru skiptir í sendi- og móttökuhluta til að auðvelda skörun og örlotuvinnslu. Sendirinn raðar táknunum í sendibiðminni þannig að hægt sé að skrifa þau í jafningja með einni RDMA-skrifaðgerð. Eftir keyrslu sendisins getur GPU framkvæmt önnur verk (svo sem margföldun deildra sérfræðinga) á meðan flutningar yfir netið eru í bið í bakgrunni. Móttökukjarnarnir loka á keyrslu þar til öllum flutningum hefur verið tekið móti. Í bakgrunni sér vinnsluferli á hýsilhlið um flutningana: því er gefið merki frá GPU þegar sendibiðminnin hafa verið fyllt, eftir það sendir það út RDMA-skrifin. Þegar netkortið gefur merki um að lokum er lokið, aflæsir það móttökaranum, sem skilar táknunum í líkanið.

Kjarnarnir eru þéttengdir hýslinum og eiga í samskiptum hvor við annan í gegnum bæði samþætt minni (unified memory) og GDRCopy. CUDA samþætt minni gerir tækjaminni eða hýsilminni kleift að vera kortlagt inn í vinnusvæði hvors tveggja, og sér gagnsætt um samskipti í gegnum PCIe.

Þó að samþætt minni hentar fyrir magngögn, er könnun með lágum töfum gerð í gegnum GDRCopy. GDRCopy notar GPUDirect RDMA til að lesa úr og skrifa í GPU-minni á örsekúndna töfum.

Til viðbótar við RDMA, nýta kjarnarnir einnig NVLink til að skiptast á táknum innan eins hnútar. Þetta getur losað umtalsverðan hluta umferðarinnar, allt að fjórðung fyrir EP32 og allt að áttung fyrir EP64, og náð heilt yfir lægri töfum.

Sendi- og móttökubiðminni

Hönnun sendibiðminna fyrir útsendingarkjarnann skiptir sköpum til að ná raunhæfum töfum sem fela í sér hýsilumboðsmanninn. Ef það eru N raðir sem hver um sig sendir T tákn, sem hver um sig er beint til R sérfræðinga af E, getur röð tekið við allt að N * T * max(R, E / N) táknum í versta mögulega tilviki, ef öllum er beint til hennar. Að auki er aðeins hægt að ná þessu lágmarksmarki þegar sendendur raða skrifum sínum samfellt, þar sem einkamóttökubiðminni myndu nota of mikið minni. Til að sendendur geti raðað skrifum sínum í röð án árekstra þarf að dreifa fullri þekkingu á leiðarupplýsingum til hverrar raðar. Þar af leiðandi skiptast útsendingarkjarnarnir okkar fyrst á fjölda tákna á hvern sérfræðing, á eftir þessu getur hvor um sig ákvarðað hvert skrif þeirra fara og hvaða hliðrun (offset) þeir taka við táknum frá hverri röð.

Einföld skipti á leiðarupplýsingum myndu leiða til óþarfa hána tafna, þar sem hver röð þyrfti að bíða eftir að skrifin kæmu áður en hún sendir út sín eigin skrif. Í staðinn frátekkum við lítið magn af einkavinnusvæði fyrir hvern sendi á hverri móttökuröð og sendum nokkur tákna með skrifum leiðarupplýsinganna. Þetta tryggir fulla bandbreiddarnýtingu í gegnum stærsta hluta útsendingarferlisins. Eftir að leiðum hefur verið skipt er afgangurinn af táknunum fluttur með einni skráningu á hvern fjarjafningja. Skipti á leiðarupplýsingum og fastastærðu biðminnin, ásamt flutningum sem fylla þau, eru sýnd á myndinni hér að neðan.

Stækka

Samsetningarkjarnarnir eru mun einfaldari, þar sem leiðarupplýsingar eru þegar tiltækar fyrir þá frá útsendingarstiginu. Þeir geta afritað táknin yfir í einni skráningu á hvern jafningja, og eftir það lesa þeir úr móttökubiðminninu til að reikna út vegið meðaltal táknanna yfir í úttaksspennur.

Fyrir NVLink eru sendi- og móttökubiðminni innan hnút útbúin í jafningjum til að þeir geti beint ýtt eða dregið tákn frá nágrannaröðum.

Útsending og samsetning

Myndirnar hér að neðan útskýra tímasetningu og samskipti milli GPU, CPU og netkortss, og sýna eina ítrun af útsendingu og samsetningu sem fléttuð er saman við kjarna líkansins.

Vinna hefst við útsendingarsendingu, þar sem kjarninn safnar saman leiðarupplýsingum og reiknar út fjölda tákna á hvern sérfræðing með frumeindasöfnun (atomic accumulation) í sameiginlegu minni innan eins blokkar. Þegar táknfjöldinn er tiltækur er hann afritaður í hýsilminni og umboðsmanninum er tafarlaust tilkynnt að byrja að senda út leiðarupplýsingar til allra hinna jafningjaraðanna. Samhliða heldur útsending áfram að reikna út safnsummu táknfjöldans og auðkennir hliðrunina sem þarf til að pakka táknum í samfelld sendibiðminni fyrir hverja röð. Þegar hliðrunin er tiltæk er öllum táknum sem á að senda í gegnum EFA pakkað í sendibiðminnin. Umboðsmanninum er tilkynnt að setja skrifin inn í sendibiðminni jafningja á milli hnúta. Innan hnútans ýta kjarnarnir einnig tafarlaust táknum inn í einkabiðminni innan sama hnút í gegnum NVLink.

Stækka

Stækka

Þegar röð hefur tekið við leiðarupplýsingum frá öllum jafningjum safnar hún þeim saman og reiknar út ýmsar hliðranir sem nauðsynlegar eru til að auðkenna tákn til útsendingar og samsetningar. Þessi vinna er unnin á CPU á meðan flutningar eru þegar í bið, þannig að hún er ekki tímakrítísk. Í kjölfarið, þegar allar hliðranir eru þekktar, eru skrif fyrir afganginn af táknunum, sem fara yfir stærð einkabiðminnisins, send inn og sendingaráfanga útsendingar er lokið.

Á móttökuhliðinni dregur kjarninn fyrst tákn frá sama hnút sem eru umfram afkastagetu einkabiðminna í gegnum NVLink. Næst lokar hann á keyrslu þar til hýsilumboðsmaðurinn gefur merki um að öllum flutningum sé lokið. Þegar merkið hefur borist er táknum raðað frá móttökubiðminninu yfir í úttaksspennu sem send er í hóp-GEMM. Þar sem biðminni eru endurnotuð á milli útsendingar og samsetningar tryggja bæði NVLink- og RDMA-hindranir að móttökubiðminni hafa verið lestið áður en næsti kjarni fær að skrifa yfir þau.

Samsetningarkjarnarnir fylgja svipuðu mynstri, raða táknum, gefa umboðsmanninum merki og bíða eftir að ljúki. Hins vegar eru lýsigögnin til að setja inn skrif sín aðgengileg og allar fjarhliðranir eru þekktar, þannig að öllum táknum sem flutt eru innan hnút er ýtt í gegnum NVLink til móttakaranna og tákn á milli hnúta eru flutt með einni skráningu. Áður en niðurstöðum er skilað safnar kjarninn saman táknunum úr móttökubiðminninu og skrifar þau inn í úttaksspennurnar.

TransferEngine fyrir MoE-leiðsögn

Til að gera frumgerð af útfærslu okkar endurnotuðum við í upphafi TransferEngine sem var smíðaður fyrir sundurgreinda forskráningu og afkóðun til að gefa út og fylgjast með RDMA-skrifum. Hins vegar, ólíkt sundurgreindri afkóðun þar sem hver hnútur sendir út mikinn fjölda skrifa á sama jafningja, sendir MoE-útsending út litla flutninga til allra jafningjanna í einni aðgerð. Beint úr kassanum voru afköst ekki ákjósanleg og útfærsla okkar var um 20 us á eftir DeepEP á ConnectX-7. Þess vegna sérhæfðum við TransferEngine til að styðja við tvær aðgerðir, dreifingu (scatter) og hindrun (barrier), til að fínstilla samskipti við mikinn fjölda jafningja.

Bæði dreifingar- og hindrunaraðgerðir bjóða upp á jafningjahópa sem hægt er að skrá fyrirfram til að fylla fyrirfram gögnin sem undirliggjandi flutningsútfærsla notar (Work Request (WR) sniðmát). Dreifing afritar mismunandi sneiðar úr sama upprunabiðminni í mismunandi hliðranir á öllum meðlimum jafningjahóps. Hindrun gefur öllum jafningjum merki í gegnum strax-gildi. Að raða þessum aðgerðum í biðröð og meðhöndla þær í lausu sparar dýrmætar örsekúndur á mikilvægu leiðinni. Á EFA, þar sem tvö 200 Gbps netkort sameinast til að veita 400 Gbps bandbreidd, skiptum við jafningjahópum á netkortin tvö í stað þess að skipta bætunum í hverjum flutningi.

Þó að við höfum í upphafi þróað TransferEngine eingöngu á EFA með því að nota libfabric, virka MoE-kjarnarnir á ConnectX-7 án þess að breyta einni línu af kóða eftir að hafa bætt við stuðningi við ConnectX-7 í TransferEngine með því að nota libibverbs. Samborið við Scalable Reliable Datagram (SRD) byggðan EFA krefst ConnectX-7 viðbótarvinnu við uppsetningu tenginga og jafningjastjórnun. Við notum Unreliable Datagram (UD) biðraðapör til að ræsa Reliable Connection (RC). Við búum til tvö biðraðapör fyrir hvern fjarjafningja, eitt fyrir tvíhliða SEND/RECV og eitt fyrir einhliða WRITE_IMM, vegna þess að bæði RECV og WRITE_IMM eyða RECV-aðgerð í röð á meðan aðgerðirnar tvrðar krefjast mismunandi biðminnisstærða. Að auki slökum við á röðun PCIe-færslna milli ConnectX-7 og GPU-minnis. Svipað og EFA útfærum við WR-sniðmátsfínstillinguna. Að auki, þegar mörg lítil skilaboð eru send til sama jafningja, notum við WR-tengingu til að bæta skilaboðatíðni.

Þar sem vinnan á GPU-hliðinni er eins á milli beggja millistykkja, ýttum við undirliggjandi flutningsútfærslu að mörkum hennar til að fara fram úr afköstum DeepEP til að leggja áherslu á að bilið á milli EFA og ConnectX-7 MoE-leiðsagnar er ákvarðað af getu undirliggjandi vélbúnaðar.

Mat

Tafir á útsendingu og samsetningu

Við matum tafir á útsendingu og samsetningu á H200 kerfum sem eru búin ConnectX-7 og EFA millistykkjum á staðlaðri DeepSeek-V3 og Kimi-K2 stillingu með falinni vídd upp á 7168, blokk-skalaðri fp8 útsendingu og bf16 samsetningu. Við tökum mið af lotustærð 128 fyrir útsendingu og 4096 fyrir samsetningu. Á ConnectX-7 berum við saman við DeepEP og fyrri NVSHMEM-undirstaða pplx-kjarna okkar, með því að nota bæði GPUDirect Async (IBGDA) og hýsilumboðsmann (IBRC). Við náum samtals töfum upp á 459 us, 582 us og 692 us á EP16, EP32 og EP64, í sömu röð. Við stöndum okkur betur en aðrir EFA-undirstaðir kjarnar sem reiða sig á almenna umboðsmenn, svo sem UCCL-EP, sem ná 519 us, 966 us og 1159 us.

Stækka

Við afkóðun, þrátt fyrir að kjarnarnir okkar séu nokkrum örsekúndum hægari en DeepEP, náum við heilt yfir lægri töfum þar sem samsetningarkjarnarnir okkar eru mun hraðari. Þó að við notum hýsilumboðsmann, vegna magngagnaflutninga okkar, förum við fram úr afköstum allra IBGDA-undirstaðra útfærslna án umboðsmanns. Við sýnum einnig að útfærsla umboðsmanns skiptir máli, þar sem mjög sérhæfður umboðsmaður okkar er stærðargráðu hraðari en almenna NVSHMEM útfærslan. Þrátt fyrir þ staðreynd að EFA sé helmingi hægari en ConnectX-7 þegar flutt eru 256 KB pakkar, sem eru nálægt dæmigerðri pakkafjöldastærð sem skipt er um við MoE-leiðsögn, er bilið á milli millistykkjanna tveggja heilt yfir minna verulegt.

Stækka

Jafnvel þó að afkóðunarfínstilltu kjarnarnir okkar geti stækkað upp að forskráningarlotustærðum án nokkurra viðbótarstillinga, eru afköstin á eftir DeepEP. Þetta stafar fyrst og fremst af því að við söfnum táknum aðeins á móttökuhlið samsetningar, á meðan DeepEP safnar í sendinum til að draga úr magni gagna sem flutt eru. Hins vegar getur þessi fínstilling haft áhrif á nákvæmni. Að auki, þar sem kjarnarnir flytja gögn í einni skráningu, nýtum við meira minni fyrir sendi- og móttökubiðminni.

Afköst Kimi-K2 / DeepSeek-V3

Til að sanna virkni kjarna okkar prófum við end-to-end afköst innanhúss ályktunarvélar okkar sem þjónustar DeepSeek-V3 (671B færibreytur) og Kimi-K2 (1T færibreytur) á mörgum p5en tilvikum búnum með Elastic Fabric Adapters (EFA) og H200 GPU. Við keyrum líkanið í drögum staðfestingarham og birtum tafir miðað við 80% samþykki með því að nota eitt MTP-lag.

Á DeepSeek-V3 berum við saman við EP=8 grunntilfelli innan hnút sem keyrir skilvirka NVLink-einu útsendingar- og samsetningarkjarna. Útfærslur á milli hnúta passa annaðhvort eða fara fram úr afköstum einstaks hnút, sérstaklega á meðalstórum lotum, sem sýnir að stækkun yfir hnúta skilar endurbótum á heildarafköstum.

Á Kimi-K2 gera kjarnarnir þjónustu mögulega. Vegna stærðar sinnar kemst líkanið ekki fyrir innan sama hnút með Data Parallelism (DP) á H200 hnút, þess vegna er útfærsla á milli hnúta nauðsynleg til að þjónusta líkanið. Þar sem líkanið hefur færri athyglisthausar náum við betri töfum en DeepSeek-V3 og við getum þjónustað líkanið á EFA á raunhæfri töf.

Stækka

Stækka

Við höfum einnig skoðað örlotuvinnslu, þó að það hafi aðeins bætt tafir við mjög háar lotustærðir eða þegar fleiri en eitt dráttartákn eru notuð. Til að njóta góðs af því að skipta hóp-GEMM vandamálum í tvennt verða táknalotustærðir að vera nægilega þéttar. Meginhluti tímans fer þó í MoE-útsendingu og samsetningu, sem gefur til kynna að allar frekari umbætur á kjörnum muni í kjölfarið bæta tafir og auðvelda örlotuvinnslu.

Framtíðarvinna

Við erum í nánu samstarfi við verkfræðinga hjá AWS til að bæta afköst á EFA. Hjá okkur munum við fylgja eftir uppfærslum á libfabric sem munu draga úr kostnaði gagnasvæðis. Að auki munum við gera tilraunir með efa-direct til að draga enn frekar úr kostnaði við vinnusvæði notenda og eiga samskipti beint við vélbúnaðinn.

Heimildir

Tækniskýrsla um DeepSeek R1

Tækniskýrsla um Kimi K2

DeepEP

UCCL-EP

Bæting á afköstum kerfisstöðva afkastamikilla tölvumála með því að nota NVIDIA Magnum IO NVSHMEM og GPUDirect Async

Tilvitnun

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}