RDMA tvíhliða samskipti fyrir LLM kerfi

LLM kerfi hafa hingað til reitt sig á hópamskipti fyrir skipulögð samhliða mynstrum við þjálfun og ályktun. Hins vegar krefjast nýleg verkefni, svo sem sundurliðuð ályktun, Mixture-of-Experts (MoE) beinun og ósamstillt fínstilling á styrktarnámi, sveigjanleika tvíhliða samskipta.

Nýjasta rannsóknargrein okkar kynnir TransferEngine, færanlegt RDMA-undirbúið samskiptasafn sem virkar yfir mismunandi netviðmótsstýringar (NIC), þar á meðal NVIDIA ConnectX-7 og AWS Elastic Fabric Adapter (EFA). Við sýnum fram á virkni þess í þremur framleiðslukerfum hjá Perplexity AI:

Sundurliðað forálag og afkóðun: Lag-fyrir-lag KvCache flutningur með síðu-skrifum og UVM-vöktum, sem gerir forálags- og afkóðunartilvikum kleift að skýjast sjálfstætt.

Vigtarflutningur fyrir RL eftirþjálfun á undir 2 sekúndum: Ofurhraðvirk samstilling vigta á milli þjálfunar- og ályktunartölva.

Virkjun milljarða-færibreytna líkana á AWS EFA: Lágmarks-seinkunar MoE dreifingar- og samrunaaðgerðir með dreifingar- og hindrunar-frumgerðum, sem ná nýjustu seinkun á ConnectX-7 og fyrstu framkvæmanlegu útfærslunni sem er samhæf við AWS EFA.

Þessi grein beinist að TransferEngine sjálfu, samskiptasafninu sem knýr þessi kerfi. Lestu alla rannsóknargreinina á arXiv og skoðaðu kóðann á GitHub.

Hvatning

Hópamskipti skara fram úr í skipulögðum samhliða mynstrum eins og Tensor Parallelism og Data Parallelism, en þau setja skorður sem takmarka notagildi þeirra við ný verksvið:

Fast meðlimatalning: Hópamskipti krefjast þess að komið sé á alþjóðlegum samskiptaheimi við ræsingu, með samstilltri uppsetningu yfir alla þátttakendur. Fyrir sundurliðaða ályktun er þetta vandamál þar sem fjöldi forálags- og afkóðunartilvika verður að stækka dýnamískt í samræmi við umferðarmynstur.

Samræmdir tensórlögun: Hópamskipti gera ráð fyrir að allir þátttakendur skiptist á tensórum með eins konar lögun og gagnategundum. Við MoE beinun er fjöldi tákna sem sendir eru til hvers sérfræðings gagnaháður og uppgötvast við keyrslu, sem neyðir þétt all-to-all hópamskipti til að fylla upp í versta fall biðminnisstærða.

Aðgerðaröðun: Forrit skilgreina samstillta merkfræði fyrir hópamskiptaviðmót, jafnvel þegar forrit þurfa aðeins að vita að röð aðgerða hafi lokið. Til dæmis, við KvCache flutning, geta allar síður frá forálagstilviki til afkóðunartilviks borist í hvaða röð sem er. Á sama hátt, við RL vigtaruppfærslur, er hægt að flytja alla vigtartensóra sjálfstætt án raðunartakmarkana.

RDMA-undirstöðu tvíhliða samskipti leysa þessar takmarkanir eðlilega, en þrjár hindranir hafa komið í veg fyrir upptöku þeirra:

Safntakmarkanir: Þó að torch.distributed og NCCL bjóði upp á tvíhliða viðmót eins og Send/Recv, þá erfa þessar aðgerðir enn hópamskiptafræði og takmarkanir.

Vélbúnaðarfjölbreytni: NVIDIA ConnectX netstýringar með Reliable Connection (RC) flutningi eru algengasta RDMA-uppsetningin, sem tryggir afhendingu í réttri röð. Skýjaþjónustuveitendur eins og AWS nota annan vélbúnað, Elastic Fabric Adapter (EFA) með Scalable Reliable Datagram (SRD) flutningi skilar skilaboðum í rangri röð. EFA krefst þess einnig að sameina fjórar 100 Gbps netstýringar (eða tvær 200 Gbps netstýringar) til að ná 400 Gbps bandbreidd.

