Trilijonų parametrų modelių įgalinimas naudojant AWS EFA

„Perplexity“ mūsų gaminiams, API ir tyrimų komandoms naudojame geriausius modelius. Dideli atvirojo kodo mišrių ekspertų (angl. Mixture-of-Experts) modeliai, tokie kaip „Kimi-K2“, kelia ypatingų iššūkių, nes didžiausi inferencijos mazgai su 8 „NVIDIA H200“ GPU negali jų efektyviai talpinti, todėl prireikia kelių mazgų diegimo. Pateikiame ekspertų paralelizavimui skirtų branduolių rinkinį, kuris pasiekia pažangiausią delsą per „ConnectX-7“, aplenkdamas „DeepEP“ našumą. Šie branduoliai taip pat pirmieji pasiekia perspektyvią delsą AWS „Elastic Fabric Adapter“ (EFA) pagrindu, todėl tampa įmanoma diegti trilijonų parametrų modelius.

Išbandykite mūsų branduolius GitHub ir perskaitykite išsamų tyrimo dokumentą arXiv.

Įvadas

Mišrių ekspertų (MoE) architektūra tapo standartine architektūra, leidžiančia padidinti mastelį iki šimtų milijardų ar trilijonų parametrų, kartu užtikrinant priimtiną delsą inferencijos metu. MoE modeliai pakeičia tankųjį transformerio sluoksnį ekspertų rinkiniu ir nedideliu tiesiniu maršruto parinkimo sluoksniu, kuris nusprendžia, su kurio eksperto išvestimi padauginti žetoną. Suporuojant žetonus, susietus su tuo pačiu ekspertu, problema tampa retąja ir lengvai paralelizuojama, nes dabar skirtingi ekspertai gali būti talpinami skirtinguose GPU, paskirstytuose per kelis mazgus.

Skirtingai nuo kitų paralelizavimo formų, tokių kaip tenzorius paralelizavimas (TP) ir duomenų paralelizavimas (DP), kuriuos galima lengvai įgyvendinti naudojant kolektyvinio ryšio bibliotekas, tokias kaip „torch.distributed“ ir „NCCL“, MoE maršruto parinkimas apima retą tarpusavio ryšį (angl. peer-to-peer). Siuntimo branduolys turi padalinti gaunamų žetonų rinkinį ir nusiųsti juos į rangus, kuriuose veikia ekspertai, o jo dualioji problema – jungimo branduolys – turi gauti apdorotus atitikmenis ir apskaičiuoti jų svertinį vidurkį. Šie perkėlimai neatitinka kolektyvinių ryšių ir reikalauja pritaikytų branduolių mažai delsai pasiekti.

„Perplexity“ kūrėme tiek nešiojamus tarpmazginius branduolius, tiek specializuotus mazgo vidinius branduolius, o savo darbą išsamiau pristatėme ankstesniame straipsnyje apie MoE ryšį. Kitame tinklaraščio įraše taip pat parodėme, kad kelių mazgų diegimas gali užtikrinti mažesnę delsą ir didesnį pralaidumą dideliems MoE modeliams.

Šiame straipsnyje atidžiai nagrinėjame mūsų naujų tarpmazginių branduolių diegimą, kuris labai pagerina ankstesnio mūsų darbo, pagrįsto „NVSHMEM“, našumą. Be pažangiausių rezultatų demonstravimo per „ConnectX-7“, taip pat parodome, kad mūsų inferencijos vykdymo laiko aplinkoje branduoliai gali būti naudojami efektyviai aptarnauti didžiausius atvirojo kodo modelius.

Inferencija per „InfiniBand“

Tenzorius paralelizavimas ir ekspertų paralelizavimas gali veiksmingai padidinti mastelį viename mazge, nes „NVLink“ užtikrina didelį pralaidumą (900 GB/s) ir mikrosekundžių delsą. Nors „NVIDIA GB200“ ir „GB300“ sistemos turi pakankamai atminties trilijonų parametrų modelių svoriams ir KV podėliams talpinti, diegimai AWS p5en egzemplioriuje su iki 8 „H200 GPU“ yra apriboti 1120 GB HBM atmintimi, kurią reikia padalinti tiek modelio svoriams, tiek KV podėliams. Dėl to tam tikriems modeliams reikalingas tarpmazginis diegimas per „InfiniBand“.

