AWS EFA жүйесінде триллион параметрлі модельдерді іске қосу

Perplexity-де біз өз өніміміз, API интерфейстеріміз және зерттеу тобымыз үшін ең жақсы модельдерді қолданамыз. Kimi-K2 сияқты ірі ашық бастапқы кодты Сарапшылар қоспасы (Mixture-of-Experts) модельдері айтарлықтай қиындықтар тудырады, өйткені 8x NVIDIA H200 GPU бар ең үлкен инференс түйіндері оларды тиімді түрде орналастыра алмайды, бұл көп түйінді орналастыруды қажет етеді. Біз ConnectX-7 жүйесінде озық кідірістерге қол жеткізетін және DeepEP өнімділігінен асатын сарапшылық параллелизмге арналған ядролар жиынтығын ұсынамыз. Сонымен қатар, бұл ядролар AWS Elastic Fabric Adapter (EFA) жүйесінде тиімді кідірістерге қол жеткізген алғашқы ядролар болып табылады, бұл триллион параметрлі модельдерді орналастыруға мүмкіндік береді.

GitHub сайтында ядроларымызды сынап көріңіз және arXiv сайтынан толық зерттеу жұмысын оқыңыз.

Сарапшылар қоспасы (Mixture-of-Experts - MoE) жүздеген миллиард немесе триллион параметрге дейін масштабтаудың стандартты архитектурасы ретінде пайда болды, сонымен бірге инференс кезінде қолайлы кідірісті қамтамасыз етеді. MoE модельдері трансформердің тығыз қабатын сарапшылар жиынтығымен және токен көбейтілетін сарапшыны анықтайтын шағын сызықтық бағыттау қабатымен алмастырады. Бір сарапшыға қатысты токендерді топтастыру арқылы бұл мәселе сирек және оңай параллельденетін болады, өйткені әртүрлі сарапшылар енді бірнеше түйінге таралған әртүрлі GPU-ларда орналастырылуы мүмкін.

torch.distributed және NCCL сияқты ұжымдық байланыс кітапханаларын пайдалана отырып оңай іске асырылатын тензорлық параллелизм (TP) және деректер параллелизмі (DP) сияқты параллелизмнің басқа түрлерінен айырмашылығы, MoE бағыттауы сирек пир-ту-пир (peer-to-peer) байланысын қамтиды. Диспетчерлік ядро кіріс токендер жиынтығын бөліп, оларды сарапшыларды орналастыратын рангтерге жіберуі тиіс, ал оның кері есебі – біріктіру ядросы (combine kernel) өңделген баламаларын қабылдап, олардың өлшенген орташа мәнін есептеуі керек. Бұл тасымалдаулар ұжымдықтарға сәйкес келмейді және төмен кідіріске қол жеткізу үшін арнайы ядроларды қажет етеді.

Perplexity-де біз портативті түйінаралық ядроларды да, мамандандырылған түйінішілік ядроларды да дамытып келеміз, бұл туралы MoE байланысы туралы бұрынгы мақалада тереңірек баяндалған болатын. Сондай-ақ біз басқа блог жазбасында көп түйінді орналастыру ірі MoE модельдері үшін төмен кідіріс пен жоғары өткізу қабілетін қамтамасыз ете алатынын көрсеттік.

Бұл мақалада біз NVSHMEM негізіндегі бұрынғы жұмысымыздың өнімділігін едәуір жақсартатын жаңа түйінаралық ядроларымызды іске асыруға терең үңілеміз. ConnectX-7 жүйесіндегі озық нәтижелерді көрсетумен қатар, біз өз инференс орындалу уақытында (runtime) бұл ядролардың ең үлкен ашық бастапқы кодты модельдерге тиімді қызмет көрсету үшін пайдаланылуы мүмкін екенін көрсетеміз.

