Ефективна и преносима комуникация между смеси от експерти

Представяме високоефективна, преносима, софтуерна библиотека с отворен код за комуникация при Mixture-of-Experts (MoE), която постига 10 пъти по-бърза производителност в сравнение със стандартните комуникационни примитиви All-to-All.

Нашата реализация включва няколко ключови технически иновации, които осигуряват превъзходна ефективност на MoE комуникацията:

Комуникация, инициирана от GPU (IBGDA): Поддържа директна комуникация между GPU и NIC, като значително намалява закъснението, тъй като заобикаля намесата на CPU.

Припокриване на комуникацията и изчисленията: Архитектура с разделени ядра (kernels) с отделни етапи на изпращане и получаване позволява изчисленията да се извършват едновременно с мрежовите трансфери.

Най-бърза производителност на един възел (single-node): 2.5 пъти по-ниско закъснение в сравнение с досега най-бързата реализация при конфигурации с един възел.

Ефективна и преносима производителност на множество възли: Нашата реализация постига скорости до 10 пъти по-високи от стандартната all-to-all комуникация. Въпреки че е приблизително 2 пъти по-бавна от силно специализираните реализации, нашият подход предлага по-добра преносимост между версиите на NVSHMEM и мрежовите среди (NVLink, CX-7 и EFA).

Библиотеката е напълно с отворен код и е достъпна на адрес https://github.com/ppl-ai/pplx-kernels.

В тази статия разглеждаме предизвикателствата пред експертния паралелизъм в мащабни MoE модели и описваме нашия подход към ефективното разпределение и комбиниране на токени в разпределени GPU среди.

Въведение

Моделите Mixture-of-Experts (MoE), като DeepSeek R1 и Mixtral 8x7B, надграждат плътните модели, като ограничават броя на теглата, които се активират за всеки токен. Вместо да постигат голям брой параметри чрез увеличаване на броя на слоевете или размера на линейните слоеве в многослойния перцептрон (MLP) на всеки девътрешен слой (decoder layer), MoE моделите заменят традиционния MLP с множество експерти и рутър (router). Например, от общо 671 милиарда параметъра на DeepSeek R1, само 37 милиарда се умножават с даден токен по време на инференс (извеждане на резултат). Това значително намалява количеството изчисления, необходими за дешифриране на токен, и подобрява закъснението в сравнение с плътен модел.

MoE моделите поставят някои допълнителни предизвикателства пред инференса в сравнение с плътните модели. Въпреки че самите експерти са малки MLP слоеве, всеки девътрешен слой включва рутър, който определя към кои експерти да бъде изпратен даден токен, като всеки токен се изпраща към множество експерти. Рутърът обикновено е малък линеен слой, който генерира разпределение на вероятностите. Обикновено се избират експертите с най-високи K резултата (top-K), а крайната активация се изчислява като претеглено средно, като се сумират изходите на експертите, умножени по тегло, получено от разпределението на вероятностите на рутъра.

За да се минимизира закъснението в разпределени MoE системи, паралелизмът може да бъде използван на множество устройства, но това води до комуникационни предизвикателства. Модели като Mixtral 8x7B или Llama-70B се побират в 8 устройства в рамките на един възел, възползвайки се от бързи NVLink връзки с ниско закъснение (до 900 Gbps). По-големите модели обаче изискват шардиране на експертите на множество възли чрез InfiniBand (с пик от 400 Gbps), което води до допълнителни предизвикателства, свързани със закъснението.

Уголеми

В тази статия разглеждаме проблема с експертния паралелизъм, като описваме нашата реализация на GPU ядра (kernels), които ефективно разпределят токените към устройствата, съдържащи назначените експерти, и ги събират обратно чрез изчисляване на претеглената сума на експертните изходи. Въпреки че съществуват агресивно оптимизирани реализации, насочени към конкретен мрежов хардуер, ние представяме силно преносима реализация, която разчита на минимален набор от примитиви на NVSHMEM, но същевременно осигурява 10 пъти по-бърза производителност от стандартната all-to-all комуникация. Нашата реализация постига върхова производителност при конфигурации с един възел, като същевременно запазва отлична преносимост в различни мрежови среди.

Шардиране и паралелизъм

