核心主张：DeepGEMM 的价值不是更高的 FLOPS，而是将效率、确定性、批次不变性三者统一——这才是大规模分布式训练真正需要的。适读人群：大模型架构师、Infra 工程师、关注 AI 底层优化的技术决策者阅读时长：约 18 分钟核心收益：理解 GEMM 优化的工程维度，掌握批次不变性设计、FP8 优化与确定性计算的第一性逻辑你应该读这篇文章的理由DeepSeek-V4 是 1.6T 参数的 MoE 模型，在数千张 GPU 上分布式训练时，团队遇到了一个诡异的问题：同一个输入，在不同批次位置，输出结果在比特层面不一致。这不是数值误差，而是完全不同的比特序列。调试花了整整两周，最终定位到 GEMM 库——传统实现为了追求极致性能，使用了 split-k 和 atomicAdd，导致浮点数累加顺序不可控，进而造成批次不一致与计算不确定。这不是 DeepSeek 独有的问题，所有大规模分布式训练迟早都会踩这个坑。DeepGEMM 的出现，就是为了系统性地解决这三个工程痛点：批次不一致、计算不确定、split-k 依赖。它的设计哲学不是"更快的矩阵乘法"，而是"在正确性约束下的最优实现"。一、从第一性原理理解问题的根源在讨论解决方案之前，必须先搞清楚：为什么传统 GEMM 会有这些问题？它们的根源是同一个吗？答案是肯定的。所有问题都源于同一个设计取舍：浮点数加法不满足结合律，但传统 GEMM 为了性能，允许累加顺序不确定。浮点数的这一特性不是 bug，而是 IEEE 754 标准的必然结果。有限精度的二进制表示，意味着(a + b) + c和a + (b + c)在浮点数域中可以得到不同的结果。传统 GEMM 库（如 cuBLAS）在设计时就接受了这个前提，用累加顺序的不确定换取更高的并行度。这个取舍在单卡、小模型的时代几乎没有代价。但当模型规模扩展到 1.6T 参数、训练集群扩展到数千张 GPU，不确定性就从"可以忽略的噪声"变成了"无法调试的系统性故障"。浮点数加法不满足结合律(a+b)+c ≠ a+(b+c)传统 GEMM 设计选择：允许累加顺序不确定split-k：将 K 维拆分给多个 thread block 并行atomicAdd：多线程并发写入同一地址批次不一致同一 token，不同位置，不同结果计算不确定相同输入，多次运行，不同结果分布式训练中的系统性故障理解了这个根源，DeepGEMM 的设计逻辑就非常清晰：它拒绝了"允许累加顺序不确定"这个前提，从这一点出发重新设计整个计算路径。二、三大痛点的本质与解法2.1 批次不一致：调试的真正噩梦现象描述同一个 token，在批次中放在第 1 位和放在第 16 位，经过同一个模型层，输出的浮点数序列在比特层面不同。这不是"差了一点点"，而是"差了很多"。为什么会发生split-k 把矩阵乘法沿 K 维度切成若干块，分给不同的 thread block 并行计算，最后再求和。问题在于：这些 thread block 的执行顺序由 GPU 硬件调度器决定，不受程序控制。当批次位置变化时，GPU 的负载分布也会变化，调度顺序随之改变，累加顺序不同，结果自然不同。为什么大规模训练中代价极高在单卡场景下，批次不一致几乎不可见——你不会把同一个输入放在不同位置然后对比输出。但在分布式训练中，不同 GPU 处理不同的批次切片，gradient all-reduce 之后梯度会被混合。如果每个 GPU 的计算本身就依赖批次位置，梯度的含义就变得模糊，收敛行为也难以预测。更严重的是，当你试图复现一个 bug 时，即使固定了随机种子，也无法保证每次运行产生完全相同的结果。DeepGEMM 的解法放弃 split-k，采用确定性归约：为每个 SM 分配独立的累加缓冲区，所有 SM 完成后按固定顺序做全局求和。这样，无论 token 在批次中处于什么位置，它经过的计算路径完全一致，输出结果在比特层面保证相同。2.2 计算不确定：无法复现的训练过程现象描述固定随机种子，固定数据顺序，固定超参数，多次运行同一个训练脚本，loss 曲线仍然不完全一致。为什么会发生atomicAdd 允许多个线程并发写入同一内存地址，GPU 硬件保证写入的原子性，但不保证顺序。哪个线程先写入，取决于当时的硬件调度状态，而硬件调度本身是系统级的，受温度、功耗、其他任务等诸多因素影响。为什么这是大问题训练不确定性在一般场景下可以接受，但在 RL 训练中代价极高。强化学习依赖精确的奖励信号，如果计算不确定，同一个策略在评估时可能给出不同的分数，采样分布会偏移，训练稳定性急剧下降。DeepSeek-V4 的 RL 阶段实测中，数值抖动导致奖励模型评分波动达到 ±5%，严重干扰训练信号。DeepGEMM 的解法每个 SM 独立累加，不使用 atomicAdd，最后执行全局确定性求和。代价是显存增加约 5%（独立缓冲区），以及不到 1% 的同步开销。这是完全值得的取舍。2.3 split-k 依赖：性能与一致性的两难为什么小批次必须用 split-kGPU 的计算单元数量巨大，小批次场景下（batch size 16）矩阵的 M 维度很小，无法分配足够多的 thread block 让 GPU 满载。split-k 通过沿 K 维度拆分，人为增加并行度，让更多 SM 参与计算，从而提升利用率。这是在硬件约束下的合理工程选择——但它的代价正是批次不变性。DeepGEMM 的替代路径既然不能用 split-k，就必须找到另一种提升利用率的方式。DeepGEMM 的答案是算子融合：将通信（All-to-All）、计算（GEMM）、内存访问在单一内核中完整融合，通过计算与通信的深度重叠来隐藏延迟，而不是通过增加计算并行度来提升利用率。这个方向对 MoE 架构天然适配——MoE 本身就有大量的 expert routing 通信，正好可以被融合进来。三、核心技术架构：MegaMoE 融合内核DeepGEMM 的性能优势，集中体现在 MegaMoE 融合内核上。这不是对传统 GEMM 的小幅优化，而是整个计算图的重新组织。All-to-All 通信Wave 2 (Expert 32-47)Wave 1 (Expert 16-31)Wave 0 (Expert 0-15)