Triljonu parametru modeļu iespējošana AWS EFA

Uzņēmumā Perplexity mēs savam produktam, mūsu API un mūsu pētniecības komandām izmantojam labākos modeļus. Lieli atvērtā pirmkoda ekspertu maisījuma (Mixture-of-Experts) modeļi, piemēram, Kimi-K2, rada īpašas problēmas, jo lielākie secināšanas mezgli ar 8x NVIDIA H200 GPU nespēj tosefektīvi izvietot, tāpēc ir nepieciešama vairāku mezglu izvietošana. Mēs piedāvājam ekspertu paralēlisma kodolu kopu, kas nodrošina modernāko latentumu ConnectX-7, pārsniedzot DeepEP veiktspēju. Šie paši kodoli ir arī pirmie, kas nodrošina dzīvotspējīgu latentumu AWS Elastic Fabric Adapter (EFA), ļaujot izvietot triljonu parametru modeļus.

Izmēģiniet mūsu kodolus pakalpojumā GitHub un izlasiet pilnu pētniecības darbu vietnē arXiv.

Ievads

Ekspertu maisījums (MoE) ir kļuvis par standarta arhitektūru mērogošanai līdz simtiem miljardu vai triljoniem parametru, vienlaikus piedāvājot saprātīgu latentumu secināšanas laikā. MoE modeļi aizstāj transformatora blīvo slāni ar ekspertu kopu un nelielu lineāro maršrutēšanas slāni, kas izlemj, ar kuru ekspertu reizināt žetonu. Sagrupējot žetonus, kas saistīti ar to pašu ekspertu, problēma kļūst reta un viegli paralelizējama, jo dažādus ekspertus tagad var mitināt dažādos GPU, kas izplatīti vairākos mezglos.

Atšķirībā no citiem paralēlisma veidiem, piemēram, tensoru paralēlisma (TP) un datu paralēlisma (DP), kurus var viegli ieviest, izmantojot kolektīvās saziņas bibliotēkas, piemēram, torch.distributed un NCCL, MoE maršrutēšana ietver retu peer-to-peer saziņai. Nosūtīšanas kodolam ir jāsadala ienākošo žetonu kopa un jānosūta tie uz rangiem, kuros mitinās eksperti, savukārt tā divējādai problēmai — apvienošanas kodolam — ir jāsaņem to apstrādātie līdzinieki un jāaprēķina to svērtais vidējais lielums. Šie pārsūtījumi neatbilst kolektīviem un prasa pielāgotus kodolus, lai panāktu zemu latentumu.

Uzņēmumā Perplexity mēs esam izstrādājuši gan portatīvos starpmezglu kodolus, gan specializētos mezgla iekšējos kodolus, plašāk iepazīstinot ar savu darbu iepriekšējā rakstā par MoE sakariem. Mēs arī citā emuāra ziņā parādījām, ka vairāku mezglu izvietošana var nodrošināt mazāku latentumu un lielāku caurlaidību lieliem MoE modeļiem.

Šajā rakstā mēs padziļināti apskatām mūsu jauno starpmezglu kodolu ieviešanu, kas ievērojami uzlabo mūsu iepriekšējā darba veiktspēju, kura pamatā ir NVSHMEM. Papildus modernāko rezultātu demonstrēšanai ConnectX-7 mēs arī demonstrējam, ka mūsu secināšanas izpildlaikā kodolus var izmantot, lai efektīvi apkalpotu lielākos atvērtā pirmkoda modeļus.

Secinājumi, izmantojot InfiniBand

Tensoru paralēlisms un ekspertu paralēlisms var efektīvi mērogot vienā mezglā, jo NVLink piedāvā augstu caurlaidību (900 GB/s) mikrosekunžu latentumā. Lai gan NVIDIA GB200 un GB300 sistēmas ir aprīkotas ar pietiekami lielu atmiņu, lai saglabātu triljonu parametru modeļu svarus un KV kešatmiņas, izvietošana AWS p5en instancē ar līdz pat 8 H200 GPU ir ierobežota līdz 1120 GB HBM, kas ir jāsadala starp modeļa svariem un KV kešatmiņām. Līdz ar to dažiem modeļiem ir nepieciešama starpmezglu izvietošana virs InfiniBand.

