Comunicació eficient i portàtil de mescla d'experts

Presentem una biblioteca d'alt rendiment, portàtil i de codi obert per a la comunicació de Mescla d'Experts (MoE) que aconsegueix un rendiment 10 vegades més ràpid en comparació amb les primitives de comunicació estàndard All-to-All.

La nostra implementació inclou diverses innovacions tècniques clau que ofereixen una eficiència superior en la comunicació MoE:

Comunicació iniciada per GPU (IBGDA): Admet comunicació directa de GPU a NIC, reduint significativament la latència en evitar la intervenció de la CPU

Superposició de comunicació i còmput: L'arquitectura de kernel dividit amb etapes d'enviament i recepció separades permet que el còmput es processi simultàniament amb les transferències de xarxa

El millor rendiment en un sol node: Una latència 2,5 vegades inferior a la de la implementació més ràpida anterior en configuracions d'un sol node

Rendiment multinode eficient i portàtil: La nostra implementació aconsegueix velocitats fins a 10 vegades més ràpides que la comunicació all-to-all estàndard. Tot i ser aproximadament 2 vegades més lenta que les implementacions altament especialitzades, el nostre enfocament ofereix una millor portabilitat entre versions de NVSHMEM i entorns de xarxa (NVLink, CX-7 i EFA)

La biblioteca és de codi obert i està disponible a https://github.com/ppl-ai/pplx-kernels.

En aquest article, explorem els reptes del paral·lelisme d'experts en models MoE a gran escala i descrivim el nostre enfocament per a l'enviament i la combinació eficients de testimonis (tokens) en entorns de GPU distribuïts.

Introducció

Els models de Mescla d'Experts (MoE), com ara DeepSeek R1 i Mixtral 8x7B, milloren els models densos limitant el nombre de pesos que s'activen per a cada testimoni (token). En lloc d'aconseguir recomptes elevats de paràmetres augmentant el nombre de capes o la mida de les capes lineals al Perceptró Multicapa (MLP) de cada capa de descodificació, els models MoE substitueixen el MLP tradicional per múltiples experts i un encaminador. Per exemple, dels 671.000 milions de paràmetres de DeepSeek R1, només 37.000 milions es multipliquen amb un testimoni determinat durant la inferència. Això redueix considerablement la quantitat de còmput necessària per descodificar un testimoni i millora la latència en comparació amb un model dens.

Els models MoE presenten alguns reptes addicionals per a la inferència en comparació amb els models densos. Tot i que els experts en si són petites capes MLP, cada capa de descodificació inclou un encaminador que decideix a quins experts s'envia un testimoni, i cada testimoni s'envia a múltiples experts. L'encaminador sol ser una petita capa lineal que produeix una distribució de probabilitat. Normalment es trien els experts amb les puntuacions top-K i l'activació final es calcula com una mitjana ponderada, sumant les sortides dels experts multiplicades per un pes derivat de la distribució de probabilitat de l'encaminador.

Per minimitzar la latència en sistemes MoE distribuïts, es pot aprofitar el paral·lelisme entre múltiples dispositius, però això introdueix reptes de comunicació. Models com Mixtral 8x7B o Llama-70B caben dins de 8 dispositius en un sol node, beneficiant-se de connexions NVLink ràpides i de baixa latència (fins a 900 Gbps). No obstant això, els models més grans requereixen fragmentar (sharding) els experts en múltiples nodes utilitzant InfiniBand (amb un pic de 400 Gbps), la qual cosa introdueix reptes addicionals de latència.

Amplia

En aquest article, explorem el problema del paral·lelisme d'experts, descrivint la nostra implementació de kernels de GPU que envien eficientment testimonis als dispositius que allotgen els experts assignats i els recullen calculant la suma ponderada de les sortides dels experts. Tot i que existeixen implementacions agressivament optimitzades per a maquinari de xarxa específic, presentem una implementació altament portàtil que es basa en un conjunt mínim de primitives NVSHMEM i ofereix un rendiment 10 vegades més ràpid que la comunicació all-to-all estàndard. La nostra implementació aconsegueix un rendiment capdavanter en configuracions d'un sol node mentre manté una excel·lent portabilitat en diversos entorns de xarxa.

Fragmentació i paral·lelisme

