Comunicação Eficiente e Portátil Mixture-of-Experts

Apresentamos uma biblioteca de alto desempenho, portátil e de código aberto para comunicação Mixture-of-Experts (MoE) que alcança um desempenho 10x mais rápido em comparação com os primitivos de comunicação padrão All-to-All.

Nossa implementação apresenta diversas inovações técnicas fundamentais que entregam uma eficiência de comunicação de MoE superior:

Comunicação iniciada por GPU (IBGDA): Suporta comunicação direta entre GPU e NIC, reduzindo significativamente a latência ao evitar o envolvimento da CPU

Sobreposição de comunicação e computação: A arquitetura de kernel dividida com estágios separados de envio e recebimento permite que a computação prossiga simultaneamente às transferências de rede

Desempenho de nó único mais rápido: Latência 2,5x menor do que a implementação mais rápida anterior em configurações de nó único

Desempenho multi-nó eficiente e portátil: Nossa implementação alcança velocidades até 10x mais rápidas do que a comunicação all-to-all padrão. Embora seja aproximadamente 2x mais lenta que implementações altamente especializadas, nossa abordagem oferece melhor portabilidade entre as versões do NVSHMEM e ambientes de rede (NVLink, CX-7 e EFA)

A biblioteca é totalmente de código aberto e está disponível em https://github.com/ppl-ai/pplx-kernels.

Neste artigo, exploramos os desafios do paralelismo de especialistas em modelos MoE de grande escala e descrevemos nossa abordagem para o envio e combinação eficiente de tokens em ambientes de GPU distribuídos.

Modelos de Mixture-of-Experts (MoE), como o DeepSeek R1 e o Mixtral 8x7B, melhoram os modelos densos ao limitar o número de pesos ativados para cada token. Em vez de alcançar contagens de parâmetros elevadas aumentando o número de camadas ou o tamanho das camadas lineares no Perceptron Multicamadas (MLP) de cada camada de decodificador, os modelos MoE substituem o MLP tradicional por múltiplos especialistas e um roteador. Por exemplo, dos 671B de parâmetros do DeepSeek R1, apenas 37B são multiplicados por um determinado token durante a inferência. Isso reduz drasticamente a quantidade de computação necessária para decodificar um token e melhora a latência em comparação com um modelo denso.

Os modelos MoE apresentam desafios adicionais para inferência, comparados aos modelos densos. Embora os próprios especialistas sejam pequenas camadas MLP, cada camada de decodificador inclui um roteador que decide para quais especialistas um token é enviado, sendo cada token enviado para múltiplos especialistas. O roteador é geralmente uma pequena camada linear que produz uma distribuição de probabilidade. Normalmente, os especialistas com as pontuações top-K são escolhidos e a ativação final é calculada como uma média ponderada, somando as saídas dos especialistas multiplicadas por um peso derivado da distribuição de probabilidade do roteador.

Para minimizar a latência em sistemas MoE distribuídos, o paralelismo pode ser explorado entre múltiplos dispositivos, mas isso introduz desafios de comunicação. Modelos como Mixtral 8x7B ou Llama-70B cabem dentro de 8 dispositivos em um único nó, beneficiando-se de interconexões NVLink rápidas e de baixa latência (até 900Gbps). No entanto, modelos maiores exigem o particionamento de especialistas em múltiplos nós usando InfiniBand (atingindo o pico de 400Gbps), o que introduz desafios adicionais de latência.

Roteamento de tokens, computação especializada e coleta de resultados em uma camada mixture-of-experts.

Neste artigo, exploramos o problema do paralelismo de especialistas, descrevendo nossa implementação de kernels de GPU que enviam tokens de forma eficiente para dispositivos que mantêm os especialistas atribuídos e os coletam de volta calculando a soma ponderada das saídas dos especialistas. Embora existam implementações agressivamente otimizadas visando hardware de rede específico, apresentamos uma implementação altamente portátil que depende de um conjunto mínimo de primitivas NVSHMEM, mas que entrega um desempenho 10x mais rápido que a comunicação all-to-all padrão. Nossa implementação alcança desempenho de última geração em configurações de nó único, mantendo uma excelente portabilidade entre vários ambientes de rede.