Nors „InfiniBand“ tebėra nepaprastai greitas, jis užtikrina tik 400 Gbps (50 GB/s) pralaidumą, o tai prideda nuo dešimčių iki šimtų mikrosekundžių delsą MoE maršruto parinkimui. Laimei, pridėtą delsą galima paslėpti naudojant bendrus ekspertus, mikropartijas ir skaičiavimo bei ryšio persidengimą, kad būtų užtikrintas perspektyvus pralaidumas už konkurencingą kainą. „DeepSeek“ pradėjo šių technikų taikymą naudodami „DeepSeek-R1“, įdiegtą H800 GPU klasteriuose ir „NVIDIA ConnectX-7 InfiniBand“ adapteriuose.

AWS klasteriuose situacija yra kitokia dėl naudojamų pasirinktinių „Elastic Fabric Adapters“ (EFA). Nors jie užtikrina maksimalų 400 Gbps pralaidumą kolektyviniuose procesuose, paprastai naudojamuose mokymo užduotyse, jie šiek tiek atsilieka nuo „ConnectX-7“ pranešimų dydžių, kuriais keičiamasi MoE siuntimo ir jungimo metu. Be to, EFA nepalaiko „GPUDirect Async“, todėl reikalinga CPU tarpinio serverio gija (angl. proxy thread), sujungianti GPU su tinklo kortele (NIC), kad būtų galima inicijuoti perkėlimus. Be papildomo sudėtingumo, papildomos PCIe operacijos suteikia mikrosekundžių vertą pridėtinę delsą visiems perkėlimams. Tokios karkasai (frameworks) kaip „NVSHMEM“ leidžia branduolių kūrėjams pateikti nuo įrenginio nepriklausomus įgyvendinimus, tačiau bendrieji API sukelia papildomų sąnaudų, dėl kurių diegimai tampa neveiksmingi tiek kainos, tiek delsos požiūriu.

„NVSHMEM“ pagrindu sukurti „pplx-kernels“

Mūsų ankstesni branduoliai abstrakčiai atskyrė apatinio lygio transportavimo įgyvendinimą per „NVSHMEM“. Jie rėmėsi nvshmemx_putmem_signal_nbi_warp, kad perkeltų žetonus po vieną, naudodami atominius skaitiklius lygiagretinti mazgams. Nors tai užtikrino priimtiną našumą naudojant „ConnectX-7 NIC“ su IBGDA, tarpiniu serveriu pagrįstas „ConnectX-7 IBRC“ įgyvendinimas buvo pastebimai lėtesnis, o EFA įgyvendinimas nesugebėjo užtikrinti mažesnės nei milisekundės delsos.

Naudojome branduolius kaip aparatinės įrangos bandymų stotį ir kartu nustatėme tinkamiausią sąsają, kurią galime pateikti savo modeliams. Iškėlėme hipotezę, kad dažni perkėlimai ir sąveika tarp branduolių, tinklo kortelių arba tarpinio serverio gijų stabdo našumą. Be to, mūsų įgyvendinimas nesirėmė jokiomis kitomis aparatinės įrangos garantijomis, išskyrus patikimumą, o tai rodė, kad galėtume paspartinti procesą sumažindami sinchronizavimo primityvų sąnaudas.

Remdamiesi šiais pastebėjimais, sukūrėme EFA pagrindu veikiančius branduolius, pateikiančius tą pačią sąsają ir optimizuojančius įrenginio branduolio bei pagrindinio kompiuterio (host) tarpinio serverio sąveiką „po kapotu“, kad būtų pasiektas maksimalus našumas.

MoE „all-to-all“ per EFA

Padidinti

Naujieji branduoliai naudoja hibridinę CPU ir GPU architektūrą, kurioje GPU branduoliai sąveikauja su modeliu įrenginyje, o pagrindiniame CPU veikianti tarpinio serverio gija valdo sąveiką su tinklo kortele. Naujieji branduoliai pakartotinai naudoja tą patį „TransferEngine“, kurį sukūrėme KV podėlio perkėlimams.

MoE maršruto parinkimą atlieka siuntimo branduolys, kuris gauna žetonus ir ekspertus kiekvienam žetonui, į kuriuos modelis turi juos nukreipti, išsiųsdamas juos per tinklą į rangus, kuriuose talpinami ekspertai. Kai sugrupagruoti GEMM branduoliai padaugina žetonus iš ekspertų svorių, jungimo branduolys perkelia žetonus į jų kilmės rangus ir apskaičiuoja jų svertinį vidurkį prieš grąžindamas juos modeliui.