За ефективен инференс теглата на модела трябва да се съхраняват в паметта на устройството, като същевременно се оставя достатъчно пространство за активации, KV кешове и други буфери, необходими за правото преминаване (forward pass) през модела. Най-мощните модели надвишават капацитета дори на най-мощните GPU-та, затова инференсът трябва да бъде разпределен между множество устройства, които могат съвместно да съхраняват теглата на модела. В зависимост от схемите за шардиране на теглата трябва да се използват различни комуникационни и изчислителни схеми за прехвърляне на изчисленията и синхронизиране на устройствата.

Уголеми

Експертният паралелизъм (EP), илюстриран на първата фигура, паралелизира единствено експертните изчисления. Различни експерти се назначават на различни устройства, които съхраняват техните тегла. След маршрутизирането (рутирането), токените се изпращат към съответното устройство, а резултатите се събират и акумулират след това. Сложността на рутирането зависи от степента на паралелизъм в другите части на модела: дублирането на други слоеве може напълно да елиминира нуждата от рутиране, тъй като всеки ранг може да избира токените от локално дублирана таблица за рутиране. Въпреки това, ако само един от ранговете изпълнява рутирането, е необходимо излъчване (broadcast), за да се разпределят токените, индексите и теглата към съответните им експерти. И накрая, all-gather или all-to-all излъчване синхронизира изходните токени с онзи ранг, който продължава изпълнението на модела. Такава реализация е сравнително проста, тъй като PyTorch вече предоставя необходимите примитиви, въпреки че могат да се постигнат някои предимства чрез обединяване на акумулацията с операцията по събиране на токените от експертите.

Уголеми

Паралелизмът само за експерти не се мащабира идеално, тъй като възлите в клъстера може да са в състояние на покой (idle), докато моделът изпълнява слоеве, които не са свързани с експерти, като например внимание (attention), нормализация (norm) и семплиране. Изчисленията на тези слоеве (предимно attention) обаче също могат да се възползват от тензорен паралелизъм (Tensor Parallelism - TP). Повечето модели разчитат на многогласово внимание (multi-head attention), което означава, че главите за внимание и съответните им Q, K и V проекции също могат да бъдат шардирани между устройствата, като се дублират или събират отсечките между различните слоеве. Ако вниманието е разпределено между всички устройства, операцията all-gather може да синхронизира активациите, което позволява рутирането да бъде дублирано и изисква синхронизационни примитиви, подобни на тези при експертния паралелизъм, за постигане на ефективна реализация. Съществуват обаче ограничения пред паралелизма на това ниво, тъй като намаляването на броя на главите за внимание под определен праг води до намаляваща възвръщаемост.

Уголеми

За да се оползотворят максимално всички устройства и да се поддържа много висока степен на експертен паралелизъм (до 128 или 256 GPU-та), е необходим земен паралелизъм (Data Parallelism - DP). При тази схема устройствата, между които е разделен моделът, се групират за едновременна обработка на заявки, като изчисляват вниманието и поддържат KV кешове, шардирани в рамките на тяхната локална група. Множество инстанции на тези паралелни групи си сътрудстват при оценяването на експертите, като всяка от тях хоства различно подмножество от теглата на експертите. В зависимост от броя на главите за внимание, една група обикновено може да обхваща цял възел, тъй като вътрешноузловата комуникация е по-бърза. Например, на фигурата по-горе един DP ранг обслужва независимо две заявки (A и B), като обработва вниманието, нормализацията и всякакви други счетоводни задачи за заявките. Другият DP ранг обработва отделна заявка C. Първият възел обаче хоства половината от експертите, а другият – другата половина, така че след рутирането токените от A и B могат да бъдат изпратени към втория възел и обратно. Това води до проблем с рядката (sparse) комуникация: всяко устройство може да изпрати различен брой токени към произволен друг целеви ранг. Съществуващите примитиви от PyTorch, предимно all_to_all, не са особено подходящи, тъй като може да изискват някаква форма на подложка (padding), GPU-to-CPU синхронизация и излъчване на метаданни. За ефективно реализиране на комуникацията са необходими потребителски ядра (custom kernels), които да обработват информацията за рутиране и да инициират комуникация от устройствата без намесата на CPU. След рутирането ядрото за разпределение (dispatch kernel) трябва да изпрати токените към ранговете, към които са били насочени, докато от страната на комбинирането трябва да се съберат активациите, принадлежащи на заявките в текущата DP група. Освен това работата трябва да бъде балансирана в рамките на една DP група, която може да има множество устройства, за да се минимизира излъчването и правилно да се дублират токените на всички рангове за следващите слоеве.

