LLM面面观之MoE

本文探讨了MoE(混合Experts)架构在大语言模型中的应用,介绍了其原理、关键组件如滑动窗口注意力和专家选择机制,并提供了MistralAI模型的源码分析。文章还讨论了如何结合LoRA和QLoRA进行微调,以及MoE的稀疏性特点。
部署运行你感兴趣的模型镜像

1. 背景

根据本qiang~最新的趋势观察,基于MoE架构的开源大模型越来越多,比如马斯克的Grok-1(314B), Qwen1.5-MoE-A2.7B等,因此想探究一下MoE里面的部分细节。

此文是本qiang~针对大语言模型的MoE的整理,包括原理、流程及部分源码

2. MoE原理

MoE的流行源于”欧洲的OpenAI” Mistral AI发布的论文及模型《Mixtral of Experts》,评测集上的效果吊打众多开源模型,如Llama 2 70B和GPT3.5。

《Mixtral of Experts》基础模型使用的是Mistral AI自研的Mistral 7B,该模型的特点包括:滑窗注意力(Sliding Window Aattention), 滚动缓冲区缓存(Rolling Buffer Cache)以及预填充-分块(Pre-fill and Chunking),具体细节可以查阅文末的论文地址。

本文以《Mixtral of Experts》为引子,探究MoE的相关细节,MoE的原理如下图所示:

图2.1 MoE的原理

(1) Transformers架构中的每一层中的FFN网络均替换为了8个FFN(专家),且由一个网关路由(gate router)进行控制

(2) 针对每一个token,每一层的网关路由仅选择其中的2个FFN(专家)来处理当前状态并进行加权输出

(3) 结果就是,每一个token访问了47B参数,但是在推理阶段仅仅使用了13B的激活参数(即,只使用2个专家,冻结其他6个专家)。

(4) 与Dropout机制对比,Dropout让部分神经元失活,而MoE是让部分专家失活。

3. 源码

本qiang~研读并尝试执行了Mistral官网的github推理代码,该代码框架非常适合新手,无他,只因其几乎只是在torch上层做的封装,很少引擎其他第三方库,不像transformers,功能强大,但不适合新手研读代码…

为了普适性,下面的代码截取了transformers框架中的代码。

首先看下通用Transformers中FFN中的代码模块,代码位置在transformers.models.mistral.modeling_mistral, 主要流程是:

(1) 先经过gate_proj和up_proj的2个[hidden_size, intermediate_size]的线性转换

(2) 使用激活函数对gate_proj进行激活

(3) 二者的内积再经过down_proj线性转换。

class MistralMLP(nn.Module):
    def __init__(self, config):
        super().__init__()
        self.config = config
        self.hidden_size = config.hidden_size
        self.intermediate_size = config.intermediate_size
        self.gate_proj = nn.Linear(self.hidden_size, self.intermediate_size, bias=False)
        self.up_proj = nn.Linear(self.hidden_size, self.intermediate_size, bias=False)
        self.down_proj = nn.Linear(self.intermediate_size, self.hidden_size, bias=False)
        self.act_fn = ACT2FN[config.hidden_act]

    def forward(self, x):
        return self.down_proj(self.act_fn(self.gate_proj(x)) * self.up_proj(x))

再来看下MoE中的专家模块,代码位置在transformers.models.mixtral.modeling_mixtral,主要流程是:

(1) 首先经过网关路由self.gate

(2) 然后选择其中2个专家,并归一化

(3) 之后遍历每个专家网络,并按照expert_mask进行筛选

(4) 如果expert_mask有值,则选择指定部分的隐藏层进行FFN操作,且输出结果进行加权

(5) 最后原地增加先前初始化的最终结果变量final_hidden_states

