Comunicación eficiente e portátil de mixture-of-experts

Presentamos unha biblioteca de alto rendemento, portátil e de código aberto para a comunicación de Mixture-of-Experts (MoE) que logra un rendemento 10 veces máis rápido en comparación coas primitivas de comunicación estándar All-to-All.

A nosa implementación presenta varias innovacións técnicas clave que ofrecen unha eficiencia superior na comunicación MoE:

Comunicación iniciada por GPU (IBGDA): Admite comunicación directa de GPU a NIC, o que reduce significativamente a latencia ao omitir a implicación da CPU

Superposición de comunicación e cálculo: A arquitectura de kernel dividida con etapas separadas de envío e recepción permite que o cálculo continúe concorrentemente coas transferencias de rede

O rendemento dun só nodo máis rápido: Unha latencia 2,5 veces menor que a implementación máis rápida anterior en configuracións dun só nodo

Rendemento multinodo eficiente e portátil: A nosa implementación alcanza velocidades ata 10 veces máis rápidas que a comunicación estándar all-to-all. Aínda que é aproximadamente 2 veces máis lenta que as implementacións moi especializadas, o noso enfoque ofrece unha mellor portabilidade entre versións de NVSHMEM e contornos de rede (NVLink, CX-7 e EFA)

A biblioteca é totalmente de código aberto e está dispoñible en https://github.com/ppl-ai/pplx-kernels.

Neste artigo, exploramos os desafíos do paralelismo de expertos en modelos MoE a gran escala e describimos o noso enfoque para a asignación e combinación eficiente de tokens en contornos de GPU distribuidos.

Introdución

Os modelos Mixture-of-Experts (MoE), como DeepSeek R1 e Mixtral 8x7B, melloran os modelos densos ao limitar o número de pesos que se activan para cada token. En lugar de acadar recuentos elevados de parámetros aumentando o número de capas ou o tamaño das capas lineais no Perceptrón Multicapa (MLP) de cada capa de descodificador, os modelos MoE substitúen o MLP tradicional por múltiples expertos e un enrutador. Por exemplo, dos 671B parámetros de DeepSeek R1, só 37B se multiplican por un token dado durante a inferencia. Isto reduce en gran medida a cantidade de cálculo necesaria para descodificar un token e mellora a latencia en comparación cun modelo denso.

Os modelos MoE presentan algúns desafíos adicionais para a inferencia en comparación cos modelos densos. Aínda que os propios expertos son pequenas capas MLP, cada capa de descodificador inclúe un enrutador que decide a que expertos se envía un token, enviándose cada token a múltiples expertos. O enrutador é normalmente unha pequena capa lineal que produce unha distribución de probabilidade. Habitualmente escóllense os expertos coas puntuacións top-K e a activación final calcúlase como unha media ponderada, sumando as saídas dos expertos multiplicadas por un peso derivado da distribución de probabilidade do enrutador.

Para minimizar a latencia en sistemas MoE distribuidos, o paralelismo pódese aproveitar en múltiples dispositivos, pero isto introduce desafíos de comunicación. Modelos como Mixtral 8x7B ou Llama-70B caben en 8 dispositivos nun único nodo, beneficiándose de interconexións NVLink rápidas e de baixa latencia (ata 900 Gbps). Non obstante, os modelos máis grandes requiren fragmentar expertos en varios nodos usando InfiniBand (cun pico de 400 Gbps), o que introduce desafíos adicionais de latencia.

Ampliar

Neste artigo, exploramos o problema do paralelismo de expertos, desfrutando da nosa implementación de kernels de GPU que envían eficazmente tokens aos dispositivos que conteñen os expertos asignados e os recollen calculando a suma ponderada das saídas dos expertos. Aínda que existen implementacións agresivamente optimizadas orientadas a hardware de rede específico, presentamos unha implementación altamente portátil que depende dun conxunto mínimo de primitivas NVSHMEM e que, con todo, ofrece un rendemento 10 veces máis rápido que a comunicación estándar all-to-all. A nosa implementación alcanza un rendemento de última xeración en configuracións dun só nodo mentres mantén unha excelente portabilidade en varios contornos de rede.

Fragmentación e paralelismo