Lai gan InfiniBand joprojām ir ļoti ātrs, tas piedāvā tikai 400 Gbps (50 GB/s) caurlaidību, pievienojot desmitiem līdz simtiem mikrosekunžu latentumu MoE maršrutēšanai. Par laimi, pievienoto latentumu var paslēpt, izmantojot koplietojamos ekspertus, mikropartijas un skaitļošanas un sakaru pārklāšanos, lai nodrošinātu dzīvotspējīgu caurlaidību par konkurētspējīgu cenu. DeepSeek bija pionieris šajās tehnikās, izmantojot DeepSeek-R1, kas izvietots H800 GPU un NVIDIA ConnectX-7 InfiniBand adapteru klasteros.

AWS klasteros situācija ir atšķirīga, jo tiek izmantoti viņu pielāgotie elastīgie auduma adapteri (EFA). Lai gan tie nodrošina pīķa 400 Gbps caurlaidību kolektīvos, ko parasti izmanto apmācības slodzēs, tie nedaudz atpaliek no ConnectX-7 ziņojumu izmēros, kas apmainīti MoE nosūtīšanas un apvienošanas laikā. Turklāt EFA neatbalsta GPUDirect Async, tāpēc ir nepieciešams CPU starpniekservera pavediens, kas savieno GPU ar NIC, lai uzsāktu pārsūtīšanu. Papildus pievienotajai sarežģītībai papildu PCIe tranšakcijas palielina mikrosekunžu pieskaitāmās izmaksas visiem pārsūtījumiem. Tādi kadri kā NVSHMEM ļauj kodolu rakstītājiem nodrošināt no ierīces neatkarīgas implementācijas, tomēr vispārējie API rada pieskaitāmās izmaksas, kas padara izvietošanu neefektīvu gan izmaksu, gan latentuma ziņā.

Uz NVSHMEM balstīti pplx-kernels

Mūsu iepriekšējie kodoli abstrahēja pamatā esošo transporta ieviešanu, izmantojot NVSHMEM. Tie balstījās uz nvshmemx_putmem_signal_nbi_warp , lai pārsūtītu žetonus pa vienam, izmantojot atomu skaitītājus, lai sinhronizētu vienaudžus. Lai gan tas piedāvāja saprātīgu veiktspēju ConnectX-7 NIC ar IBGDA, uz starpniekserveri balstītā ConnectX-7 IBRC ieviešana bija ievērojami lēnāka, savukārt EFA ieviešana nespēja nodrošināt latentumu zem milisekundes.

Mēs izmantojām kodolus kā testa stendu pamatā esošajai aparatūrai, vienlaikus nosakot vispiemērotāko saskarni, ko pakļaut mūsu modeļiem. Mēs izvirzījām hipotēzi, ka bieža pārsūtīšana un mijiedarbība starp kodoliem un NIC vai starpniekservera pavedieniem kavēja veiktspēju. Turklāt mūsu ieviešana nebalstījās uz nekādām garantijām no aparatūras, izņemot uzticamību, kas liecina, ka mēs varētu paātrināt lietas, samazinot sinhronizācijas primitīvu pieskaitāmās izmaksas.

Pēc šiem novērojumiem mēs izstrādājām uz EFA balstītus kodolus, kas eksponē to pašu saskarni, optimizējot ierīces kodola un resursdatora starpniekservera mijiedarbību zem pārsega, lai nodrošinātu maksimālu veiktspēju.

MoE all-to-all virs EFA

Izvērst

Jaunie kodoli seko hibrīdai CPU-GPU arhitektūrai, kur GPU kodoli mijiedarbojas ar modeli ierīcē, bet resursdatora CPU palaists starpniekservera pavediens apstrādā mijiedarbību ar NIC. Jaunie kodoli atkārtoti izmanto to pašu TransferEngine, ko mēs uzbūvējām KV kešatmiņas pārsūtīšanai.

MoE maršrutēšanu veic nosūtīšanas kodols, kas saņem žetonus un žetoniem paredzētos ekspertus, lai tos maršrutētu no modeļa, nosūtot tos pa tīklu uz rangiem, kuros mitinās eksperti. Pēc tam, kad grupētie GEMM kodoli reizināt žetonus ar eksperta svariem, apvienošanas kodols pārsūta žetonus uz to avota rangiem un aprēķina to svērto vidējo rādītāju pirms to atgriešanas modelim.