NVSHMEM

NVSHMEM е специфична за NVIDIA реализация на OpenSHMEM, която предоставя средства за преносима комуникация между устройствата, абстрахиращи сложността на базовия хардуер. API интерфейсът може да изразява четения и записи между устройства, които се мапват към примитивите на отделните транспортни слоеве. Поддържат се както NVLink, така и RDMA, което осигурява известна степен на преносимост и позволява на NVSHMEM ядрата да работят в рамките на един възел или в клъстер от множество възли. В нашите ядра използваме операции за отдалечен достъп до паметта (remote memory writes) и сигнализиране за прехвърляне на данни и синхронизиране на участващите устройства.

Операциите в NVSHMEM са изградени около концепцията за симетрична памет: те работят върху буфери, които са били заделени на всички устройства, участващи в комуникацията между устройствата. Локалното устройство може да използва адрес, получен в рамките на собствения си локален буфер, заедно с индекса на целевия ранг, за да укаже местоположението на дестинацията за дадена операция. Фигурата по-долу илюстрира тази концепция: и двете GPU-та заделят симетрични буфери с един и същ размер, като запазват src указатели към тях. Първият ранг иска да изпрати 3 цели числа към втория, като ги разположи в началото на буфера: nvshmem_int_put_nbi извежда началния адрес от локалния буфер, като указва целевото устройство. Вторият ранг извежда отместване (offset) от собствения си буфер, като изпраща един елемент към първото устройство с отместване от едно. Въпреки че целевите адреси трябва винаги да бъдат симетрични буфери, заделени с помощта на nvshmem_alloc, изходните буфери могат да бъдат произволни области от паметта на устройството, при условие че са предварително регистрирани в NVSHMEM.

Въпреки че NVSHMEM предоставя широка гама от примитиви, нашите ядра разчитат само на 3 функции, като изграждат цялата синхронизация и заграждане (fencing) върху тях.

Уголеми

nvshmemx_putmem_signal_nbi_warp: Прехвърля блок от данни от едно устройство към друго, като едновременно с това задава флаг на отдалеченото устройство. Операцията или задава (NVSHMEM_SIGNAL_SET), или увеличава (NVSHMEM_SIGNAL_ADD) 64-битова локация. Флагът се актуализира, след като целият блок памет бъде прехвърлен. Ако отдалеченото устройство забележи промяна във флага, то може безопасно да достъпи буфера в собствената си памет. Тази функция е полезна за обединяване на прехвърлянето на данни и синхронизацията.

nvshmemx_signal_op работи с една-единствена локация в паметта, обикновено 64-битов флаг, като го задава или увеличава атомно (atomically). Тя е полезна за изпращане на метаданни и синхронизиране на устройства.

nvshmem_uint64_wait_until се използва от получаващата страна на сигнал за поллиране (проверяване) на флаг, докато отдалеченото устройство го актуализира.

Осигуряването на каквато и да е форма на подредба между операциите чрез nvshmem_quiet или nvshmem_fence е скъпоструващо, поради което нашата реализация на ядрата избягва използването на каквито и да е други примитиви на NVSHMEM и минимизира зависимостите извън отделните двойки за изпращане и получаване (send-receive). При изпращане на данни винаги използваме неблокиращата версия на функциите, без да чакаме данните дори да бъдат изпратени извън локалния ранг. Друга, имплицитна синхронизация в рамките на групата ядра гарантира, че тези буфери няма да бъдат деструктивно презаписани, докато мрежовите адаптери (NIC) се нуждаят от достъп до тях.

NVSHMEM използва GPUDirect RDMA, така че мрежовият адаптер (NIC) да може директно да чете и записва в GPU паметта за обмен на данни, без да ангажира CPU. Освен това на ConnectX NIC адаптерите NVSHEMEM поддържа инициирана от GPU комуникация (известна още като InfiniBand GPUDirect Async или IBGDA), която позволява на GPU да подава RDMA операции директно към NIC и да проверява (poll) опашката за завършване на NIC директно. На платформи, които не поддържат инициирана от GPU комуникация, NVSHMEM създава „прокси“ тема (thread) на хост CPU за иницииране на комуникацията и проверка за завършване от името на GPU. Програмата NVSHMEM е преносима независимо от това дали инициираната от GPU комуникация се поддържа, или не. Въпреки това инициираната от GPU комуникация значително намалява закъснението, тъй като напълно заобикаля заобиколния път през CPU.

