Billió paraméteres modellek engedélyezése az AWS EFA-n

A Perplexitynél a legjobb modelleket használjuk termékeinkhez, API-jainkhoz és kutatócsoportjainkhoz. A nagy, nyílt forráskódú MoE (Mixture-of-Experts) modellek, mint például a Kimi-K2, különleges kihívásokat jelentenek, mivel a 8 darab NVIDIA H200 GPU-val rendelkező legnagyobb inferencia-csomópontok nem tudják őket hatékonyan befogadni, ami több csomópontot átívelő (multi-node) kiépítést tesz szükségessé. Olyan kernelek sorozatát mutatjuk be a szakértői párhuzamossághoz (expert parallelism), amelyek csúcskategóriás késleltetéseket érnek el ConnectX-7-en, felülmúlva a DeepEP teljesítményét. Ugyancsak ezek az elsők, amelyek életképes késleltetést érnek el az AWS Elastic Fabric Adapteren (EFA), lehetővé téve a billió paraméteres modellek telepítését.

Próbálja ki kerneleinket a GitHub oldalon, és olvassa el a teljes kutatási cikket az arXiv-on.

A Mixture-of-Experts (MoE) architektúra a szabvánnyá vált a több száz milliárd vagy billió paraméterre való skálázásban, miközben ésszerű késleltetést biztosít az inferencia során. A MoE modellek a transzformátor sűrű rétegét szakértők egy halmazával és egy kis lineáris útválasztó (routing) réteggel helyettesítik, amely eldönti, hogy egy tokent melyik szakértővel kell szorozni. Az azonos szakértőhöz tartozó tokenek csoportosításával a probléma ritkává (sparse) és triviálisan párhuzamosíthatóvá válik, mivel a különböző szakértők mostantól több csomópontra kiterjedő, különböző GPU-kon futtathatók.

A párhuzamosság más formáival – például a tenzorpárhuzamossággal (TP) és az adatpárhuzamossággal (DP) – ellentétben, amelyek könnyen megvalósíthatók olyan kollektív kommunikációs könyvtárakkal, mint a torch.distributed és a NCCL, a MoE útválasztás ritka (sparse) peer-to-peer kommunikációt foglal magában. Egy elosztó (dispatch) kernelnek szét kell osztania a bejövő tokenek halmazát, és el kell küldenie azokat a szakértőket hosztoló rangoknak, míg a duális problémájának, az egyesítő (combine) kernelnek fogadnia kell a feldolgozott párokat, és ki kell számítania azok súlyozott átlagát. Ezek az átvitelek nem képezhetők le kollektívekre, és testreszabott kerneleket igényelnek az alacsony késleltetés eléréséhez.

A Perplexitynél hordozható csomópontok közötti (inter-node) és speciális csomóponton belüli (intra-node) kerneleket egyaránt fejlesztünk, és munkánkat részletesebben is bemutattuk a MoE kommunikációról szóló korábbi cikkünkben. Egy másik blogbejegyzésünkben azt is kimutattuk, hogy a több csomópontos kiépítés alacsonyabb késleltetést és nagyobb áteresztőképességet eredményezhet a nagy MoE modellek esetében.

Ebben a cikkben mélyrehatóan bemutatjuk az új csomópontok közötti kerneleink megvalósítását, amely jelentősen javítja az NVSHMEM-alapú korábbi munkánk teljesítményét. Amellett, hogy csúcskategóriás eredményeket mutatunk be ConnectX-7-en, azt is demonstráljuk, hogy az inferencia futtatókörnyezetünkön belül a kernelek hatékonyan használhatók a legnagyobb nyílt forráskódú modellek kiszolgálására.

A tenzorpárhuzamosság és a szakértői párhuzamosság hatékonyan skálázható egyetlen csomóponton belül, mivel az NVLink nagy áteresztőképességet (900 GB/s) biztosít mikroszekundumos nagyságrendű késleltetéssel. Míg az NVIDIA GB200 és GB300 rendszerek elegendő memóriával rendelkeznek a billió paraméteres modellek súlyainak és KV-gyorsítótárainak (KV cache) tárolásához, az AWS p5en példányain történő kiépítések legfeljebb 8 H200 GPU-val 1120 GB HBM-re vannak korlátozva, amelyet meg kell osztani a modellsúlyok és a KV-gyorsítótárak között. Következésképpen bizonyos modellek InfiniBandon keresztüli, csomópontok közötti kiépítést igényelnek.