Para unha inferencia eficiente, os pesos dun modelo deben manterse na memoria do dispositivo, deixando tamén espazo suficiente para activacións, cachés KV e outros búferes requiridos pola pasada cara adiante a través do modelo. Os modelos máis capaces superan a capacidade incluso das GPUs máis potentes, polo que a inferencia debe distribuírse entre múltiples dispositivos, que poden almacenar colectivamente os pesos do modelo. Dependendo dos esquemas de fragmentación dos pesos, débense utilizar diferentes esquemas de comunicación e cálculo para descargar o cálculo e sincronizar os dispositivos.

Ampliar

O paralelismo de expertos (EP), ilustrado na primeira figura, só paraleliza o cálculo dos expertos. Asignanse diferentes expertos a distintos dispositivos, que conteñen os seus pesos. Despois do enrutamento, os tokens envíanse ao dispositivo correspondente e os resultados recóllense e acumúlanse despois. A complexidade do enrutamento depende do grao de paralelismo nas outras partes do modelo: a replicación doutras capas podería eliminar por completo a necesidade de enrutamento, xa que cada rango pode seleccionar os tokens dunha táboa de enrutamento replicada localmente. Non obstante, se só un dos rangos executa o enrutamento, requírese unha difusión para enviar tokens, índices e pesos aos seus respectivos expertos. Finalmente, unha recollida global (all-gather) ou unha difusión all-to-all sincroniza os tokens de saída co rango que continúe a execución do modelo. Tal implementación é relativamente sinxela xa que torch xa expón as primitivas necesarias, aínda que se poderían obter algúns beneficios fusionando a acumulación coa operación de recollida que recolle os tokens dos expertos.

Ampliar

O paralelismo exclusivo de expertos non se escala de maneira ideal, xa que os nós dun clúster poden estar inactivos mentres o modelo executa capas non expertas, como atención, norma e mostraxe. Non obstante, o cálculo destas capas, principalmente a atención, tamén pode beneficiarse do paralelismo de tensores (TP). A maioría dos modelos baséanse na atención multi-head, o que significa que as cabezas de atención e as súas proyecións Q, K e V correspondentes tamén se poden fragmentar entre dispositivos, replicando ou recollendo os cortes entre varias capas. Se a atención se distribúe por todos os dispositivos, unha recollida global pode sincronizar as activacións, permitindo que o enrutamento sexa replicado, o que require primitivas de sincronización similares ao caso do paralelismo de expertos para unha implementación eficiente. Non obstante, hai límites para o paralelismo a este nivel, xa que reducir o número de cabezas de atención por debaixo dun determinado limiar producirá rendementos decrecentes.

Ampliar

Para utilizar mellor todos os dispositivos e admitir un grao moi alto de paralelismo de expertos, de ata 128 ou 256 GPUs, requírese paralelismo de datos (DP). Baixo este esquema, os dispositivos nos que se divide un modelo agrúpanse para xestionar solicitudes de forma concorrente, calculando a atención e mantendo cachés KV fragmentados no seu grupo local. Múltiples instancias destes grupos paralelos colaboran na avaliación de expertos, cada unha aloxando un subconxunto diferente dos pesos dos expertos. Dependendo do número de cabezas de atención, un grupo pode abarcar normalmente ata o tamaño dun nodo enteiro, xa que a comunicación intra-nodo é máis rápida. Por exemplo, na figura anterior, un rango DP atende de forma independente dúas solicitudes, A e B, xestionando a atención, a norma e calquera outra contabilidade das solicitudes. O outro rango DP procesa unha solicitude distinta C. Non obstante, o primeiro nodo alberga a metade dos expertos, mentres que o outro nodo a outra metade, polo que despois do enrutamento os tokens de A e B poden ser enviados ao segundo nodo e viceversa. Isto leva a un problema de comunicación dispersa: cada dispositivo pode enviar un número diferente de tokens a calquera outro rango de destino. As primitivas existentes de torch, principalmente all_to_all, non son particularmente axeitadas, xa que poden requirir algunha forma de recheo (padding) ou sincronización de GPU a CPU e difusión de metadatos. Para implementar a comunicación de forma eficaz, requírense kernels personalizados para procesar a información de enrutamento e iniciar a comunicación desde os dispositivos sen intervención da CPU. Despois do enrutamento, un kernel de envío (dispatch) debe enviar tokens aos rangos aos que foron enrutados, mentres que no lado de combinación débense recoller as activacións pertencentes ás solicitudes do grupo DP actual. Ademais, o traballo debe equilibrarse dentro dun grupo DP que pode ter múltiples dispositivos, co fin de minimizar a difusión e replicar correctamente os tokens en todos os rangos para as seguintes capas.

