Ефективний і переносний зв'язок суміші експертів (mixture-of-experts)

Огляд переносного зв'язку для моделей Mixture-of-Experts (MoE) з акцентом на оптимізацію паралелізму GPU та зменшення затримок у великомасштабних моделях ШІ

АвториPerplexity Research

Ми представляємо високопродуктивну, переносну, відкриту бібліотеку для зв'язку Mixture-of-Experts (MoE), яка досягає у 10 разів швидшої продуктивності порівняно зі стандартними примітивами зв'язку All-to-All.

Наша реалізація має кілька ключових технічних інновацій, які забезпечують вищу ефективність зв'язку MoE:

Зв'язок, ініційований GPU (IBGDA): Підтримує прямий зв'язок між GPU та NIC, значно зменшуючи затримку завдяки обходу залучення CPU

Перекриття зв'язку та обчислень: Розділена архітектура ядер з окремими етапами надсилання та отримання дозволяє виконувати обчислення одночасно з передачею даних у мережі

Найвища продуктивність на одному вузлі: у 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) кожного шару декодера, моделі MoE замінюють традиційний MLP на кілька експертів і маршрутизатор. Наприклад, із 671 мільярда параметрів DeepSeek R1 лише 37 мільярдів множаться на заданий токен під час виведення. Це значно зменшує обсяг обчислень, необхідних для декодування токена, і покращує затримку порівняно зі щільною моделлю.

Моделі MoE створюють додаткові проблеми для виведення порівняно зі щільними моделями. Хоча самі експерти є невеликими шарами MLP, кожен шар декодера містить маршрутизатор, який визначає, до яких експертів надсилається токен, причому кожен токен надсилається до кількох експертів. Маршрутизатор зазвичай є невеликим лінійним шаром, що створює розподіл ймовірностей. Зазвичай вибираються експерти з найвищими оцінками Top-K, а остаточна активація обчислюється як зважене середнє значення шляхом підсумовування виходів експертів, помножених на вагу, отриману з розподілу ймовірностей маршрутизатора.

Щоб мінімізувати затримку в розподілених системах MoE, можна використовувати паралелізм на кількох пристроях, але це створює проблеми зі зв'язком. Такі моделі, як Mixtral 8x7B або Llama-70B, вміщуються на 8 пристроях в межах одного вузла, отримуючи переваги від швидких з'єднань NVLink із низькою затримкою (до 900 Гбіт/с). Однак більші моделі вимагають шардингу експертів на кількох вузлах за допомогою InfiniBand (з піковою швидкістю 400 Гбіт/с), що створює додаткові проблеми із затримками.

Маршрутизація токенів, обчислення експертів і збір результатів у шарі mixture-of-experts.

У цій статті ми досліджуємо проблему експертного паралелізму, описуючи нашу реалізацію ядер GPU, які ефективно надсилають токени на пристрої, що містять призначених експертів, і збирають їх назад шляхом обчислення зваженої суми виходів експертів. Хоча існують агресивно оптимізовані реалізації, що націлені на певне мережеве обладнання, ми представляємо високопереносну реалізацію, яка спирається на мінімальний набір примітивів NVSHMEM, але забезпечує продуктивність у 10 разів швидшу за стандартний зв'язок all-to-all. наша реалізація досягає найкращої у своєму класі продуктивності в конфігураціях з одним вузлом, зберігаючи при цьому чудову переносимість у різних мережевих середовищах.

Шардинг і паралелізм

Для ефективного виведення ваги моделі повинні зберігатися в пам'яті пристрою, залишаючи при цьому достатньо простору для активацій, кешів KV та інших буферів, необхідних для прямого проходження моделі. Найпотужніші моделі перевищують ємність навіть найпотужніших GPU, тому виведення має бути розподілене між кількома пристроями, які можуть спільно зберігати ваги моделі. На основі схем шардингу ваг необхідно використовувати різні схеми зв'язку та обчислень для розвантаження обчислень і синхронізації пристроїв.

Паралелізм експертів на двох GPU.

