5.2创新架构

一、MoE(Mixture of Experts,混合专家模型)

了解混合专家模型架构,与 Dense 架构相比有什么优劣

是一种提升大模型推理效率和参数利用率的关键技术

核心思想 :在模型中增加多个"专家模块"(Experts),每个 Expert 是一个子网络(如一个 MLP)。通过一个 门控网络 (Router/Gating Function) 控制,每次只激活少数几个 Experts 来参与计算,达到稀疏激活效果。不是每次推理都激活所有参数,而是"按需"激活部分专家网络,从而降低计算开销、扩大模型容量。

关键部分:

  1. MoE 层:MoE 代替了传统的 transformer 模型中的 FFN。MoE 层包含若干"专家",每个专家是独立的神经网络。在实际应用中,这些专家通常是 FFN,但也可以是更复杂的网络结构

  2. 门控网络:用来决定哪些 token 被发送到哪个专家。有时一个 token 可以被发送到多个专家。

    门控网络本质上是一个可学习的模型组件,参数是可训练的。当输入数据进入门控网络后,门控网络会对输入数据的特征进行提取和分析(比如可能会分析输入文本的语义、语法、关键词等特征)然后根据这些特征计算每个专家模型的分数。(比如有 n 个专家模型,门控网络会输出一个 n 维向量,向量中的每个元素对应一个专家模型的分数。)经过 softmax 函数后被转化为概率值,概率值最大的那个专家模型就会被选择来处理该输入数据。当然也有可能存在多个专家模型以不同权重共同处理输入数据的情况,这个具体取决于 MoE 模型的设计方式。

稠密模型、稀疏模型 :

传统的 transformer 的 FNN 是稠密模型,因为它所有的参数(包括权重和偏置)都会被激活,所有参数都被用于计算输出,没有任何部分被遗弃。

而 MoE 因为有专家的选择,所以仅激活总参数中的一部分,所以是稀疏模型。

某些专家模型过度使用或不足使用应该如何解决(负载平衡问题) ?

如果门控网络倾向于频繁选择某些特定专家,可能导致这些专家过载,而其他专家则闲置,致这些专家未能充分训练。整体而言容易造成计算资源的浪费 和模型性能的下降 。

解决方法:

可以引入负载平衡损失函数,每个 MoE 层都集成一个损失函数,鼓励门控网络将每批次的 token 均匀分配给各个专家,确保所有专家的负载相对均衡。

5. MoE 模型训练过程中存在不稳定的问题如何解决?

门控网络根据输入数据的 logits 值来选择合适的专家。但是在训练过程中过大的 logits 值可能导致数溢出,影响模型的训练效果。

可以引入 router z-loss 来缓解这个问题,loss 的计算方式如下:

简单来说就是对每个专家的 logits 进行指数运算,然后对所有专家的结果求和,并取对数。接着,将该值平方后在批次上取平均。

deepseekMoE 比 MoE 做了哪些改进?

https://www.xiaohongshu.com/explore/67a6d320000000002a00f26f?xsec_source=pc_feed\&note_flow_source=wechat

  1. 专家细粒度分割:MoE 可使不同专家聚焦不同领域的任务,在特定领域上表现出色,但是处理通用知识领域的问题时,专家工作不如垂直领域明显,效果不如 Dense 模型好。因训练和微调的稀疏激活机制,MoE 模型微调不如 Dense 模型直接有效,需要更复杂的调参数和策略 -> 细粒度专家分割。在保持专家总参数数量不变 的情况下,通过将 N 个 FFN 中间隐藏维度缩小为原来的 m 分之 1,即每个专家 FFN 分割成 m 个更小的专家,即总共得到 mN 个细粒度专家。由于每个专家变小,为保持计算成本不变,激活的专家数量增加原来的 m 倍。细粒度分割后,不同知识可被更精确地分解到不同细化后的专家中学习,每个专家能保持更高专业化水平。从组合角度看,显著提升了激活专家的组合灵活性。

  2. 负载均衡问题-> 无辅助损失策略。传统解决方案是增加《负载平衡损失函数》,

    (1)但是 deepspeekV3 通过为每个专家引入一个可动态调整的偏差项 ,并将其添加到选择专家分数中来确定 top-K 路由。在训练过程中,根据专家的负载情况动态调整偏差项:如果专家负载过高,则减小偏差项;如果负载不足,则增加偏差项。同时通过互补的序列级辅助损失来防止单个序列内的极端不平衡。

    (2)还增加节点限制路由机制,使每个 token 最多路由至 M 个节点,减少跨节点通信量,并结合无 token 丢弃策略,在训练和推理阶段均保持负载均衡,确保数据完整性和性能稳定,同时通过计算与通信并行化提升训练吞吐量