Тензорлық параллелизм мен сарапшылық параллелизм бір түйін ішінде тиімді түрде масштабталуы мүмкін, өйткені NVLink микросекундтық кідіріспен жоғары өткізу қабілетін (900 ГБ/с) қамтамасыз етеді. NVIDIA GB200 және GB300 жүйелері триллион параметрлі модельдердің салмақтары мен KV кэштерін сақтау үшін жеткілікті жадымен жабдықталғанымен, 8 H200 GPU-ға дейінгі AWS p5en данасындағы орналастырулар модель салмақтары мен KV кэштері арасында бөлінуі тиіс 1120 ГБ HBM жадымен шектелген. Демек, кейбір модельдер InfiniBand арқылы түйінаралық орналастыруларды талап етеді.

InfiniBand әлі де өте жылдам болғанымен, ол бар болғаны 400 Гбит/с (50 ГБ/с) өткізу қабілетін ұсынады, бұл MoE бағыттауына ондаған немесе жүздеген микросекундтық кідіріс қосады. Бақытымызға орай, қосылған кідірістерді бәсекеге қабілетті бағамен өміршең өткізу қабілетін жеткізу үшін ортақ сарапшылар, микропакеттеу және есептеу-байланыс қабаттасуы (computation-communication overlapping) арқылы жасыруға болады. DeepSeek бұл әдістерге H800 GPU кластерлерінде және NVIDIA ConnectX-7 InfiniBand адаптерлерінде орналастырылған DeepSeek-R1 арқылы жол ашты.

AWS кластерлерінде тапсырыс бойынша жасалған Elastic Fabric Adapters (EFA) құрылғыларын пайдалануға байланысты жағдай басқаша. Олар әдетте оқыту жұмыс жүктемелерінде қолданылатын ұжымдықтарда 400 Гбит/с шыңындағы өткізу қабілетін қамтамасыз етсе де, MoE диспетчериясы мен біріктіру кезінде алмастырылатын хабарлама өлшемдері бойынша ConnectX-7 жүйесіне сәл жетпейді. Сонымен қатар, EFA GPUDirect Async қолдамайды, бұл тасымалдауды бастау үшін GPU-ны NIC-пен байланыстыратын процессорлық тредті (CPU proxy thread) қажет етеді. Қосымша күрделіліктерден басқа, қосымша PCIe транзакциялары барлық тасымалдауларға микросекундтарға жуық үстеме шығын қосады. NVSHMEM сияқты фреймворктер ядро жазушыларға құрылғыға тәуелсіз іске асыруларды қамтамасыз етуге мүмкіндік береді, алайда жалпы API интерфейстері құны мен кідірісі тұрғысынан орналастыруларды тиімсіз ететін үстеме шығындарды тудырады.

Біздің бұрынғы ядролар түпкілікті тасымалдау іске асырылуын NVSHMEM арқылы абстракциялады. Олар пирлерді синхрондау үшін атомдық санауыштарды пайдалана отырып, токендерді бірінен соң бірін тасымалдау үшін nvshmemx_putmem_signal_nbi_warp функциясына сүйенді. Бұл IBGDA бар ConnectX-7 NIC құрылғыларында қолайлы өнімділікті ұсынғанымен, проксиге негізделген ConnectX-7 IBRC іске асырылуы айтарлықтай баяу болды, ал EFA іске асырылуы бір миллисекундтан төмен кідірістерді жеткізе алмады.

Біз ядроларды аппараттық құралдар үшін сынақ алаңы ретінде пайдаландық, сонымен бірге модельдерімізге ұсынылатын ең қолайлы интерфейсті анықтадық. Ядролар мен NIC немесе прокси трендері арасындағы жиі тасымалдаулар мен өзара әрекеттесулер өнімділікті нашарлатады деп болжадық. Сонымен қатар, біздің іске асыруымыз сенімділіктен басқа аппараттық құралдардың ешқандай кепілдіктеріне сүйенген жоқ, бұл синхрондау примитивтерінің үстеме шығындарын азайту арқылы жұмысты жылдамдата алатынымызды көрсетті.

Осы бақылаулардан кейін біз ең жоғары өнімділік үшін құрылғы ядросының хост проксиімен өзара әрекеттесуін оңтайландыра отырып, сол интерфейсті көрсететін EFA негізіндегі ядроларымызды жасадық.