Per a una inferència eficient, els pesos d'un model s'han de mantenir a la memòria del dispositiu, deixant també prou espai per a les activacions, les memòries cau KV i altres memòries intermèdies (buffers) necessàries per a la passada cap endavant (forward pass) a través del model. Els models més capaços superen la capacitat fins i tot de les GPU més potents, de manera que la inferència s'ha de repartir entre múltiples dispositius, que poden emmagatzemar col·lectivament els pesos del model. Segons els esquemes de fragmentació dels pesos, s'han d'utilitzar diferents esquemes de comunicació i còmput per descarregar el còmput i sincronitzar els dispositius.

Amplia

El paral·lelisme d'experts (EP), il·lustrat a la primera figura, només paral·lelitza el còmput dels experts. S'assignen diferents experts a diferents dispositius, que contenen els seus pesos. Després de l'encaminament, els testimonis s'envien al dispositiu corresponent, i els resultats es recullen i s'acumulen posteriorment. La complexitat de l'encaminament depèn del grau de paral·lelisme a les altres parts del model: replicar altres capes podria eliminar completament la necessitat d'encaminament, ja que cada rang pot seleccionar els testimonis d'una taula d'encaminament replicada localment. No obstant això, si només un dels rangs executa l'encaminament, cal una difusió (broadcast) per enviar els testimonis, els índexs i els pesos als seus respectius experts. Finalment, un all-gather o una difusió all-to-all sincronitza els testimonis de sortida amb qualsevol rang que continuï l'execució del model. Aquesta implementació és relativament senzilla, ja que PyTorch ja exposa les primitives necessàries, tot i que es podrien obtenir alguns beneficis fusionant l'acumulació amb l'operació gather que recull els testimonis dels experts.

Amplia

El paral·lelisme basat només en experts no escala de manera ideal, ja que els nodes d'un clúster poden estar ociosos mentre el model executa capes que no són d'experts, com ara l'atenció, la normalització i el mostreig. No obstant això, el còmput d'aquestes capes, principalment l'atenció, també es pot beneficiar del paral·lelisme de tensors (TP). La majoria dels models es basen en l'atenció multi-capçalera (multi-head attention), la qual cosa significa que les capçaleres d'atenció i les seves projeccions Q, K i V corresponents també es poden fragmentar entre dispositius, replicant o recollint les porcions entre diverses capes. Si l'atenció es reparteix entre tots els dispositius, un all-gather pot sincronitzar les activacions, permetent que l'encaminament es repliqui i requerint primitives de sincronització similars al cas del paral·lelisme d'experts per a una implementació eficient. No obstant això, hi ha límits al paral·lelisme en aquest nivell, ja que reduir el nombre de capçaleres d'atenció per sota d'un determinat llindar produirà rendiments decreixents.

Amplia

Per utilitzar al màxim tots els dispositius i suportar un grau molt elevat de paral·lelisme d'experts, de fins a 128 o 256 GPU, cal el paral·lelisme de dades (DP). Sota aquest esquema, els dispositius entre els quals es divideix un model s'agrupen per gestionar les sol·licituds de manera concurrent, calculant l'atenció i mantenint memòries cau KV fragmentades al llarg del seu grup local. Múltiples instàncies d'aquests grups paral·lels col·laboren en l'avaluació d'experts, i cadascuna allotja un subconjunt diferent dels pesos dels experts. Segons el nombre de capçaleres d'atenció, un grup normalment pot abastar fins a la mida d'un node sencer, ja que la comunicació intranode és més ràpida. Per exemple, a la figura anterior, un rang DP serveix de manera independent dues sol·licituds, A i B, gestionant l'atenció, la normalització i qualsevol altra comptabilitat per a les sol·licituds. L'altre rang DP processa una sol·licitud C diferent. No obstant això, el primer node allotja la meitat dels experts, mentre que l'altre node l'altra meitat; per tant, després de l'encaminament, els testimonis de A i B es poden enviar al segon node i viceversa. Això condueix a un problema de comunicació dispersa (sparse): cada dispositiu pot enviar un nombre diferent de testimonis a qualsevol altre rang de destinació. Les primitives existents de PyTorch, principalment all_to_all, no són especialment adequades, ja que poden requerir alguna forma de farciment (padding) o sincronització de GPU a CPU i difusió de metadades. Per implementar la comunicació de manera eficaç, es requereixen kernels personalitzats per processar la informació d'encaminament i iniciar la comunicació des dels dispositius sense la intervenció de la CPU. Després de l'encaminament, un kernel d'enviament (dispatch) ha d'enviar testimonis als rangs als quals s'han encaminat, mentre que a la banda de combinació s'han de recollir les activacions pertanyents a les sol·licituds del grup DP actual. A més, cal equilibrar el treball dins d'un grup DP que pot tenir múltiples dispositius, per tal de minimitzar la difusió i replicar correctament els testimonis en tots els rangs per a les capes posteriors.