class MixtralSparseMoeBlock(nn.Module):

    def __init__(self, config):
        super().__init__()
        self.hidden_dim = config.hidden_size
        self.ffn_dim = config.intermediate_size
        self.num_experts = config.num_local_experts
        self.top_k = config.num_experts_per_tok

        # gating
        self.gate = nn.Linear(self.hidden_dim, self.num_experts, bias=False)

        self.experts = nn.ModuleList([MixtralBlockSparseTop2MLP(config) for _ in range(self.num_experts)])

    def forward(self, hidden_states: torch.Tensor) -> torch.Tensor:
        """ """
        batch_size, sequence_length, hidden_dim = hidden_states.shape
        hidden_states = hidden_states.view(-1, hidden_dim)
        # router_logits: (batch * sequence_length, n_experts)
        router_logits = self.gate(hidden_states)

        routing_weights = F.softmax(router_logits, dim=1, dtype=torch.float)
        routing_weights, selected_experts = torch.topk(routing_weights, self.top_k, dim=-1)
        routing_weights /= routing_weights.sum(dim=-1, keepdim=True)
        # we cast back to the input dtype
        routing_weights = routing_weights.to(hidden_states.dtype)

        final_hidden_states = torch.zeros(
            (batch_size * sequence_length, hidden_dim), dtype=hidden_states.dtype, device=hidden_states.device
        )

        # One hot encode the selected experts to create an expert mask
        # this will be used to easily index which expert is going to be sollicitated
        expert_mask = torch.nn.functional.one_hot(selected_experts, num_classes=self.num_experts).permute(2, 1, 0)

        # Loop over all available experts in the model and perform the computation on each expert
        for expert_idx in range(self.num_experts):
            expert_layer = self.experts[expert_idx]
            idx, top_x = torch.where(expert_mask[expert_idx])

            if top_x.shape[0] == 0:
                continue

            # in torch it is faster to index using lists than torch tensors
            top_x_list = top_x.tolist()
            idx_list = idx.tolist()

            # Index the correct hidden states and compute the expert hidden state for
            # the current expert. We need to make sure to multiply the output hidden
            # states by `routing_weights` on the corresponding tokens (top-1 and top-2)
            current_state = hidden_states[None, top_x_list].reshape(-1, hidden_dim)
            current_hidden_states = expert_layer(current_state) * routing_weights[top_x_list, idx_list, None]

            # However `index_add_` only support torch tensors for indexing so we'll use
            # the `top_x` tensor here.
            final_hidden_states.index_add_(0, top_x, current_hidden_states.to(hidden_states.dtype))
        final_hidden_states = final_hidden_states.reshape(batch_size, sequence_length, hidden_dim)
        return final_hidden_states, router_logits

其中MixtralBlockSparseTop2MLP代码如下,可以看到和传统MistralMLP内容完全一致。

class MixtralBlockSparseTop2MLP(nn.Module):
    def __init__(self, config: MixtralConfig):
        super().__init__()
        self.ffn_dim = config.intermediate_size
        self.hidden_dim = config.hidden_size

        self.w1 = nn.Linear(self.hidden_dim, self.ffn_dim, bias=False)
        self.w2 = nn.Linear(self.ffn_dim, self.hidden_dim, bias=False)
        self.w3 = nn.Linear(self.hidden_dim, self.ffn_dim, bias=False)

        self.act_fn = ACT2FN[config.hidden_act]

    def forward(self, hidden_states):
        current_hidden_states = self.act_fn(self.w1(hidden_states)) * self.w3(hidden_states)
        current_hidden_states = self.w2(current_hidden_states)
        return current_hidden_states

4. MoE微调

由于MoE只是将每一层的FFN改变为了每一层的gate网关路由+8个FFN专家,且gate网关路由和8个专家内部均为线性运算,所以可以无缝地结合LoRA、QLoRA进行指令微调。

可以参考开源项目:https://github.com/yangjianxin1/Firefly

5. 答疑解惑

(1) 问:MoE 8*7B的模型是56B参数?

答:MoE 8*7B的参数量是47B,而不是56B,原因是每一层除了8个专家网络外,其他层均是复用的。

(2) 问:MoE的基础模型是Mistral 7B?

答:不是,MoE的模型架构与Mistral 7B相同,但其中的FFN替换为了8个FFN,且MoE是基于多语言数据集预训练而来的。

(3) MoE的稀疏性(sparse)体现在哪里?

答:在训练和推理时,同时只有两个专家网络会被激活,进行前向计算,其它专家网络处于失活状态。

6. 总结

一句话足矣~

本文主要针对大语言模型的MoE,包括原理及部分源码。

此外,建议大家可以针对源码进行运行,关于源码,欢迎大家一块交流。

7. 参考

(1) Mistral 7B:https://arxiv.org/pdf/2310.06825v1.pdf

(2) MoE: https://arxiv.org/pdf/2401.04088v1.pdf

(3) MoE开源指令微调框架Firefly: https://github.com/yangjianxin1/Firefly

您可能感兴趣的与本文相关的镜像

ComfyUI

ComfyUI

AI应用
ComfyUI

ComfyUI是一款易于上手的工作流设计工具,具有以下特点:基于工作流节点设计,可视化工作流搭建,快速切换工作流,对显存占用小,速度快,支持多种插件,如ADetailer、Controlnet和AnimateDIFF等

