UC Berkeley的UCCL项目发布了mKernel,一个MIT许可的库,将节点内NVLink通信、节点间RDMA和密集计算融合进单个持久CUDA kernel——同时运行而非顺序stage。激励数字是前沿训练团队知道的:通信消耗forward pass的43.6%和端到端训练时间的32%,对于expert-parallel all-to-all主导的MoE模型上升到总执行时间的高达47%。如果你近一半的训练时间是网络等待计算或计算等待网络,它们之间的kernel边界就是浪费所在,mKernel的赌注是移除那个边界。

两个机制驱动收益。第一,CPU不随GPU扩展——每个单独的kernel启动和同步检查花费微秒,在H100/H200级硬件上已成为可测量的流水线延迟,持久融合kernel支付该成本一次而非按stage。第二,融合在tile/chunk粒度实现细粒度kernel内重叠:不是在粗kernel边界完成所有通信然后开始计算(或反之),mKernel在一个kernel内交错它们,因此通过RDMA到达的tile喂给GEMM,而下一个tile仍在传输中。该库交付五个融合kernel,覆盖重要模式:AllGather+GEMM、GEMM+AllReduce、MoE Dispatch+GEMM、Ring Attention和GEMM+ReduceScatter——token routing、expert parallelism和sequence-parallel attention。在2节点H200集群上通过AWS EFA或ConnectX-7 InfiniBand测试。

生态系统解读:通信-计算融合是多节点训练的下一个效率前沿,现在单GPU kernel优化已经成熟。NCCL和NVSHMEM将通信视为与计算分离的原语;持久kernel融合方法是关闭那些库结构上无法关闭的kernel边界重叠gap的东西。具体到MoE——其中通信是47%的最大time sink——这是最高杠杆的优化位置,这就是为什么MoE Dispatch+GEMM是五个交付kernel之一。结构性信号是这来自学术界,MIT许可,不是来自vendor——NVIDIA的DeepEP和NVSHMEM是最接近的比较,一个开放MIT替代改变了谁可以在comm-compute融合上构建而无vendor锁定。

诚实的警告:writeup没有给出对NCCL或DeepEP的头对头speedup数字,测试仅2节点H200(多节点规模行为是开放问题),持久融合kernel是出了名的难调试和调优。如果你周一早上多节点训练MoE或大模型:mKernel值得在你自己的fabric上benchmark,特别是如果通信是你测量的bottleneck——但先profile你的comm占比,在你的节点数上复现,并将已发布NCCL比较的缺失视为在押注训练运行前要验证的东西。