NVSHMEM

NVSHMEM é unha implementación de OpenSHMEM específica de NVIDIA que ofrece facilidades de comunicación portátiles entre dispositivos que abstraen a complexidade do hardware subxacente. A API pode expresar lecturas e escrituras de dispositivo a dispositivo, que se mapean ás primitivas de capas de transporte individuais. Admítense tanto NVLink como RDMA, o que concede un grao de portabilidade e permite que os kernels NVSHMEM operen dentro dun nodo ou a través dun clúster de varios nós. nos nosos kernels, usamos escrituras de memoria remota e operacións de sinalización para transferir datos e sincronizar os dispositivos participantes.

As operacións de NVSHMEM están construídas arredor do concepto de memoria simétrica: operan en búferes que foron asignados en todos os dispositivos que participan na comunicación entre dispositivos. Un dispositivo local pode usar un enderezo derivado dentro do seu propio búfer local xunto co índice do rango de destino para especificar o destino dunha operación. A figura seguinte ilustra este concepto: ambas as GPUs asignan búferes simétricos do mesmo tamaño, conservando punteiros src para eles. O primeiro rango quere enviar 3 enteiros ao segundo, colocándoos no inicio do búfer: nvshmem_int_put_nbi deriva o enderezo de inicio do búfer local, especificando o dispositivo de destino. O segundo rango deriva un desprazamento do seu propio búfer, enviando un elemento ao primeiro dispositivo, desprazando un. Aínda que os enderezos de destino deben ser sempre búferes simétricos asignados usando nvshmem_alloc, os búferes de orixe poden ser rexións arbritarias da memoria do dispositivo, sempre que estean pre-rexistrados con NVSHMEM.

Aínda que NVSHMEM ofrece unha ampla gama de primitivas, os nosos kernels dependen de só 3 funcións, construíndo toda a sincronización e delimitación sobre elas.

Ampliar

nvshmemx_putmem_signal_nbi_warp: Transfire un bloque de datos dun dispositivo a outro, á vez que establece un indicador no dispositivo remoto. A operación establece (NVSHMEM_SIGNAL_SET) ou incrementa (NVSHMEM_SIGNAL_ADD) unha localización de 64 bits. O indicador actualízase despois de que se transfira todo o bloque de memoria. Se o dispositivo remoto observa un cambio no indicador, pode acceder de forma segura ao búfer na súa propia memoria. Esta función é útil para fusionar a transferencia de datos e a sincronización.

nvshmemx_signal_op opera nunha única localización de memoria, normalmente un indicador de 64 bits, establecéndoo ou incrementándoo de forma atómica. É útil para enviar metadatos e sincronizar dispositivos.

nvshmem_uint64_wait_until utilízase no extremo receptor dun sinal para sondar un indicador ata que o remoto o actualice.

Garantir calquera forma de ordenación entre operacións a través de nvshmem_quiet ou nvshmem_fence é custoso, polo que a nosa implementación dos kernels evita o uso de calquera outra primitiva NVSHMEM e minimiza calquera dependencia distinta de pares individuais de envío e recepción. Ao enviar datos, sempre usamos a versión non bloqueante das funcións, sen esperar a que os datos sequera sexan enviados fóra do rango local. Outra sincronización implícita en todo o grupo de kernels garante que estes búferes non se sobrescriban destrutivamente mentres as NIC necesitan acceso a eles.

NVSHMEM usa GPUDirect RDMA para que a NIC poida ler e escribir directamente na memoria da GPU para o intercambio de datos sen implicar as CPUs. Ademais, nas NIC ConnectX, NVSHMEM admite a comunicación iniciada por GPU (tamén coñecida como InfiniBand GPUDirect Async, ou IBGDA), o que permite que a GPU envíe operacións RDMA directamente á NIC e sonde a cola de finalización da NIC directamente. En plataformas que non admiten a comunicación iniciada por GPU, NVSHMEM xera un fío "proxy" na CPU host para iniciar a comunicación e sondar a finalización en nome da GPU. O programa NVSHMEM é portátil independentemente de se se admite ou non a comunicación iniciada por GPU. Non obstante, a comunicación iniciada por GPU reduce significativamente a latencia porque omite por completo o rodeo cara á CPU.