NVSHMEM

NVSHMEM és una implementació d'OpenSHMEM específica d'NVIDIA, que proporciona facilitats de comunicació portàtils entre dispositius que abstracten la complexitat del maquinari subjacent. L'API pot expressar lectures i escriptures de dispositiu a dispositiu, que es mapegen a les primitives de les capes de transport individuals. S'admeten tant NVLink com RDMA, la qual cosa atorga un grau de portabilitat i permet que els kernels de NVSHMEM operin dins d'un node o a través d'un clúster de múltiples nodes. Als nostres kernels, utilitzem escriptures de memòria remota i operacions de senyalització per transferir dades i sincronitzar els dispositius participants.

Les operacions de NVSHMEM es basen en el concepte de memòria simètrica: operen sobre memòries intermèdies (buffers) que s'han assignat a tots els dispositius que participen en la comunicació entre dispositius. Un dispositiu local pot utilitzar una adreça derivada dins del seu propi buffer local juntament amb l'índex del rang de destinació per especificar la destinació d'una operació. La figura següent il·lustra aquest concepte: ambdues GPU assignen buffers simètrics de la mateixa mida, retinguent punters src cap a ells. El primer rang vol enviar 3 nombres enters al segon, col·locant-los a l'inici del buffer: nvshmem_int_put_nbi deriva l'adreça d'inici a partir del buffer local, especificant el dispositiu de destinació. El segon rang deriva un desplaçament (offset) del seu propi buffer, enviant un element al primer dispositiu, desplaçant-se un. Tot i que les adreces de destinació han de ser sempre buffers simètrics assignats mitjançant nvshmem_alloc, els buffers d'origen poden ser regions arbitràries de la memòria del dispositiu, sempre que estiguin prèviament registrats amb NVSHMEM.

Tot i que NVSHMEM ofereix una àmplia gamma de primitives, els nostres kernels es basen en només 3 funcions, construint tota la sincronització i protecció (fencing) sobre elles.

Amplia

nvshmemx_putmem_signal_nbi_warp: Transfereix un bloc de dades d'un dispositiu a un altre, alhora que estableix un senyalador (flag) al dispositiu remot. L'operació estableix (NVSHMEM_SIGNAL_SET) o incrementa (NVSHMEM_SIGNAL_ADD) una ubicació de 64 bits. El senyalador s'actualitza després de transferir tot el bloc de memòria. Si el dispositiu remot observa un canvi en el senyalador, pot accedir amb seguretat al buffer de la seva pròpia memòria. Aquesta funció és útil per combinar la transferència de dades i la sincronització.

nvshmemx_signal_op opera sobre una sola ubicació de memòria, normalment un senyalador de 64 bits, establint-lo o incrementant-lo de manera atòmica. És útil per enviar metadades i sincronitzar dispositius.

nvshmem_uint64_wait_until s'utilitza al costat receptor d'un senyal, per sondejar (poll) un senyalador fins que el remot l'actualitzi.

Garantir qualsevol forma d'ordenació entre operacions mitjançant nvshmem_quiet o nvshmem_fence és costós, per la qual cosa la nostra implementació dels kernels evita l'ús de qualsevol altra primitiva de NVSHMEM i minimitza qualsevol dependència que no sigui parells individuals d'enviament-recepció. En enviar dades, sempre utilitzem la versió no bloquejant de les funcions, sense esperar que les dades ni tan sols s'enviïn fora del rang local. Altra sincronització implícita a través del grup de kernels assegura que aquests buffers no es sobrescriguin de manera destructiva mentre les targetes de xarxa (NIC) necessiten accés a ells.

NVSHMEM utilitza GPUDirect RDMA perquè la NIC pugui llegir i escriure directament a la memòria de la GPU per a l'intercanvi de dades sense implicar les CPU. A més, a les NIC ConnectX, NVSHEMEM admet la comunicació iniciada per GPU (també coneguda com a InfiniBand GPUDirect Async, o IBGDA), la qual cosa permet que la GPU publiqui operacions RDMA directament a la NIC i consulti directament la cua de finalització de la NIC. A les plataformes que no admeten la comunicació iniciada per GPU, NVSHMEM genera un fil («proxy» thread) a la CPU amfitriona per iniciar la comunicació i consultar la finalització en nom de la GPU. El programa NVSHMEM és portàtil independentment de si s'admet la comunicació iniciada per GPU o no. No entanto, la comunicació iniciada per GPU redueix significativament la latència perquè passa completament per alt el desviament cap a la CPU.