Tiek siuntimo, tiek jungimo branduoliai yra padalinti į siuntėjo ir gavėjo puses, kad būtų lengviau pasiekti persidengimą ir mikropartijas. Siuntėjas sumaišo žetonus į siuntimo buferius, kad juos būtų galima įrašyti į partnerius per vieną RDMA įrašymo operaciją. Paleidęs siuntėją, GPU gali atlikti kitus darbus (pvz., bendro eksperto daugybą), kol perkėlimai per tinklą laukia fone. Gavėjo branduoliai blokuojami, kol gaunami visi perkėlimai. Fone pagrindinio kompiuterio pusės darbinė gija apdoroja perkėlimus: GPU jai praneša, kai siuntimo buferiai yra užpildyti, po to ji išsiunčia RDMA įrašymus. Kai tinklo kortelė praneša apie užbaigimą, ji atblokuoja gavėją, kuris grąžina žetonus modeliui.

Branduoliai yra glaudžiai susieti su pagrindiniu kompiuteriu ir bendrauja tarpusavyje per vieningą atmintį (unified memory) ir „GDRCopy“. CUDA vieninga atmintis leidžia įrenginio atminčiai arba pagrindinio kompiuterio atminčiai būti susietoms į abiejų adresų erdves, skaidriai valdant ryšį per PCIe.

Nors vieninga atmintis tinka masiniams perkėlimams, maža delsa užtikrinama naudojant „GDRCopy“. „GDRCopy“ naudoja „GPUDirect RDMA“, kad skitytų ir rašytų į GPU atmintį mikrosekundės delsa.

Be RDMA, mazgo viduje branduoliai taip pat išnaudoja „NVLink“ žetonams keistis. Tai gali sumažinti didelę srauto dalį – iki ketvirtadalio EP32 ir iki aštuntadalio EP64, taip pasiekiant bendrą mažesnę delsą.

Siuntimo ir gavimo buferiai

Siuntimo buferių dizainas siuntimo branduoliui yra itin svarbus siekiant pasiekti perspektyvią delsą bendraujant su pagrindinio kompiuterio tarpiniu serveriu. Jei yra N rangų, iš kurių kiekvienas išsiunčia T žetonų, ir kiekvienas nukreipiamas į R ekspertų iš E, blogiausiu atveju rangas gali gauti iki N * T * max(R, E / N) žetonų, jei visi yra nukreipiami į jį. Be to, šią minimalią ribą galima pasiekti tik tada, kai siuntėjai savo įrašus išdėsto gretutinai, nes privatūs gavimo buferiai sunaudotų per daug atminties. Kad siuntėjai galėtų išdėstyti savo įrašus nuosekliai be konfliktų, kiekvienam rangui turi būti perduota visa informacija apie maršrutus. Dėl to mūsų siuntimo branduoliai iš pradžių keičiasi žetonų kiekiais pagal eksperto, po ko kiekvienas iš jų gali nustatyti, kur nukeliauja jų įrašai ir iš kurio rango jie gauna žetonus bei kokiu poslinkiu.

Paprastas keitimasis maršruto informacija sukeltų be reikalo didelę delsą, nes kiekvienas rangas turėtų laukti, kol įrašai atkeliaus, prieš išsiunčiant bet kokius savo įrašus. Vietoj to mes rezervuojame nedidelį kiekį privačios erdvės kiekviename gavėjo range ir išsiunčiame dalį žetonų kartu su maršruto informacijos įrašais. Tai užtikrina visišką pralaidumo išnaudojimą didesnėje siuntimo proceso dalyje. Pakeitus maršrutus, likusieji žetona perkeliami per vieną įrašą kiekvienam nuotoliniam partneriui. Maršruto informacijos keitimasis ir fiksuoto dydžio buferiai bei juos užpildantys perkėlimai pavaizduoti žemiau esančiame paveikslėlyje.

Padidinti

Jungimo branduoliai yra kur kas paprastesni, nes maršruto informacija jiems jau prieinama iš siuntimo etapo. Jie gali nukopijuoti žetonus per vieną įrašą vienam partneriui, po ko skaito iš gavimo buferio, kad apskaičiuotų žetonų svertinį vidurkį išvesties tenzoriuose.