RDMA және NVLink гибридті байланысы, хост-прокси арқылы бастайтын және қабылдайтын рангтарды, прокси жұмысшыларын және NIC-терді көрсетеді.

Жаңа ядролар гибридті CPU-GPU архитектурасын ұстанады, мұнда GPU ядролары құрылғыдағы модельмен әрекеттеседі, ал хост CPU-да жұмыс істейтін прокси тренд (proxy thread) NIC-пен өзара әрекеттесуді басқарады. Жаңа ядролар KV кэш тасымалдаулары үшін біз салған TransferEngine жүйесін қайта пайдаланады.

MoE бағыттауы токендерді және сарапшыларды орналастыратын рангтерге желі арқылы жібере отырып, модельден токендерді және бағыттау үшін әр токенге арналған сарапшыларды қабылдайтын диспетчерлік ядро арқылы орындалады. Топталған GEMM ядролары токендерді сарапшы салмақтарымен көбейткеннен кейін, біріктіру ядросы токендерді бастапқы рангтеріне тасымалдайды және оларды модельге қайтару алдында олардың өлшенген орташа мәнін есептейді.

Диспетчерлік те, біріктіру ядролары да қабаттасу мен микропакеттеуді жеңілдету үшін жіберуші және алушы бөліктеріне бөлінген. Жіберуші токендерді бір RDMA жазу операциясы арқылы пирлерге жазуға болатындай етіп жіберу буферлеріне араластырады. Жіберушіні орындағаннан кейін GPU желі арқылы тасымалдаулар фондық режимінде күтіліп жатқан кезде басқа жұмыстарды орындай алады (мысалы, ортақ сарапшы көбейту). Алушы ядролар барлық тасымалдаулар қабылданғанша бұғатталады. Фондық режимінде хост жағындағы жұмысшы тренді (worker thread) тасымалдауларды басқарады: жіберу толтырылған кезде ол туралы GPU хабарлайды, содан кейін ол RDMA жазуларын жібереді. NIC аяқталғанын хабарлағаннан кейін, ол алушының бұғаттауын шешеді, ал ол токендерді модельге қайтарады.

Ядролар хостпен тығыз байланысқан, бірыңғай жады (unified memory) және GDRCopy арқылы бір-бірімен қарым-қатынас жасайды. CUDA бірыңғай жады құрылғы жадын немесе хост жадын екеуінің де адрес кеңістігіне картаға түсіруге мүмкіндік береді, бұл PCIe арқылы байланысты мөлдір түрде басқарады.

Бірыңғай жады жаппай тасымалдаулар үшін қолайлы болғанымен, төмен кідірісті сауалнама (polling) GDRCopy арқылы жүзеге асырылады. GDRCopy микросекундтық кідіріспен GPU жадынан оқу және оған жазу үшін GPUDirect RDMA пайдаланады.

RDMA-дан басқа, түйін ішінде ядролар токендерді алмасу үшін NVLink-ті де пайдаланады. Бұл трафиктің едәуір бөлігін, EP32 үшін төрттен біріне дейін және EP64 үшін сегізден біріне дейін түсіріп, жалпы алғанда төмен кідірістерге қол жеткізе алады.

Диспетчерлік ядроға арналған жіберу буферлерінің дизайны хост проксиін қамтитын өміршең кідірістерге қол жеткізу үшін өте маңызды. Егер әрқайсысы T токендерді диспетчерлейтін N ранг болса, олардың әрқайсысы E ішінен R сарапшыларына бағытталса, егер барлығы соған бағытталса, ең нашар жағдайда ранг N * T * max(R, E / N) токендерге дейін қабылдай алады. Сонымен қатар, бұл минималды шектеу тек жіберушілер өздерінің жазбаларын үздіксіз орналастырған кезде ғана қол жеткізілуі мүмкін, өйткені жеке қабылдау буферлері тым көп жадыны пайдаланады. Жіберушілер өз жазбаларын қақтығыстарсыз дәйекті түрде орналастыра алуы үшін бағыттау туралы толық ақпарат әр рангке таратылуы тиіс. Демек, біздің диспетчерлік ядролар алдымен сарапшы бойынша токендер санын алмастырады, содан кейін олардың әрқайсысы өз жазбаларының қайда баратынын және әр рангтен токендерді қандай ығысумен (offset) алатынын анықтай алады.