优点:

  1. 计算稀疏化每个 token 只激活少数 experts(比如 2/64),节省计算量
  2. 提升表达能力:各专家负责不同特征区域,提升泛化能力和任务表现

缺点:

  1. 可能出现专家负载不平衡的问题
  2. 训练过程中不稳定问题,使用 router z-loss
  3. 调优门槛高:超参数多(expert 数、top-k、均衡损失)

与 Dense 架构(传统大模型架构)对比:

对比项 Dense 架构 MoE 架构
激活方式 所有层都计算 仅激活部分专家
参数量 vs 计算量 参数和计算成正比 参数多,计算少
训练效率 简单但慢 快但路由复杂
表达能力 泛化能力有限 各专家可专精不同任务
可扩展性 难以突破 100B 轻松扩展至万亿参数
应用难度 部署简单 通信调度复杂,需要高效系统支持(如 DeepSpeed)

适用场景:

场景 是否适用 理由
✅ 超大模型预训练 ✅ 如 Google Switch Transformer(1.6T)、DeepSeek-MoE(236B)
✅ 推理效率优化 ✅ 在不损失性能前提下降低 GPU 计算
❌ 小模型或小任务 ❌ 稀疏调度、路由器训练反而成了负担
✅ 多任务学习/多语种 ✅ 不同专家可适配不同语言或任务,天然适合多任务

代表性 MoE 模型:

模型 参数量 特点
Switch Transformer(Google) 1.6T 每 token 激活 1 个 expert,极简高效
GLaM(Google) 1.2T MoE + mixture routing,多任务适配好
DeepSeek-MoE(字节) 236B top-4-of-128 expert 稀疏激活
Mixtral (Mistral) 12.9B x 2-of-8 experts MoE 架构高效对话,延迟低,性能优
GShard(Google) MoE 并行化框架 支持亿级 token 并行训练

二、Mamba、RWKV

了解 Mamba、RWKV 等前沿架构,它们的创新之处。与 transformer 架构的优劣对比

为什么要寻找 Transformer 替代方案?

Transformer 架构虽然强大,但它有几个固有缺点:

  • 🚫 自注意力计算复杂度高 :时间复杂度是 O ( n 2 ) O(n^2) O(n2)(n 为序列长度)
  • 🧠 不擅长处理超长序列(比如 >10K tokens)
  • 🚧 硬件瓶颈:显存占用大、推理效率低

所以一些研究者提出新的结构:Mamba、RWKV 等,目标是用线性复杂度的结构替代 Transformer 的 Attention 机制,同时保留其建模能力。

1. Mamba(2023,Stanford,曼巴)

Mamba 是一种基于 状态空间模型(State Space Model,SSM) 的序列建模架构,用于替代 Attention。SSM 可以看作是 RNN 的变体

核心思想 :用**连续状态空间模型(State Space Models)**构建序列依赖关系。

输入序列通过一个"可学习的滤波器"进行卷积变换,捕捉上下文依赖。

模型中采用一种称为 selective SSM 的机制,它可以高效地只关注重要的上下文片段。

📌 类似于"只在需要的地方应用注意机制",但计算是线性复杂度 O ( n ) O(n) O(n)。

三大创新 :

https://blog.csdn.net/v_JULY_v/article/details/134923301

  1. 对输入信息有选择性处理(Selection Mechanism)
  2. 硬件感知的算法(Hardware-aware Algorithm)
    该算法采用"并行扫描算法"而非"卷积"来进行模型的循环计算(使得不用 CNN 也能并行训练),但为了减少 GPU 内存层次结构中不同级别之间的 IO 访问,它没有具体化扩展状态
    当然,这点也是受到了 S5(Simplified State Space Layers for Sequence Modeling)的启发
  3. 更简单的架构
    将 SSM 架构的设计与 transformer 的 MLP 块合并为一个块(combining the design of prior SSM architectures with the MLP block of Transformers into a single block),来简化过去的深度序列模型架构,从而得到一个包含 selective state space 的架构设计

优点:

优点 描述
⚡ 线性时间复杂度 高效处理超长文本,如 64K+ token
🔍 可解释性更强 通过分析状态的变化来理解傻姑娘下文学习等现象(SSM 是动态系统建模的经典形式
🧠 具备长距记忆能力 比标准 Transformer 更好地建模长依赖

缺点:

  • 架构复杂,训练调参困难
  • 目前缺乏 Chat 类大模型落地经验(仍在发展阶段)
  • 高性能训练还依赖特殊优化(如 FlashConv)

适用场景 :

序列长度很长的任务,如 DNA 序列、生成长视频、写小说

2.RWKV(R(Receptance)- W(Weight)- K(Key)- V(Value))

RNNs:在处理长序列时,内存与计算成本低,但梯度消失与非并行化的特性限制了其扩展性和性能。

Transformers:通过自注意力机制能高效管理依赖关系并支持并行化,但计算复杂度高,尤其在处理长序列时,内存和计算成本极为庞大。

为解决这些问题,RWKV 应运而生。

核心理念 是结合 RNN 与 Transformer 的优势,避免各自的局限。

RWKV 是一种融合 RNN 和 Transformer 的混合架构,具有线性复杂度,完全可以 GPU 并行。

(RWKV 的贡献在于:采用线性计算与内存复杂度,解决 Transformer 的二次复杂度问题。支持并行化训练与推理,

提高计算效率。通过新架构实现类似 Transformer 的性能,同时处理大规模参数,达到与同规模 Transformer 相当的效果。

整体架构 :

RWKV 的核心包括时间混合(Time Mixing)与通道混合(Channel Mixing)模块。它通过引入可训练 的时间衰减向量 W 来捕捉长程依赖,同时支持高效的并行化操作。RWKV 中的 R、W、K、V 代表四个关键元素:

R(Receptance):接收过去输入信息,决定历史数据对当前状态的影响程度。

W(Weight):控制信息随时间的衰减,确保每个时间步的权重逐渐减小。

K 与 V:帮助计算输入之间的相似度并传递实际信息,支持历史信息的选择性聚合。

(Token Shift 与模块设计

Token Shift 机制通过线性插值结合当前时间步与上一时间步的输入,以便更好地捕捉动态变化。这一机制在时间混合与通道混合中均有应用,有效增强了长程依赖关系的捕捉。

时间与通道混合

Time Mix:就是 RWKV

Channel Mix :主要增强模型的非线性能力 。

RWKV 通过 Time Mix 与 Channel Mix 模块的结合,提高了模型在长序列处理中的表现,使得模型能够在保持高效计算的同时,捕捉更复杂的时间与通道依赖。

优点

优点 描述
✅ 支持 token-by-token 推理 非常适合边生成边计算的任务
⚡ 推理速度快 可媲美或超越 GPT 类模型
🧠 参数效率高 训练出来的模型更轻量,效果仍强

缺点:

  • 社区支持较弱,主力是开源志愿者
  • 没有强大的生态(对比 HuggingFace 或 OpenAI)
  • 架构仍然在快速迭代中,不够稳定

与 Transformer 的对比总结

项目 Transformer Mamba RWKV
架构类型 Attention 状态空间模型 (SSM) RNN + Transformer 融合
时间复杂度 O ( n 2 ) O(n^2) O(n2) O ( n ) O(n) O(n) O ( n ) O(n) O(n)
训练并行性 强 中等 强
推理效率 中等 高 高(可边推理边生成)
长序列能力 一般 很强 强
工程成熟度 非常高 尚在发展 较低
  1. 为什么 Transformer 不适合长文本建模?
  2. Mamba 和 Attention 的区别是什么?
  3. RWKV 是怎么实现并行 RNN 的?
  4. 请比较 Transformer、Mamba、RWKV 的计算复杂度与推理能力
  5. 你会选择哪个架构用于边生成边推理的应用场景?为什么?
相关推荐
沫璃染墨4 分钟前
《从零入门Linux系统篇(五十八):线程篇·十一——线程安全与死锁详解:从可重入到多锁管理》
linux·服务器·开发语言·c++·驱动开发·安全·架构
用户5708462574409 分钟前
AI 会话该什么时候重开?一份「上下文卫生」的判断清单
架构
励志不掉头发的内向程序员24 分钟前
从鼠标点击到画出一条线:CAD 交互层的状态机设计
后端·架构
bullkingluo31 分钟前
从零到一搭建企业级智能问答系统:Ch14 · 三层记忆与断点续跑
架构·llm·agent
400分32 分钟前
从零到「机械臂会放试管」:π0.5 VLA 真机部署完全指南(第二节)
人工智能·架构
滑翔的企鹅33 分钟前
从真实系统看 CMS 与知识内容平台的架构演进
架构
黑妹天下第一乖44 分钟前
第 04 讲:阿加犀 AIMO 模型优化平台与 Model Farm 模型广场实战
人工智能·嵌入式硬件·矩阵·架构·iot
HLAIA光子1 小时前
RAG Chunks 切分优化后成本骤降 86%
后端·性能优化·架构
Dawson Zhu2 小时前
《Agentic Design Patterns》第 2 章导读:路由(Routing)
人工智能·语言模型·架构·aigc·agi
传奇开心果编程3 小时前
【Compose Multiplatform 跨端开发学与练】第6课 状态管理与架构
android·学习·ui·ios·架构·kotlin·composer