Kernels portàtils

Implementem la comunicació MoE mitjançant un parell de kernels d'enviament i combinació. Els kernels d'enviament s'encarreguen de llegir els testimonis i la informació d'encaminament a cada rang, enviant-los als experts adequats. Els kernels de combinació recullen les activacions produïdes pels experts i les envien de tornada als seus rangs d'origen, alhora que calculen la mitjana ponderada dels experts seleccionats a partir dels pesos calculats per l'encaminador. Els kernels es divideixen encara més en un component d'enviament i un altre de recepció, per tal de permetre que les transferències de dades se superposin amb el còmput. Els kernels d'enviament no són bloquejants ni sincronitzadors: simplement envien totes les escriptures als remots. A l'altre extrem, els kernels de combinació només llegeixen de la memòria, esperant fins que s'hagin transferit totes les dades necessàries. Després d'enviar el treball a les NIC, mentre les dades es transfereixen de manera asíncrona per la xarxa, les GPU poden fer un altre treball útil localment, com ara aplicar experts compartits o calcular l'atenció.

Cada parell de kernels té els seus propis buffers de memòria simètrica, i cada rang assigna emmagatzematge privat per rebre dades de tots els altres rangs. El nombre màxim de testimonis que es poden enviar des d'un grup DP és fix en tots els rangs, la qual cosa també estableix el límit superior que cada rang pot rebre per a cada expert local de cada rang d'enviament DP. Això permet que els rangs emissors deriven una adreça única al rang de destinació a la qual escriure, sense requerir cap sincronització entre ells. Unes hores després de rebre les dades, els kernels reorganitzen els testimonis per disposar-los a la memòria en el format òptim requerit pels kernels receptors. Tot i que els buffers tenen una dimensió considerable, es reutilitzen en totes les capes seqüencials d'un model.

Amplia

L'única forma de sincronització global, tal com s'il·lustra a la figura anterior, s'implementa al kernel de combinació-recepció. Un cop s'envien les dades des de l'enviament, un rang torna i continua l'execució quan rep tots els testimonis que necessita dels altres rangs i entra als kernels de combinació-enviament tan bon punt es processen. La barrera a la combinació-recepció garanteix que cap rang pugui avançar-se i iniciar l'enviament-enviament mentre qualsevol altre rang encara està esperant per rebre dades, la qual cosa podria causar una superposició destructiva. La sincronització es fa al kernel de combinació per simplicitat; com a optimització, es podria implementar la mateixa barrera entre els kernels de recepció-enviament i d'enviament-combinació, reduint encara més la latència en permetre a les NIC més temps per establir les transferències mentre la GPU executa altres kernels.