Бағыттау ақпаратын жай ғана алмастыру қажетсіз жоғары кідірістерге әкеледі, өйткені әрбір ранг өзінің жазбаларын жібермес бұрын жазбалардың келуін күтуі керек еді. Оның орнына біз әрбір қабылдаушы рангте жеке жіберуші кеңістігінің аз мөлшерін сақтаймыз және бағыттау ақпаратының жазбаларымен қатар кейбір токендерді жібереміз. Бұл диспетчерлік процестің басым бөлігінде толық өткізу қабілетін пайдалануды қамтамасыз етеді. Маршруттар алмасылғаннан кейін қалған токендер қашықтағы бір пирге бір жазу арқылы тасымалданады. Бағыттау ақпараты мен бекітілген өлшемді буферлер алмасуы, сондай-ақ оларды толтыратын тасымалдаулар төмендегі суретте көрсетілген.

MoE dispatch үшін буфер орналасуы, токен деректері мен бағыттау метадеректері екі ранг арасында қалай орналастырылып, алмасатынын көрсетеді.

Біріктіру ядролары әлдеқайда қарапайым, өйткені бағыттау ақпараты оларға диспетчерлік кезеңнен бастап қолжетімді. Олар пирге бір жазу арқылы токендерді көшіре алады, содан кейін олар шығыс тензорларына токендердің өлшенген орташа мәнін есептеу үшін қабылдау буферінен оқиды.

NVLink үшін түйін ішіндегі жіберу және қабылдау буферлері көрші рангтерден токендерді тікелей итеру немесе тарту үшін пирлерге картаға түсіріледі.

Төмендегі суреттерде модель ядроларымен кезектесіп орналасқан диспетчерлеу және біріктірудің бір итерациясын көрсете отырып, уақыт пен GPU, CPU және NIC арасындағы өзара әрекеттесулер егжей-тегжейлі сипатталған.

Жұмыс диспетчерлік жіберуден басталады, ядро бағыттау ақпаратын біріктіреді және бір блок ішіндегі ортақ жадыда атомдық жинақтау арқылы сарапшы бойынша токендер санын есептейді. Токендер сандары қолжетімді болғаннан кейін, олар хост жадына көшіріледі және проксиге басқа барлық пир рангтерге бағыттау ақпаратын жіберуді бастау дереу хабарланады. Параллель түрде диспетчерлеу үздіксіз ранг бойынша жіберу буферлеріне токендерді жинау үшін қажетті ығысуларды анықтай отырып, токендер сандарының жиынтық қосындысын есептеуді жалғастырады. Ығысулар қолжетімді болғаннан кейін, EFA арқылы жіберілетін барлық токендер жіберу буферлеріне жиналады. Проксиге жазбаларды түйінаралық пирлердің жіберу буферлеріне орналастыру туралы хабарланады. Түйін ішінде ядролар сонымен қатар NVLink арқылы бір түйін ішіндегі жеке буферлерге токендерді дереу итереді.

MoE dispatch үшін уақыттау мен үйлестіру, кезең-кезеңімен орындалатын GPU, CPU және NIC операцияларын әрі олардың синхрондалуын көрсетеді.

MoE combine үшін уақыттау мен үйлестіру, GPU, CPU және NIC операцияларын әрі олардың синхрондалуын көрсетеді.

Ранг барлық пирлерден бағыттау ақпаратын алғаннан кейін, ол оны орталықтандырады және диспетчерлеу мен біріктіру үшін токендерді анықтауға қажетті әртүрлі ығысуларды есептейді. Бұл жұмыс тасымалдаулар әлі де күтіліп жатқан кезде CPU-да орындалады, сондықтан бұл кідіріс үшін маңызды емес. Кейіннен, барлық ығысулар белгілі болғаннан кейін, жеке буфер өлшемінен асатын қалған токендер үшін жазбалар орналастырылады және диспетчерлеудің жіберу фазасы аяқталады.