Експертний паралелізм (EP), проілюстрований на першому малюнку, розпаралелює лише обчислення експертів. Різні експерти призначаються на різні пристрої, які зберігають їхні ваги. Після маршрутизації токени надсилаються на відповідний пристрій, а результати збираються та накопичуються згодом. Складність маршрутизації залежить від ступеня паралелізму в інших частинах моделі: реплікація інших шарів може повністю усунути потребу в маршрутизації, оскільки кожен ранг може вибирати токени з локально реплікованої таблиці маршрутизації. Однак, якщо лише один із рангів виконує маршрутизацію, для надсилання токенів, індексів і ваг відповідним експертам потрібна трансляція (broadcast). Нарешті, операція all-gather або трансляція all-to-all синхронізує вихідні токени з тим рангом, який продовжує виконання моделі. Така реалізація є відносно простою, оскільки torch вже надає необхідні примітиви, хоча певну вигоду можна отримати завдяки об'єднанню накопичення з операцією збору, яка збирає токени від експертів.

Поєднання паралелізму експертів із тензорним паралелізмом на двох GPU.

Паралелізм лише для експертів масштабується не ідеально, оскільки вузли в кластері можуть простояти, поки модель виконує неекспертні шари, такі як увага, нормалізація та семплювання. Однак обчислення цих шарів, насамперед уваги, також можуть отримати вигоду від тензорного паралелізму (TP). Більшість моделей покладаються на багатоголову увагу, що означає, що голови уваги та їхні відповідні проєкції Q, K і V також можуть бути розділені між пристроями (зашардовані), реплікуючи або збираючи зрізи між різними шарами. Якщо увага розподілена по всіх пристроях, операція all-gather може синхронізувати активації, дозволяючи реплікувати маршрутизацію, що вимагає примітивів синхронізації, подібних до випадку експертного паралелізму, для ефективної реалізації. Однак існують обмеження щодо паралелізму на цьому рівні, оскільки зменшення кількості голів уваги нижче певного порогу призведе до зменшення віддачі.

Поєднання паралелізму експертів із паралелізмом даних для окремих запитів на двох GPU.

Щоб найкраще задіяти всі пристрої та підтримувати дуже високий ступінь експертного паралелізму (до 128 або 256 GPU), потрібен паралелізм даних (DP). За цією схемою пристрої, між якими розділена модель, групуються для одночасного обробляння запитів, обчислюючи увагу та підтримуючи кеші KV, зашардовані у їхній локальній групі. Кілька екземплярів цих паралельних груп співпрацюють в оцінюванні експертів, причому кожен містить різну підмножину ваг експертів. Залежно від кількості голів уваги група зазвичай може охоплювати розмір цілого вузла, оскільки внутрішньовузловий зв'язок є швидшим. Наприклад, на малюнку вище один ранг DP незалежно обслуговує два запити, A і B, обробляючи увагу, нормалізацію та будь-який інший облік запитів. Інший ранг DP обробляє окремий запит C. Однак перший вузол містить половину експертів, а інший вузол — іншу половину, тому після маршрутизації токени з A і B можуть бути надіслані на другий вузол і навпаки. Це призводить до проблеми розрідженого зв'язку: кожен пристрій може надсилати різну кількість токенів до будь-якого іншого цільового рангу. Наявні примітиви з torch, насамперед all_to_all, не дуже добре підходять, оскільки вони можуть вимагати певної форми доповнення (padding) або синхронізації GPU з CPU та трансляції метаданих. Для ефективної реалізації зв'язку потрібні спеціальні ядра (custom kernels) для оброблення інформації про маршрутизацію та ініціювання зв'язку з пристроїв без втручання CPU. Після маршрутизації ядро диспетчеризації повинно надсилати токени на ранги, до яких вони були спрямовані, тоді як на стороні комбінування необхідно збирати активації, що належать до запитів у поточної групі DP. Крім того, робота повинна бути збалансована в межах групи DP, яка може мати кілька пристроїв, щоб мінімізувати трансляцію та правильно реплікувати токени на всіх рангах для наступних шарів.

NVSHMEM