Hugbúnaðarfæranleiki: Núverandi RDMA söfn þjást af söluaðilalæsingu. DeepEP krefst GPU-hafinna RDMA (IBGDA) sem aðeins er fáanlegt á ConnectX. NVSHMEM sýnir alvarlega frammistöðuýrnun á EFA. Söfn eins og Mooncake og NIXL skorta stuðning við EFA eða eru enn í fyrstu þróun. Fyrir vikið er engin framkvæmanleg þjónustuveitendafæranleg lausn til fyrir LLM ályktun.

TransferEngine

TransferEngine bregst við þessum hindrunum með fjórum kjarnaeiginleikum:

Sameiginlegar flutningsforsendur: Í stað þess að miða við ákveðna netstýringu gerir TransferEngine ráð fyrir því einu að undirliggjandi flutningur sé áreiðanlegur en óraðaður, þ.e. skurðpunktur trygginga sem bæði RC- og SRD-flutningar veita.

ImmCounter samstilling: Nýstárleg frumgerð fyrir tilkynningu um lokun sem virkar án þess að treysta á skilaboðaröð, sem gerir sama kóða kleift að keyra á bæði röðuðum (RC) og óröðuðum (SRD) flutningum.

Fjöl-netstýringa stuðningur: Gagnsæ stjórnun margra netstýringa á hvern GPU, sem skiptir sjálfkrafa í sundur flutningum til að hámarka bandbreidd.

Lágmarks viðmótsflötur: Lítill hópur aðgerða sem dugar til að byggja upp flókin samskiptamynstur.

Stækka

TransferEngine ræsir einn vinnsluferli á hvern GPU. Hver vinnsluferli stýrir DomainGroup sem hnitastjórnar 1 til 4 RDMA netstýringum, allt eftir vélbúnaðarvettvangi (stök ConnectX-7 veitir 400 Gbps, á meðan EFA krefst fjögurra 100 Gbps millistykkja eða tveggja 200 Gbps millistykkja). Innan DomainGroup er hvert Domain vélbúnaðarsértækt og stýrir stakri netstýringu, sem sér um biðraðastjórnun, verkbeiðni og lokunarvöktun.

Hvert TransferEngine tilvik birtir eitt main address fyrir auðkenni og leit jafningja. Fjarlægir jafningjar skiptast á NetAddr gögnunum sem kóða netföng og hægt er að raðtengja fyrir úti-í-rás samskipti. Allir jafningjar í kerfi verða að nota sama fjölda netstýringa á hvern GPU. Þessi einsa uppsetning gerir TransferEngine kleift að skipta flutningum greindarfullkomlega: þegar flutningur er ræstur vita bæði uppruni og áfangastaður nákvæmlega hvaða netstýringar eru tiltækar, sem gerir sjálfvirka álagsskiptingu kleift yfir öll millistykkja.

Viðmótshönnun

TransferEngine birtir lágmarks viðmót sem dregur fram flækjustig undirliggjandi RDMA viðmóta.

Viðmótið samanstendur af nokkrum lykilhlutum:

Minni skráning

RDMA aðgerðir krefjast þess að minnissvæði séu skráð hjá netstýringunni fyrir gagnaflutning. reg_mr fallið tekur við ábendingu, lengd og tæki, og skilar tveimur handföngum:

MrHandle: Staðbundið handfang sem notað er sem uppruni fyrir flutninga

MrDesc: Raðtengjanlegur lýsari sem hægt er að skiptast á við fjarlæga jafningja til að gera þeim kleift að skrifa í skráða minnið

MrDesc gagnabyggingin inniheldur lista yfir fjarlæg netföng og fjarlæga lykla (einn á hvern netstýringu) sem veita fjarlægan aðgang að minnissvæðinu. Þessi hönnun meðhöndlar fjöl-netstýringa uppsetningar eðlilega.

Tvíhliða Send/Recv

Fyrir lítil skilaboð og RPC-stýringarstýriskilaboð býður TransferEngine upp á submit_send og submit_recvs:

submit_send: Sendir skilaboðin til fjarlægs jafningja sem auðkenndur er með NetAddr. Skilaboðunum er afritað innbyrðis, þannig að sá sem kallar getur strax endurnotað eða losað biðminnið.

submit_recvs: Birtir safn af móttökubiðminnum. Þegar skilaboð berast er afturkalli hrint af stað með mótteknum gögnum. Biðminninu er sjálfkrafa skilað í safnið eftir að afturkalli lýkur.

Einhliða skrift

Fyrir magn-gagnaflutninga býður TransferEngine upp á núll-afritunar einhliða skrifaðgerðir:

submit_single_write: Flytur samfellt svæði frá uppruna til áfangastaðar

submit_paged_writes: Flytur ósamfelldar síður tilgreindar með vísum, skrefum og hliðrunum

Báðar aðgerðir taka við valfrjálsu 32-bita strax-gildi sem er afhent móttakara atómískt við lokun.

Vélin skiptir stórum flutningum sjálfkrafa á milli margra netstýringa til að hámarka bandbreidd.

Jafningjahópar og magn-aðgerðir

Fyrir aðgerðir sem miða að mörgum jafningjum (algengt í MoE beinun), býður TransferEngine upp á fínstilltar frumgerðir:

add_peer_group: For-skráir safn af jafningjaföngum fyrir hraða leit

submit_scatter: Sendir mismunandi gagnabúta til hvers jafningja í hópnum

submit_barrier: Sendir aðeins-strax tilkynningu til allra jafningja (núll-bita flutningur)

Þessar aðgerðir eru fínstilltar fyrir litla seinkun með því að skyndiminni innri gagnabygginga og sniðmátagerð RDMA verkbeiðna, sem kemur í veg fyrir endurtekinn uppsetningarkostnað.

UVM Vökta: GPU-til-CPU Merkjagjöf

Lykiláskorun í LLM kerfum er að samstilla RDMA flutninga við framgang GPU. Tilvalið væri að gagnaflutningur hefjist um leið og GPU skilar útkomu, en að vafra um GPU frá CPU er óhagkvæmt.

TransferEngine bregst við þessu með UVM Watchers: sameinuðum sýndarminnisstöðum sem hægt er að uppfæra með GPU kjörnum (jafnvel innan CUDA grafíka) og vaka á skilvirkan hátt af CPU með því að nota GDRCopy. Þegar UVM vökti er úthlutað er afturkall skráð sem er ræst í hvert skipti sem GPU uppfærir gildið.

Þetta gerir kleift að nota mynstur eins og lag-fyrir-lag KvCache flutning: eftir að hver transformer lag klárast, hækkar GPU vöktuna, sem kveikir á RDMA flutningi á KvCache þess lags á meðan síðari lög halda áfram að reikna.

Tilkyning um lokun

TransferEngine býður upp á tilkynningarkerfi um lokun fyrir bæði frumkvöðlahliðina (sá sem kallar á submit_write) og móttakarahliðina (skotmark skrifaðgerða).

Tilkynning á frumkvöðlahlið: Þegar skrifaðgerð er send inn getur sá sem kallar valið að fá tilkynningu við lokun í gegnum annað hvort afturköllunarfall eða atómt fána. Þessi tilkynning staðfestir að gögnunum hafi verið flutt með árangri úr upprunabiðminninu.

Tilkynning á móttakarahlið: Lykilnýjungin er ImmCounter, hluti sem rekur teljara vísitöluð með 32-bita strax-tölum. Þegar skrifaðgerð ber með sér strax-gildi, er ImmCounter móttakarans hækkað atómískt við afhendingu gagna. expect_imm_count fallið gerir móttakara kleift að skrá afturkall sem kveikir þegar ákveðið strax-gildi nær markteljara. Teljararnir geta verið gagnsætt samstilltir við GPU í gegnum GDRCopy, vakaðir beint eða fylgst með í gegnum afturköll.

Þetta kerfi á móttakarahlið veitir áreiðanlega samstillingu án þess að krefjast skilaboðaraðar. Þetta virkar jafn vel á ConnectX netstýringum (sem tryggja afhendingu í röð yfir RC flutning) og EFA netstýringum (sem skila skilaboðum í rangri röð yfir SRD flutning).

Útfærsla

TransferEngine er útfært í Rust, þar sem úthlutanir, þræðir og samstilling eru fínstillt vandlega til að lágmarka seinkun og ná háum afköstum. Vélin ræsir einn vinnsluferli á hvern DomainGroup, sem hver um sig er læstur við CPU kjarna á NUMA hnútnum sem tækin eru tengd við, og lágmarkar þannig bæði tímasetningar- og minnisaðgangsseinkun. Gagnabyggingar sem eru sértækar fyrir lén eru úthlutaðar eftir læsingu til að tryggja að minni sé frátekið í réttum NUMA hnút. Einn vinnsluferli sér um allt að 4 Domain (hver stýrir stakri netstýringu), á meðan annar sérstakur þráður vaktar GPU til að uppfæra UVM vökta. Samskipti á milli þráða fara fram í gegnum læsivaldar biðraðir.