Алушы жағында ядро алдымен NVLink арқылы жеке буферлердің сыйымдылығынан асатын сол түйіннен токендерді тартады. Содан кейін хост проксиі барлық тасымалдаулардың аяқталғанын хабарлағанша ол бұғатталады. Сигнал қабылданғаннан кейін токендер қабылдау буферлерінен топтық GEMM-ге берілген шығыс тензорына араластырылады. Буферлер диспетчерлеу мен біріктіру арасында қайта пайдаланылатындықтан, NVLink пен RDMA барьерлері де келесі ядроға оларды үстінен жазуға рұқсат етпес бұрын қабылдау буферлерінің оқылғанын қамтамасыз етеді.

Біріктіру ядролары токендерді араластыру, проксиге сигнал беру және аяқталуын күту арқылы шамамен ұқсас үлгіні ұстанады. Дегенмен, олардың жазбаларын орналастыруға арналған метадеректер оңай қолжетімді және барлық қашықтағы ығысулар белгілі, сондықтан түйіншілік ішінде тасымалданатын барлық токендер NVLink арқылы алушыларға итеріледі және түйінаралық токендер бір жазу арқылы тасымалданады. Нәтижелерді қайтармас бұрын, ядро токендерді қабылдау буферлерінен жинақтайды, оларды шығыс тензорларына жазады.

Іске асыруды прототиптеу үшін біз бастапқыда RDMA жазуларын шығару және бақылау үшін бөлінген префилл мен декодтау үшін құрылған Transfer Engine жүйесін қайта пайдаландық. Дегенмен, әрбір түйін бірдей пирге көптеген жазуларды орналастыратын бөлінген декодтаудан айырмашылығы, MoE диспетчерлеуі бір операцияда барлық пирлерге шағын тасымалдауларды орналастырады. Дайын күйінде өнімділік оңтайлы болмады және біздің іске асыру ConnectX-7 жүйесінде DeepEP-тен шамамен 20 мкс артта қалды. Демек, біз пирлердің үлкен санымен өзара әрекеттесуді оңтайландыру үшін scatter және barrier сияқты екі операцияны қолдау мақсатында TransferEngine жүйесін мамандандырдық.

Scatter және barrier операциялары түпкілікті тасымалдау іске асырылуы пайдаланатын деректер құрылымдарын алдын ала толтыру үшін алдын ала тіркелуі мүмкін пир топтарын көрсетеді (Work Request (WR) шаблондау). Scatter бірдей бастапқы буфердің әртүрлі кесінділерін пир тобының барлық мүшелеріндегі әртүрлі ығысуларға көшіреді. Barrier жедел хабарлама арқылы барлық пирлерге сигнал береді. Бұл операцияларды жаппай кезекке қою және өңдеу маңызды жолда құнды микросекундтарды үнемдейді. Екі 200 Гбит/с NIC 400 Гбит/с өткізу қабілетін қамтамасыз ету үшін біріктіретін EFA-да біз әрбір тасымалдаудың байттарын шардтаудың орнына пир топтарын екі NIC арасында шардтаймыз.

Бастапқыда біз TransferEngine жүйесін тек libfabric көмегімен EFA-да әзірлегенімізбен, MoE ядролары TransferEngine жүйесіне libibverbs көмегімен ConnectX-7 қолдауын қосқаннан кейін кодтың бір жолын өзгертпей ConnectX-7 жүйесінде жұмыс істейді. Scalable Reliable Datagram (SRD) негізіндегі EFA-мен салыстырғанда, ConnectX-7 қосылымды орнату және пирлерді басқару үшін қосымша жұмысты талап етеді. Біз Сенімді қосылымды (Reliable Connection - RC) жүктеу үшін Сенімсіз датаграмма (Unreliable Datagram - UD) кезек жұбын пайдаланамыз. Біз әрбір қашықтағы пир үшін екі кезек жұбын жасаймыз, біреуі екі жақты SEND/RECV үшін және біреуі бір жақты WRITE_IMM үшін, өйткені RECV пен WRITE_IMM екеуі де RECV операциясын ретімен тұтынады, ал екі операция әртүрлі буфер өлшемдерін талап етеді. Сонымен қатар, біз ConnectX-7 пен GPU жады арасындағы PCIe транзакцияларын ретімен орындауды жеңілдетеміз. EFA сияқты, біз WR шаблондау оңтайландыруын іске асырамыз. Сонымен қатар, бір пирге бірнеше шағын хабарлама жіберген кезде, хабарлама жылдамдығын жақсарту үшін WR тізбектеуін пайдаланамыз.