NVSHMEM — це специфічна для NVIDIA реалізація OpenSHMEM, що надає засоби переносного зв'язку між пристроями, які абстрагують складність базового апаратного забезпечення. API може виражати операції читання та запису між пристроями, які зіставляються з примітивами окремих транспортних шарів. Підтримуються як NVLink, так і RDMA, що забезпечує певний ступінь переносимості та дозволяє ядрам NVSHMEM працювати всередині вузла або по всьому кластеру з кількох вузлів. У наших ядрах ми використовуємо віддалений запис у пам'ять та операції сигналізації для передачі даних і синхронізації пристроїв, що беруть участь у процесі.

Операції NVSHMEM побудовані навколо концепції симетричної пам'яті: вони працюють з буферами, які були виділені на всіх пристроях, що беруть участь у зв'язку між пристроями. Локальний пристрій може використовувати адресу, отриману в межах власного локального буфера, разом з індексом цільового рангу, щоб вказати призначення операції. На малюнку нижче проілюстровано цю концепцію: обидва графічні процесори виділяють симетричні буфери однакового розміру, зберігаючи вказівники src на них. Перший ранг хоче надіслати 3 цілі числа другому, розмістивши їх на початку буфера: nvshmem_int_put_nbi виводить початкову адресу з локального буфера, вказуючи цільовий пристрій. Другий ранг виводить зміщення зі власного буфера, надсилаючи один елемент першому пристрою зі зміщенням на один. Хоча цільові адреси завжди повинні бути симетричними буферами, виділеними за допомогою nvshmem_alloc, вихідні буфери можуть бути довільними областями пам'яті пристрою за умови, що вони попередньо зареєстровані в NVSHMEM.

Хоча NVSHMEM надає широкий спектр примітивів, наші ядра спираються лише на 3 функції, будуючи на них усю синхронізацію та захист (fencing).

Симетрична пам’ять і віддалені записи між двома GPU за допомогою NVSHMEM.

nvshmemx_putmem_signal_nbi_warp: передає блок даних з одного пристрою на інший, а також встановлює прапорець на віддаленому пристрої. Операція або встановлює (NVSHMEM_SIGNAL_SET), або інкрементує (NVSHMEM_SIGNAL_ADD) 64-бітну комірку. Прапорець оновлюється після передачі всього блоку пам'яті. Якщо віддалений пристрій помітив зміну прапорця, він може безпечно отримати доступ до буфера у власній пам'яті. Ця функція корисна для об'єднання передачі даних і синхронізації.

nvshmemx_signal_op працює з однією коміркою пам'яті, зазвичай 64-бітним прапорцем, атомарно встановлюючи його або інкрементуючи. Це корисно для передачі метаданих та синхронізації пристроїв.

nvshmem_uint64_wait_until використовується на приймаючій стороні сигналу для опитування прапорця, доки віддалений пристрій не оновлює його.

Забезпечення будь-якої форми впорядкування між операціями за допомогою nvshmem_quiet або nvshmem_fence є ресурсомістким, тому наша реалізація ядер уникає використання будь-яких інших примітивів NVSHMEM і мінімізує будь-які залежності, окрім окремих пар надсилання-отримання. Під час надсилання даних ми завжди використовуємо неблокуючу версію функцій, не чекаючи, поки дані навіть будуть надіслані з локального рангу. Інша неявна синхронізація в групі ядер гарантує, що ці буфери не будуть руйнівно перезаписані, поки мережевим адаптерам (NIC) потрібен доступ до них.

NVSHMEM використовує GPUDirect RDMA, щоб мережевий адаптер (NIC) міг безпосередньо читати та записувати пам'ять GPU для обміну даними без залучення процесорів (CPU). Крім того, на адаптерах ConnectX NIC технологія NVSHEMEM підтримує зв'язок, ініційований GPU (також відомий як Infiniband GPUDirect Async або IBGDA), що дозволяє GPU надсилати операції RDMA безпосередньо на NIC і безпосередньо опитувати чергу завершення NIC. На платформах, які не підтримують ініційований GPU зв'язок, NVSHMEM створює "проксі"-тред на хост-процесорі для ініціювання зв'язку та опитування завершення від імені GPU. Програма NVSHMEM є переносною незалежно від того, підтримується зв'язок, ініційований GPU, чи ні. Однак зв'язок, ініційований GPU, значно скорочує затримку, оскільки він повністю обходить обхідний шлях до CPU.