Gan nosūtīšanas, gan apvienošanas kodoli ir sadalīti sūtītāja un uztvērēja pusē, lai veicinātu pārklāšanos un mikropartijas. Sūtītājs sajauc žetonus nosūtīšanas buferos, lai tos varētu ierakstīt vienaudžos, izmantojot vienu RDMA rakstīšanas darbību. Pēc sūtītāja izpildes GPU var veikt citu darbu (piemēram, koplietojamo ekspertu reizināšanu), kamēr pārsūtīšana tīklā notiek fonā. Uztvērēja kodoli bloķējas, līdz ir saņemti visi pārsūtījumi. Fonā resursdatora puses darbinieka pavediens apstrādā pārsūtījumus: GPU to signalizē, kad nosūtīšanas buferi ir aizpildīti, pēc tam tas nosūta RDMA rakstīšanu. Kad NIC signalizē par pabeigšanu, tas atbloķē uztvērēju, kas atgriež žetonus modelim.

Kodoli ir cieši savienoti ar resursdatoru, sazinoties viens ar otru, izmantojot gan vienoto atmiņu, gan GDRCopy. CUDA vienotā atmiņa ļauj ierīces atmiņu vai resursdatora atmiņu kartēt abu adrešu telpās, pārredzamā veidā apstrādājot saziņu, izmantojot PCIe.

Lai gan vienotā atmiņa ir piemērota lielapjoma pārsūtīšanai, aptauja ar zemu latentumu tiek veikta, izmantojot GDRCopy. GDRCopy izmantoj GPUDirect RDMA, lai lasītu un rakstītu GPU atmiņā mikrosekunžu latentumā.

Papildus RDMA mezglā kodoli izmanto arī NVLink, lai apmainītos ar žetoniem. Tas var atslogot ievērojamu satiksmes daļu, līdz pat ceturtdaļai EP32 un līdz astotajai daļai EP64, tādējādi panākot kopumā zemāku latentumu.

Sūtīšanas un saņemšanas buferi

Nosūtīšanas kodola sūtīšanas buferu dizains ir ļoti svarīgs, lai sasniegtu dzīvotspējīgu latentumu, kas saistīts ar resursdatora starpniekserveri. Ja ir N rangi, no kuriem katrs nosūta T žetonus, no kuriem katrs ir maršrutēts uz R ekspertiem no E, rangs var saņemt līdz pat N * T * max(R, E / N) žetoni ļaunākajā gadījumā, ja visi ir maršrutēti uz to. Turklāt šo minimālo robežu var sasniegt tikai tad, ja sūtītāji izvieto savus ierakstus blakus, jo privātie saņemšanas buferi aizņemtu pārāk daudz atmiņas. Lai sūtītāji varētu secīgi izkārtot savus ierakstus bez konfliktiem, katram rangam ir jāizplata pilnīgas zināšanas par maršrutēšanas informāciju. Līdz ar to mūsu nosūtīšanas kodoli vispirms apmainās ar žetonu skaitu uz vienu ekspertu, pēc kura katrs var noteikt, kur nonāk viņu ieraksti un no kura ranga tie saņem žetonus.

Vienkārša apmaiņa ar maršrutēšanas informāciju radītu nevajadzīgi lielu latentumu, jo katram rangam būtu jāgaida, līdz ieraksti pienāks, pirms nosūtīt savus ierakstus. Tā vietā mēs rezervējam nelielu daudzumu privātās vietas katram sūtītājam katrā uztvērēja rangā un nosūtām dažus žetonus kopā ar maršrutēšanas informācijas ierakstiem. Tas nodrošina pilnīgu joslas platuma izmantošanu lielākajā daļā nosūtīšanas procesa. Pēc tam, kad maršruti ir apmainīti, atlikušie žetoni tiek pārsūtīti, izmantojot vienu ierakstu uz vienu attālo vienaudzi. Maršrutēšanas informācijas apmaiņa un fiksēta izmēra buferi, kā arī pārsūtīšana, kas tos aizpilda, ir parādīti zemāk redzamajā attēlā.

Izvērst

Apvienošanas kodoli ir ievērojami vienkāršāki, jo maršrutēšanas informācija tiem jau ir pieejama no nosūtīšanas posma. Tie var kopēt žetonus vienā rakstīšanas reizē uz vienu vienaudzi, pēc kura tie nolasa no saņemšanas bufera, lai aprēķinātu žetonu svērto vidējo rādītāju izejas tensoriem.