GPU жағындағы жұмыс екі адаптерде де бірдей болғандықтан, EFA мен ConnectX-7 MoE бағыттауы арасындағы алшақтық түпкілікті аппараттық құралдардың мүмкіндіктерімен анықталатынын атап өту үшін DeepEP өнімділігінен асып түсу мақсатында біз түпкілікті тасымалдау іске асырылуын шегіне дейін жеткіздік.

Біз ConnectX-7 және EFA адаптерлерімен жабдықталған H200 жүйелерінде 7168 жасырын өлшемі, блоктық масштабталған fp8 диспетчерлеуі және bf16 біріктіруі бар стандартты DeepSeek-V3 және Kimi-K2 конфигурациясында диспетчерлеу және біріктіру кідірістерін бағаладық. Біз диспетчерлеу үшін 128 және біріктіру үшін 4096 топтама өлшемін қарастырамыз. ConnectX-7 жүйесінде біз DeepEP пен GPUDirect Async (IBGDA) және хост проксиін (IBRC) пайдалана отырып, біздің бұрынғы NVSHMEM негізіндегі pplx-kernels ядроларымызбен салыстырамыз. Біз EP16, EP32 және EP64 жүйелерінде сәйкесінше 459 мкс, 582 мкс және 692 мкс біріктірілген кідірістерге қол жеткіземіз. Біз 519 мкс, 966 мкс және 1159 мкс қол жеткізетін UCCL-EP сияқты жалпы проксилерге сүйенетін басқа EFA негізіндегі ядролардан озып түсеміз.

EP64 MoE decode үшін dispatch және combine кідірісі, көрсетілген іске асырулар мен байланыс жолдарын салыстырады.

Декодтауда ядроларымыз DeepEP-ке қарағанда бірнеше микросекундқа баяу болғанымен, біз біріктіру ядроларымыз едәуір жылдамырақ болғандықтан, жалпы алғанда төмен кідірістерге қол жеткіземіз. Хост проксиін пайдаланғанымызбен, жаппай тасымалдаулардың арқасында біз барлық IBGDA негізіндегі проксисіз іске асырулардың өнімділігінен асамыз. Сондай-ақ біз проксиді іске асыру маңызды екенін көрсетеміз, өйткені біздің жоғары мамандандырылған проксиіміз жалпы NVSHMEM іске асырылуына қарағанда бір есе жылдамырақ. MoE бағыттауы арқылы алмастырылатын әдеттегі пакет өлшеміне жақын болатын 256 КБ пакеттерді тасымалдаған кезде EFA ConnectX-7-ге қарағанда екі есе баяу екеніне қарамастан, екі адаптер арасындағы алшақтық жалпы алғанда соншалықты маңызды емес.

EP64 MoE prefill үшін dispatch және combine кідірісі, pplx пен DeepEP байланыс жолдарын салыстырады.

Біздің декодтауға оңтайландырылған ядроларымыз ешқандай қосымша түзетусіз префилл топтамасының өлшемдеріне дейін масштабтала алғанымен, өнімділік DeepEP-тен қалып қоюда. Бұл біз ең алдымен біріктірудің алушы жағында ғана токендерді жинақтайтындығымызға байланысты, ал DeepEP тасымалданатын деректер мөлшерін азайту үшін жіберуші жағында жинақтайды. Дегенмен, бұл оңтайландыру дәлдікке әсер етуі мүмкін. Сонымен қатар, ядролар деректерді бір жазу арқылы тасымалдайтындықтан, біз жіберу және қабылдау буферлері үшін көбірек жадыны пайдаланамыз.

