Comunicación eficiente y portátil de mezcla de expertos

Presentamos una biblioteca de código abierto, portátil y de alto rendimiento para la comunicación de Mezcla de Expertos (MoE) que logra un rendimiento 10 veces más rápido en comparación con las primitivas de comunicación All-to-All estándar.

Nuestra implementación presenta varias innovaciones técnicas clave que ofrecen una eficiencia superior en la comunicación de MoE:

Comunicación iniciada por GPU (IBGDA): Es compatible con la comunicación directa de GPU a NIC, lo que reduce significativamente la latencia al omitir la participación de la CPU

Solapamiento de comunicación y cómputo: La arquitectura de kernel dividida con etapas de envío y recepción separadas permite que el cómputo se realice de forma concurrente con las transferencias de red

Rendimiento más rápido en un solo nodo: Una latencia 2.5 veces menor que la implementación más rápida anterior en configuraciones de un solo nodo

Rendimiento multinodo eficiente y portátil: Nuestra implementación alcanza velocidades hasta 10 veces más rápidas que la comunicación all-to-all estándar. Aunque es aproximadamente 2 veces más lenta que las implementaciones altamente especializadas, nuestro enfoque ofrece una mejor portabilidad entre versiones de NVSHMEM y entornos de red (NVLink, CX-7 y EFA)

La biblioteca es totalmente de código abierto y está disponible en https://github.com/ppl-ai/pplx-kernels.

En este artículo, exploramos los desafíos del paralelismo de expertos en modelos MoE a gran escala y describimos nuestro enfoque para el envío y la combinación eficientes de tokens en entornos de GPU distribuidos.

Introducción

Los modelos de Mezcla de Expertos (MoE), como DeepSeek R1 y Mixtral 8x7B, mejoran a los modelos densos al limitar el número de pesos que se activan para cada token. En lugar de lograr recuentos altos de parámetros al aumentar el número de capas o el tamaño de las capas lineales en el Perceptrón Multicapa (MLP) de cada capa de decodificador, los modelos MoE reemplazan el MLP tradicional con múltiples expertos y un enrutador. Por ejemplo, de los 671 mil millones de parámetros de DeepSeek R1, solo 37 mil millones se multiplican con un token dado durante la inferencia. Esto reduce en gran medida la cantidad de cómputo necesaria para decodificar un token y mejora la latencia en comparación con un modelo denso.

Los modelos MoE presentan algunos desafíos adicionales para la inferencia en comparación con los modelos densos. Si bien los expertos en sí son pequeñas capas MLP, cada capa de decodificador incluye un enrutador que decide a qué expertos se envía un token, y cada token se envía a múltiples expertos. Por lo general, el enrutador es una pequeña capa lineal que produce una distribución de probabilidad. Usualmente, se eligen los expertos con las puntuaciones más altas de K y la activación final se calcula como un promedio ponderado, sumando las salidas de los expertos multiplicadas por un peso derivado de la distribución de probabilidad del enrutador.

Para minimizar la latencia en sistemas MoE distribuidos, se puede aprovechar el paralelismo en múltiples dispositivos, pero esto introduce desafíos de comunicación. Modelos como Mixtral 8x7B o Llama-70B caben en 8 dispositivos en un solo nodo, beneficiándose de interconexiones NVLink rápidas y de baja latencia (hasta 900 Gbps). Sin embargo, los modelos más grandes requieren fragmentar (sharding) a los expertos en múltiples nodos utilizando InfiniBand (con un pico de 400 Gbps), lo que introduce desafíos adicionales de latencia.

Ampliar

En este artículo, exploramos el problema del paralelismo de expertos, describiendo nuestra implementación de kernels de GPU que envían eficientemente tokens a los dispositivos que contienen a los expertos asignados y los recopilan calculando la suma ponderada de las salidas de los expertos. Si bien existen implementaciones optimizadas de forma agresiva dirigidas a un hardware de red específico, presentamos una implementación altamente portátil que se basa en un conjunto mínimo de primitivas de NVSHMEM, a la vez que ofrece un rendimiento 10 veces más rápido que la comunicación all-to-all estándar. Nuestra implementación logra un rendimiento de vanguardia en configuraciones de un solo nodo al tiempo que mantiene una excelente portabilidad en diversos entornos de red.

Fragmentación y paralelismo