Преносими ядра (Portable Kernels)

Ние реализираме MoE комуникацията чрез двойка ядра за разпределение (dispatch) и комбиниране (combine). Ядрата за разпределение отговарят за четенето на токени и информация за рутиране на всеки ранг, като ги изпращат към съответните експерти. Ядрата за комбиниране събират активациите, произведени от експертите, и ги изпращат обратно към техните изходни рангове, като едновременно с това изчисляват претегленото средно от избраните експерти въз основа на теглата, изчислени от рутъра. Ядрата са допълнително разделени на компонент за изпращане и компонент за получаване, за да се позволи припокриване на прехвърлянето на данни с изчисленията. Ядрата за изпращане са неблокиращи и несинхронизиращи: те просто разпределят всички записи към отдалечените устройства. От друга страна, ядрата за комбиниране само четат от паметта, като изчакват, докато всички необходими данни бъдат прехвърлени. След разпределянето на работата към мрежовите адаптери, докато данните се прехвърлят асинхронно по мрежата, GPU-тата могат да извършват друга полезна работа локално, като например прилагане на споделени експерти или изчисляване на внимание.

Всяка двойка ядра разполага със собствени симетрични буфери за памет, като всеки ранг заделя лично хранилище за получаване на данни от всички останали рангове. Максималният брой токени, които могат да бъдат разпределени от една DP група, е фиксиран за всички рангове, което определя и горната граница, която всеки ранг може да получи за всеки локален експерт от всеки DP ранг. Това позволява на ранговете изпращачи да изведат уникален адрес на целевия ранг за запис, без да е необходима каквато и да е синхронизация помежду им. След като данните бъдат получени, ядрата разбъркват токените, за да ги подредят в паметта в оптималния формат, изискван от получаващите ядра. Въпреки че буферите имат значителни размери, те се използват повторно във всички последователни слоеве на модела.

Уголеми

Единствената форма на глобална синхронизация, както е илюстрирано на фигурата по-горе, е реализирана в ядрото за комбиниране и получаване (combine-receive). След като данните бъдат разпределени от изпращането, рангът се връща и продължава изпълнението, когато получи всички необходими токени от останалите рангове, и влиза в ядрата за комбиниране и изпращане (combine-send), веднага щом те бъдат обработени. Бариерата в combine-receive гарантира, че никой ранг не може да изпревари останалите и да започне dispatch-send, докато друг ранг все още чака да получи данни, което потенциално би довело до деструктивно припокриване. Синхронизацията се извършва в ядрото за комбиниране с цел опростяване; като оптимизация същата бариера би могла да се реализира между ядрата за разпределение и получаване (dispatch-receive) и комбиниране и изпращане (combine-send), което допълнително ще намали закъснението, като даде повече време на мрежовите адаптери да уредят трансферите, докато GPU изпълнява други ядра.