NVLink gadījumā sūtīšanas un saņemšanas buferi mezglā tiek kartēti vienaudžos, lai tie varētu tieši nospiest vai vilkt žetonus no blakus esošajiem rangiem.

Nosūtīšana un apvienošana

Tālāk redzamajos attēlos ir detalizēti aprakstīts laiks un mijiedarbība starp GPU, CPU un NIC, parādot vienu nosūtīšanas un apvienošanas iterāciju, kas mijiedarbojas ar modeļa kodoliem.

Darbs sākas nosūtīšanas sūtīšanā, kodolam apkopojot maršrutēšanas informāciju un aprēķinot žetonu skaitu uz vienu ekspertu, izmantojot atomu uzkrāšanu koplietojamā atmiņā vienā blokā. Tiklīdz žetonu skaits ir pieejams, tie tiek kopēti resursdatora atmiņā, un starpniekserveris tiek nekavējoties informēts, lai sāktu maršrutēšanas informācijas nosūtīšanu visiem pārējiem vienaudžu rangiem. Paralēli nosūtīšana turpina aprēķināt žetonu skaita kumulatīvo summu, identificējot nobīdes, kas nepieciešamas, lai iepakotu žetonus nepārtrauktos sūtīšanas buferos. Tiklīdz nobīdes ir pieejamas, visi žetoni, kas nosūtāmi caur EFA, tiek iepakoti sūtīšanas buferos. Starpniekserverim tiek paziņots, ka ieraksti ir jāievieto starpmezglu vienaudžu sūtīšanas buferos. Mezglā kodoli arī nekavējoties iespiež žetonus privātajos buferos tajā pašā mezglā, izmantojot NVLink.

Izvērst

Izvērst

Kad rangs saņem maršrutēšanas informāciju no visiem vienaudžiem, tas to centralizē un aprēķina dažādas nobīdes, kas nepieciešamas, lai identificētu žetonus nosūtīšanai un apvienošanai. Šis darbs tiek veikts CPU, kamēr pārsūtīšana jau gaida, tāpēc tas nav kritisks latentumam. Pēc tam, kad visas nobīdes ir zināmas, tiek ievietoti ieraksti par atlikušajiem žetoniem, kas pārsniedz privātā bufera izmēru, un nosūtīšanas fāze ir pabeigta.

Uztvērēja galā kodols vispirms izvelk žetonus no tā paša mezgla, kas pārsniedz privāto buferu ietilpību, izmantojot NVLink. Pēc tam tas bloķējas, līdz resursdatora starpniekserveris signalizē par visu pārsūtīšanu pabeigšanu. Kad signāls ir saņemts, žetoni tiek sajaukti no saņemšanas buferiem izvades tensorā, kas nodots grupas GEMM. Tā kā buferi tiek izmantoti atkārtoti starp nosūtīšanu un apvienošanu, gan NVLink, gan RDMA barjeras nodrošina, ka uztvērēja buferi ir nolasīti, pirms tiek ļauts nākamajam kodolam tos pārrakstīt.

Apvienošanas kodoli ievērojami seko līdzīgam modelim, sajaucot žetonus, signalizējot starpniekserverim un gaidot pabeigšanu. Tomēr metadati to ierakstu ievietošanai ir viegli pieejami, un visas attālās nobīdes ir zināmas, tāpēc visi mezglā pārsūtītie žetoni tiek nospiesti, izmantojot NVLink uz uztvērējiem, un starpmezglu žetoni tiek pārsūtīti, izmantojot vienu rakstīšanu. Pirms rezultātu atgriešanas kodols uzkrāj žetonus no saņemšanas buferiem, ierakstot tos izvades tensoros.

TransferEngine priekš MoE maršrutēšanas

Lai izveidotu mūsu ieviešanas prototipu, mēs sākotnēji atkārtoti izmantojām pārsūtīšanas dzinēju (Transfer Engine), kas uzbūvēts dezagregētai iepriekšējai aizpildīšanai un dekodēšanai, lai izsniegtu un izsekotu RDMA rakstīšanu. Tomēr, atšķirībā no dezagregētās dekodēšanas, kur katrs mezgls ievieto lielu skaitu rakstīšanas vienam un tam pašam vienaudzim, MoE nosūtīšana ievieto nelielus pārsūtījumus visiem vienaudžiem vienā darbībā. No kastes veiktspēja nebija optimāla, un mūsu ieviešana atpalika no DeepEP par ConnectX-7 par aptuveni 20us. Līdz ar to mēs specializējām TransferEngine, lai atbalstītu divas darbības — izkliedi (scatter) un barjeru (barrier) —, lai optimizētu mijiedarbību ar lielu skaitu vienaudžu.