Para una inferencia eficiente, los pesos de un modelo deben mantenerse en la memoria del dispositivo, dejando también Espacio suficiente para las activaciones, cachés KV y otros búferes requeridos por el paso hacia adelante (forward pass) a través del modelo. Los modelos más capaces superan la capacidad incluso de las GPU más capaces, por lo tanto, la inferencia debe distribuirse en múltiples dispositivos, los cuales pueden almacenar colectivamente los pesos del modelo. Según los esquemas de fragmentación de los pesos, se deben utilizar diferentes esquemas de comunicación y cómputo para descargar el cómputo y sincronizar los dispositivos.

Ampliar

El paralelismo de expertos (EP), ilustrado en la primera figura, solo paraleliza el cómputo de los expertos. Se asignan diferentes expertos a distintos dispositivos, los cuales contienen sus pesos. Después del enrutamiento, los tokens se envían al dispositivo correspondiente, y los resultados se recopilan y acumulan posteriormente. La complejidad del enrutamiento depende del grado de paralelismo en las otras partes del modelo: replicar otras capas podría eliminar por completo la necesidad de enrutamiento, ya que cada rango (rank) puede seleccionar los tokens de una tabla de enrutamiento replicada localmente. Sin embargo, si solo uno de los rangos ejecuta el enrutamiento, se requiere una difusión (broadcast) para enviar los tokens, índices y pesos a sus respectivos expertos. Finalmente, un all-gather o una difusión all-to-all sincroniza los tokens de salida con cualquier rango que continúe la ejecución del modelo. Dicha implementación es relativamente sencilla ya que torch ya expone las primitivas requeridas, aunque se podrían obtener algunos beneficios al fusionar la acumulación con la operación gather que recopila los tokens de los expertos.

Ampliar

El paralelismo exclusivo de expertos no se escala de manera ideal, ya que los nodos en un clúster pueden estar inactivos mientras el modelo ejecuta capas que no son de expertos, como la atención (attention), la norma y el muestreo. Sin embargo, el cómputo de estas capas, principalmente la atención, también puede beneficiarse del paralelismo de tensores (TP). La mayoría de los modelos se basan en la atención de múltiples cabezales (multi-head attention), lo que significa que los cabezales de atención y sus proyecciones Q, K y V correspondientes también se pueden fragmentar entre dispositivos, replicando o recopilando las porciones (slices) entre varias capas. Si la atención se distribuye en todos los dispositivos, un all-gather puede sincronizar las activaciones, lo que permite replicar el enrutamiento, requiriendo primitivas de sincronización similares al caso del paralelismo de expertos para una implementación eficiente. Sin embargo, existen límites para el paralelismo en este nivel, ya que reducir el número de cabezales de atención por debajo de cierto umbral producirá rendimientos decrecientes.

Ampliar

Para utilizar mejor todos los dispositivos y admitir un grado muy alto de paralelismo de expertos, de hasta 128 o 256 GPU, se requiere el paralelismo de datos (DP). Bajo este esquema, los dispositivos en los que se divide un modelo se agrupan para manejar solicitudes de forma concurrente, calculando la atención y manteniendo cachés KV fragmentadas en su grupo local. Múltiples instancias de estos grupos paralelos colaboran en la evaluación de expertos, y cada uno aloja un subconjunto diferente de los pesos de los expertos. Según el número de cabezales de atención, un grupo normalmente puede abarcar hasta el tamaño de un nodo completo, ya que la comunicación intranodo es más rápida. Por ejemplo, en la figura anterior, un rango DP atiende de manera independiente dos solicitudes, A y B, manejando la atención, la norma y cualquier otro registro para las solicitudes. El otro rango DP procesa una solicitud C distinta. Sin embargo, el primer nodo aloja la mitad de los expertos y el otro nodo la otra mitad, por lo que, después del enrutamiento, los tokens de A y B pueden enviarse al segundo nodo y viceversa. Esto conduce a un problema de comunicación dispersa (sparse): cada dispositivo puede enviar un número diferente de tokens a cualquier otro rango de destino. Las primitivas existentes de torch, principalmente all_to_all, no son particularmente adecuadas, ya que pueden requerir alguna forma de relleno (padding) o sincronización de GPU a CPU y difusión de metadatos. Para implementar la comunicación de manera efectiva, se requieren kernels personalizados para procesar la información de enrutamiento e iniciar la comunicación desde los dispositivos sin intervención de la CPU. Después del enrutamiento, un kernel de envío debe enviar los tokens a los rangos a los que fueron enrutados, mientras que en el lado de combinación se deben recopilar las activaciones pertenecientes a las solicitudes en el grupo DP actual. Además, el trabajo debe equilibrarse dentro de un grupo DP que puede tener múltiples dispositivos, con el fin de minimizar la difusión y replicar correctamente los tokens en todos los rangos para las capas posteriores.

