★ FEATURED ARTICLE 先把算子这个词说清楚很多人第一次听到算子是在学数学分析或者泛函的时候那时候它指的是从一个函数空间到另一个函数空间的映射比如微分算子、积分算子。但今天在 AI 圈子里说的算子含义要朴素得多基本就是一次具体的运算操作。你打开 PyTorch 写一行y torch.matmul(a, b)这就是一次矩阵乘法算子写torch.relu(x)这是激活函数算子写F.softmax(scores, dim-1)这是 softmax 算子。一个神经网络不管是卷积网络还是 Transformer本质上就是一张算子组成的计算图输入张量沿着这张图流动每经过一个节点就被做一次变换最后输出结果。训练时反向传播也是沿着这张图把梯度一个个算子地传回去。所以你可以把算子理解成深度学习框架里的原子操作。框架和编译器的工作就是把这些高层的算子翻译成 GPU 上真正执行的 CUDA 内核kernel。一个算子在 GPU 上跑得快不快取决于很多底层细节访存是不是连续、有没有把数据尽量留在高速缓存里、计算和访存的比例也就是常说的算术强度够不够高、有没有被启动开销和同步开销拖慢。为什么这玩意儿值得专门拿出来说因为大模型的规模把这些问题放大到了极致。一个千亿参数的模型前向一次要做海量的矩阵乘法和注意力计算任何一个高频算子的效率差一点乘以几十层、乘以每个 token、乘以万亿级的训练步数最后就是电费、显卡租用费、训练周期上的巨大差别。反过来能把显存占用降下来就意味着同样的卡能塞更大的 batch、更长的上下文训练和推理的经济账完全不一样。这就是为什么训练大模型的团队几乎都会在算子层面投入大量工程资源——这不是什么独家秘方而是这行的基本功。理解了这一层再来看 DeepSeek 做的事情就能更准确地判断哪些是真创新、哪些是把基本功做得比较狠。DeepSeek 在算子层面做的几件事混合专家MoE里的路由与调度DeepSeek-V3 是一个混合专家模型里面有大量专家子网络但每个 token 每次只激活其中很小的一部分。MoE 这个架构本身不是 DeepSeek 发明的早年的 Switch Transformer、GShard 都是这个路子。MoE 真正的难点恰恰就落在算子和调度层面。第一个难点是路由gating / router。路由器本身是一个小算子它给每个 token 打分决定把它送给哪几个专家。路由算子看起来简单但它的质量直接决定了 MoE 的效率如果路由不准token 被送去了不相关的专家等于白算如果路由太偏科某些专家被挤爆、某些专家闲着负载不均整个并行效率就垮了。DeepSeek 在路由上引入过带负载均衡损失的辅助机制让专家之间的负载尽量均匀这本质上是在路由算子里加了一个约束项牺牲一点点单点最优换整体吞吐。第二个难点是专家并行Expert Parallelism下的通信。当专家分散在很多张卡上时一个 token 要去找它的专家就得跨卡传数据这就是 all-to-all 通信。all-to-all 是 MoE 训练里最容易被卡脖子的算子之一因为它通信量大、模式不规则。DeepSeek 在 V3 里用了一种叫 DualPipe 的流水线并行方案核心思想是让通信和计算尽量重叠——在等数据传过来的时候GPU 别闲着去算下一段能算的东西。这个思路业界都有但 DeepSeek 把它做到了比较精细的程度配合它自己的流水线切分方式把气泡bubble也就是 GPU 空转的时间压得比较小。所以 MoE 这块DeepSeek 的贡献更多是在超大规模下把路由、负载均衡、通信重叠这些算子和调度细节调到位而不是凭空造了一个新算子。多头潜在注意力MLA这是 DeepSeek 在算子层面最常被提到的一项也确实是比较有原创性的改动。先回忆标准的多头注意力MHA和它的省显存变体 GQA/MQA。注意力计算里每个 token 会生成 Query、Key、Value 三组向量。训练时还好麻烦在推理为了自回归地生成下一个 token模型要把历史上所有 token 的 Key 和 Value 都存下来这就是 KV 缓存。上下文一长、batch 一大KV 缓存能吃掉巨量显存而且访存带宽会成为瓶颈——注意力算子很多时候不是算不过来是数据搬不过来。MLA 的思路是既然 KV 缓存这么占地方那我干脆把 Key 和 Value 先压缩到一个低维的潜在向量里缓存只存这个压缩后的低维表示算注意力时再把它解压回高维去用。这样缓存的体积就按压缩比例降下来了。DeepSeek 还做了一个巧妙的设计叫解耦位置编码——把跟位置有关的那部分单独拿出来不塞进压缩的潜在向量里避免位置信息干扰压缩效果。从算子角度看MLA 的代价是计算图变复杂了多了一步压缩、多了一步解压矩阵乘法的形状也变了。它省的是显存和访存但并没有省掉计算量本身甚至因为多了投影单看 FLOPs 可能还略增。这笔账划不划算取决于你的瓶颈到底在显存/带宽还是在算力。对推理这种通常卡在显存和带宽上的场景MLA 是划算的这也是为什么它主要服务于推理效率。值得说一句的是MLA 不是免费午餐。它引入了额外的投影矩阵这些矩阵本身的训练和数值稳定性需要调压缩维度选多少也是个 trade-off压太狠会掉精度。DeepSeek 的贡献在于把这套设计在大规模模型上验证跑通了并且给出了工程上可实现的算子写法而不是停留在论文里。FP8 低精度训练传统大模型训练主流用 BF16也有用 FP16 的。FP8 是更短的浮点数格式只有 8 位意味着同样的显存能存更多数、显存带宽要搬的数据更少、GPU 上 FP8 的矩阵乘法单元吞吐更高。听起来很美但 8 位浮点数的动态范围和精度都非常有限直接拿来训练梯度、激活值很容易溢出或者下溢模型训着训着就崩了。DeepSeek 在 V3 上把 FP8 训练真正做到了大规模可用这里面算子层面的功夫主要在两块。一块是缩放scaling。FP8 表示范围窄所以要在算之前给张量乘一个缩放因子把数值挪到 FP8 能表示的区间里算完再除回来。这个缩放因子怎么定、多久更新一次、是按张量整体缩放还是按更细的粒度比如按 block、按 channel缩放都是算子实现里的细节。缩放做得太粗精度丢得多做得太细开销又上去了。另一块是误差补偿和混合精度策略。不是所有算子都无脑上 FP8。DeepSeek 的做法是关键的、对精度敏感的环节比如某些累加、某些归一化、损失计算保留更高精度把真正占大头的矩阵乘法放到 FP8 上跑。同时配合一些数值稳定的技巧让训练不炸。这本质上是在算子级别做精度的分区调度哪里能省、哪里不能省分得很细。FP8 这块 DeepSeek 走得比较靠前是少数公开把 FP8 端到端训练跑通到前沿模型规模的案例之一。但也要客观Hopper 架构的 GPU 本身就支持 FP8 硬件加速DeepSeek 是第一个把这套硬件能力在超大规模训练里用出效果的团队之一而不是发明了 FP8 格式。底层工程手写内核、内存复用、算子融合这部分最不性感但往往是效率差距的真正来源也最不像营销话术能吹出来的——因为它是实打实的代码。**算子融合kernel fusion**是常见手段把多个连续的算子合并成一个 GPU 内核减少中间结果写回显存再读出来的开销。比如把矩阵乘 加偏置 激活融成一个内核中间结果就不用落地到显存了。DeepSeek 在训练和推理栈里大量用这类融合。内存复用和重计算activation recomputation / gradient checkpointing训练时为了省显存不把所有中间激活都存着而是在反向传播需要时重新算一遍。这是用计算换显存DeepSeek 在超大规模下把这套策略和它的并行方案配合得很紧。手写 CUDA 内核框架自带的通用算子往往不是针对某个特定形状、特定硬件的最优解。当某个算子被调用了几十亿次手写一个针对性的内核把访存模式、寄存器使用、线程块划分都调到贴合硬件收益就很可观。DeepSeek 的开源代码里能看到不少这类针对性实现。通信库和并行策略的定制除了 DualPipeDeepSeek 还配合了它自己的流水线切分、张量并行、专家并行的组合方式让不同并行维度之间的通信尽量不互相阻塞。这些都不是单个算子而是算子之上的调度层但它们最终都落到 GPU 上执行的通信算子和计算算子的配合上。一个更冷静的总结把上面这些串起来看DeepSeek 在算子层面的创新比较准确的描述是它没有发明一个横空出世、别人完全没想过的新算子而是把一堆业界已知的优化方向——MoE 路由与负载均衡、注意力压缩MLA 这一项原创性相对高、FP8 低精度训练、通信计算重叠、算子融合与手写内核——在超大规模、真实训练前沿模型的条件下做得比较扎实、比较省并且公开验证了可行性。它的成本优势是算法选型 工程细节 硬件适配三者一起堆出来的而不是靠某一个神奇算子一招制胜。MLA 是其中原创性最强的一个FP8 大规模训练是其中工程难度最高的一个DualPipe 和 MoE 调度是其中把已知思路做到极致的代表。所以与其把 DeepSeek 看成算子魔法不如把它看成一个把基本功练到极致的团队在别人觉得差不多就行了的底层细节上多抠了那么几刀最后抠出了别人用不起的成本结构。这既不神化它也不贬低它大概是描述这件事最合适的尺度。
阅读完成 · 觉得有帮助？