Kernels portátiles

Implementamos a comunicación MoE a través dun par de kernels de envío (dispatch) e combinación (combine). Os kernels de envío encárganse de ler tokens e información de enrutamento en cada rango, enviándoos aos expertos axeitados. Os kernels de combinación recollen as activacións producidas polos expertos e envíanas de volta aos seus rangos de orixe, á vez que calculan a media ponderada dos expertos seleccionados en función dos pesos calculados polo enrutador. Os kernels divídense ademais nun compoñente de envío e recepción, co fin de permitir que as transferencias de datos se superpoñan co cálculo. Os kernels de envío son todos non bloqueantes e non sincronizadores: simplemente envían todas as escrituras aos remotos. No outro extremo, os kernels de combinación só len da memoria, agardando ata que se transfiran todos os datos necesarios. Despois de enviar o traballo ás NIC, mentres os datos se transfiren de forma asíncrona a través da rede, as GPUs poden facer outro traballo útil localmente, como aplicar expertos compartidos ou calcular a atención.

Cada par de kernels ten os seus propios búferes de memoria simétrica, asignando cada rango almacenamento privado para recibir datos de todos os outros rangos. O número máximo de tokens que se poden enviar desde un grupo DP é fixo en todos os rangos, o que tamén establece o límite superior que cada rango pode recibir para cada experto local de cada rango de DP. Isto permite aos rangos remitentes derivar un enderezo único no dispositivo de destino no que escribir, sen necesidade de ningunha sincronización entre eles. Despois de recibir os datos, os kernels mesturan os tokens para organizalos na memoria no formato óptimo esixido polos kernels receptores. Aínda que os compoñentes teñen unha dimensión considerable, reutilízanse en todas as capas secuenciadas dun modelo.

Ampliar

A única forma de sincronización global, tal como se ilustra na figura anterior, impleméntase no kernel de combinación-recepción (combine-receive). Unha vez que os datos son enviados desde o envío, un rango regresa e continúa a execución cando recibe todos os tokens que necesita dos outros rangos e entra nos kernels de envío de combinación tan pronto como son procesados. A barreira na combinación-recepción garante que ningún rango poida adiantarse e comezar o envío-emisión mentres calquera outro rango aínda estea agardando para recibir datos, o que podería causar unha superposición destrutiva. A sincronización faise no kernel de combinación por simplicidade; como optimización, poderíase implementar a mesma barreira entre a recepción de envío e os kernels de envío de combinación, reducindo aínda máis a latencia ao permitir ás NICs máis tempo para resolver as transferencias mentres a GPU está a executar outros kernels.