<think>好的,用户想了解深度求索公司的两个模型:DeepSeek-MoE和DeepSeek-LLM的区别。首先我需要回忆这两个模型的相关信息,确保自己理解正确。 首先,DeepSeek-MoE是基于MoE架构的,而DeepSeek-LLM是传统的密集模型。MoE是混合专家系统,它通过多个专家网络处理不同任务,可能更高效。而LLM通常是Transformer架构,参数密集,所有参数都参与计算。 接下来要考虑它们的结构差异。MoE模型可能参数量更大,但计算成本较低,因为每次激活部分参数。而LLM虽然参数少,但计算时使用全部参数,可能更耗资源。例如,DeepSeek-MoE-16B有160亿参数,但每个token只使用约29亿,而DeepSeek-LLM-7B有70亿参数,全部参与计算。 然后是性能方面,用户可能关心效果和效率。MoE在相同计算成本下可能效果更好,或者相同效果时更高效。比如,DeepSeek-MoE-16B在相同计算量下接近DeepSeek-LLM-7B的效果,但参数量更大但计算量少。 应用场景的区别也很重要。MoE适合需要高效率、处理多样化任务的场景,LLM适合对效果要求高且资源充足的情况。用户可能需要根据自身需求选择。 另外,训练策略的不同。MoE需要更复杂的训练方法,比如路由策略和负载均衡,而LLM训练相对标准。用户如果是技术人员,可能需要知道这些细节。 用户可能的背景是什么?可能是开发者、研究者,或者企业用户。他们可能需要选择适合的模型来部署应用。需要解释清楚两者的优缺点,帮助用户做决策。 有没有可能用户没提到的深层需求?比如成本考量、部署难度、模型的可扩展性。这些因素也可能影响他们的选择,但用户没有明确问,可能需要简要提及。 最后要确保回答准确,结构清晰,分点说明区别,用例子和参数帮助理解。避免使用太专业的术语,保持口语化,但核心概念要准确。</think>DeepSeek-MoE 和 DeepSeek-LLM 是深度求索(DeepSeek)公司推出的两种大语言模型,它们在架构设计和应用场景上有明显区别。以下是主要差异的对比: --- ### **1. 模型架构** - **DeepSeek-MoE** - 基于 **MoE(Mixture of Experts,混合专家)** 架构,将模型拆分为多个“专家”子网络,每个输入仅激活部分专家(如2-4个),实现“分而治之”的高效计算。 - 典型示例:DeepSeek-MoE-16B(总参数量160亿),每个token仅激活约29亿参数,计算量显著降低。 - **DeepSeek-LLM** - 采用 **传统密集架构(Dense Model)**,所有参数参与每个输入的推理,计算资源消耗较高。 -7B(70亿参数),每个token需调用全部参数。 --- ### **2. 性能与效率** - **计算效率** - **MoE**:通过稀疏激活减少计算量,适合高吞吐场景。例如,DeepSeek-MoE-16B在相同计算成本下,性能接近DeepSeek-LLM-7B。 - **LLM**:计算密集,资源需求高,但同等参数量下通常表现更强(如DeepSeek-LLM-67B在数学、代码任务上优于主流开源模型)。 - **模型效果** - **MoE**:在相同计算成本下,效果可媲美小规模密集模型,但参数量更大(如16B MoE vs. 7B LLM)。 - **LLM**:参数量直接决定能力上限,大参数模型(如67B)在复杂任务中表现更优。 --- ### **3. 应用场景** - **DeepSeek-MoE** - 适合需要**高效率、低成本处理多样化任务**的场景,例如实时对话、多任务API服务。 - 优势:在有限算力下支持更大模型规模,平衡效果与成本。 - **DeepSeek-LLM** - 适合**对效果要求极高且资源充足**的场景,如复杂推理、代码生成、数学问题求解。 - 优势:模型能力上限更高,尤其在专业领域表现突出。 --- ### **4. 训练复杂度** - **MoE**:需额外设计专家路由策略、负载均衡(防止某些专家被过度使用),训练难度较高。 - **LLM**:训练流程相对标准化,依赖大规模数据和算力。 --- ### **总结对比表** | 特性 | DeepSeek-MoE | DeepSeek-LLM | |--------------|----------------------------| | **架构** | 稀疏激活(MoE) | 密集全参数激活 | | **计算效率** | 高(动态激活专家) | 较低(全参数参与) | | **适用场景** | 高吞吐、多任务并行 | 复杂任务、高精度需求 | | **典型参数量** | 16B(总参数量) | 7B/67B(实际调用参数量) | | **资源需求** | 更低计算成本 | 更高计算成本 | --- ### **选择建议** - 若需**低成本部署且任务多样**,优先考虑MoE架构(如DeepSeek-MoE-16B)。 - 若追求**极致效果且算力充足**,选择大规模密集模型(如DeepSeek-LLM-67B)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

mengrennwpu

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值