Kalbant apie „NVLink“, siuntimo ir gavimo buferiai mazgo viduje yra susiejami su partneriais, kad jie galėtų tiesiogiai siųsti arba traukti žetonus iš kaimyninių rangų.

Siuntimas ir jungimas (Dispatch and Combine)

Žemiau esančiuose paveikslėliuose išsamiai aprašomas laikas ir sąveika tarp GPU, CPU ir tinklo kortelės, parodant vieną siuntimo ir jungimo iteraciją, persipinančią su modelio branduoliais.

Darbas prasideda siuntimo išsiuntime, branduoliui apibendrinant maršruto informaciją ir apskaičiuojant žetonų kiekius pagal ekspertą per atominį kaupimą bendrojoje atmintyje vieno bloko ribose. Kai žetonų kiekiai tampa pasiekiami, jie nukopijuojami į pagrindinio kompiuterio atmintį, o tarpiniam serveriui nedelsiant pranešama pradėti siuntimo informacijos siuntimą visiems kitiems partnerių rangams. Lygiagrečiai siuntimas tęsia kaupiamosios žetonų kiekių sumos skaičiavimą, nustatydamas poslinkius, reikalingus žetonams sugrupuoti į gretutinius siuntimo buferius. Kai poslinkiai tampa pasiekiami, visi per EFA siunčiami žetonai sugrupuojami į siuntimo buferius. Tarpiniam serveriui pranešama paskelbti įrašus tarpmazginių partnerių siuntimo buferiuose. Mazgo viduje branduoliai taip pat nedelsiant per „NVLink“ įstumia žetonus į privačius buferius tame pačiame mazge.

Padidinti

Padidinti

Kai rangas gauna maršruto informaciją iš visų partnerių, jis ją centralizuoja ir apskaičiuoja įvairius poslinkius, būtinus žetonams nustatyti siuntimui ir jungimui. Šis darbas atliekamas CPU, kol perkėlimai jau laukia, todėl jam netaikomi kritiniai delsos reikalavimai. Vėliau, kai visi poslinkiai tampa žinomi, paskelbiami likusių žetonų, viršijančių privataus buferio dydį, įrašai ir siuntimo fazė baigiasi.

Gavėjo pusėje branduolys pirmiausia per „NVLink“ ištraukia iš to paties mazgo žetonus, kurie viršija privačių buferių talpą. Tada jis blokuojamas, kol pagrindinio kompiuterio tarpinis serveris praneša apie visų perkėlimų pabaigą. Gavus signalą, žetonai sumaišomi iš gavimo buferių į išvesties tenzorių, perduotą grupiniam GEMM. Kadangi buferiai naudojami pakartotinai tarp siuntimo ir jungimo, tiek „NVLink“, tiek RDMA barjerai užtikrina, kad gavimo buferiai buvo perskaityti, prieš leidžiant kitam branduoliui juos perrašyti.

Jungimo branduoliai veikia panašiu principu: sumaišo žetonus, praneša tarpiniam serveriui ir laukia užbaigimo. Tačiau jų įrašų paskelbimo metaduomenys yra lengvai pasiekiami, o visi nuotoliniai poslinkiai yra žinomi, todėl visi mazgo viduje perkelti žetonai per „NVLink“ nustumiami gavėjams, o tarpmazginiai žetona perkeliami per vieną įrašą. Prieš grąžindamas rezultatus, branduolys suakumuliuoja žetonus iš gavimo buferių, įrašydamas juos į išvesties tenzorius.

„TransferEngine“, skirtas MoE maršruto parinkimui

Siekdami sukurti mūsų įgyvendinimo prototipą, iš pradžių pakartotinai naudojome „Transfer Engine“, sukonstruotą atskirtam pirminiam užpildymui (prefill) ir dekodavimui, kad galėtume inicijuoti ir sekti RDMA įrašus. Tačiau, skirtingai nuo atskirto dekodavimo, kur kiekvienas mazgas paskelbia daug įrašų tam pačiam partneriui, MoE siuntimas paskelbia mažus perkėlimus visiems partneriams vienos operacijos metu. Iš karto pritaikytas našumas nebuvo optimalus, o mūsų įgyvendinimas atsiliko nuo „DeepEP“ per „ConnectX-7“ maždaug 20 mikrosekundėmis. Dėl to pritaikėme „TransferEngine“, kad palaikytų dvi operacijas – sklaidą (scatter) ir barjerą (barrier), siekdami optimizuoti sąveiką su dideliu partnerių skaičiumi.