Para uma inferência eficiente, os pesos de um modelo devem ser mantidos na memória do dispositivo, deixando também espaço suficiente para ativações, caches KV e outros buffers necessários para a passagem direta pelo modelo. Os modelos mais capazes excedem a capacidade até mesmo das GPUs mais poderosas; portanto, a inferência deve ser distribuída por vários dispositivos, que podem armazenar coletivamente os pesos do modelo. Com base nos esquemas de particionamento de pesos, diferentes esquemas de comunicação e computação devem ser usados para descarregar a computação e sincronizar os dispositivos.

Paralelismo de especialistas em duas GPUs.

O Paralelismo de Especialistas (EP), ilustrado na primeira figura, paraleliza apenas a computação do especialista. Especialistas diferentes são atribuídos a dispositivos diferentes, que retêm seus pesos. Após o roteamento, os tokens são enviados para o dispositivo correspondente, sendo os resultados coletados e acumulados posteriormente. A complexidade do roteamento depende do grau de paralelismo nas outras partes do modelo: replicar outras camadas poderia eliminar totalmente a necessidade de roteamento, já que cada classificação pode selecionar os tokens de uma tabela de roteamento replicada localmente. No entanto, se apenas uma das classificações executar o roteamento, uma transmissão é necessária para enviar tokens, índices e pesos para seus respectivos especialistas. Finalmente, um all-gather ou uma transmissão all-to-all sincroniza os tokens de saída com a classificação que continua a execução do modelo. Tal implementação é relativamente simples, pois o torch já expõe os primitivos necessários, embora alguns benefícios pudessem ser obtidos ao fundir a acumulação com a operação de coleta dos tokens dos especialistas.

Combinação de paralelismo de especialistas com paralelismo de tensores em duas GPUs.

O paralelismo exclusivo de especialistas não escala idealmente, pois os nós em um cluster podem ficar ociosos enquanto o modelo executa camadas que não são de especialistas, como atenção, normalização e amostragem. No entanto, a computação dessas camadas, principalmente a atenção, também pode se beneficiar do Paralelismo de Tensores (TP). A maioria dos modelos depende de atenção de múltiplas cabeças, o que significa que as cabeças de atenção e suas projeções Q, K e V correspondentes também podem ser particionadas entre dispositivos, replicando ou reunindo as fatias entre várias camadas. Se a atenção for espalhada por todos os dispositivos, um all-gather pode sincronizar as ativações, permitindo que o roteamento seja replicado, exigindo primitivas de sincronização semelhantes ao caso do paralelismo de especialistas para uma implementação eficiente. No entanto, existem limites para o paralelismo nesse nível, já que reduzir o número de cabeças de atenção abaixo de um determinado limite produzirá retornos decrescentes.

Combinação de paralelismo de especialistas com paralelismo de dados para solicitações separadas em duas GPUs.

Para utilizar melhor todos os dispositivos e suportar um grau muito alto de paralelismo de especialistas, de até 128 ou 256 GPUs, o Paralelismo de Dados (DP) é necessário. Nesse esquema, os dispositivos nos quais um modelo é dividido são agrupados para lidar com solicitações simultaneamente, computando a atenção e mantendo os caches KV particionados em seu grupo local. Várias instâncias desses grupos paralelos colaboram na avaliação de especialistas, cada uma hospedando um subconjunto diferente dos pesos dos especialistas. Com base no número de cabeças de atenção, um grupo pode normalmente abranger até o tamanho de um nó inteiro, já que a comunicação intra-nó é mais rápida. Por exemplo, na figura acima, uma classificação DP atende independentemente duas solicitações, A e B, lidando com atenção, normalização e qualquer outro controle para as solicitações. A outra classificação DP processa uma solicitação distinta C. No entanto, o primeiro nó hospeda metade dos especialistas, enquanto o outro nó hospeda a outra metade, portanto, após o roteamento, os tokens de A e B podem ser enviados para o segundo nó e vice-versa. Isso leva a um problema de comunicação esparsa: cada dispositivo pode enviar um número diferente de tokens para qualquer outra classificação de destino. Primitivas existentes do torch, principalmente all_to_all, não são particularmente adequadas, pois podem exigir alguma forma de preenchimento ou sincronização GPU-para-CPU e transmissão de metadados. Para implementar a comunicação de forma eficaz, kernels personalizados são necessários para processar as informações de roteamento e iniciar a comunicação a partir dos dispositivos sem intervenção da CPU. Após o roteamento, um kernel de despacho deve enviar tokens para as classificações para as quais foram roteados, enquanto no lado da combinação as ativações pertencentes às solicitações no grupo DP atual devem ser coletadas. Além disso, o trabalho deve ser equilibrado dentro de um grupo DP que pode ter múltiplos dispositivos, a fim de minimizar a transmissão e replicar corretamente os tokens em todas as classificações para as camadas subsequentes.

