Le projet UCCL de UC Berkeley a sorti mKernel, une librairie sous licence MIT qui fusionne la communication NVLink intra-node, le RDMA inter-node, pis le compute dense en kernels CUDA persistants uniques — les roulant simultanément au lieu de stages séquentiels. Le chiffre motivant, c'est celui que les équipes d'entraînement frontière connaissent : la communication consomme 43,6% du forward pass pis 32% du temps d'entraînement end-to-end, montant jusqu'à 47% du temps total d'exécution pour les modèles MoE où l'all-to-all expert-parallèle domine. Si presque la moitié de ton temps d'entraînement, c'est le réseau qui attend le compute ou le compute qui attend le réseau, la frontière de kernel entre les deux, c'est là que le gaspillage vit, pis le pari de mKernel, c'est d'enlever cette frontière.

Deux mécanismes portent le gain. Premièrement, les CPUs scalent pas avec les GPUs — chaque lancement de kernel séparé pis check de synchronisation coûte des microsecondes qui sont devenues des délais de pipeline mesurables sur du hardware classe H100/H200, pis un kernel fusionné persistant paie ce coût une fois au lieu de par-stage. Deuxièmement, la fusion permet l'overlap intra-kernel fine-grained à granularité tile/chunk : au lieu de finir toute la communication puis démarrer le compute (ou vice-versa) aux frontières grossières de kernel, mKernel les interleave dans un seul kernel donc un tile arrivé par RDMA feed le GEMM pendant que le prochain tile est encore en vol. La librairie ship cinq kernels fusionnés couvrant les patterns qui comptent : AllGather+GEMM, GEMM+AllReduce, MoE Dispatch+GEMM, Ring Attention, pis GEMM+ReduceScatter — routing de tokens, parallélisme d'experts, pis attention séquence-parallèle. Testé sur des clusters 2-nodes H200 via AWS EFA ou ConnectX-7 InfiniBand.

La lecture écosystème : la fusion communication-compute, c'est la prochaine frontière d'efficacité pour l'entraînement multi-node maintenant que l'optimisation de kernel single-GPU est mature. NCCL pis NVSHMEM traitent la communication comme une primitive séparée du compute ; l'approche de fusion kernel-persistant, c'est ce qui ferme le gap d'overlap de frontière-de-kernel que ces librairies peuvent structurellement pas. Pour MoE spécifiquement — où la communication est le plus gros time sink à 47% — c'est l'endroit le plus haut-levier à optimiser, c'est pourquoi MoE Dispatch+GEMM est un des cinq kernels shipés. Le signal structurel, c'est que ça vient de l'académie sous licence MIT, pas d'un vendeur — DeepEP pis NVSHMEM de NVIDIA sont la comparaison la plus proche, pis une alternative MIT ouverte change qui peut bâtir sur la fusion comm-compute sans vendor lock-in.

Les caveats honnêtes : le writeup donne aucun chiffre de speedup tête-à-tête contre NCCL ou DeepEP, le testing est 2-node H200 seulement (le comportement multi-node-at-scale, c'est la question ouverte), pis les kernels fusionnés persistants sont notoirement durs à débugger pis tuner. Si tu entraînes du MoE ou de gros modèles multi-node lundi matin : mKernel vaut un benchmark sur ta propre fabric, surtout si la communication est ton bottleneck mesuré — mais profile ta fraction de comm en premier, reproduis sur ton node count, pis traite l'absence de comparaisons NCCL publiées comme la chose à vérifier avant de parier un training run dessus.