Bár az InfiniBand továbbra is rendkívül gyors, mindössze 400 Gbps (50 GB/s) áteresztőképességet kínál, ami tíztől százig terjedő mikroszekundummal növeli a MoE útválasztás késleltetését. Szerencsére a plusz késleltetések elrejthetők a megosztott szakértők, a mikrokötegelés (micro-batching) és a számítás-kommunikáció átfedése (computation-communication overlapping) révén, így versenyképes költségek mellett biztosítható az életképes áteresztőképesség. A DeepSeek úttörő szerepet játszott ezekben a technikákban a DeepSeek-R1 révén, amelyet H800 GPU-k fürtjein és NVIDIA ConnectX-7 InfiniBand adaptereken helyeztek üzembe.

Az AWS-fürtökön a helyzet más az egyéni Elastic Fabric Adapterek (EFA) használata miatt. Bár ezek 400 Gbps csúcs-áteresztőképességet biztosítanak a betanítási munkaterheléseknél jellemzően használt kollektíveken, kissé elmaradnak a ConnectX-7-től a MoE elosztás és egyesítés során kicserélt üzenetméretek terén. Ezenkívül az EFA nem támogatja a GPUDirect Async funkciót, ami egy olyan CPU proxy szálat igényel, amely összeköti a GPU-t a hálózati kártyával (NIC) az átvitelek elindításához. A megnövekedett összetekségen túl a további PCIe-tranzakciók mikroszekundumos többletterhelést (overhead) adnak minden átvitelhez. Az olyan keretrendszerek, mint az NVSHMEM, lehetővé teszik a kernelírók számára, hogy eszközfüggetlen implementációkat biztosítsanak, azonban az általános API-k olyan többletterhelést okoznak, ami a kiépítéseket hatástalanná teszi mind a költségek, mind a késleltetés szempontjából.

Korábbi kerneleink az NVSHMEM segítségével elvonták az alsó szintű transzportimplementációt. Az nvshmemx_putmem_signal_nbi_warp függvényre támaszkodtak a tokenek egyenkénti átviteléhez, atomi számlálókat használva a peer-ek szinkronizálásához. Míg ez elfogadható teljesítményt nyújtott az IBGDA-val rendelkező ConnectX-7 hálózati kártyákon, a proxyn alapuló ConnectX-7 IBRC implementáció lényegesen lassabb volt, míg az EFA implementáció nem tudott egy ezredmásodperc alatti késleltetést biztosítani.

A kerneleket az alapprogramhardver tesztkörnyezeteként használtuk, miközben meghatároztuk a modelljeink számára feltárandó legmegfelelőbb interfészt. Feltételezésünk szerint a kernelek és a hálózati kártyák vagy a proxy szálak közötti gyakori átvitelek és interakciók akadályozták a teljesítményt. Ezenkívül implementációnk a megbízhatóságon kívül nem támaszkodott semmilyen garanciára a hardver részéről, ami arra utalt, hogy a szinkronizációs primitívek többletterhelésének csökkentésével felgyorsíthatjuk a folyamatokat.

Ezen megfigyeléseket követően megterveztük az EFA-alapú kerneleinket, amelyek ugyanezt az interfészt tárják fel, és a motorháztető alatt optimalizálják az eszközkernelek és a hoszt proxy közötti interakciókat a csúcsteljesítmény érdekében.

RDMA és NVLink hibrid kommunikáció hoszt proxyval, amely az indító és fogadó rankeket, a proxy-munkásokat és a NIC-eket mutatja.

Az új kernelek hibrid CPU-GPU architektúrát követnek, ahol a GPU-kernelek az eszközön lévő modellel kommunikálnak, a hoszt CPU-n futó proxy szál pedig a hálózati kártyával való interakciókat kezeli. Az új kernelek újrahasznosítják ugyanazt a TransferEngine-t, amelyet a KV-gyorsítótár átvitelekhez építettünk.

A MoE útválasztást egy elosztó (dispatch) kernel hajtja végre, amely fogadja a modelltől a tokeneket és a tokonkénti szakértőket, amelyekhez irányítani kell őket, és elküldi azokat a hálózaton keresztül a szakértőket hosztoló rangoknak. Miután a csoportosított GEMM-kernelek megszorozzák a tokeneket a szakértői súlyokkal, az egyesítő (combine) kernel átviszi a tokeneket a forrásrangjaikra, és kiszámítja azok súlyozott átlagát, mielőtt visszaküldené őket a modellnek.