NVSHMEM é uma implementação do OpenSHMEM específica da NVIDIA, que fornece instalações de comunicação inter-dispositivos portáteis que abstraem a complexidade do hardware subjacente. A API pode expressar leituras e gravações de dispositivo para dispositivo, que são mapeadas para os primitivos de camadas de transporte individuais. Tanto o NVLink quanto o RDMA são suportados, concedendo um grau de portabilidade e permitindo que os kernels NVSHMEM operem dentro de um nó ou em um cluster de vários nós. Em nossos kernels, usamos gravações em memória remota e operações de sinalização para transferir dados e sincronizar os dispositivos participantes.

As operações NVSHMEM são construídas em torno do conceito de memória simétrica: elas operam em buffers que foram alocados em todos os dispositivos participantes da comunicação inter-dispositivos. Um dispositivo local pode usar um endereço derivado dentro de seu próprio buffer local junto com o índice da classificação de destino para especificar o destino de uma operação. A figura abaixo ilustra esse conceito: ambas as GPUs alocam buffers simétricos do mesmo tamanho, mantendo ponteiros src para eles. A primeira classificação deseja enviar 3 inteiros para a segunda, colocando-os no início do buffer: nvshmem_int_put_nbi deriva o endereço inicial do buffer local, especificando o dispositivo de destino. A segunda classificação deriva um deslocamento de seu próprio buffer, enviando um elemento para o primeiro dispositivo, deslocando por um. Embora os endereços de destino devam ser sempre buffers simétricos alocados usando nvshmem_alloc, os buffers de origem podem ser regiões arbitrárias da memória do dispositivo, desde que sejam pré-registrados no NVSHMEM.

Embora o NVSHMEM forneça uma ampla gama de primitivas, nossos kernels dependem de apenas 3 funções, construindo toda a sincronização e proteção sobre elas.

Memória simétrica e gravações remotas entre duas GPUs usando NVSHMEM.

nvshmemx_putmem_signal_nbi_warp: Transfere um bloco de dados de um dispositivo para outro, ao mesmo tempo que define um sinalizador no dispositivo remoto. A operação define (NVSHMEM_SIGNAL_SET) ou incrementa (NVSHMEM_SIGNAL_ADD) um local de 64 bits. O sinalizador é atualizado após a transferência de todo o bloco de memória. Se o dispositivo remoto observar uma alteração no sinalizador, ele pode acessar com segurança o buffer em sua própria memória. Esta função é útil para agrupar transferência de dados e sincronização.

nvshmemx_signal_op opera em um único local de memória, geralmente um sinalizador de 64 bits, definindo-o ou incrementando-o atomicamente. É útil para enviar metadados e sincronizar dispositivos.

nvshmem_uint64_wait_until é usado na extremidade receptora de um sinal, para pesquisar um sinalizador até que o dispositivo remoto o atualize.

Garantir qualquer forma de ordenação entre operações através de nvshmem_quiet ou nvshmem_fence é caro, portanto, nossa implementação dos kernels evita o uso de quaisquer outros primitivos NVSHMEM e minimiza quaisquer dependências além de pares individuais de envio-recebimento. Ao enviar dados, sempre usamos a versão não bloqueante das funções, sem esperar que os dados sejam sequer enviados da classificação local. Outras sincronizações implícitas entre o grupo de kernels garantem que esses buffers não sejam sobrescritos de forma destrutiva enquanto as NICs precisarem de acesso a eles.

O NVSHMEM usa GPUDirect RDMA para que a NIC possa ler e gravar diretamente na memória da GPU para troca de dados sem envolver CPUs. Além disso, nas NICs ConnectX, o NVSHMEM suporta comunicação iniciada por GPU (também conhecida como Infiniband GPUDirect Async ou IBGDA), que permite que a GPU poste operações RDMA diretamente na NIC e pesquise a fila de conclusão da NIC diretamente. Em plataformas que não suportam comunicação iniciada por GPU, o NVSHMEM gera um tópico "proxy" na CPU host para iniciar a comunicação e pesquisar a conclusão em nome da GPU. O programa NVSHMEM é portátil, independentemente de a comunicação iniciada por GPU ser suportada ou não. No entanto, a comunicação iniciada por GPU reduz significativamente a latência porque ignora completamente o desvio para a CPU.