Ambdós kernels es divideixen entre tots els SM disponibles dels dispositius: mentre que els kernels d'enviament-enviament i recepció-combinació s'han de paral·lelitzar segons un recompte màxim de testimonis per rang (max_m), els kernels de recepció-enviament i enviament-combinació han de gestionar aquest nombre de testimonis de cada rang i expert local, per a un màxim de max_m * (num_experts // EP) * (EP // TP).

Enviament (Dispatch)

El kernel d'enviament s'encarregava d'enviar testimonis i factors d'escalat de blocs als iguals (peers) que allotgen els experts als quals s'han encaminat els testimonis. El costat emissor es basa en l'especialització de warp per paral·lelitzar dues tasques: agregar la informació d'encaminament per determinar quants testimonis s'envien des de cada rang i empaquetar els testimonis en missatges que s'enviaran al remot. El costat receptor primer espera que es rebin tots els recomptes de testimonis, després llegeix i desempaqueix les càrregues útils (payloads) de la memòria compartida als tensors que es passaran als kernels Grouped GEMM aigües avall. També emmagatzema informació en buffers compartits amb els kernels de combinació, per indicar on s'ha de retornar cada testimoni. Aquesta informació és necessària ja que el kernel de recepció reorganitza els testimonis en buffers contigus en un ordre no determinista.

Amplia

A la part emissora, un únic warp de 32 fils a cada bloc s'encarrega de llegir la informació d'encaminament i comptar el nombre de testimonis que s'espera que cada expert de destinació rebi d'aquest rang, enviant el recompte més un mitjançant nvshmem_signal_op. El recompte s'incrementa en un, ja que la transició de zero a no zero a l'extrem remot significa la recepció dels recomptes d'un rang d'origen. En paral·lel, els warps restants cooperen per copiar testimonis a la memòria simètrica a través de tots els blocs en paral·lel, empaquetant activacions, factors d'escalat i el seu índex al rang local en un tros contigu. L'índex és requerit pel remitent de combinació per determinar l'adreça on s'escriurà el testimoni. A continuació, després d'assegurar-se que totes les dades s'han copiat mitjançant una barrera a través dels grups de warp, els warps tornen a operar de manera independent, cadascun enviant el mateix buffer a un expert diferent en paral·lel. Els testimonis s'envien mitjançant nvshmemx_putmem_signal_nbi_warp, que també augmenta de manera atòmica el recompte de testimonis enviats des del rang local al dispositiu remot. Dins d'un grup DP, atès que cada rang posseeix una rèplica del testimoni que s'enviarà, l'enviament s'equilibra uniformement, i cada dispositiu envia un subconjunt dels testimonis.

A la banda de recepció, tots els kernels primer se sincronitzen amb els rangs emissors esperant que s'enviïn els recomptes totals de testimonis. Després, tots esperen que els recomptes de testimonis enviats incrementats de manera atònica s'estableixin als recomptes totals, indicant que totes les càrregues útils dels rangs d'origen també s'han enviat, gràcies a la semàntica de la crida putmem. Els kernels sondejant els recomptes utilitzant nvshmem_uint64_wait_until, paral·lelitzant l'operació a través de tots els blocs i fils. Posteriorment, una barrera entre blocs garanteix que cap bloc llegeixi els buffers tret que totes les dades s'hagin rebut correctament. Distribuïts entre blocs i sincronitzats mitjançant un comptador incrementat de manera atòmica, els testimonis es copien de la memòria simètrica a buffers contigus normals que es converteixen en les entrades dels kernels aigües avall que implementen els experts. El rang d'origen, l'índex de l'expert i l'índex del testimoni s'emmagatzemen per separat, assenyalant exactament la ubicació on el kernel de combinació ha d'enviar les activacions. Tot i que els testimonis d'un grup DP s'envien des de diferents dispositius, s'agrupen tots per ser passats a l'expert corresponent.

Combinació (Combine)

Els kernels de combinació es divideixen de nou en meitats d'enviament i recepció: els emissors kopien les activacions de 16 bits no quantificades als dispositius remots, i els kernels de recepció esperen que s'enviïn les dades i calculen localment la mitjana ponderada de totes les contribucions dels experts. A més, també actuen com a barrera per sincronitzar la seqüència d'enviament-combinació: cada rang estableix un senyalador en cada igual en entrar als kernels d'enviament, i no es permet que els kernels de recepció retornin a menys que observeu que el senyalador està establert. La latència de la sincronització és mínima, ja que se superposa amb la comunicació i el còmput reals.

Amplia

Pel costat emissor, els kernels recorren la llista de testimonis assignats a tots els experts locals en paral·lel, escrivint-los en un buffer del rang de destinació. El rang de destinació, l'índex de l'expert i l'índex del testimoni es llegeixen dels buffers per testimoni poblats pels kernels de dispersió (scatter) en rebre els testimonis. Cada emissor té la seva pròpia regió de memòria privada per expert a la qual escriure, tal com s'indica a la figura anterior, evitant la necessitat de sincronització. De manera similar a l'enviament, la combinació incrementa de manera atòmica els comptadors per testimoni al rang de destinació per indicar la recepció de les dades: quan el comptador coincideix amb el nombre d'experts als quals s'ha enviat un testimoni, es pot accedir al contingut del testimoni.

Al kernel de recepció, la llista de testimonis es recorre en paral·lel a través de múltiples blocs, esperant que arribi el seu contingut mitjançant el sondeig del senyalador establert per l'operació de senyalització. En arribar, les càrregues útils es llegeixen dels buffers privats, amb la taula d'encaminament indicant de quin buffer llegir i quin pes assignar a cada expert. Els resultats s'escriuen llavors a tensors assignats externament, i el kernel finalitza l'execució un cop tots els dispositius superen la barrera. A través d'un grup DP, tots els rangs reben una còpia de cada activació d'expert per calcular les seves pròpies rèpliques.

Comparatives (Benchmarks)

Avaluem els nostres kernels en un clúster de 128 GPU repartides en 16 nodes connectats mitjançant InfiniBand i targetes de xarxa CX-7. Provem tant GPUDirect Async (IBGDA) com Reliable Connection (RC) amb un proxy de CPU. Les comparem amb la implementació altament optimitzada de DeepSeek, així com amb les primitives denses proporcionades per PyTorch (mitjançant NCCL) o NVSHMEM.

Amplia

Tot i que en l'operació all-to-all densa de NVSHMEM el rendiment d'IBRC i IBGDA és similar (6378 µs vs 6180 µs), IBGDA és significativament més ràpid amb els kernels dispersos. Sumant l'enviament i la combinació, IBGDA utilitza 902 µs mentre que IBRC triga 3223 µs, la qual cosa suposa una millora de 3,6x en la latència. Tot i que all-to-all està limitat per l'amplada de banda, els kernels dispersos difonen ordres de magnitud menys dades, estant limitats per la latència. En activar les transferències de xarxa directament des d'una GPU, sense necessitat d'un proxy de CPU per coordinar la GPU i la NIC, la latència d'extrem a extrem es redueix significativament.

Tot i que els nostres kernels portàtils són aproximadament 2 vegades més lents que els kernels altament optimitzats de DeepSeek, milloren la latència 10 vegades en comparació amb els kernels densos (902 µs vs 9944 µs).

A més, la divisió en components d'emissió-recepció també permet amagar una part de la latència, a diferència de les primitives de la biblioteca.

Amplia

En un sol node (EP8), NVSHMEM utilitza NVLINK per al transport, oferint una latència inferior i un rendiment superior a la xarxa entre nodes. Els nostres kernels portàtils són aproximadament 2,5 vegades més ràpids que DeepEP en un sol node (186 µs vs 481 µs).

Millors posteriors

Els kernels descrits aquí superen les primitives integrades dels marcadors (frameworks) d'IA i ofereixen un rendiment decent sense sobreespecialitzar-se per a transports particulars entre dispositius, com ara NVLink o InfiniBand. A més de les oportunitats ja esmentades, es poden aconseguir guanys addicionals de rendiment substituint les primitives de comunicació per versions més especialitzades. Per exemple, a través de NVLink, l'ús de memòria simètrica es podria substituir per buffers compartits entre els dispositius, eliminant algunes còpies i permetent esquemes de sincronització de graella més fina, a través de testimonis individuals en lloc de lots de testimonis. A través d'InfiniBand, una implementació podria accedir directament als parells de cues subjacents, eliminant la necessitat de transferir tant els recomptes de testimonis esperats com els enviats i buidant els testimonis de les cues als buffers de sortida a mesura que arriben. No entanto, aquestes implementacions tenen el cost de la portabilitat, mentre que la nostra implementació permet avaluar clústers amb configuracions específiques abans de comprometre esforç de desenvolupament per optimitzar per a un maquinari particular.

Conclusió

Hem presentat una biblioteca d'alt rendiment i portàtil per a la comunicació MoE que aconsegueix un rendiment 10 vegades més ràpid en comparació amb la comunicació estàndard all-to-all, mantenint la compatibilitat entre diverses configuracions de maquinari. En desplegaments d'un sol node amb NVLink, la nostra solució demostra una latència 2,5 vegades inferior a la de les implementacions anteriors.

El nostre enfocament equilibra el rendiment amb la portabilitat mitjançant innovacions clau que inclouen el suport per a la comunicació iniciada per GPU, una arquitectura de kernel dividit que permet la superposició de còmput i comunicació, i l'enviament eficient de testimonis utilitzant primitives NVSHMEM mínimes. Tot i ser aproximadament 2 vegades més lenta que les implementacions altament especialitzades en configuracions multinode, la nostra biblioteca ofereix una flexibilitat superior en diversos entorns de xarxa (NVLink, CX-7 i EFA).

A mesura que els models MoE continuïn escalant, les estratègies de comunicació eficients com la nostra guanyaran una importància creixent per al desplegament pràctic. La nostra implementació de codi obert està disponible a https://github.com/ppl-ai/pplx-kernels.

Referències

DeepEP

Informe tècnic de DeepSeek-V3

NVIDIA NVSHMEM

Citació

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