Tiek sklaidos, tiek barjero operacijos pateikia partnerių grupes, kurias galima iš anksto užregistruoti, kad būtų iš anksto užpildytos duomenų struktūros, naudojamos apatinio lygio transportavimo įgyvendinimo (darbo užklausos (WR) šablonų kūrimo). Sklaida nukopijuoja skirtingas dalis iš to paties šaltinio buferio į skirtingus poslinkius visuose partnerių grupės nariuose. Barjeras praneša visiems partneriams per tiesioginį pranešimą. Šių operacijų įtraukimas į eilę ir masinis apdorojimas sutaupo vertingų mikrosekundžių kritiniame kelyje. EFA atveju, kai dvi 200 Gbps tinklo kortelės susijungia ir suteikia 400 Gbps pralaidumą, mes padaliname partnerių grupes per abi tinklo korteles, o ne daliname kiekvieno perkėlimo baitus.

Nors iš pradžių „TransferEngine“ sukūrėme tik naudodami EFA per libfabric, MoE branduoliai veikia „ConnectX-7“ nepakeitę nė vienos kodo eilutės, kai „TransferEngine“ buvo pridėtas „ConnectX-7“ palaikymas naudojant libibverbs. Lyginant su keičiamo dydžio patikimo datagramo (SRD) pagrindu veikiančia EFA, „ConnectX-7“ reikalauja papildomo darbo ryšio nustatymui ir partnerių valdymui. Naudojame nepatikimo datagramo (UD) eilių porą patikimam ryšiui (RC) paleisti. Kiekvienam nuotoliniam partneriui sukuriame dvi eilių poras: vieną dvipusiam SEND/RECV, o kitą – vienpusiam WRITE_IMM, nes ir RECV, ir WRITE_IMM vartoja RECV operaciją iš eilės, o šioms dviem operacijoms reikalingi skirtingi buferių dydžiai. Be to, sušvelniname PCIe operacijų tvarką tarp „ConnectX-7“ ir GPU atminties. Panašiai kaip EFA, įgyvendiname WR šablonų optimizavimą. Be to, siųsdami kelis mažus pranešimus tam pačiam partneriui, naudojame WR grandininį sujungimą pranešimų dažniui pagerinti.

Kadangi darbas GPU pusėje yra identiškas abiejuose adapteriuose, pasiekėme apatinio lygio transportavimo įgyvendinimo ribas, kad aplenktume „DeepEP“ našumą ir pabrėžtume, jog skirtumą tarp EFA ir „ConnectX-7“ MoE maršruto parinkimo lemia apatinio lygio aparatinės įrangos galimybės.

Įvertinimas

Siuntimo / jungimo delsa

Įvertinome siuntimo ir jungimo delsą H200 sistemose, kuriose įrengti „ConnectX-7“ ir EFA adapteriai standartinėje „DeepSeek-V3“ ir „Kimi-K2“ konfigūracijoje su paslėptu 7168 matmeniu, blokuose masteliais keičiamu fp8 siuntimu ir bf16 jungimu. Vertiname 128 partijos dydį siuntimui ir 4096 – jungimui. „ConnectX-7“ atveju lyginame su „DeepEP“ ir mūsų ankstesniais „NVSHMEM“ pagrindu sukurtais „pplx-kernels“, naudojant tiek „GPUDirect Async“ (IBGDA), tiek pagrindinio kompiuterio tarpinį serverį (IBRC). Pasiekiame bendrą 459 us, 582 us ir 692 us delsą atitinkamai EP16, EP32 ir EP64 atvejais. Mes pralenkiame kitus EFA pagrindu veikiančius branduolius, besiremiančius bendraisiais tarpiniais serveriais, tokiais kaip „UCCL-EP“, kurie pasiekia 519 us, 966 us ir 1159 us.

Padidinti