Implementamos a comunicação MoE através de um par de kernels de despacho e combinação. Os kernels de despacho são responsáveis pela leitura de tokens e informações de roteamento em cada classificação, despachando-os para os especialistas apropriados. Os kernels de combinação coletam as ativações produzidas pelos especialistas e as enviam de volta para suas classificações de origem, enquanto também calculam a média ponderada dos especialistas selecionados com base nos pesos calculados pelo roteador. Os kernels são divididos ainda mais em um componente de envio e recebimento, a fim de permitir que as transferências de dados sejam sobrepostas à computação. Os kernels de envio são todos não bloqueantes e não sincronizantes: eles simplesmente despacham todas as gravações para os remotos. Na outra extremidade, os kernels de combinação apenas leem da memória, aguardando até que todos os dados necessários tenham sido transferidos. Após despachar o trabalho para as NICs, enquanto os dados são transferidos assincronicamente pelo fio, as GPUs podem realizar outros trabalhos úteis localmente, como aplicar especialistas compartilhados ou computar atenção.

Cada par de kernels possui seus próprios buffers de memória simétrica, com cada classificação alocando armazenamento privado para receber dados de todas as outras classificações. O número máximo de tokens que podem ser despachados de um grupo DP é fixo entre as classificações, o que também define o limite superior que cada classificação pode receber para cada especialista local de cada classificação DP. Isso permite que as classificações emissoras derivem um endereço exclusivo na classificação de destino para gravar, sem exigir nenhuma sincronização entre elas. Após o recebimento dos dados, os kernels embaralham os tokens para organizá-los na memória no formato ideal exigido pelos kernels receptores. Embora os buffers tenham uma dimensão considerável, eles são reutilizados em todas as camadas sequenciais de um modelo.

Kernels separados de envio e recebimento para operações de despacho e combinação.

A única forma de sincronização global, conforme ilustrado na figura acima, é implementada no kernel de combinação-recebimento. Uma vez que os dados são despachados do envio, uma classificação retorna e continua a execução quando recebe todos os tokens de que precisa das outras classificações e entra nos kernels de combinação-envio assim que eles são processados. A barreira no combinação-recebimento garante que nenhuma classificação possa seguir em frente e iniciar o despacho-envio enquanto qualquer outra classificação ainda estiver aguardando para receber dados, causando potencialmente uma sobreposição destrutiva. A sincronização é feita no kernel de combinação por simplicidade; como uma otimização, a mesma barreira poderia ser implementada entre os kernels de despacho-recebimento e combinação-envio, reduzindo ainda mais a latência ao permitir que as NICs tenham mais tempo para liquidar as transferências enquanto a GPU está executando outros kernels.

