DeepSeek MoE模型优化与未来演进及字节超稀疏内存技术

深度学习优化的新突破：MoE模型与Ultra-Sparse Memory技术的最新进展

几个月前写过一篇《一个关于MoE的猜想》，最近在优化DeepSeek MoE推理时，发现这确实是一个值得深挖的问题。从算法层面看，这恰恰是DeepSeek-V3/R1 MoE的一个薄弱环节，值得进一步分析和提升效率。顺带也梳理了一下字节跳动的Ultra-Sparse Memory Network的相关工作。

先说几个核心判断：任何算法的效率提升，说到底就是在计算、通信和存储之间找到平衡点。以DeepSeek MoE为例，它的单专家结构如下：

import torch
from torch import nn
import torch.nn.functional as F

class Expert(nn.Module):
    def __init__(self, dim: int, inter_dim: int):
        super().__init__()
        self.w1 = nn.Linear(dim, inter_dim)
        self.w2 = nn.Linear(inter_dim, dim)
        self.w3 = nn.Linear(dim, inter_dim)

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        return self.w2(F.silu(self.w1(x)) * self.w3(x))

按照DeepSeek-R1定义的参数——dim=7168, moe-inter-dim=2048，以及论文中提到的对256个Tokens的Batch处理，来计算一下算力开销：

dim = 7168
inter_dim = 2048
tokens = 256
e = Expert(dim, inter_dim)

from ptflops import get_model_complexity_info
input_tokens = (1,tokens,dim)
flops, params = get_model_complexity_info(e, input_tokens, as_strings=True,print_per_layer_stat=True)

Expert(
  44.05 M, 100.000% Params, 11.28 GMac, 99.995% MACs, 
  (w1): Linear(14.68 M, 33.329% Params, 3.76 GMac, 33.328% MACs, in_features=7168, out_features=2048, bias=True)
  (w2): Linear(14.69 M, 33.341% Params, 3.76 GMac, 33.340% MACs, in_features=2048, out_features=7168, bias=True)
  (w3): Linear(14.68 M, 33.329% Params, 3.76 GMac, 33.328% MACs, in_features=7168, out_features=2048, bias=True)
)

单专家就要加载44.05MB的参数，整个模型专家参数加起来是(256+1) × 60层 × 44.05M ≈ 663B，几乎占到了总参数量的98%。训练时Batch大，加载数据与加载参数的比例影响不大；但推理时单个Batch只有256个Token，数据量仅为256 × 7168B ≈ 1.8MB，却要加载44.05MB参数，开销非常不成比例。而实际计算量只有11.28GMAC，相比之下很小。可以说，细粒度MoE算法加上FP8，本质上是为了解决国内算力受限问题才这样设计的。

内存访问和通信的问题还需要进一步解决，这也是DeepSeek-V3为什么提出要做Prefill和Decode分离，以及在Decoding集群中采用EP320并行的原因。

MoE的演进方向

那么，是否可以进一步优化，降低MoE阶段的数据/参数访存比？这就是提出两级Gate Function做法的初衷：

期望通过构造一个2级的Routing Gate，让Attention中携带的信息通过两个Gate找到矩阵(x,y)位置对应的某个或多个Expert。比如，把Hidden-dim切分成16片，同时实现一个256选8的MoE算法，这样每个专家的inter-dim维度就能继续降低，模型的参数量还能进一步提升。

从某种意义上说，这很像PKM（Product Key Memory）的思路，也是字节Ultra-Sparse Memory Network文章开头那张图的核心思想。

你会发现，这本质上和通过两个Gate找到矩阵中(x,y)对应某个Expert的做法是一致的。字节论文中的描述，更适合用另一种视角来理解：把MoE视为内存层，两级页表作为Gating函数。从这个角度看，大模型本身就能构造出一个类似于通用计算机架构的系统——它自己能产生代码并运行。

字节Ultra-Sparse Memory Network

原始PKM（Product Key-Based Memory）算法是这样设计的：将内存层抽象成两段Key和Value，查询向量q通过一个非线性激活算子计算分数，然后乘以V得到结果。当Memory size变大时，采用稀疏方式获取Row和Column的topM分数进行计算。

然后通过row/col分数计算grid分数，得到最终输出。

PKM还采用了类似Multihead的机制，由多个Key来检索共享的Value。

字节Ultra-Sparse Memory（USM）对PKM做了几处改进：

1. 移除了输出时的Softmax操作
2. 对Query和Key添加了LayerNorm，提高训练稳定性
3. 采用逐渐衰减的学习率
4. 在生成Query的线性层前添加了causal depthwise卷积，增强Query信号
5. 类似Group Query Attention的机制，共享Key降低计算复杂度
6. 将Value数量减半再翻倍

与PKM每层添加内存层不同，USM在多个Transformer block中间插入Memory层。主要原因是：随着内存增大，Gating Score函数很难准确查询到正确的Value，同时大规模训练时存在通信和计算负载不均衡的问题。

另外，PKM还有一个问题：Row和Col各自取topM后再相加取topM得到grid score，这种做法无法满足对内存访问的多样性需求。因此期望将Row和Col协同运算，即Tucker Decomposed Query-Key Retrieval（TDQKR）。

其中涉及一些可学习参数构成的tucker core，但由于效率不高，又引入了对C的SVD分解，再通过特征值约束构建辅助损失函数。

另一个技术是Implicit Value Expansion（IVE）。核心挑战在于：大量内存访问时，训练期间维护大内存表的开销很大。本质上是一种虚拟内存的实现，做法相当复杂，还有进一步优化的空间。

最终效果如文章开头所述：相比MoE，推理延迟降低，内存访问带宽加大，Validation Loss接近。

进一步分析

字节论文中只测试了小规模模型。从消融实验结果看，这些工程优化对Loss的改善幅度似乎并不显著。

另一方面，这些复杂的技术对于超过600B参数的模型是否能够顺利收敛，训练效率的损失有多大，都还需要更多验证。整体方案过于复杂，尤其是对未来Post-Train的RL工作流可能带来不小的影响。

其实DeepSeek采用的AuxLoss-Free策略——通过Gating函数增加Bias来做路由选择，然后在hidden-dim维度上再做一次Gating——可能是一个更好的改进方向。再结合内存访问优化，基于Expert indecs做Prefetch，以及考虑是否基于ExpertGroup设计多级页表，这些都需要算法、GPU微架构和训练框架的协同，这一点至关重要。

总结

算法如何匹配硬件架构，训练和推理时内存访问的Trade-Off如何平衡——DeepSeek MoE第一步解决了对大算力的依赖，但未来模型算法和基础设施的整合，进一步解除对网络和内存访问的依赖，才是更需要解决的问题。

必须强调的是，算法本身一定要足够简单才能实现规模化，也才能保证未来Reasoning RL工作流的稳定性。接下来如果工作稍有空闲，还会从范畴论的角度分析DeepSeek-R1相关的强化学习工作。通盘考虑来做Infra优化是必要的——算法和Infra必须紧密协同，不能单独为了MFU或解除Memory Bound就优化其中一项。训练和推理的性能也要协同，有时甚至要牺牲一些训练MFU来换取更高的推理效率，毕竟推理的计算规模未来会远超训练。

更进一步来看，从DeepSeek MoE的设计，也能看出Nvidia GB200 NVL72的设计初衷——为什么要加大内存容量和带宽，为什么要采用更高密度的NVL互联。但坦率地说，这未必是一条正确的路径。从算法层面解除对大带宽网络的需求和延迟约束，才是真正值得努力的方向。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：DeepSeek MoE模型优化与未来演进及字节超稀疏内存技术要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题