NVSHMEM

NVSHMEM es una implementación de OpenSHMEM específica de NVIDIA que proporciona facilidades de comunicación portátiles entre dispositivos que abstraen la complejidad del hardware subyacente. La API puede expresar lecturas y escrituras de dispositivo a dispositivo, las cuales se mapean a las primitivas de las capas de transporte individuales. Se admiten tanto NVLink como RDMA, lo que otorga un grado de portabilidad y permite que los kernels de NVSHMEM operen dentro de un nodo o a través de un clúster de múltiples nodos. En nuestros kernels, utilizamos escrituras de memoria remota y operaciones de señalización para transferir datos y sincronizar los dispositivos participantes.

Las operaciones de NVSHMEM se basan en el concepto de memoria simétrica: operan en búferes que se han asignado en todos los dispositivos que participan en la comunicación entre dispositivos. Un dispositivo local puede usar una dirección derivada dentro de su propio búfer local junto con el índice del rango de destino para especificar el destino de una operación. La figura a continuación ilustra este concepto: ambas GPU asignan búferes simétricos del mismo tamaño, reteniendo punteros src hacia ellos. El primer rango quiere enviar 3 enteros al segundo, colocándolos al inicio del búfer: nvshmem_int_put_nbi deriva la dirección de inicio a partir del búfer local, especificando el dispositivo de destino. El segundo rango deriva un desplazamiento (offset) de su propio búfer, enviando un elemento al primer dispositivo y desplazándose uno. Si bien las direcciones de destino siempre deben ser búferes simétricos asignados usando nvshmem_alloc, los búferes de origen pueden ser regiones arbitrarias de la memoria del dispositivo, siempre que estén previamente registradas en NVSHMEM.

Aunque NVSHMEM proporciona una amplia gama de primitivas, nuestros kernels se basan en solo 3 funciones, construyendo toda la sincronización y la delimitación (fencing) sobre ellas.

Ampliar

nvshmemx_putmem_signal_nbi_warp: Transfiere un bloque de datos de un dispositivo a otro, a la vez que establece un indicador (flag) en el dispositivo remoto. La operación establece (NVSHMEM_SIGNAL_SET) o incrementa (NVSHMEM_SIGNAL_ADD) una ubicación de 64 bits. El indicador se actualiza después de que se transfiere todo el bloque de memoria. Si el dispositivo remoto observa un cambio en el indicador, puede acceder de forma segura al búfer en su propia memoria. Esta función es útil para fusionar la transferencia de datos y la sincronización.

nvshmemx_signal_op opera en una única ubicación de memoria, típicamente un indicador de 64 bits, estableciéndolo o incrementándolo de forma atómica. Es útil para enviar metadatos y sincronizar dispositivos.

nvshmem_uint64_wait_until se utiliza en el extremo receptor de una señal, para sondear (poll) un indicador hasta que el remoto lo actualice.

Garantizar cualquier forma de orden entre operaciones a través de nvshmem_quiet o nvshmem_fence es costoso, por lo que nuestra implementación de los kernels evita el uso de cualquier otra primitiva de NVSHMEM y minimiza cualquier dependencia que no sean pares individuales de envío y recepción. Al enviar datos, siempre utilizamos la versión no bloqueante de las funciones, sin esperar a que los datos sean siquiera enviados fuera del rango local. Otra sincronización implícita a través del grupo de kernels garantiza que estos búferes no se sobrescriban destructivamente mientras las NIC necesitan acceso a ellos.