Переносні ядра

Ми реалізуємо зв'язок MoE за допомогою пари ядер диспетчеризації та комбінування. Ядра диспетчеризації відповідають за читання токенів та інформації про маршрутизацію на кожному ранзі, надсилаючи їх відповідним експертам. Ядра комбінування збирають активації, вироблені експертами, і відсилають їх назад на їхні вихідні ранги, одночасно обчислюючи зважене середнє від вибраних експертів на основі ваг, обчислених маршрутизатором. Ядра далі розділені на компонент надсилання та отримання, щоб дозволити перекривати передачу даних з обчисленнями. Ядра надсилання є неблокуючими та несинхронізуючими: вони просто надсилають усі записи на віддалені пристрої. З іншого боку, ядра комбінування лише читають з пам'яті, чекаючи, поки всі необхідні дані будуть передані. Після надсилання роботи на NIC, поки дані асинхронно передаються по дроту, графічні процесори можуть виконувати іншу корисну роботу локально, наприклад застосовувати спільних експертів або обчислювати увагу.

Кожна пара ядер має власні буфери симетричної пам'яті, причому кожен ранг виділяє приватне сховище для отримання даних від усіх інших рангів. Максимальна кількість токенів, які можуть бути надіслані з групи DP, є фіксованою для всіх рангів, що також встановлює верхню межу, яку кожен ранг може отримати для кожного локального експерта від кожного рангу DP. Це дозволяє рангам-відправникам визначати унікальну адресу на цільовому ранзі для запису без необхідності будь-якої синхронізації між ними. Після отримання даних ядра перетасовують токени, щоб розмістити їх у пам'яті в оптимальному форматі, необхідному для приймаючих ядер. Хоча буфери мають значний розмір, вони повторно використовуються на всіх послідовних шарах моделі.

Окремі ядра надсилання та отримання для операцій dispatch і combine.

Єдиною формою глобальної синхронізації, як проілюстровано на малюнку вище, є реалізована в ядрі комбінування-отримання. Щойно дані надсилаються з надсилання, ранг повертається і продовжує виконання, коли отримує всі необхідні токени від інших рангів, і входить у ядра комбінування-надсилання, щойно вони будуть оброблені. Бар'єр в обміні-отриманні гарантує, що жоден ранг не зможе випередити події та розпочати диспетчеризацію-надсилання, поки будь-який інший ранг усе ще чекає на отримання даних, що потенційно може спричинити деструктивне перекриття. Синхронізація виконується в ядрі комбінування заради простоти; як оптимізацію, такий самий бар'єр можна реалізувати між диспетчеризацією-отриманням і ядрами комбінування-надсилання, що ще більше зменшить затримку, дозволивши NIC більше часу на завершення передач, поки GPU виконує інші ядра.