Gan izkliedes, gan barjeras darbības pakļauj vienaudžu grupas, kuras var iepriekš reģistrēt, lai iepriekš aizpildītu datu struktūras, ko izmanto pamatā esošā transporta ieviešana (darba pieprasījuma (WR) veidnes). Izkliede kopē dažādas šķēles no viena avota bufera dažādās nobīdēs visiem vienaudžu grupas dalībjiem. Barjera signalizē visiem vienaudžiem caur tūlītēju. Šo operāciju rindu sakārtošana un apstrāde lielapjoma ietaupa vērtīgas mikrosekundes kritiskajā ceļā. Uz EFA, kur divi 200 Gbps NIC agregāti nodrošina 400 Gbps joslas platumu, mēs sadalām grupas vienaudžus starp diviem NIC, nevis sadalām katras pārsūtīšanas baitus.

Lai gan sākotnēji mēs izstrādājām TransferEngine tikai uz EFA, izmantojot libfabric, MoE kodoli darbojas uz ConnectX-7, nemainot nevienu koda līniju pēc tam, kad TransferEngine tika pievienots ConnectX-7 atbalsts, izmantojot libibverbs. Salīdzinājumā ar mērogojamu uzticamu datagrammu (SRD) balstītu EFA, ConnectX-7 prasa papildu darbu savienojuma iestatīšanai un vienaudžu pārvaldīšanai. Mēs izmantojam neuzticamu datagrammu (UD) rindu pāri, lai sāknētu uzticamu savienojumu (RC). Mēs izveidojam divus rindu pārus katram attālam vienaudzim, vienu divpusējam SEND/RECV un vienu vienpusējam WRITE_IMM, jo gan RECV, gan WRITE_IMM patērē RECV darbību secībā, kamēr abām darbībām ir nepieciešami dažādi bufera izmēri. Turklāt mēs atslābinām PCIe transakciju secību starp ConnectX-7 un GPU atmiņu. Līdzīgi kā EFA, mēs ieviešam WR veidņu optimizāciju. Turklāt, nosūtot vairākus mazus ziņojumus tam pašam vienaudzim, mēs izmantojam WR ķēdi, lai uzlabotu ziņojumu ātrumu.

Tā kā GPU puses darbs ir identisks visos adapteros, mēs virzījām pamatā esošo transporta ieviešanu uz tās robežām, lai pārsniegtu DeepEP veiktspēju, lai uzsvērtu, ka atšķirību starp EFA un ConnectX-7 MoE maršrutēšanu nosaka pamatā esošās aparatūras iespējas.

Novērtējums

Nosūtīšanas/apvienošanas latentums

Mēs novērtējām nosūtīšanas un apvienošanas latentumu H200 sistēmās, kas aprīkotas ar ConnectX-7 un EFA adapteriem standarta DeepSeek-V3 un Kimi-K2 konfigurācijā ar slēpto dimensiju 7168, bloka mēroga fp8 nosūtīšanu un bf16 apvienošanu. Mēs uzskatām, ka partijas lielums ir 128 nosūtīšanai un 4096 apvienošanai. Vietnē ConnectX-7 mēs salīdzinām ar DeepEP un mūsu iepriekšējiem uz NVSHMEM balstītajiem pplx-kernels, izmantojot gan GPUDirect Async (IBGDA), gan resursdatora starpniekserveri (IBRC). Mēs sasniedzam kombinēto latentumu 459us, 582us un 692us attiecīgi EP16, EP32 un EP64. Mēs pārspējam citus uz EFA balstītus kodolus, kas paļaujas uz vispārējiem starpniekserveriem, piemēram, UCCL-EP, kas sasniedz 519us, 966us un 1159us.

Izvērst