Ambos os kernels divídense entre todos os SM dispoñibles dos dispositivos: mentres que os kernels de envío-emisión e combinación-recepción deben paralelizarse nun recuento máximo de tokens por rango (max_m), os kernels de recepción-emisión e combinación-envío deben xestionar tantos tokens de cada rango e experto local, para un máximo de max_m * (num_experts // EP) * (EP // TP).

Envío (Dispatch)

O kernel de envío encárgase de enviar tokens e factores de escala de bloques aos pares que aloxan os expertos aos que se enrutaron os tokens. O lado do remitente baséase na especialización de warps para paralelizar dúas tarefas: agregar información de enrutamento para determinar cantos tokens se envían desde cada rango e empaquetar os tokens en mensaxes para ser enviadas ao remoto. O lado do receptor primeiro agarda a que se reciban todos os recuentos de tokens, despois le e desempacota as cargas útiles da memoria compartida nos tensores que se pasarán aos kernels Grouped GEMM auga abaixo. Tamén almacena información en búferes compartidos cos kernels de combinación, para indicar onde se debe devolver cada token. Esta información é necesaria xa que o kernel receptor mestura os tokens en búferes contiguos nunha orde non determinista.

Ampliar

Na parte do remitente, un único warp de 32 fíos en cada bloque encárgase de ler a información de enrutamento e contar o número de tokens que se espera que cada experto de destino reciba deste rango, enviando o recuento máis un usando nvshmem_signal_op. O recuento increméntase nun, xa que a transición de cero a non cero no extremo remoto significa a recepción dos recuentos dun rango de orixe. En paralelo, os warps restantes cooperan para copiar tokens na memoria simétrica en todos os bloques en paralelo, empaquetando activacións, factores de escala e o seu índice no rango local nun anaco contiguo. O índice é requirido polo remitente de combinación para determinar o enderezo onde se escribirá o token. A continuación, despois de garantir que todos os datos foron copiados a través dunha barreira entre os grupos de warps, os warps operan de novo de forma independente, enviando cada un o mesmo búfer a un experto diferente en paralelo. Os tokens envíanse usando nvshmemx_putmem_signal_nbi_warp, o que tamén aumenta de forma atómica o recuento de tokens enviados desde o rango local no dispositivo remoto. Dentro dun grupo DP, dado que cada rango posúe unha réplica do token que se vai enviar, o envío está equilibradamente repartido, e cada dispositivo envía un subconxunto dos tokens.

No extremo receptor, todos os kernels sincronízanse primeiro cos rangos remitentes agardando a que se envíen os recuentos totais de tokens. Despois, todos agardan a que os recuentos de tokens enviados incrementados de forma atómica se estabilicen nos recuentos totais, o que indica que todas as cargas útiles dos rangos de orixe tamén foron enviadas, grazas á semántica da chamada putmem. Os kernels fan unha sondaxe dos recuentos usando nvshmem_uint64_wait_until, paralelizando a operación en todos os bloques e fíos. Posteriormente, unha barreira entre bloques garante que ningún bloque lea os búferes a menos que todos os datos fosen recibidos correctamente. Distribuidos entre bloques e sincronizados mediante un contador incrementado de forma atómica, os compoñentes cópianse desde a memoria simétrica en búferes contiguos normais que se converten nas entradas dos kernels auga abaixo que implementan os expertos. O rango de orixe, o índice de experto e o índice de token almacénanse por separado, sinalando exactamente a localización onde o kernel de combinación ten que enviar as activacións. Aínda que os tokens dun grupo DP se envían desde diferentes dispositivos, agrúpanse todos para ser pasados ao experto correspondente.

Combinación (Combine)

Os kernels de combinación divídense de novo en mitades de envío e recepción: os remitentes copian as activacións de 16 bits sen cuantizar aos dispositivos remotos, mentres que os kernels receptores agardan a que os datos se envíen e calculan localmente a media ponderada de todas as contribucións dos expertos. Ademais, tamén actúan como unha barreira para sincronizar a secuencia de envío-combinación: cada rango establece un indicador en cada par ao entrar nos kernels de envío, e aos kernels receptores non se lles permite regresar a menos que observen que o indicador está establecido. A latencia da sincronización é mínima, xa que se superpoñen coa comunicación e o cálculo reais.

Ampliar

No lado do remitente, os kernels percorren a lista de tokens asignados a todos os expertos locais en paralelo, escribindoos nun búfer no rango de destino. O rango de destino, o índice de experto e o índice de token lénse dos búferes por token poboados polos kernels de dispersión tras a recepción dos tokens. Cada remite ten a súa propia rexión de memoria privada por experto na que escribir, tal como se indica na figura anterior, evitando a necesidade de sincronización. De forma similar ao envío, a combinación incrementa de forma atómica os contadores por token no rango de destino para indicar a recepción dos datos: cando o contador coincide co número de expertos aos que se enviou un token, pódese acceder ao contido do token.

No kernel receptor, a lista de tokens percorrse en paralelo a través de múltiples bloques, agardando a que chegue o seu contido mediante a sondaxe do indicador establecido pola operación de sinalización. Tras a chegada, as cargas útiles lénse dos búferes privados, indicando a táboa de enrutamento cal búfer ler e que peso asignar a cada experto. Os resultados escríbense entón en tensores asignados externamente, e o kernel remata a execución unha vez que todos os dispositivos superan a barreira. A través dun grupo DP, todos os rangos reciben unha copia de cada activación de experto para calcular as súas propias réplicas.

Benchmarks

Avaliamos os nosos kernels nun clúster de 128 GPUs repartidas en 16 nós conectados mediante InfiniBand e NICs CX-7. Probamos tanto GPUDirect Async (IBGDA) como Reliable Connection (RC) cun proxy de CPU. Comparamos con DeepSeek, altamente optimizado, así como coas primitivas densas proporcionadas por PyTorch (a través de NCCL) ou NVSHMEM.

Ampliar

Aínda que na operación densa all-to-all de NVSHMEM, o rendemento de IBRC e IBGDA é similar (6378 µs fronte a 6180 µs), IBGDA é significativamente máis rápido cos kernels dispersos. Sumando o envío e a combinación (Dispatch e Combine), IBGDA usa 902 µs mentres que IBRC leva 3223 µs, o que supón unha mellora de 3,6 veces na latencia. Aínda que o all-to-all está limitado polo ancho de banda, os kernels dispersos difunden ordes de magnitude menos datos, estando limitados pola latencia. Ao activar as transferencias de rede directamente desde unha GPU, sen requirir un proxy de CPU para coordinar a GPU e a NIC, a latencia de extremo a extremo redúcese significativamente.

Aínda que os nosos kernels portátiles son aproximadamente 2 veces máis lentos que os kernels DeepSeek altamente optimizados, melloran a latencia 10 veces en comparación cos kernels densos (902 µs fronte a 9944 µs).

Ademais, a división en compoñentes de envío e recepción tamén permite agochar parte da latencia, a diferenza das primitivas de biblioteca.

Ampliar

Nun único nodo (EP8), NVSHMEM utiliza NVLINK para o transporte, proporcionando menor latencia e maior rendemento que a rede entre nós. Os nosos kernels portátiles son aproximadamente 2,5 veces máis rápidos que DeepEP nun único nodo (186 µs fronte a 481 µs).

Melloras adicionais

Os kernels descritos aquí superan as primitivas integradas dos frameworks de ML e ofrecen un rendemento decente sen sobreespecializarse para transportes particulares entre dispositivos, como NVLink ou InfiniBand. Ademais das oportunidades xa mencionadas, pódense obter ganancias adicionais de rendemento substituíndo as primitivas de comunicación por versións máis especializadas. Por exemplo, en NVLink, o uso de memoria simétrica podería substituírse por búferes compartidos entre os dispositivos, eliminando algunha copia e permitindo esquemas de sincronización máis refinados, a través de tokens individuais en vez de lotes de tokens. En InfiniBand, unha implementación podería acceder aos pares de colas subxacentes directamente, eliminando a necesidade de transferir tanto os recuentos de tokens esperados como enviados e baleirando os tokens das colas nos búferes de saída a medida que chegan. Non obstante, tales implementacións teñen o custo da portabilidade, mentres que a nosa implementación permite avaliar clústeres con configuracións específicas antes de comprometer esforzo de desenvolvemento para optimizar para un hardware particular.

Conclusión

Presentamos unha biblioteca de alto rendemento e portátil para a comunicación MoE que logra un rendemento 10 veces máis rápido en comparación coa comunicación estándar all-to-all mentres mantén a compatibilidade entre diversas configuracións de hardware. Nas implementacións nun único nodo con NVLink, a nosa solución mostra unha latencia 2,5 veces menor que as implementacións anteriores.

O noso enfoque equilibra o rendemento coa portabilidade a través de innovacións clave que inclúen a compatibilidade coa comunicación iniciada por GPU, unha arquitectura de kernel dividida que permite a superposición de cálculo e comunicación, e a asignación eficiente de tokens mediante primitivas NVSHMEM mínimas. Aínda que é aproximadamente 2 veces máis lenta que as implementacións moi especializadas en configuracións multinodo, a nosa biblioteca ofrece unha superior flexibilidade en varios contornos de rede (NVLink, CX-7 e EFA).

A medida que os modelos MoE continúan escalando, as estratexias de comunicación eficientes como a nosa serán cada vez máis importantes para a implementación práctica. A nosa implementación totalmente de código aberto está dispoñible en https://github.com/ppl-ai/pplx-kernels.

Referencias

DeepEP

Informe técnico de DeepSeek-V3

NVIDIA NVSHMEM

Cita

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