Mind az elosztó, mind az egyesítő kernel küldő és fogadó félre van osztva az átfedés és a mikrokötegelés megkönnyítése érdekében. A küldő a küldési pufferekbe rendezi a tokeneket, így azok egyetlen RDMA írási művelettelírhatók a peer-ekbe. A küldő végrehajtása után a GPU képes egyéb feladatokat elvégezni (például a megosztott szakértői szorzást), amíg a hálózati átvitelek a háttérben függőben vannak. A fogadó kernelek blokkolnak mindaddig, amíg az összes átvitel meg nem érkezik. A háttérben egy hoszt oldali munkaszál (worker thread) kezeli az átviteleket: a GPU jelzést küld neki, amikor a küldési pufferek feltöltődtek, ezt követően elindítja az RDMA írásokat. Amikor a hálózati kártya jelzi a befejezést, feloldja a fogadó blokkolását, amely visszaküldi a tokeneket a modellnek.

A kernelek szorosan kapcsolódnak a hoszthoz, egységes memórián (unified memory) és GDRCopy-n keresztül kommunikálva egymással. A CUDA egységes memória lehetővé teszi az eszközmemória vagy a hosztmemória leképezését mindkettő címtérébe, átlátható módon kezelve a PCIe-n keresztüli kommunikációt.

Míg az egységes memória alkalmas tömeges átvitelekre, az alacsony késleltetésű lekérdezés (polling) a GDRCopy segítségével történik. A GDRCopy GPUDirect RDMA-t használ a GPU-memóriából való olvasáshoz és oda történő íráshoz mikroszekundumos késleltetéssel.

Az RDMA mellett a csomóponton belül a kernelek az NVLinket is kihasználják a tokenek cseréjéhez. Ez a forgalom jelentős hányadát képes tehermentesíteni, EP32 esetén akár a negyedét, EP64 esetén pedig akár a nyolcadát is, összességében alacsonyabb késleltetést eredményezve.

Az elosztó kernel küldési puffereinek kialakítása kulcsfontosságú a hoszt proxy-t érintő életképes késleltetések eléréséhez. Ha N darab rang van, amelyek mindegyike T tokent diszpatcsel, és mindegyik R szakértőhöz van irányítva E-ből, akkor a legrosszabb lehetséges esetben egy rang legfeljebb N * T * max(R, E / N) tokent kaphat, ha mindegyik oda van irányítva. Ezen túlmenően ez az alsó korlát csak akkor érhető el, ha a küldők egymás mellett (contiguously) helyezik el az írásaikat, mivel a privát fogadási pufferek túl sok memóriát emésztenének fel. Ahhoz, hogy a küldők konfliktusok nélkül egymás után tudják elhelyezni az írásaikat, az útválasztási információk teljes körű ismeretét el kell juttatni az egyes rangokhoz. Következésképpen az elosztó kerneleink először cserélnek tokenszámokat szakértőnként, ami után mindegyik meg tudja határozni, hogy hová mennek az írásaik, és milyen eltolásból (offset) kapnak tokeneket az egyes rangoktól.

Az útválasztási információk egyszerű cseréje feleslegesen magas késleltetést eredményezne, mivel minden rangnak meg kellene várnia az írások megérkezését, mielőtt bármilyen saját írást elindítana. Ehelyett kis mennyiségű privát küldőnkénti teret tartunk fenn minden egyes fogadó rangon, és az útválasztási információk írásai mellett néhány tokent is elküldünk. Ez biztosítja a teljes sávszélesség-kihasználtságot az elosztási folyamat nagy részében. Az útvonalak cseréje után a fennmaradó tokenek átvitele távoli peer-enként egyetlen írással történik. Az útválasztási információk cseréjét és a rögzített méretű puffereket, valamint az azokat feltöltő átviteleket az alábbi ábra szemlélteti.

Az MoE diszpatch bufferelrendezése, amely bemutatja, hogyan vannak elrendezve és kicserélve a tokenadatok és az útválasztási metaadatok két rank között.

Az egyesítő (combine) kernelek lényegesen egyszerűbbek, mivel az útválasztási információk már rendelkezésükre állnak az elosztási szakaszból. Peer-enként egyetlen írással át tudják másolni a tokeneket, am ನಂತರ a fogadási pufferből olvasva kiszámítják a tokenek súlyozott átlagát a kimeneti tenzorokba.

Az NVLink esetében a csomóponton belüli küldési és fogadási pufferek be vannak képezve a peer-ekbe, hogy azok közvetlenül le tudják húzni vagy fel tudják tolni a tokeneket a szomszédos rangokról.