Dekodēšanā, neskatoties uz to, ka mūsu kodoli ir par dažām mikrosekundēm lēnāki nekā DeepEP, mēs sasniedzam kopumā zemāku latentumu, jo mūsu apvienošanas kodoli ir ievērojami ātrāki. Lai gan mēs izmantojam resursdatora starpniekserveri, pateicoties mūsu lielapjoma pārsūtīšanai, mēs pārsniedzam visu uz IBGDA balstītu bezstarpnieka implementāciju veiktspēju. Mēs arī parādām, ka starpniekservera ieviešanai ir nozīme, jo mūsu īpaši specializētais starpniekserveris ir par lielumu ātrāks nekā vispārējā NVSHMEM ieviešana. Neskatoties uz to, ka EFA ir divreiz lēnāka nekā ConnectX-7, pārsūtot 256 KB paketes, kas ir tuvu tipiskajam MoE maršrutēšanas apmainīto pakešu izmēram, atšķirība starp abiem adapteriem kopumā ir mazāk būtiska.

Izvērst

Lai gan mūsu dekodēšanai optimizētie kodoli var mērogot līdz iepriekšējas aizpildīšanas partijas lielumiem bez jebkādiem papildu pielāgojumiem, veiktspēja atpaliek no DeepEP. Tas galvenokārt ir saistīts ar faktu, ka mēs uzkrājam žetonus tikai apvienošanas uztvērēja pusē, turpretim DeepEP uzkrājas sūtītājā, lai samazinātu pārsūtīto datu apjomu. Tomēr šai optimizācijai var būt ietekme uz precizitāti. Turklāt, tā kā kodoli pārsūta datus vienā rakstīšanas reizē, mēs izmantojam vairāk atmiņas sūtīšanas un saņemšanas buferiem.

Kimi-K2 / DeepSeek-V3 caurlaidība

Lai pierādītu mūsu kodolu dzīvotspēju, mēs veicam mūsu iekšējā secināšanas dzinēja veiktspējas salīdzinošo novērtējumu, kas apkalpo DeepSeek-V3 (671B parametri) un Kimi-K2 (1T parametri) vairākās p5en instancēs, kas aprīkotas ar elastīgajiem auduma adapteriem (EFA) un H200 GPU. Mēs palaižam modeli melnraksta verificēšanas režīmā un ziņojam par latentumu, pieņemot 80% pieņemšanas līmeni, izmantojot vienu MTP slāni.

Vietnē DeepSeek-V3 mēs salīdzinām ar EP=8 mezgla iekšējo bāzes līniju, kas izpilda efektīvus tikai NVLink nosūtīšanas un apvienošanas kodolus. Starpmezglu izvietošana kopumā vai nu atbilst, vai pārsniedz vienas mezgla izvietošanas veiktspēju, jo īpaši vidēja lieluma partijās, parādot, ka mērogošana starp mezgliem sniedz uzlabojumus vispārējā caurlaidībā.

Vietnē Kimi-K2 kodoli nodrošina apkalpošanu. Tā lieluma dēļ modelis nevar ietilpt tajā pašā mezglā, izmantojot datu paralēlismu (DP) H200 mezglā, tāpēc, lai apkalpotu modeli, ir nepieciešama starpmezglu izvietošana. Tā kā modelim ir mazāk uzmanības galviņu, mēs sasniedzam labāku latentumu nekā DeepSeek-V3 un mēs varam apkalpot modeli ar EFA ar dzīvotspējīgu latentumu.

Izvērst

Izvērst

Mēs esam apsvēruši arī mikropartijas, lai gan tās uzlaboja latentumu tikai pie ļoti liela partijas lieluma vai izmantojot vairāk nekā vienu melnraksta žetonu. Lai gūtu labumu no grupēto GEMM problēmu sadalīšanas divās daļās, žetonu partiju lielumiem ir jābūt pietiekami blīviem. Lielākā daļa laika joprojām tiek tērēta MoE nosūtīšanai un apvienošanai, kas norāda, ka visi turpmākie kodolu uzlabojumi attiecīgi uzlabos latentumu un atvieglos mikropartijas.

Turpmākais darbs

Mēs cieši sadarbojamies ar AWS inženieriem, lai uzlabotu veiktspēju ar EFA. No savas puses mēs sekosim līdzi libfabric atjauninājumiem, kas samazinās datu plaknes pieskaitāmās izmaksas. Turklāt mēs eksperimentēsim ar efa-direct, lai vēl vairāk samazinātu lietotāja vietas pieskaitāmās izmaksas un tieši sadarbotos ar aparatūru.

Atsauces

DeepSeek R1 tehniskais ziņojums

Kimi K2 tehniskais ziņojums

DeepEP

UCCL-EP

HPC sistēmu tīkla veiktspējas uzlabošana, izmantojot NVIDIA Magnum IO NVSHMEM un GPUDirect Async

Citāts

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