Dekodavimo metu, nepaisant to, kad mūsų branduoliai keliomis mikrosekundėmis lėtesni už „DeepEP“, pasiekiame bendrą mažesnę delsą, nes mūsų jungimo branduoliai yra žymiai greitesni. Nors naudojame pagrindinio kompiuterio tarpinį serverį, dėl masinių perkėlimų pralenkiame visų IBGDA pagrindu veikiančių įgyvendinimų be tarpinių serverių našumą. Taip pat parodome, kad tarpinio serverio įgyvendinimas yra svarbus, nes mūsų itin specializuotas tarpinis serveris yra eile greitesnis už bendrą „NVSHMEM“ įgyvendinimą. Nepaisant to, kad EFA yra du kartus lėtesnė už „ConnectX-7“, kai perkeliami 256 KB paketai, artimi įprastam MoE maršruto parinkimo paketo dydžiui, skirtumas tarp dviejų adapterių bendrai yra mažiau pastebimas.

Padidinti

Nors mūsų dekodavimui optimizuoti branduoliai gali pritaikyti mastelį prie pirminio užpildymo partijų dydžių be jokių papildomų pakeitimų, našumas atsilieka nuo „DeepEP“. Tai daugiausia lemia tai, kad žetonus kaupiame tik jungimo gavėjo pusėje, o „DeepEP“ kaupia siuntėjo pusėje, kad sumažintų perkeliamų duomenų kiekį. Tačiau šis optimizavimas gali turėti įtakos tikslumui. Be to, kadangi branduoliai perkelia duomenis per vieną įrašą, siuntimo ir gavimo buferiams sunaudojame daugiau atminties.

„Kimi-K2“ / „DeepSeek-V3“ pralaidumas

Norėdami įrodyti savo branduolių perspektyvumą, atliekame vidinio inferencijos variklio, aptarnaujančio „DeepSeek-V3“ (671 mlrd. parametrų) ir „Kimi-K2“ (1 trln. parametrų), galutinio našumo (end-to-end) etaloninį tyrimą keliose p5en egzemplioriuose, kuriuose įrengti „Elastic Fabric Adapters“ (EFA) ir „H200 GPU“. Vykdome modelį juodraščio tikrinimo režimu ir pateikiame delsą, darant prielaidą, kad priėmimo rodiklis yra 80%, naudojant vieną MTP sluoksnį.

„DeepSeek-V3“ atveju lyginame su EP=8 mazgo vidine atskaitos taško sistema (baseline), vykdančia efektyvius „NVLink“ siuntimo ir jungimo branduolius. Tarpmazginiai diegimai bendrai arba prilygsta vieno mazgo diegimo našumui, arba jį viršija, ypač vidutinio dydžio partijose, taip parodydami, kad mastelio keitimas tarp mazgų pagerina bendrą pralaidumą.

„Kimi-K2“ atveju branduoliai įgalina aptarnavimą. Dėl savo dydžio modelis negali tilpti tame pačiame mazge, naudojant duomenų paralelizavimą (DP) H200 mazge, todėl modeliui aptarnauti reikalingas tarpmazginis diegimas. Kadangi modelis turi mažiau dėmesio (attention) galvučių, pasiekiame geresnę delsą nei „DeepSeek-V3“ ir galime aptarnauti modelį per EFA priimtina delsa.

Padidinti

Padidinti

Taip pat apsvarstėme mikropartijas, nors jos pagerino delsą tik esant labai dideliems partijų dydžiams arba naudojant daugiau nei vieną juodraščio žetoną. Kad būtų nauda iš grupuotų GEMM problemų padalijimo į dvi dalis, žetonų partijų dydžiai turi būti pakankamai tankūs. Didžioji laiko dalis vis tiek sunaudojama MoE siuntimui ir jungimui, o tai rodo, kad bet kokie tolesni branduolių patobulinimai atitinkamai pagerins delsą ir palengvins mikropartijų naudojimą.

Ateities darbai

Glaudžiai bendradarbiaujame su AWS inžinieriais, kad pagerintume našumą per EFA. Savo ruožtu seksime libfabric atnaujinimus, kurie sumažins duomenų plokštumos sąnaudas. Be to, eksperimentuosime su efa-direct, kad dar labiau sumažintume vartotojo erdvės sąnaudas ir tiesiogiai sąveikautume su aparatine įranga.

Literatūra

„DeepSeek R1“ techninė ataskaita

„Kimi K2“ techninė ataskaita

DeepEP

UCCL-EP

HPC sistemų tinklo našumo gerinimas naudojant „NVIDIA Magnum IO NVSHMEM“ ir „GPUDirect Async“

Citata

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