O projeto UCCL da UC Berkeley lançou mKernel, uma biblioteca sob licença MIT que funde a comunicação NVLink intra-nó, o RDMA inter-nó, e o compute denso em kernels CUDA persistentes únicos — rodando-os simultaneamente em vez de stages sequenciais. O número motivador é o que times de treinamento fronteira conhecem: a comunicação consome 43,6% do forward pass e 32% do tempo de treinamento end-to-end, subindo até 47% do tempo total de execução para modelos MoE onde o all-to-all expert-paralelo domina. Se quase metade do seu tempo de treinamento é a rede esperando o compute ou o compute esperando a rede, a fronteira de kernel entre eles é onde mora o desperdício, e a aposta do mKernel é remover essa fronteira.

Dois mecanismos impulsionam o ganho. Primeiro, os CPUs não escalam com os GPUs — cada lançamento de kernel separado e check de sincronização custa microssegundos que se tornaram atrasos de pipeline mensuráveis em hardware classe H100/H200, e um kernel fundido persistente paga esse custo uma vez em vez de por-stage. Segundo, a fusão permite overlap intra-kernel fine-grained a granularidade tile/chunk: em vez de terminar toda a comunicação depois iniciar o compute (ou vice-versa) em fronteiras grossas de kernel, mKernel os interleva dentro de um kernel então um tile chegado por RDMA alimenta o GEMM enquanto o próximo tile ainda está em voo. A biblioteca envia cinco kernels fundidos cobrindo os padrões que importam: AllGather+GEMM, GEMM+AllReduce, MoE Dispatch+GEMM, Ring Attention, e GEMM+ReduceScatter — routing de tokens, paralelismo de experts, e atenção sequência-paralela. Testado em clusters 2-nós H200 via AWS EFA ou ConnectX-7 InfiniBand.

A leitura de ecossistema: a fusão comunicação-compute é a próxima fronteira de eficiência para treinamento multi-nó agora que a otimização de kernel single-GPU é madura. NCCL e NVSHMEM tratam a comunicação como uma primitiva separada do compute; a abordagem de fusão kernel-persistente é o que fecha o gap de overlap de fronteira-de-kernel que essas bibliotecas estruturalmente não podem. Para MoE especificamente — onde a comunicação é o maior time sink a 47% — é o lugar de mais alta-alavancagem a otimizar, por isso MoE Dispatch+GEMM é um dos cinco kernels enviados. O sinal estrutural é que isso veio da academia sob licença MIT, não de um vendor — DeepEP e NVSHMEM da NVIDIA são a comparação mais próxima, e uma alternativa MIT aberta muda quem pode construir sobre fusão comm-compute sem vendor lock-in.

As ressalvas honestas: o writeup não dá números de speedup cara-a-cara contra NCCL ou DeepEP, o teste é 2-nós H200 apenas (o comportamento multi-nó-em-escala é a pergunta aberta), e kernels fundidos persistentes são notoriamente difíceis de debugar e tunar. Se você treina MoE ou modelos grandes multi-nó segunda de manhã: mKernel vale um benchmark na sua própria fabric, especialmente se a comunicação é seu bottleneck medido — mas perfile sua fração de comm primeiro, reproduza no seu número de nós, e trate a ausência de comparações NCCL publicadas como a coisa a verificar antes de apostar um training run nele.