Az alábbi ábrák részletesen bemutatják az időzítést, valamint a GPU, a CPU és a NIC közötti interakciókat, feltüntetve az elosztás és az egyesítés egy iterációját a modell kerneleivel összefonódva.

A munka az elosztási küldésben (dispatch send) kezdődik, ahol a kernel összegyűjti az útválasztási információkat, és atomi akkumulációval kiszámítja a szakértőkénti tokenszámokat egyetlen blokkon belüli osztott memóriában. Amint a tokenszámok rendelkezésre állnak, a rendszer átmásolja azokat a hoszt memóriába, és a proxy azonnal értesítést kap az útválasztási információk elküldésének megkezdéséről az összes többi peer rang felé. Ezzel párhuzamosan az elosztás tovább számítja a tokenszámok kumulatív összegét, azonosítva a tokenek egymás melletti küldési pufferekbe csomagolásához szükséges eltolásokat. Amint az eltolások elérhetők, az EFA-n keresztül elküldendő összes tokent be kell csomagolni a küldési pufferekbe. A proxy értesítést kap az írások elhelyezéséről a csomópontok közötti peer-ek küldési puffereibe. A csomóponton belül a kernelek az NVLinken keresztül is azonnal betolják a tokeneket a csomóponton belüli privát pufferekbe.

Az MoE diszpatch időzítése és koordinációja, amely a GPU-, CPU- és NIC-műveletek szakaszolását és szinkronizációját mutatja.

Az MoE combine időzítése és koordinációja, amely a GPU-, CPU- és NIC-műveleteket és azok szinkronizációját mutatja.

Amikor egy rang megkapja az útválasztási információkat az összes peer-től, központosítja azokat, és kiszámítja a különféle eltolásokat, amelyek az elosztáshoz és egyesítéshez szükséges tokenek azonosításához szükségesek. Ez a munka a CPU-n történik, miközben az átvitelek már függőben vannak, így nem késleltetéskritikus. Ezt követően, amint minden eltolás ismert, a privát puffer méretét meghaladó tokenek fennmaradó részére vonatkozó írások bekerülnek a rendszerbe, és az elosztás küldési fázisa befejeződik.

A fogadó oldalon a kernel először azokat a tokeneket húzza le ugyanabból a csomópontból az NVLinken keresztül, amelyek meghaladják a privát pufferek kapacitását. Ezután blokkol, amíg a hoszt proxy jelzi az összes átvitel befejezését. A jelzés megérkezése után a tokenek a fogadási pufferekből átrendeződnek a csoportos GEMM-nek átadott kimeneti tenzorba. Mivel a pufferek újra vannak használva az elosztás és az egyesítés között, mind az NVLink, mind az RDMA korlátok biztosítják, hogy a fogadói pufferek ki legyenek olvasva, mielőtt a következő kernel felülírhatná őket.

Az egyesítő kernelek hasonló mintát követnek: átrendezik a tokeneket, jeleznek a proxynak és várnak a befejezésre. Az írások közzétételéhez szükséges metaadatok azonban azonnal rendelkezésre állnak, és minden távoli eltolás ismert, így a csomóponton belül ávitt összes token az NVLinken keresztül fel lett tolva a fogadókhoz, a csomópontok közötti tokenek átvitele pedig egyetlen írással történik. Az eredmények visszaküldése előtt a kernel akkumulálja a tokeneket a fogadói pufferekből, és beírja azokat a kimeneti tenzorokba.

Implementációnk prototípusának elkészítéséhez kezdetben újrahasznosítottuk a szétválasztott (disaggregated) előfeltöltéshez (prefill) és dekódoláshoz készült Transfer Engine-t az RDMA írások indításához és nyomon követéséhez. A szétválasztott dekódolással ellentétben azonban, ahol minden csomópont nagy számú írást küld ugyanabba a peer-be, a MoE elosztás kis átviteleket küld az összes peer-nek egyetlen műveletben. Dobozon kívül (out-of-the-box) a teljesítmény nem volt optimális, és implementációnk mintegy 20 us-mal lemaradt a DeepEP-től a ConnectX-7-en. Ennek következtében szakosítottuk a TransferEngine-t két művelet, a szórás (scatter) és a korlát (barrier) támogatására, hogy optimalizáljuk az interakciókat nagy számú peer-rel.