Ambos os kernels são divididos entre todos os SMs disponíveis dos dispositivos: enquanto os kernels de despacho-envio e combinação-recebimento devem paralelizar através de uma contagem máxima de tokens por classificação (max_m), os kernels de despacho-recebimento e combinação-envio devem lidar com esse número de tokens de cada classificação e especialista local, para um máximo de max_m * (num_experts // EP) * (EP // TP).

O kernel de despacho é responsável pelo despacho de tokens e fatores de escala de bloco para pares que hospedam os especialistas para os quais os tokens foram roteados. O lado do emissor depende da especialização de warp para paralelizar duas tarefas: agregar informações de roteamento para determinar quantos tokens são enviados de cada classificação e empacotar os tokens em mensagens para serem despachadas para o remoto. O lado do receptor primeiro aguarda o recebimento de todas as contagens de tokens; em seguida, ele lê e desempacota as cargas úteis da memória compartilhada para os tensores que serão passados para os kernels Grouped GEMM a jusante. Ele também armazena informações em buffers compartilhados com os kernels de combinação, para indicar onde cada token deve ser enviado de volta. Essas informações são necessárias, pois o kernel de recebimento embaralha os tokens em buffers contíguos em uma ordem não determinística.

Despacho de tokens e sinalização de sua chegada entre os ranks de origem e de destino.

Na parte do emissor, um único warp de 32 tópicos em cada bloco é responsável por ler as informações de roteamento e contar o número de tokens que cada especialista de destino deve receber desta classificação, enviando a contagem mais um usando nvshmem_signal_op. A contagem é incrementada em um, pois a transição de zero para não zero na extremidade remota significa o recebimento das contagens de uma classificação de origem. Em paralelo, os warps restantes cooperam para copiar tokens em memória simétrica através de todos os blocos em paralelo, empacotando ativações, fatores de escala e seu índice na classificação local em um pedaço contíguo. O índice é exigido pelo emissor de combinação para determinar o endereço onde o token será gravado. Em seguida, após garantir que todos os dados tenham sido copiados através de uma barreira nos grupos de warp, os warps operam novamente de forma independente, cada um enviando o mesmo buffer para um especialista diferente em paralelo. Os tokens são enviados usando nvshmemx_putmem_signal_nbi_warp, que também aumenta atomicamente a contagem de tokens enviados da classificação local no dispositivo remoto. Dentro de um grupo DP, como cada classificação possui uma réplica do token a ser enviado, o despacho é equilibrado uniformemente, com cada dispositivo enviando um subconjunto dos tokens.

Na extremidade de recebimento, todos os kernels primeiro sincronizam com as classificações emissoras aguardando o envio das contagens totais de tokens. Posteriormente, todos aguardam que as contagens de tokens enviados, incrementadas atomicamente, se estabilizem nas contagens totais, indicando que todas as cargas úteis das classificações de origem também foram enviadas, graças à semântica da chamada putmem. Os kernels pesquisam as contagens usando nvshmem_uint64_wait_until, paralelizando a operação entre todos os blocos e tópicos. Subsequentemente, uma barreira entre blocos garante que nenhum bloco leia os buffers a menos que todos os dados tenham sido recebidos corretamente. Espalhados pelos blocos e sincronizados através de um contador incrementado atomicamente, os tokens são copiados da memória simétrica para buffers contíguos regulares que se tornam as entradas para os kernels a jusante que implementam os especialistas. A classificação de origem, o índice do especialista e o índice do token são armazenados separadamente, identificando exatamente o local para onde o kernel de combinação tem que enviar as ativações. Mesmo que os tokens dentro de um grupo DP sejam enviados de diferentes dispositivos, eles são todos agrupados para serem passados para o especialista correspondente.

Os kernels de combinação são divididos novamente em metades de envio e recebimento: os emissores copiam as ativações de 16 bits não quantizadas para os dispositivos remotos, com os kernels de recebimento aguardando o envio dos dados e calculando a média ponderada de todas as contribuições dos especialistas localmente. Além disso, eles também atuam como uma barreira, para sincronizar a sequência despacho-combinação: cada classificação define um sinalizador em cada par ao entrar nos kernels de envio, com os kernels de recebimento não tendo permissão para retornar, a menos que observem o sinalizador sendo definido. A latência da sincronização é mínima, pois se sobrepõe à comunicação e à computação reais.

Combinação das saídas dos especialistas nos tokens em cada rank de paralelismo de dados.

No lado do emissor, os kernels percorrem a lista de tokens atribuídos a todos os especialistas locais em paralelo, gravando-os em um buffer na classificação de destino. A classificação de destino, o índice do especialista e o índice do token são lidos dos buffers por token preenchidos pelos kernels de dispersão após o recebimento dos tokens. Cada emissor tem sua própria região de memória privada por especialista para gravar, conforme indicado na figura acima, evitando a necessidade de sincronizar. Semelhante ao despacho, a combinação incrementa atomicamente os contadores por token na classificação de destino para indicar o recebimento dos dados: quando o contador corresponde ao número de especialistas para os quais um token foi despachado, o conteúdo do token pode ser acessado.

No kernel de recebimento, a lista de tokens é percorrida em paralelo entre múltiplos blocos, aguardando que seu conteúdo chegue pesquisando o sinalizador definido pela operação de sinalização. Após a chegada, as cargas úteis são lidas dos buffers privados, com a tabela de roteamento indicando qual buffer ler e qual peso atribuir a cada especialista. Os resultados são então gravados em tensores alocados externamente, com o kernel terminando a execução assim que todos os dispositivos passam pela barreira. Em um grupo DP, todas as classificações recebem uma cópia de cada ativação de especialista para computar suas próprias réplicas.

Avaliamos nossos kernels em um cluster de 128 GPUs espalhadas por 16 nós conectados via InfiniBand e NICs CX-7. Testamos tanto o GPUDirect Async (IBGDA) quanto a Conexão Confiável (RC) com um proxy de CPU. Nós os comparamos com a implementação do DeepSeek altamente otimizada, bem como com os primitivos densos fornecidos pelo PyTorch (através do NCCL) ou NVSHMEM.

Latência de comunicação para 128 tokens por GPU em uma configuração EP128 multinó.

Embora na operação all-to-all densa do NVSHMEM o desempenho de IBRC e IBGDA seja semelhante (6378 µs vs 6180 µs), o IBGDA é significativamente mais rápido com os kernels esparsos. Somando o Despacho e a Combinação, o IBGDA usa 902 µs enquanto o IBRC leva 3223 µs - uma melhoria de 3,6x na latência. Enquanto o all-to-all é limitado pela largura de banda, os kernels esparsos transmitem ordens de magnitude menos dados, sendo limitados pela latência. Ao disparar transferências de rede diretamente de uma GPU, sem exigir um proxy de CPU para coordenar a GPU e a NIC, a latência de ponta a ponta é reduzida significativamente.

Embora nossos kernels portáteis sejam cerca de 2x mais lentos que os kernels DeepSeek altamente otimizados, eles melhoram a latência em 10x em comparação com os kernels densos (902 µs vs 9944 µs).

Além disso, a divisão em componentes emissor-receptor também permite que parte da latência seja ocultada, ao contrário dos primitivos da biblioteca.

Latência de comunicação para 128 tokens por GPU em uma configuração EP8 de nó único.

Em nó único (EP8), o NVSHMEM utiliza NVLINK para transporte, proporcionando menor latência e maior rendimento do que o trabalho em rede entre nós. Nossos kernels portáteis são cerca de 2,5x mais rápidos que o DeepEP em nó único (186µs vs 481 µs).

Os kernels descritos aqui superam os primitivos integrados das estruturas de ML e oferecem um desempenho decente sem super-especialização para transportes inter-dispositivos específicos, como NVLink ou InfiniBand. Além das oportunidades já mencionadas, ganhos de desempenho adicionais são alcançáveis substituindo os primitivos de comunicação por versões mais especializadas. Por exemplo, através do NVLink, o uso de memória simétrica poderia ser substituído por buffers compartilhados entre os dispositivos, eliminando algumas cópias e permitindo esquemas de sincronização de granulação mais fina, através de tokens individuais em vez de lotes de tokens. Através do InfiniBand, uma implementação poderia acessar os pares de fila subjacentes diretamente, eliminando a necessidade de transferir as contagens de tokens esperados e enviados e liberando tokens das filas para buffers de saída conforme eles chegam. No entanto, tais implementações têm o custo da portabilidade, enquanto nossas implementações permitem que clusters com configurações específicas sejam avaliados antes de comprometer o esforço de desenvolvimento para otimizar para hardware específico.

Apresentamos uma biblioteca de alto desempenho e portátil para comunicação MoE que alcança um desempenho 10x mais rápido em comparação com a comunicação all-to-all padrão, mantendo a compatibilidade entre diversas configurações de hardware. Em implantações de nó único com NVLink, nossa solução demonstra uma latência 2,5x menor do que as implementações anteriores.

Nossa abordagem equilibra desempenho com portabilidade através de inovações fundamentais, incluindo suporte à comunicação iniciada por GPU, uma arquitetura de kernel dividida que permite a sobreposição de computação-comunicação e despacho eficiente de tokens usando primitivas NVSHMEM mínimas. Embora seja aproximadamente 2x mais lenta do que implementações altamente especializadas em configurações multi-nó, nossa biblioteca oferece flexibilidade superior entre vários ambientes de rede (NVLink, CX-7 e EFA).

À medida que os modelos MoE continuam a escalar, estratégias de comunicação eficientes como a nossa tornar-se-ão cada vez mais importantes para a implantação prática. Nossa implementação totalmente de código aberto está disponível em https://github.com/ppl-ai/pplx-kernels.

DeepEP

Relatório Técnico do 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}
}

Introdução

Particionamento e Paralelismo

NVSHMEM

Kernels Portáteis

Despacho

Combinação

Benchmarks

Melhorias Adicionais

Conclusão

Referências

Citação