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比較的缺失視為在押注訓練執行前要驗證的東西。