Mind a szórási, mind a korlátműveletek olyan peer-csoportokat tesznek elérhetővé, amelyek előregisztrálhatók az alsó szintű transzportimplementáció által használt adatszerkezetek előzetes feltöltéséhez (Work Request (WR) sablonozás). A szórás különböző szeleteket másol ugyanabból a forráspufferből különböző eltolásokra egy peer-csoport minden tagján. A korlát egy azonnali üzeneten (immediate) keresztül jelzi az összes peer-nek. Ezen műveletek tömeges várólistára helyezése (enqueuing) és kezelése értékes mikroszekundumokat takarít meg a kritikus útvonalon. Az EFA-n, ahol két 200 Gbps-os hálózati kártya egyesül 4096 Gbps-os sávszélességet biztosítva, a peer-eket a két hálózati kártya között shardoljuk ahelyett, hogy az egyes átvitelek bájtjait shardolnánk.

Bár kezdetben a TransferEngine-t kizárólag EFA-n fejlesztettük a libfabric használatával, a MoE kernelek egyetlen sor kód megváltoztatása nélkül működnek a ConnectX-7-en, miután hozzáadtuk a ConnectX-7 támogatást a TransferEngine-ben a libibverbs használatával. A Scalable Reliable Datagram (SRD) alapú EFA-hoz képest a ConnectX-7 további munkát igényel a kapcsolat beállításához és a peer-ek kezeléséhez. Megbízható kapcsolat (Reliable Connection, RC) bootstrapeléséhez Unreliable Datagram (UD) sorpárt (queue pair) használunk. Két sorpárt hozunk létre minden távoli peer-hez, egyet a kétoldalas SEND/RECV-hez és egyet az egyoldalas WRITE_IMM-hez, mivel mind a RECV, mind a WRITE_IMM sorrendben fogyasztja a RECV műveletet, miközben a két művelet eltérő pufferméretet igényel. Ezenkívül lazítjuk a PCIe tranzakciók sorrendiségét a ConnectX-7 és a GPU memória között. Az EFA-hoz hasonlóan megvalósítjuk a WR sablonozási optimalizálást. Ezenkívül, ha több kis üzenetet küldünk ugyanannak a peer-nek, WR láncolást (chaining) használunk az üzenetsebesség javítására.

Mivel a GPU oldali munka mindkét adapter esetében azonos, az alsó szintű transzportimplementációt a végsőkig feszítettük, hogy felülmúljuk a DeepEP teljesítményét, rávilágítva arra, hogy az EFA és a ConnectX-7 MoE útválasztás közötti rést az alsó szintű hardver képességei határozzák meg.

Értékeltük az elosztási és egyesítési késleltetéseket ConnectX-7 és EFA adapterekkel felszerelt H200 rendszereken, a szabványos DeepSeek-V3 és Kimi-K2 konfiguráción, 7168-as rejtett dimenzióval, blokk-skálázott fp8 elosztással és bf16 egyesítéssel. Az elosztásnál 128-as, az egyesítésnél 4096-os kötegméretet (batch size) veszünk figyelembe. A ConnectX-7-en összehasonlítjuk a DeepEP-pel és a korábbi NVSHMEM-alapú pplx-kerneleinkkel, GPUDirect Async-et (IBGDA) és hoszt proxyt (IBRC) egyaránt használva. EP16, EP32 és EP64 esetén 459 us, 582 us, illetve 692 us kombinált késleltetést érünk el. Felülmúljuk az általános proxykra támaszkodó egyéb EFA-alapú kerneleket, például az UCCL-EP-t, amelyek 519 us, 966 us és 1159 us értéket érnek el.

Az EP64 MoE decode diszpatch- és combine-késleltetése, az ábrázolt implementációk és kommunikációs útvonalak összehasonlításával.

A dekódolás során – annak ellenére, hogy kerneleink néhány mikroszekundummal lassabbak a DeepEP-nél – összességében alacsonyabb késleltetést érünk el, mivel az egyesítő kerneleink lényegesen gyorsabbak. Bár hoszt proxyt használunk, a tömeges átviteleinknek köszönhetően felülmúljuk az összes IBGDA-alapú, proxy nélküli implementáció teljesítményét. Azt is bemutatjuk, hogy a proxy megvalósítása számít, mivel a rendkívül specializált proxynk nagyságrenddel gyorsabb az általános NVSHMEM implementációnál. Annak ellenére, hogy az EFA kétszer olyan lassú, mint a ConnectX-7 256 KB-os csomagok átvitelekor, amelyek közel vannak a MoE útválasztás által kicserélt tipikus csomagsérethez, a két adapter közötti rés összességében kevésbé jelentős.