Ядроларымыздың өміршеңдігін дәлелдеу үшін біз Elastic Fabric Adapters (EFA) және H200 GPU-ларымен жабдықталған бірнеше p5en даналарында DeepSeek-V3 (671B параметр) және Kimi-K2 (1T параметр) қызмет көрсететін меншікті инференс қозғалтқышымыздың түпкілікті өнімділігін сынақтан өткіземіз. Біз модельді жобаны тексеру режимінде іске қосамыз және бір MTP қабатын пайдалана отырып, 80% қабылдау жылдамдығын болжай отырып кідірісті хабарлаймыз.

DeepSeek-V3 жүйесінде біз тиімді NVLink-ке ғана қатысты диспетчерлеу және біріктіру ядроларын іске қосатын EP=8 түйінішілік базалық сызығымен салыстырамыз. Түйінаралық орналастырулар жалпы алғанда бір түйінді орналастырудың өнімділігіне сәйкес келеді немесе одан асып түседі, әсіресе орташа өлшемді топтамаларда, бұл түйіндер бойынша масштабтау жалпы өткізу қабілетін жақсартатынын көрсетеді.

Kimi-K2 жүйесінде ядролар қызмет көрсетуге мүмкіндік береді. Өлшеміне байланысты модель H200 түйінінде Деректер параллелизмін (DP) пайдалана отырып бір түйіннің ішіне сыймайды, сондықтан модельге қызмет көрсету үшін түйінаралық орналастыру қажет. Модельде назар аударатын бастар аз болғандықтан, біз DeepSeek-V3-ке қарағанда жақсырақ кідірістерге қол жеткіземіз және біз модельге EFA-да өміршең кідіріспен қызмет көрсете аламыз.

DeepSeek-V3 үшін бір GPU-ға шаққандағы өткізу қабілеті мен output жылдамдығының EP32, EP16 және EP8 конфигурацияларындағы арақатынасы.

Kimi-K2 үшін бір GPU-ға шаққандағы өткізу қабілеті мен output жылдамдығының EP32 және EP16 конфигурацияларындағы арақатынасы.

Сондай-ақ біз микропакеттеуді қарастырдық, бірақ ол тек өте жоғары топтама өлшемдерінде немесе бірнеше жоба токендерін пайдаланған кезде ғана кідірістерді жақсартты. Топталған GEMM мәселелерін екіге бөлудің пайдасын көру үшін токен топтамасының өлшемдері жеткілікті түрде тығыз болуы тиіс. Уақыттың басым бөлігі әлі де MoE диспетчерлеуі мен біріктіруге жұмсалады, бұл ядроларға кез келген қосымша жақсартулар нәтижесінде кідірістерді жақсартатынын және микропакеттеуді жеңілдететінін көрсетеді.

Біз EFA өнімділігін жақсарту үшін AWS инженерлерімен тығыз жұмыс істеп жатырмыз. Өз тарапымыздан біз деректер жазықтығының үстеме шығындарын азайтатын libfabric жаңартуларын қадағалайтын боламыз. Сонымен қатар, біз пайдаланушы кеңістігінің үстеме шығындарын одан әрі азайту және аппараттық құралдармен тікелей интерфейс жасау үшін efa-direct көмегімен тәжірибе жасаймыз.

DeepSeek R1 техникалық есебі

Kimi K2 техникалық есебі

DeepEP

UCCL-EP

NVIDIA Magnum IO NVSHMEM және GPUDirect Async көмегімен HPC жүйелерінің желілік өнімділігін жақсарту

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

Кіріспе

InfiniBand арқылы инференс

NVSHMEM негізіндегі pplx-kernels

EFA арқылы MoE all-to-all

Жіберу және қабылдау буферлері

Диспетчерлеу және біріктіру

MoE бағыттауы үшін TransferEngine

Бағалау

Диспетчерлеу/біріктіру кідірісі

Kimi-K2 / DeepSeek-V3 өткізу қабілеті

Болашақ жұмыс

Пайдаланылған әдебиеттер

Дәйексөз