NVSHMEM utiliza GPUDirect RDMA para que la NIC pueda leer y escribir directamente en la memoria de la GPU para el intercambio de datos sin involucrar a las CPU. Además, en las NIC ConnectX, NVSHMEM es compatible con la comunicación iniciada por GPU (también conocida como Infiniband GPUDirect Async o IBGDA), lo que permite a la GPU enviar operaciones RDMA directamente a la NIC y sondear la cola de finalización de la NIC de forma directa. En plataformas que no admiten la comunicación iniciada por GPU, NVSHMEM genera un hilo “proxy” en la CPU host para iniciar la comunicación y sondear la finalización en nombre de la GPU. El programa NVSHMEM es portátil independientemente de si se admite o no la comunicación iniciada por GPU. Sin embargo, la comunicación iniciada por GPU reduce significativamente la latencia porque evita por completo el desvío hacia la CPU.

Kernels portátiles

Implementamos la comunicación de MoE a través de un par de kernels de envío y recepción (dispatch y combine). Los kernels de envío son responsables de leer los tokens y la información de enrutamiento en cada rango, enviándolos a los expertos apropiados. Los kernels de combinación recopilan las activaciones producidas por los expertos y las envían de vuelta a sus rangos de origen, al tiempo que calculan el promedio ponderado de los expertos seleccionados en función de los pesos calculados por el enrutador. Los kernels se dividen además en un componente de envío y otro de recepción, con el fin de permitir que las transferencias de datos se solapen con el cómputo. Los kernels de envío son todos no bloqueantes y no sincronizadores: simplemente envían todas las escrituras a los remotos. En el otro extremo, los kernels de combinación solo leen de la memoria, esperando hasta que se hayan transferido todos los datos requeridos. Después de enviar el trabajo a las NIC, mientras los datos se transfieren de forma asincrónica a través de la red, las GPU pueden realizar otro trabajo útil localmente, como aplicar expertos compartidos o calcular la atención.

Cada par de kernels tiene sus propios búferes de memoria simétrica, y cada rango asigna almacenamiento privado para recibir datos de todos los demás rangos. El número máximo de tokens que se pueden enviar desde un grupo DP es fijo en todos los rangos, lo que también establece el límite superior que cada rango puede recibir para cada experto local de cada rango de envío DP. Esto permite a los rangos emisores derivar una dirección única en el rango de destino para escribir, sin requerir ninguna sincronización entre ellos. Después de recibir los datos, los kernels barajan los tokens para organizarlos en la memoria en el formato óptimo requerido por los kernels receptores. Si bien los búferes tienen una dimensión considerable, se reutilizan en todas las capas secuenciales de un modelo.

Ampliar

La única forma de sincronización global, como se ilustra en la figura anterior, se implementa en el kernel de combinación y recepción (combine-receive). Una vez que los datos se envían desde el envío, un rango regresa y continúa la ejecución cuando recibe todos los tokens que requiere de los otros rangos y entra en los kernels de envío de combinación tan pronto como se procesan. La barrera en combine-receive garantiza que ningún rango pueda adelantarse y comenzar el envío de despacho (dispatch-send) mientras cualquier otro rango todavía esté esperando para recibir datos, lo que podría causar un solapamiento destructivo. La sincronización se realiza en el kernel de combinación por simplicidad; como optimización, se podría implementar la misma barrera entre los kernels de recepción de despacho y envío de combinación, reduciendo aún más la latencia al permitir que las NIC tengan más tiempo para asentar las transferencias mientras la GPU ejecuta otros kernels.