Az EP64 MoE prefill diszpatch- és combine-késleltetése, a pplx és a DeepEP kommunikációs útvonalainak összehasonlításával.

Annak ellenére, hogy a dekódolásra optimalizált kerneleink további finomhangolások nélkül képesek skálázódni az előfeltöltési kötegméretekre, a teljesítmény elmarad a DeepEP-től. Ez elsősorban annak tudható be, hogy mi csak az egyesítés fogadó oldalán akkumuláljuk a tokeneket, míg a DeepEP a küldő oldalon akkumulál az átvitt adatok mennyiségének csökkentése érdekében. Ez az optimalizálás azonban hatással lehet a pontosságra. Ezenkívül, mivel a kernelek egyetlen írással továbbítják az adatokat, több memóriát használunk a küldési és fogadási pufferekhez.

Kerneleink életképességének bizonyítására teljesítménytesztet (benchmark) futtatunk a DeepSeek-V3-at (671B paraméter) és a Kimi-K2-t (1T paraméter) kiszolgáló saját inferenciamotorunk teljesítményének mérésére több p5en példányon, amelyek Elastic Fabric Adapterekkel (EFA) és H200 GPU-kkal vannak felszerelve. A modellt tervezet-ellenőrzési (draft verification) módban futtatjuk, és 80%-os elfogadási arányt feltételezve jelentjük a késleltetést egyetlen MTP réteg használatával.

A DeepSeek-V3-on összehasonlítjuk egy EP=8 csomóponton belüli alapvonallal, amely hatékony, kizárólag NVLinket használó elosztási és egyesítési kerneleket futtat. A csomópontok közötti kiépítések összességében vagy elérik, vagy meghaladják az egycsomópontos kiépítés teljesítményét, különösen a közepes méretű kötegek esetén, ami bizonyítja, hogy a csomópontokon átívelő skálázás valóban javítja az általános áteresztőképességet.

A Kimi-K2 esetében a kernelek lehetővé teszik a kiszolgálást. Méretéből adódóan a modell nem fér el ugyanabban a csomópontban adatpárhuzamosság (DP) használatával egy H200 csomóponton, így a modell kiszolgálásához csomópontok közötti kiépítés szükséges. Mivel a modellnek kevesebb figyelmi feje (attention head) van, jobb késleltetést érünk el, mint a DeepSeek-V3 esetében, és életképes késleltetéssel tudjuk kiszolgálni a modellt az EFA-n.

DeepSeek-V3 GPU-nkénti átviteli teljesítménye az output sebességéhez viszonyítva EP32, EP16 és EP8 konfigurációkban.

Kimi-K2 GPU-nkénti átviteli teljesítménye az output sebességéhez viszonyítva EP32 és EP16 konfigurációkban.

Fontolóra vettük a mikrokötegelést is, bár az csak nagyon magas kötegméretek esetén vagy egynél több tervezet-token használatakor javította a késleltetést. Ahhoz, hogy a csoportosított GEMM problémák kettéosztásából előny származzon, a tokonkötegek méretének kellően sűrűnek kell lennie. Az idő nagyobb részét továbbra a MoE elosztás és egyesítés emészti fel, ami azt jelzi, hogy a kernelek bármilyen további továbbfejlesztése ennek következtében javítja a késleltetést és megkönnyíti a mikrokötegelést.

Szorosan együttműködünk az AWS mérnökeivel az EFA teljesítményének javítása érdekében. A magunk részéről figyelemmel kísérjük a libfabric frissítéseit, amelyek csökkentik az adatréteg többletterhelését. Ezenkívül kísérletezni fogunk az efa-direct-tel, hogy tovább csökkentsük a felhasználói tér (userspace) többletterhelését, és közvetlenül kommunikáljunk a hardverrel.

DeepSeek R1 technikai jelentés

Kimi K2 technikai jelentés

DeepEP

UCCL-EP

HPC-rendszerek hálózati teljesítményének javítása NVIDIA Magnum IO NVSHMEM és GPUDirect Async használatával

BibTeX

@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}
}

Bevezetés

Inferencia InfiniBandon keresztül

NVSHMEM-alapú pplx-kernelek

MoE all-to-all az EFA-n keresztül

Küldési és fogadási pufferek

Elosztás és egyesítés (Dispatch and Combine)

TransferEngine a MoE útválasztáshoz

Értékelés

Elosztási/egyesítési késleltetés (Dispatch/Combine Latency)

Kimi-K2 / DeepSeek-V3 áteresztőképesség

Jövőbeli munkák

Hivatkozások

Idézet