mKernel 开源：多 GPU 多节点融合内核库，将通信与计算合并为单个 CUDA 内核

一句话看懂

UC Berkeley 发布 mKernel，将多 GPU 节点内外的通信与计算融合为单个持久 CUDA 内核，旨在消除主机驱动的通信瓶颈。

详细发生了什么

GPU 通信开销是生产级 AI 工作负载的显著瓶颈。据 mKernel 项目引用的数据，通信在前向传播中消耗 43.6% 的时间，在端到端训练中占 32%，在流行的 MoE 模型中甚至高达 47%。UC Berkeley UCCL 团队因此发布了 mKernel，一个将节点内 NVLink 通信、节点间 RDMA 和密集计算融合为单个持久 CUDA 内核的库。

传统多 GPU 通信采用主机驱动模式：CPU 运行控制路径，调用 NCCL 或 NVSHMEM 等库发起集合操作。但 CPU 扩展速度跟不上 GPU 算力增长——例如 GB300 NVL72 机架集成 72 块 Blackwell Ultra GPU，提供 720 PFLOP/s FP8/FP6 性能，微秒级的主机编排开销直接导致流水线气泡。此外，主机驱动系统只能在粗粒度的内核边界重叠计算和通信，无法实现 tile 或 chunk 级别的细粒度重叠。

mKernel 的替代方案是 GPU 驱动通信：GPU 自身触发传输，通信与计算融合在同一内核中。它支持多 GPU 和多节点，通过 SM 专业化让 CTA 自分配角色（计算、节点内通信、节点间发送、节点间归约），SM 数量可按形状调整。通信后端基于 libibverbs 实现 GPU 发起的 RDMA 写入，不依赖 NCCL 或 NVSHMEM。

mKernel 包含五个融合内核：AllGather + GEMM、GEMM + AllReduce、MoE Dispatch + GEMM、Ring Attention 和 GEMM + ReduceScatter。评估在两组 2 节点 × 8 H200 集群上进行，分别使用 AWS EFA 和 InfiniBand 互连，与 NCCL、Triton-distributed、Flux、Mercury 等进行了对比。

中文圈视角

mKernel 对国内 AI 训练场景有直接参考价值，但使用门槛较高。首先，它要求 NVIDIA Hopper GPU（sm_90a）和 CUDA 12.9，这意味着国内大部分使用 A100 或 V100 的集群无法直接受益。其次，通信后端依赖 libibverbs，需要 InfiniBand 或 RoCE 网络，而国内许多数据中心仍以以太网为主，AWS EFA 后端则需在 AWS 上运行，对国内用户不友好。

国内类似工作包括华为昇腾的 HCCL（异构通信库）和百度飞桨的通信优化，但 mKernel 的“融合内核”思路更激进——将通信和计算完全合并为单个持久内核。对于使用 DeepSeek、Qwen 等 MoE 模型的团队，mKernel 的 MoE Dispatch + GEMM 内核能直接减少 token 路由的 staging buffer 往返，有望显著降低通信开销。不过，mKernel 目前仅支持 Hopper 架构，且未提供国产 GPU 适配，短期内国内用户只能通过学术合作或自行移植来使用。

几条值得记住的细节

mKernel 将节点内 NVLink 和节点间 RDMA 通信融合到同一个持久 CUDA 内核中，实现 tile 级别的细粒度重叠。
五个融合内核覆盖 AllGather+GEMM、GEMM+AllReduce、MoE Dispatch+GEMM、Ring Attention 和 GEMM+ReduceScatter。
通信后端基于 libibverbs，不依赖 NCCL 或 NVSHMEM，支持 InfiniBand 和 AWS EFA 两种网络。
要求 NVIDIA Hopper GPU（sm_90a）和 CUDA 12.9，Python 环境需安装 PyTorch。
评估在 2 节点 × 8 H200 集群上进行，与 NCCL、Triton-distributed 等对比，更大规模基准测试仍在进行中。

一句话总结

mKernel 通过 GPU 驱动的融合内核大幅降低多节点通信开销，但当前仅支持 Hopper GPU 和 InfiniBand/EFA 网络，国内用户需关注后续适配进展。