DeepGEMM 的 Mega MoE 用了一个叫Symmetric Buffer的精巧设计把多 GPU MoE 从先通信再计算变成了边通信边计算。传统 MoE 通信的问题MoE 推理中token 需要根据路由结果分发到不同专家所在的 GPU。传统做法GPU 0 的 token → NCCL all-to-all → GPU 1 的专家这涉及GPU 0 把数据拷到 NCCL 缓冲区 → NCCL 通过 NVLink 发送 → GPU 1 从 NCCL 缓冲区拷贝出来。两次拷贝 通信延迟。Symmetric Buffer 的做法利用 NVIDIATMA (Tensor Memory Accelerator)NVLink 的对称地址映射所有 GPU 分配一块相同大小、相同虚拟地址的显存这就是 “symmetric” 的含义每张卡往自己的那块区域写数据其他卡通过 NVLink直接读这块区域——不需要 NCCL不需要数据搬运从 DeepGEMM 的代码可以看到关键结构structSymBuffer{int64_tbase;// 本卡缓冲区的基地址int64_toffsets[72];// 其他 72 张卡的偏移量uint32_trank_idx;// 自己是第几张卡};GPU kernel 里要读其他卡的数据时ptr_tmap(ptr,dst_rank_idx){returnoffsets[dst_rank_idx]ptr;// 一个加法就拿到远程地址}为什么这么快从 sglang 的 benchmark 数据看8×H100 NVLinkPayloadNCCLDeepEPSymmetric Memory2MB28μs13μs45μs64MB210μs418μs44μsNCCL 和 DeepEP 的延迟随 payload 线性增长而 Symmetric Memory恒定 ~45μs。因为数据根本没发送——其他卡直接读你的显存延迟只取决于 NVLink 的单次访问延迟。DeepGEMM Mega MoE 怎么用的在fp8_fp4_mega_moe中Symmetric Buffer 被用来做通信-计算完全融合Dispatch 阶段每个 token 的路由结果写入 Symmetric Buffer 对应位置L1 GEMM 阶段GPU kernel 直接通过SymBuffer::map()读取其他卡的 token边读边算不需要等 all-to-all 完成L2 GEMM 阶段同理输出也写回 Symmetric Buffer其他卡直接读整个 MoE 前向传播变成了一个巨大的融合 kernel通信被完全隐藏在计算中。依赖的硬件/软件硬件NVLink跨卡 P2P 直接访问 TMASM100/H100 的异步内存拷贝引擎软件PyTorch 的torch.distributed._symmetric_memory基于 NVSHMEM2025 年 GTC 发布PyTorch 2.9 支持限制只支持同节点内NVLink 范围跨节点 RDMA 还不行一句话总结Symmetric Buffer 把多 GPU MoE 从先通信再计算变成了边通信边计算——每张卡直接读其他卡的显存省掉了 NCCL 的两次拷贝和同步开销延迟从 O(payload) 降到 O(1)。#DeepSeek #DeepGEMM #SymmetricBuffer #NVLink #MoE #GPU