Viðmótið sendir beiðnir á DomainGroup sem þjónar viðeigandi tæki, þar sem sú fyrsta þjónar einnig hýsilnum. Í þröngri lykkju vaktar lénsvinnsluferli eftir nýjum verkum og setur forgang á innsendingu nýrra beiðna. Það fer eftir vélbúnaði og uppsetningu, beiðnum er skipt niður og álagi dreift jafnt yfir tiltæk Domain. Fyrstu skrif samsettrar beiðni eru send strax í sendibiðröð netstýringarinnar. Þegar nýjar beiðnir eru þrotnar heldur vinnsluferlið áfram með biðstöðu aðgerða og sendir skrif til að fylla vélbúnaðarpípuna. Í kjölfarið er lokunarbiðröðum vakað til að leita að loknum flutningum og strax teljarahækkunum. Viðburðum er safnað saman til að skila tilkynningum per flutning og afhenda flutninginn yfir í sérstakt afturköllunarþráð sem er deilt af öllum hópum.

Skipting innan DomainGroup er sveigjanleg. Flutningum er hægt að beina að ákveðnum netstýringum eftir vísitölu. Hægt er að skipta stökum skrifum. Síðuflutningur, dreifing og hindrunaraðgerðir, sem allar þýðast yfir í margar skriftur, geta skipt yfir allar netstýringar.

Vélbúnaðarsértækar fínstillingar

Domain í TransferEngine eru sérhæfð og fínstillt fyrir vélbúnaðinn sem þau stýra:

AWS EFA: EFA útfærslan notar libfabric, og stýrir lénafriði á hvern netstýringu innan DomainGroup. Helstu ákvarkanir um útfærslu og fínstillingar eru m.a.:

Núll-stærðar skriftur: EFA víkur frá RDMA forskriftinni með því að krefjast gildra marklýsara jafnvel fyrir núll-stærðar skrif. Þess vegna framfylgir TransferEngine gildum lýsara fyrir alla flutninga.

Verkbeiðnasniðmát: Fyllir út fyrirfram og heldur almennum reitum libfabric gagnabygginga áður en sent er, sem dregur úr kostnaði per aðgerð fyrir magnflutninga og jafningjahópaaðgerðir

NVIDIA ConnectX-7: ConnectX-7 útfærslan notar libibverbs með RC flutningi. Helstu ákvarkanir um útfærslu og fínstillingar eru m.a.:

UD biðraðapör fyrir handabönd: Hvert Domain notar Unreliable Datagram (UD) biðraðapar til að skiptast á RC tengingarmínum.

Sérstök RC biðraðapör: Býr til 2 RC biðraðapör á hvern jafningja, annað fyrir tvíhliða Send/Recv aðgerðir og hitt fyrir einhliða Write og WriteImm aðgerðir. Þessi aðskilnaður er nauðsynlegur vegna þess að bæði Recv og WriteImm lokanir eyða verkbeiðnum í birtingarröð, sem leyfir hágæða Recv merkfræði en styður WriteImm án truflana.

Verkbeiðnasniðmát: Fyllir út fyrirfram sameiginlega reiti verkbeiðnagagnabygginga fyrir magnflutninga og jafningjahópa.

Verkbeiðnakeðja: Tengir allt að 4 verkbeiðnir í gegnum next ábendingu ibv_send_wr, sem dregur úr fjölda dyrabjölluhringinga í netstýringuna.

Slökkt röðun: Virkjar IBV_ACCESS_RELAXED_ORDERING til að leyfa PCIe færslur í rangri röð á milli netstýringar og GPU minnis.

Niðurstaða

Með því að miða að skurðpunkti trygginga þvert á mismunandi RDMA flutninga og kynna röðunar-óháða samstillingu í gegnum ImmCounter, veitir TransferEngine færanlegan grunn fyrir tvíhliða samskipti í LLM kerfum. Safnið er opinn hugbúnaður og fáanlegt á GitHub, og við hvetjum samfélagið til að kanna það og byggja á því fyrir ný samskiptamynstur í stórum vélnámskerfum.

Tilvitnun

@online{perplexity2025RdmaPointToPointCommunicationForLlmSystems,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{RDMA point-to-point communication for LLM systems}},
  date = {2025-11-05},
  url = {https://www.perplexity.ai/hub/blog/rdma-point-to-point-communication-for-llm-systems}
}