И двете ядра са разпределени между всички налични SM (Streaming Multiprocessors) на устройствата: докато ядрата dispatch-send и combine-receive трябва да паралелизират спрямо максималния брой токени за ранг (max_m), ядрата dispatch-receive и combine-send трябва да обработват толкова токени от всеки ранг и локален експерт, до максимум max_m * (num_experts // EP) * (EP // TP).

Разпределение (Dispatch)

Ядрото за разпределение отговаря за разпределянето на токените и коефициентите за мащабиране на блокове (block scaling factors) към партньорските устройства, които хостват експертите, към които токените са били насочени. Изпращащата страна разчита на warp специализация (warp specialization), за да паралелизира две задачи: агрегиране на информацията за рутиране, за да се определи колко токена се изпращат от всеки ранг, и опаковане на токените в съобщения за изпращане към отдалеченото устройство. Получаващата страна първо изчаква да бъдат получени всички бройки токени, след което прочита и разопакова полезните данни (payloads) от споделената памет в тензорите, които ще бъдат предадени към следващите по веригата Групирани GEMM ядра (Grouped GEMM kernels). Тя също така съхранява информация в буфери, споделени с ядрата за комбиниране, за да указва къде трябва да бъде изпратен обратно всеки токен. Тази информация е необходима, тъй като ядрото за получаване разбърква токените в непрекъснати буфери в недетерминиран ред.

Уголеми

В изпращащата част един единствен warp от 32 теми (threads) във всеки блок отговаря за четенето на информацията за рутиране и преброяването на броя токени, които се очаква да получи всеки целеви експерт от този ранг, като изпраща броя плюс едно с помощта на nvshmem_signal_op. Броячът се увеличава с единица, тъй като преходът от нула към ненулева стойност в отдалечения край ознаменува получаването на броячите от изходен ранг. Успоредно с това останалите warp-ове си сътрудстват за паралелно копиране на токените в симетричната памет през всички блокове, като опаковат активациите, факторите на мащабиране и техния индекс в локалния ранг в непрекъснат блок. Индексът е необходим на изпращача за комбиниране, за да се определи адресът, на който ще бъде записан токенът. След това, след като се уверят чрез бариера между warp групите, че всички данни са копирани, warp-овете отново работят независимо, като всеки от тях изпраща паралелно един и същ буфер към различен експерт. Токените се изпращат с помощта на nvshmemx_putmem_signal_nbi_warp, което също така атомно увеличава броя на изпратените токени от локалния ранг на отдалеченото устройство. В рамките на една DP група, тъй като всеки ранг притежава реплика на токена за изпращане, разпределението е балансирано равномерно, като всяко устройство изпраща подмножество от токените.

В получаващия край всички ядра първо се синхронизират с ранговете изпращачи, като изчакват да бъдат изпратени общите бройки токени. След това всички те изчакват атомно увеличаваните броячи на изпратени токени да достигнат общите бройки, което показва, че всички полезни данни от изходните рангове също са били изпратени, благодарение на семантиката на извикването putmem. Ядрата проверяват (poll) броячите с помощта на nvshmem_uint64_wait_until, като паралелизират операцията във всички блокове и теми (threads). Впоследствие междублокова бариера гарантира, че никой блок няма да чете буферите, освен ако всички данни не са получени правилно. Разпределени между блоковете и синхронизирани чрез атомно увеличаван брояч, токените се копират от симетричната памет в обикновени непрекъснати буфери, които се превръщат във входни данни за следващите ядра, реализиращи експертите. Изходният ранг, индексът на експерта и индексът на токен се съхраняват отделно, като точно определят местоположението, до което ядрото за комбиниране трябва да изпрати активациите. Въпреки че токените от дадена DP група се изпращат от различни устройства, те се групират заедно, за да бъдат предадени на съответния експерт.

Комбиниране (Combine)

Ядрата за комбиниране отново са разделени на половини за изпращане и получаване: изпращачите копират неквантуваните 16-битови активации към отдалечените устройства, а получаващите ядра изчакват данните да бъдат изпратени и изчисляват претегленото средно на всички експертни приноси локално. Освен това те действат и като бариера за синхронизиране на последователността dispatch-combine: всеки ранг задава флаг на всеки партньор при влизане в ядрата за изпращане, като на получаващите ядра не е позволено да се върнат, освен ако не установят, че флагът е зададен. Закъснението на синхронизацията е минимално, тъй като се припокрива с реалната комуникация и изчисления.

Уголеми

От страна на изпращача ядрата обхождат списъка с токени, назначени на всички локални експерти паралелно, като ги записват в буфер на целевия ранг. Целевият ранг, индексът на експерта и индексът на токен се четат от буферите за отделни токени, попълнени от scatter ядрата при получаването на токените. Всеки изпращач има собствена частна област в паметта за всеки експерт, в която да записва, както е показано на фигурата по-горе, което избягва необходимостта от синхронизация. По подобен начин на разпределението, комбинирането атомно увеличава броячите за отделни токени на целевия ранг, за да укаже получаването на данните: когато броячът съвпадне с броя на експертите, към които е бил разпределен даден токен, съдържанието на токена може да бъде достъпено.

В ядрото за получаване списъкът с токени се обхожда паралелно в множество блокове, като се изчаква пристигането на тяхното съдържание чрез поллиране (проверяване) на флага, зададен от операцията за сигнализиране. При пристигане полезните данни се четат от частните буфери, като таблицата за рутиране указва кой буфер да се чете и какво тегло да се зададе на всеки експерт. След това резултатите се записват във външно заделени тензори, като ядрото завършва изпълнението си, след като всички устройства преминат бариерата. В рамките на една DP група всички рангове получават копие на всяка експертна активация, за да изчислят собствените си реплики.

Бенчмаркове (Benchmarks)

Ние оценяваме нашите ядра в клъстер от 128 GPU-та, разположени в 16 възла, свързани чрез InfiniBand и CX-7 NIC адаптери. Изпитваме както GPUDirect Async (IBGDA), така и Reliable Connection (RC) с CPU прокси. Сравняваме ги със силно оптимизираната реализация на DeepSeek, както и с плътните примитиви, предоставени от PyTorch (чрез NCCL) или NVSHMEM.

Уголеми

Въпреки че при плътната all-to-all операция на NVSHMEM производителността на IBRC и IBGDA е сходна (6378 µs срещу 6180 µs), IBGDA е значително по-бърза при редките (sparse) ядра. Събирайки Dispatch и Combine, IBGDA използва 902 µs, докато IBRC отнема 3223 µs – 3.6-кратно подобрение в закъснението. Въпреки че all-to-all е ограничена от пропускателната способност (bandwidth bound), редките ядра излъчват многократно по-малко данни, като са ограничени от закъснението (latency bound). Чрез задействане на мрежови трансфери директно от GPU, без да се изисква CPU прокси за координиране на GPU и NIC, закъснението от край до край (end-to-end latency) се намалява значително.

Въпреки че нашите преносими ядра са около 2 пъти по-бавни от силно оптимизираните ядра на DeepSeek, те подобряват закъснението с 10 пъти в сравнение с плътните ядра (902 µs срещу 9944 µs).

Освен това разделянето на компоненти за изпращане и получаване позволява част от закъснението да бъде скрито, за разлика от библиотечните примитиви.

Уголеми

При конфигурация с един възел (EP8) NVSHMEM използва NVLINK за пренос на данни, което осигурява по-ниско закъснение и по-висока пропусквателна способност от междуузловата мрежа. Нашите преносими ядра са около 2.5 пъти по-бързи от DeepEP на един възел (186 µs срещу 481 µs).

Бъдещи подобрения

Описаните тук ядра надминават вградените примитиви на ML рамките и предлагат прилична производителност, без да се свръхспециализират за конкретни междуустройствени транспорти като NVLink или InfiniBand. Освен вече споменатите възможности, допълнителни печалби в производителността могат да бъдат постигнати чрез замяна на комуникационните примитиви с по-специализирани версии. Например през NVLink използването на симетрична памет може да бъде заменено с буфери, споделени между устройствата, което елиминира част от копирането и позволява по-фино настроени схеми за синхронизация – през отделни токени вместо през партиди от токени. През InfiniBand дадена реализация би могла да достъпва директно основните двойки опашки (queue pairs), което елиминира необходимостта от прехвърляне както на очаквания, така и на изпратения брой токени, както и изчистването на токени от опашките в изходните буфери с пристигането им. Подобни реализации обаче идват за сметка на преносимостта, докато нашите реализации позволяват оценяване на клъстери със специфични конфигурации, преди да се ангажират усилия за разработване и оптимизиране за конкретен хардуер.

Заключение

Представихме високоефективна, преносима библиотека за MoE комуникация, която постига 10 пъти по-бърза производителност в сравнение със стандартната all-to-all комуникация, като същевременно поддържа съвместимост между разнообразни хардуерни конфигурации. При внедрявания на един възел с NVLink нашето решение демонстрира 2.5 пъти по-ниско закъснение от предходни реализации.

Нашият подход балансира производителността с преносимостта чрез ключови иновации, включително поддръжка на инициирана от GPU комуникация, архитектура с разделени ядра, позволяваща припокриване на изчисленията и комуникацията, и ефективно разпределение на токени с използване на минимални примитиви на NVSHMEM. Въпреки че е приблизително 2 пъти по-бавна от силно специализираните реализации при многоузлови настройки, нашата библиотека предлага превъзходна гъвкавост в различни мрежови среди (NVLink, CX-7 и EFA).

Тъй като MoE моделите продължават да се мащабират, ефективните комуникационни стратегии като нашата ще стават все по-важни за практическото им внедряване. Нашата напълно отворена реализация е достъпна на адрес https://github.com/ppl-ai/pplx-kernels.

Източници

DeepEP

Технически доклад за DeepSeek-V3

NVIDIA NVSHMEM

Цитиране

@online{perplexity2025EfficientAndPortableMixtureOfExpertsCommunication,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Phi Hoang},
  title = {{Efficient and portable mixture-of-experts communication}},
  date = {2025-04-02},
  url = {https://www.perplexity.ai/hub/blog/efficient-and-portable-mixture-of-experts-communication}
}