El proyecto UCCL de UC Berkeley lanzó mKernel, una librería bajo licencia MIT que fusiona la comunicación NVLink intra-nodo, el RDMA inter-nodo, y el compute denso en kernels CUDA persistentes únicos — corriéndolos simultáneamente en lugar de stages secuenciales. El número motivador es el que los equipos de entrenamiento frontera conocen: la comunicación consume 43.6% del forward pass y 32% del tiempo de entrenamiento end-to-end, subiendo hasta 47% del tiempo total de ejecución para modelos MoE donde el all-to-all expert-paralelo domina. Si casi la mitad de tu tiempo de entrenamiento es la red esperando el compute o el compute esperando la red, la frontera de kernel entre ellos es donde vive el desperdicio, y la apuesta de mKernel es quitar esa frontera.
Dos mecanismos impulsan la ganancia. Primero, los CPUs no escalan con los GPUs — cada lanzamiento de kernel separado y check de sincronización cuesta microsegundos que se han vuelto retrasos de pipeline medibles en hardware clase H100/H200, y un kernel fusionado persistente paga ese costo una vez en lugar de por-stage. Segundo, la fusión permite overlap intra-kernel fine-grained a granularidad tile/chunk: en lugar de terminar toda la comunicación luego iniciar el compute (o viceversa) en fronteras gruesas de kernel, mKernel los interleaviza dentro de un kernel así que un tile llegado por RDMA alimenta el GEMM mientras el próximo tile aún está en vuelo. La librería envía cinco kernels fusionados cubriendo los patrones que importan: AllGather+GEMM, GEMM+AllReduce, MoE Dispatch+GEMM, Ring Attention, y GEMM+ReduceScatter — routing de tokens, paralelismo de expertos, y atención secuencia-paralela. Probado en clusters 2-nodos H200 vía AWS EFA o ConnectX-7 InfiniBand.
La lectura de ecosistema: la fusión comunicación-compute es la próxima frontera de eficiencia para el entrenamiento multi-nodo ahora que la optimización de kernel single-GPU es madura. NCCL y NVSHMEM tratan la comunicación como una primitiva separada del compute; el enfoque de fusión kernel-persistente es lo que cierra el gap de overlap de frontera-de-kernel que esas librerías estructuralmente no pueden. Para MoE específicamente — donde la comunicación es el mayor time sink al 47% — es el lugar de más alto-apalancamiento a optimizar, por eso MoE Dispatch+GEMM es uno de los cinco kernels enviados. La señal estructural es que esto vino de la academia bajo licencia MIT, no de un vendor — DeepEP y NVSHMEM de NVIDIA son la comparación más cercana, y una alternativa MIT abierta cambia quién puede construir sobre fusión comm-compute sin vendor lock-in.
Las advertencias honestas: el writeup no da números de speedup cara-a-cara contra NCCL o DeepEP, el testing es 2-nodos H200 solo (el comportamiento multi-nodo-a-escala es la pregunta abierta), y los kernels fusionados persistentes son notoriamente difíciles de debuggear y tunear. Si entrenas MoE o modelos grandes multi-nodo el lunes por la mañana: mKernel vale un benchmark en tu propia fabric, especialmente si la comunicación es tu bottleneck medido — pero perfila tu fracción de comm primero, reproduce en tu conteo de nodos, y trata la ausencia de comparaciones NCCL publicadas como lo a verificar antes de apostar un training run en ello.