Обидва ядра розділені на всі доступні SM пристроїв: тоді як ядра диспетчеризації-надсилання та комбінування-отримання повинні розпаралелювати на основі максимальної кількості токенів на ранг (max_m), ядра диспетчеризації-отримання та комбінування-надсилання повинні обробляти таку кількість токенів від кожного рангу та локального експерта, що становить максимум max_m * (num_experts // EP) * (EP // TP).

Диспетчеризація

Ядро диспетчеризації відповідає за надсилання токенів і блочних коефіцієнтів масштабування вузлам-партнерам, які містять експертів, до яких були спрямовані токени. Відправна сторона спирається на спеціалізацію warp для розпаралелювання двох завдань: агрегації інформації про маршрутизацію для визначення кількості токенів, що надсилаються з кожного рангу, та упакування токенів у повідомлення для надсилання на віддалений вузел. Приймаюча сторона спочатку чекає на отримання всіх лічильників токенів, потім вона читає та розпаковує корисні дані (payloads) із спільної пам'яті в тензори, які будуть передані подальшим ядрам Grouped GEMM. Вона також зберігає інформацію в буферах, спільних з ядрами комбінування, щоб вказати, куди слід надіслати кожен токен назад. Ця інформація необхідна, оскільки приймаюче ядро перетасовує токени в безперервних буферах у недетермінованому порядку.

Відправлення токенів і сигналізація про їхнє надходження між вихідними та цільовими рангами.

У частині відправника один warp із 32 тредів на кожному блоці відповідає за читання інформації про маршрутизацію та підрахунок кількості токенів, які кожен цільовий експерт має отримати від цього рангу, надсилаючи підраховану кількість плюс один за допомогою nvshmem_signal_op. Кількість інкрементується на одиницю, оскільки перехід від нуля до ненульового значення на віддаленій стороні означає отримання підрахунків із вихідного рангу. Паралельно решта warp-ів співпрацюють, щоб скопіювати токени в симетричну пам'ять по всіх блоках паралельно, упаковуючи активації, коефіцієнти масштабування та їхній індекс на локальному ранзі у безперервний фрагмент. Індекс необхідний відправнику комбінування для визначення адреси, за якою буде записано токен. Далі, переконавшись, що всі дані були скопійовані за допомогою бар'єра для всіх груп warp, самі warp-и знову працюють незалежно, причому кожен надсилає один і той самий буфер різним експертам паралельно. Токени надсилаються за допомогою nvshmemx_putmem_signal_nbi_warp, що також атомарно збільшує кількість надісланих токенів із локального рангу на віддаленому пристрої. У межах групи DP, оскільки кожен ранг володіє реплікою токена, що надсилається, диспетчеризація збалансована рівномірно, і кожен пристрій надсилає підмножину токенів.

На стороні отримання всі ядра спочатку синхронізуються з рангами-відправниками, чекаючи на пересилання загальної кількості токенів. Після цього вони всі чекають, поки атомарно інкрементовані кількості надісланих токенів досягнуть загальних значень, що вказує на те, що всі корисні дані з вихідних рангів також були переслані, завдяки семантиці виклику putmem. Ядра опитують лічильники за допомогою nvshmem_uint64_wait_until, розпаралелюючи операцію по всіх блоках і тредах. Згодом міжблочний бар'єр гарантує, що жоден блок не читає буфери, якщо всі дані не були коректно отримані. Розподілені по блоках і синхронізовані за допомогою атомарно інкрементованого лічильника, токени копіюються з симетричної пам'яті у звичайні безперервні буфери, які стають вхідними даними для наступних ядер, що реалізують експертів. Вихідний ранг, індекс експерта та індекс токена зберігаються окремо, точно вказуючи місце розташування, куди ядро комбінування повинно надіслати активації. Попри те, що токени з групи DP надсилаються з різних пристроїв, усі вони групуються разом для передачі відповідному експерту.

Комбінування

Ядра комбінування знову розділені на половинні компоненти надсилання та отримання: відправники копіюють неквантовані 16-бітні активації на віддалені пристрої, а приймаючі ядра чекають на пересилання даних і локально обчислюють зважене середнє значення внесків усіх експертів. Крім того, вони також діють як бар'єр для синхронізації послідовності диспетчеризації та комбінування: кожен ранг встановлює прапорець на кожному партнері під час входу в ядра надсилання, причому ядрам отримання заборонено повертатися, якщо вони не бачать встановленим цей прапорець. Затримка синхронізації є мінімальною, оскільки вона перекривається з фактичним зв'язком та обчисленнями.

Об’єднання виходів експертів у токени на кожному ранзі паралелізму даних.

На стороні відправника ядра проходять список токенів, призначених усім локальним експертам паралельно, записуючи їх у буфер на цільовому ранзі. Цільовий ранг, індекс експерта та індекс токена зчитуються з буферів для кожного токена, які заповнюються ядрами розкидання (scater) після отримання токенів. Кожен відправник має власну приватну область пам'яті для кожного експерта для запису, як показано на малюнку вище, що дозволяє уникнути потреби в синхронізації. Подібно до диспетчеризації, комбінування атомарно інкрементує лічильники для кожного токена на цільовому ранзі, щоб вказати на отримання даних: коли лічильник збігається з кількістю експертів, яким був надісланий токен, можна отримати доступ до вмісту токена.

У ядрі отримання список токенів обходиться паралельно по кількох блоках, чекаючи на надходження їхнього вмісту шляхом опитування прапорця, встановленого операцією сигналізації. Після прибуття корисні дані зчитуються з приватних буферів, причому таблиця маршрутизації вказує, з якого буфера читати і яку вагу призначити кожному експерту. Потім результати записуються в зовнішньо виділені тензори, а виконання ядра завершується, коли всі пристрої проходять бар'єр. У межах групи DP усі ранги отримують копію активації кожного експерта для обчислення власних реплік.

Бенчмарки

Ми оцінюємо наші ядра на кластері з 128 GPU, розподілених по 16 вузлах, з'єднаних через InfiniBand і мережеві адаптери CX-7. Ми випробовуємо як GPUDirect Async (IBGDA), так і надійне з'єднання (RC) із проксі процесора (CPU). Ми порівнюємо їх з високооптимізованою реалізацією DeepSeek, а також з щільними примітивами, що надаються PyTorch (через NCCL) або NVSHMEM.

Затримка комунікації для 128 токенів на GPU у багатовузловій конфігурації EP128.

Хоча для операції all-to-all зі щільною пам'яттю NVSHMEM продуктивність IBRC та IBGDA є подібною (6378 мкс проти 6180 мкс), IBGDA є значно швидшою з розрідженими ядрами. Додаючи диспетчеризацію та комбінування, IBGDA використовує 902 мкс, тоді як IBRC займає 3223 мкс — покращення затримки в 3,6 раза. Хоча all-to-all обмежено пропускною здатністю, розріджені ядра транслюють на кілька порядків менше даних, будучи обмеженими затримкою. Шляхом безпосереднього ініціювання мережевих передач із графічного процесора, без необхідності використання проксі-процесора (CPU) для координації GPU та NIC, затримка від кінця до кінця (end-to-end) значно зменшується.

Хоча наші переносні ядра приблизно в 2 рази повільніші за високооптимізовані ядра DeepSeek, вони покращують затримку в 10 разів порівняно зі щільними ядрами (902 мкс проти 9944 мкс).

Крім того, поділ на компоненти відправника та отримувача також дозволяє приховати частину затримки, на відміну від примітивів бібліотеки.

Затримка комунікації для 128 токенів на GPU в одновузловій конфігурації EP8.

На одному вузлі (EP8) NVSHMEM використовує NVLINK для транспортування, забезпечуючи меншу затримку та вищу пропускну здатність, ніж міжвузлові мережі. Наші переносні ядра приблизно в 2,5 раза швидші за DeepEP на одному вузлі (186 мкс проти 481 мкс).

Подальші вдосконалення

Описані тут ядра перевершують вбудовані примітиви фреймворків ML і пропонують прийнятну продуктивність без надмірної спеціалізації для конкретних транспортних засобів між пристроями, таких як NVLink або InfiniBand. Окрім уже згаданих можливостей, подальшого приросту продуктивності можна досягти, замінивши примітиви зв'язку більш спеціалізованими версіями. Наприклад, через NVLink використання симетричної пам'яті можна замінити буферами, спільними для всіх пристроїв, що усуне деяке копіювання та дозволить застосувати схеми більш дегранульованої синхронізації — для окремих токенів замість пакетів токенів. Через InfiniBand реалізація могла б звертатися безпосередньо до базових пар черг, що усунуло б потребу передавати як очікувану, так і надіслану кількість токенів, а також очищати токени з черг у вихідні буфери в міру їх надходження. Однак такі реалізації коштують втрати переносимості, тоді як наша реалізація дозволяє оцінювати кластери з конкретними конфігураціями перед тим, як витрачати зусилля на розробку для оптимізації під певне обладнання.

Висновок

Ми представили високопродуктивну, переносну бібліотеку для зв'язку 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

Цитування

BibTeX
@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://perplexity.coolkeypoint.com/hub/blog/efficient-and-portable-mixture-of-experts-communication}
}