Ambos kernels se dividen entre todos los SM disponibles de los dispositivos: mientras que los kernels de envío de despacho y recepción de combinación deben paralelizarse en función de un recuento máximo de tokens por rango (max_m), los kernels de recepción de despacho y envío de combinación deben manejar esa cantidad de tokens de cada rango y experto local, para un máximo de max_m * (num_experts // EP) * (EP // TP).

Envío (Dispatch)

El kernel de envío es responsable de enviar tokens y factores de escala de bloques a los pares que alojan a los expertos a los que se enrutaron los tokens. El lado emisor se basa en la especialización de warps para paralelizar dos tareas: agregar información de enrutamiento para determinar cuántos tokens se envían desde cada rango y empaquetar los tokens en mensajes para ser enviados al remoto. El lado receptor primero espera a que se reciban todos los recuentos de tokens, luego lee y desenpaqueta las cargas útiles (payloads) de la memoria compartida en los tensores que se pasarán a los kernels Grouped GEMM posteriores. También almacena información en búferes compartidos con los kernels de combinación para indicar a dónde se debe devolver cada token. Esta información es necesaria ya que el kernel receptor baraja los tokens en búferes contiguos en un orden no determinista.

Ampliar

En la parte emisora, un solo warp de 32 hilos en cada bloque es responsable de leer la información de enrutamiento y contar el número de tokens que se espera que cada experto de destino reciba de este rango, enviando el recuento más uno usando nvshmem_signal_op. El recuento se incrementa en uno, ya que la transición de cero a no cero en el extremo remoto significa la recepción de los recuentos de un rango de origen. En paralelo, los warps restantes cooperan para copiar los tokens en la memoria simétrica en todos los bloques en paralelo, empaquetando las activaciones, los factores de escala y su índice en el rango local en un fragmento contiguo. El índice es requerido por el emisor de combinación para determinar la dirección en la que se escribirá el token. A continuación, después de asegurarse de que todos los datos se han copiado a través de una barrera en los grupos de warps, los warps operan nuevamente de forma independiente, y cada uno envía el mismo búfer a un experto diferente en paralelo. Los tokens se envían utilizando nvshmemx_putmem_signal_nbi_warp, lo que también aumenta de forma atómica el recuento de tokens enviados desde el rango local en el dispositivo remoto. Dentro de un grupo DP, dado que cada rango posee una réplica del token que se va a enviar, el envío se equilibra de manera uniforme, y cada dispositivo envía un subconjunto de los tokens.

En el extremo receptor, todos los kernels se sincronizan primero con los rangos emisores esperando a que se envíen los recuentos totales de tokens. Posteriormente, todos esperan a que los recuentos de tokens enviados incrementados de forma atómica se estabilicen en los recuentos totales, lo que indica que todas las cargas útiles de los rangos de origen también se han enviado, gracias a la semántica de la llamada putmem. Los kernels sondean los recuentos usando nvshmem_uint64_wait_until, paralelizando la operación en todos los bloques e hilos. Posteriormente, una barrera entre bloques garantiza que ningún bloque lea los búferes a menos que todos los datos se hayan recibido correctamente. Distribuidos entre bloques y sincronizados a través de un contador incrementado de forma atómica, los tokens se copian de la memoria simétrica a búferes contiguos regulares que se convierten en las entradas de los kernels posteriores que implementan a los expertos. El rango de origen, el índice del experto y el índice del token se almacenan por separado, señalando exactamente la ubicación a la que el kernel de combinación tiene que enviar las activaciones. Aunque los tokens de un grupo DP se envían desde diferentes dispositivos, todos se agrupan para ser pasados al experto correspondiente.

Combinación (Combine)

Los kernels de combinación se dividen nuevamente en mitades de envío y recepción: los emisores copian las activaciones de 16 bits no cuantizadas a los dispositivos remotos, mientras que los kernels receptores esperan a que los datos sean enviados y calculan el promedio ponderado de todas las contribuciones de los expertos localmente. Además, también actúan como una barrera para sincronizar la secuencia de envío y combinación (dispatch-combine): cada rango establece un indicador en cada par al entrar en los kernels de envío, y a los kernels receptores no se les permite regresar a menos que observen que el indicador está establecido. La latencia de sincronización es mínima, ya que se solapa con la comunicación y el cómputo reales.

Ampliar

En el lado del emisor, los kernels recorren la lista de tokens asignados a todos los expertos locales en paralelo, escribiéndolos en un búfer en el rango de destino. El rango de destino, el índice del experto y el índice del token se leen de los búferes por token poblados por los kernels de dispersión (scatter) tras la recepción de los tokens. Cada emisor tiene su propia región de memoria privada por experto para escribir, como se indica en la figura anterior, evitando la necesidad de sincronizar. De manera similar al envío, la combinación incrementa de forma atómica los contadores por token en el rango de destino para indicar la recepción de los datos: cuando el contador coincide con el número de expertos a los que se envió un token, se puede acceder al contenido del token.

En el kernel receptor, la lista de tokens se recorre en paralelo a través de múltiples bloques, esperando a que llegue su contenido mediante el sondeo del indicador establecido por la operación de señalización. Tras la llegada, las cargas útiles se leen de los búferes privados, indicando la tabla de enrutamiento qué búfer leer y qué peso asignar a cada experto. Los resultados se escriben en tensores asignados externamente, y el kernel finaliza su ejecución una vez que todos los dispositivos superan la barrera. A través de un grupo DP, todos los rangos reciben una copia de cada activación de experto para calcular sus propias réplicas.

Pruebas de rendimiento (Benchmarks)

Evaluamos nuestros kernels en un clúster de 128 GPU distribuidas en 16 nodos conectados mediante InfiniBand y NIC CX-7. Probamos tanto GPUDirect Async (IBGDA) como Reliable Connection (RC) con un proxy de CPU. Los comparamos con la implementación de DeepSeek altamente optimizada, así como con las primitivas densas proporcionadas por PyTorch (a través de NCCL) o NVSHMEM.

Ampliar

Aunque en la operación densa all-to-all de NVSHMEM el rendimiento de IBRC e IBGDA es similar (6378 µs frente a 6180 µs), IBGDA es significativamente más rápido con los kernels dispersos. Sumando el envío y la combinación (Dispatch y Combine), IBGDA utiliza 902 µs mientras que IBRC toma 3223 µs, lo que representa una mejora de 3.6 veces en la latencia. Si bien all-to-all está limitado por el ancho de banda, los kernels dispersos transmiten órdenes de magnitud menos datos, estando limitados por la latencia. Al activar las transferencias de red directamente desde una GPU, sin requerir un proxy de CPU para coordinar la GPU y la NIC, la latencia de extremo a extremo se reduce significativamente.

Si bien nuestros kernels portátiles son aproximadamente 2 veces más lentos que los kernels altamente optimizados de DeepSeek, mejoran la latencia en 10 veces en comparación con los kernels densos (902 µs frente a 9944 µs).

Además, la división en componentes emisor-receptor también permite ocultar parte de la latencia, a diferencia de las primitivas de la biblioteca.

Ampliar

En un solo nodo (EP8), NVSHMEM utiliza NVLINK para el transporte, ofreciendo menor latencia y mayor rendimiento (throughput) que las redes entre nodos. Nuestros kernels portátiles son aproximadamente 2.5 veces más rápidos que DeepEP en un solo nodo (186 µs frente a 481 µs).

Mejoras adicionales

Los kernels descritos aquí superan a las primitivas integradas de los frameworks de ML y ofrecen un rendimiento decente sin una especialización excesiva para transportes particulares entre dispositivos, como NVLink o InfiniBand. Además de las oportunidades ya mencionadas, se pueden lograr mayores ganancias de rendimiento reemplazando las primitivas de comunicación con versiones más especializadas. Por ejemplo, en NVLink, el uso de memoria simétrica podría reemplazarse por búferes compartidos entre los dispositivos, eliminando parte de la copia y permitiendo esquemas de sincronización de grano más fino, a través de tokens individuales en lugar de lotes de tokens. En InfiniBand, una implementación podría acceder directamente a los pares de colas subyacentes, eliminando la necesidad de transferir tanto los recuentos de tokens esperados como los enviados y vaciando los tokens de las colas en los búferes de salida a medida que llegan. Sin embargo, tales implementaciones tienen el costo de la portabilidad, mientras que nuestras implementaciones permiten evaluar clústeres con configuraciones específicas antes de comprometer esfuerzo de desarrollo para optimizar para un hardware particular.

Conclusión

Hemos presentado una biblioteca portátil de alto rendimiento para la comunicación de MoE que logra un rendimiento 10 veces más rápido en comparación con la comunicación all-to-all estándar, al tiempo que mantiene la compatibilidad entre diversas configuraciones de hardware. En implementaciones de un solo nodo con NVLink, nuestra solución demuestra una latencia 2.5 veces menor que las implementaciones anteriores.

Nuestro enfoque equilibra el rendimiento con la portabilidad a través de innovaciones clave que incluyen soporte para la comunicación iniciada por GPU, una arquitectura de kernel dividida que permite el solapamiento de cómputo y comunicación, y el envío eficiente de tokens utilizando primitivas mínimas de NVSHMEM. Aunque es aproximadamente 2 veces más lenta que las implementaciones altamente especializadas en configuraciones multinodo, nuestra biblioteca ofrece una flexibilidad superior en varios entornos de red (NVLink, CX-7 y EFA).

A medida que los modelos MoE continúan escalando, las estrategias de comunicación eficientes como la nuestra serán cada vez más importantes para su implementación práctica. Nuestra implementación totalmente de código abierto está disponible en https://github.com/ppl-ai/pplx-kernels.

Referencias

DeepEP

Informe técnico de DeepSeek-V3

NVIDIA NVSHMEM

Citación

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