DeepSeekMoE:迈向混合专家语言模型的终极专业化

news2025/4/22 3:01:26

一、结论写在前面

论文提出了MoE语言模型的DeepSeekMoE架构,目的是实现终极的专家专业化(expert specialization)。通过细粒度的专家分割和共享专家隔离,DeepSeekMoE相比主流的MoE架构实现了显著更高的专家专业化和性能。从较小的2B参数规模开始,论文验证了DeepSeekMoE的优势,展示了其接近MoE模型上限性能的能力。此外,论文证明DeepSeekMoE具有比GShard更高水平的专家特化。

放大到16B参数规模,论文在2T标记上训练DeepSeekMoE 16B,并展示了其与DeepSeek 7B和LLaMA2 7B可比的卓越性能,仅需要大约40%的计算量。另外,论文进行了监督微调用于对齐,基于DeepSeekMoE 16B构建了一个MoE聊天模型,进一步展示了其适应性和通用性。此外,论文初步探索以将DeepSeekMoE放大到145B参数:DeepSeekMoE 145B相对于GShard架构仍保持实质性优势,并展示了与DeepSeek 67B可比的性能,仅使用28.5%(可能甚至18.2%)的计算量。

论文公开了了DeepSeekMoE 16B的模型checkpoint,它可以在40GB内存的单GPU上部署。

Figure 1 | DeepSeekMoE 16B与开源模型在Open LLM Leaderboard上的比较。红色虚线是从除DeepSeekMoE 16B之外的所有模型的数据点线性拟合得到的。DeepSeekMoE 16B始终以很大的优势胜过具有类似激活参数数量的模型,并在性能上与LLaMA2 7B相媲美,后者的激活参数数量大约是其2.5倍

二、论文的简单介绍

2.1 论文的背景

最近的研究和实践通过充分的可用训练数据经验性地证明,扩大语言模型的参数和计算预算可以获得显著更强的模型。然而,必须承认的是,将模型扩展到极大规模的努力也与极高的计算成本相关联。考虑到成本,混合专家(Mixture-of-Experts,MoE)架构已成为一种流行的解决方案。它可以实现参数扩展,同时将计算成本保持在适度水平。

尽管MoE架构展示出有前景的潜力,但现有MoE架构可能存在知识杂交(f knowledge hybridity )和知识冗余(knowledge redundancy)的问题,这限制了专家专业化,即每个专家获得非重叠和专注的知识。传统的MoE架构用MoE层代替Transformer中的前馈网络(Feed-Forward Networks,FFN)。每个MoE层由多个专家组成,每个在结构上与标准FFN相同,每个token分配给一个或两个专家。这种架构体现出两个潜在问题:

(1)知识杂交:现有的MoE实践通常采用有限数量的专家(例如8或16),因此分配给特定专家的标记可能会涵盖不同的知识。因此,指定的专家将倾向于在其参数中汇集不同类型的知识,这些知识很难同时利用。

(2)知识冗余:分配给不同专家的token可能需要共同知识。因此,多个专家可能会在各自的参数中收敛到共享知识的获取,从而导致专家参数中的冗余。这些问题共同阻碍了现有MoE实践中的专家专业化,使其无法达到MoE模型的理论上限性能。

2.2 论文的方案

Figure 2 | DeepSeekMoE的示意图。子图(a)展示了具有传统top-2路由策略的MoE层。子图(b)说明了精细的专家细分策略。随后,子图(c)展示了共享专家隔离策略的集成,构成了完整的DeepSeekMoE架构。值得注意的是,在这三种架构中,专家参数和计算成本保持不变
 

DeepSeek MoE设计上述结构的前提在于假设:特定专家能可以覆某种领域知识。专家的细粒度切分可以避免一个专家覆盖太多领域把知识学杂了;共享专家可以让一些公共知识每次都参与计算。

同时期国外开源的Mistral of Experts也放了技术报告,它是完全照着GPT-4解密报告复现的MoE,模型结构就是经典的GShard方式。技术报告里的Sec. 5 Routing analysis展示很多路由工作的特征,这些都是非常新鲜的一手资料。有一些结论很有趣:

Mixtral of Experts

  1. 路由规则与文本的语义主题无关,这意味着专家并不专门精通某一领域的知识。
  2. 路由规则展示出了一定的语法特性,例如,某些关键词经常被分配给同一位专家。
  3. 路由规则还展示了位置的局部性,相邻的token通常被路由到同一位专家,这表明token在句子中的位置与路由选择有关。

结论1是比较颠覆传统认知的,又给了公众号做标题党一次机会。

混合专家系统里根本没专家?开源MoE模型论文引网友热议

那么也就是说按照Mistral报告的观察,DeepSeek-MoE设计的动机可能不太成立。我觉得DeepSeek开发者可以参考Mistral的Sec 5做实验看看结论是否一致。

为应对上述两个潜在问题,论文提出了DeepSeekMoE,这是一种创新的MoE架构,专门设计用于实现终极专家专业化。架构包含两大主要策略:

细粒度专家细分

在专家数量有限的情况下,分配给特定专家的标记更有可能涵盖各种类型的知识。因此,指定的专家将意图在其参数中学习非常不同类型的知识,并且它们很难同时被利用。然而,如果每个标记可以路由到更多的专家,不同的知识将有可能分解并在不同的专家中学到。在这种情况下,每个专家仍然可以保持高水平的专业化,有助于在专家之间实现更专注的知识分布。

为了实现这一目标,在保持一致的专家参数数量和计算成本的同时,通过更细粒度地分割专家。更细致的专家分割使得激活的专家组合更加灵活和适应。具体而言,在图 2(a) 中显示的典型 MoE 架构之上,我们通过将每个专家 FFN 的中间隐藏维度减小到其原始大小的 1/m 倍来将每个专家细分为 m 个较小的专家。由于每个专家变得较小,相应地,我们也增加激活的专家数量到 m 倍,以保持相同的计算成本,如图 2(b) 所示。

从组合的角度看,细粒度专家分割策略极大地增强了激活专家的组合灵活性。举例来说,考虑 N = 16 的情况。典型的 top-2 路由策略可以产生 16 2 = 120 种可能的组合。相比之下,如果每个专家分为 4 个较小的专家,细粒度的路由策略可以产生 64 8 = 4,426,165,368 种潜在的组合。组合灵活性的激增增强了实现更准确和有针对性的知识获取的潜力。

共享专家隔离

在传统的路由策略中,分配给不同专家的标记可能需要一些共同的知识或信息。因此,多个专家可能会在各自的参数中收敛于获取共享知识,从而导致专家参数的冗余。然而,如果有专门负责捕捉和 cons共享知识的专业专家,跨不同上下文的参数冗余将得到缓解。这种冗余的减轻将有助于构建更具参数效率的模型,并拥有更专业化的专家。

为实现这一目标,除了精细的专家细分策略之外,进一步隔离 𝐾𝑠个专家作为共享专家。无论路由模块如何,每个标记都将被确定性地分配给这些共享专家。为了保持恒定的计算成本,其他路由专家中激活的专家的数量将减少 𝐾,如图2(c)所示。

负载平衡考虑

自动学习的路由策略可能会遇到负载不平衡的问题,表现为两个显著的缺陷。首先,存在路由崩溃的风险,即模型始终只选择少数专家,阻止其他专家充分训练。其次,如果专家分布在多个设备上,负载不平衡可能会加剧计算瓶颈。

专家级平衡损失:为了缓解路由崩溃的风险,论文还采用了专家级平衡损失。

设备级平衡损失:除了专家级平衡损失外,论文引入了设备级平衡损失。当旨在缓解计算瓶颈时,就不必在专家级别强制执行严格的平衡约束,因为对负载平衡的过度约束会损害模型性能。相反,论文的主要目标是确保设备之间的平衡计算

2.3 论文的效果

从一个仅有2B参数的适度规模开始,验证了DeepSeekMoE架构的优势。在跨越多种任务的12个零试验或少试验基准测试中进行评估。实证结果表明,DeepSeekMoE 2B大大超过了GShard 2B,甚至匹配了GShard 2.9B,一个更大的MoE模型,具有1.5倍的专家参数和计算量。值得注意的是,DeepSeekMoE 2B的性能几乎接近具有相等参数数量的密集对应物,这为MoE语言模型设定了严格的上限。为了获得更深入的见解,对DeepSeekMoE进行了精心的消融研究和专家专业化分析。这些研究验证了细粒度专家细分和共享专家隔离的有效性,并提供了支持DeepSeekMoE可以实现高水平专家专业化的经验证据。

将模型参数扩大到16B,并在包含2T个标记的大规模语料上训练DeepSeekMoE 16B。评估结果显示,与仅使用约40%的计算量,DeepSeekMoE 16B达到与在相同2T语料上训练的密集模型DeepSeek 7B相当的性能。

还将DeepSeekMoE与开源模型进行了比较,评估结果表明,DeepSeekMoE 16B始终以大幅度超过参数数量相近的模型,并与LLaMA2 7B的性能相当,后者的激活参数数约为前者的2.5倍。图1展示了在Open LLM Leaderboard1上的评估结果。

另外,论文进行了监督微调(SFT)用于对齐,将模型转换为聊天模型。评估结果显示,在聊天设置中,DeepSeekMoE Chat 16B也取得了与DeepSeek Chat 7B和LLaMA2 SFT 7B相当的性能。这些结果鼓舞我们进一步进行扩展DeepSeekMoE到145B的初步尝试。实验结果仍然一致验证了其相对于GShard架构的重大优势。此外,它显示了与DeepSeek 67B相当的性能,仅使用28.5%(可能甚至只有18.2%)的计算量。

Table 1 | 验证实验的评估结果。粗体字表示最佳结果。与其他MoE架构相比,DeepSeekMoE表现出明显的性能优势

Table 2 | DeepSeekMoE、更大的GShard模型和更大的dense模型之间的比较。在“#专家”一行中,𝑎 + 𝑏表示𝑎个共享专家和𝑏个路由专家。在“#激活专家”一行中,𝑎 + 𝑏表示𝑎个激活的共享专家和𝑏个激活的路由专家。DeepSeekMoE在性能上与包含1.5倍专家参数和计算的GShard模型相媲美。此外,DeepSeekMoE几乎接近具有16倍FFN参数的dense模型的性能,这在模型容量方面为MoE模型设定了上限

Figure 3 | DeepSeekMoE的消融研究。为清晰展示,性能经过归一化处理。所有比较的模型具有相同数量的参数和激活参数。我们可以看到,精细的专家细分和共享专家隔离都有助于更强大的整体性能

Figure 4 | 关于禁用顶级路由专家比例的Pile损失。值得注意的是,DeepSeekMoE对禁用顶级路由专家比例的敏感性更大,表明DeepSeekMoE中路由专家之间的冗余较低

Table 3 | DeepSeek 7B和DeepSeekMoE 16B之间的比较。粗体字表示最佳或接近最佳。仅占40.5%的计算量,DeepSeekMoE 16B在性能上与DeepSeek 7B相媲美

Table 4 | LLaMA2 7B和DeepSeekMoE 16B之间的比较。仅占39.6%的计算量,DeepSeekMoE 16B在大多数基准测试上胜过LLaMA2 7B

Table 5 | LLaMA2 SFT 7B、DeepSeek Chat 7B和DeepSeekMoE Chat 16B之间的比较,这三个模型都在相同的SFT数据上进行了微调。与两个7B dense模型相比,DeepSeekMoE Chat 16B在大多数基准测试上仍然在仅占40%的计算量下达到相当或更好的性能

Table 6 | DeepSeek 67B(Dense)和约140B总参数规模的MoE模型之间的比较。在“#专家”和“#激活专家”一行中,𝑎 + 𝑏分别表示𝑎个共享专家和𝑏个路由专家。粗体字表示最佳或接近最佳的性能,最后一列除外。DeepSeekMoE 145B,甚至仅有一半激活专家参数的DeepSeekMoE 142B在性能上大大优于GShard 137B。此外,以28.5%的计算量,DeepSeekMoE 145B在性能上与DeepSeek 67B相媲美

论文贡献总结如下:

  • 架构创新。我提出了DeepSeekMoE,这是一种创新性的MoE架构,旨在实现终极的专家特化,它采用细粒度专家分割和共享专家隔离两种主要策略。

  • 经验证明进行了广泛的实验来经验证实DeepSeekMoE架构的有效性。实验结果验证了DeepSeekMoE 2B中的高水平专家特化,并表明DeepSeekMoE 2B几乎可以接近MoE模型的上限性能。

  • 可扩展性。将DeepSeekMoE扩大到训练一个160亿参数的模型,并展示仅使用约40%的计算量,DeepSeekMoE 16B就达到了DeepSeek 7B和LLaMA2 7B的可比性能。我们还进行了将DeepSeekMoE扩大到1450亿的参数的初步尝试,突出了其相对于GShard架构的持续优势,并展示了与DeepSeek 67B可比的性能。

  • MoE的对齐。成功地对DeepSeekMoE 16B进行了监督微调来创建对齐的聊天模型,展示了DeepSeekMoE 16B的适应性和通用性。

  • 公开发布。向公众发布了DeepSeekMoE 16B的模型checkpoint。值得注意的是,这个模型可以在不需要量化的情况下在具有40GB内存的单GPU上部署。

论文标题:DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models

论文链接:https://arxiv.org/pdf/2401.06066.pdf

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2291720.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

扩散模型(二)

相关阅读:扩散模型(一) Parameterization of L t L_t Lt​ for Training Loss 回想一下,我们需要训练一个神经网络来近似反向扩散过程中的条件概率分布,即, p θ ( x t − 1 ∣ x t ) N ( x t − 1 ; μ θ ( x t…

【Numpy核心编程攻略:Python数据处理、分析详解与科学计算】2.18 对象数组:在NumPy中存储Python对象

2.18 对象数组:在NumPy中存储Python对象 目录 #mermaid-svg-shERrGOBuM2rBzeB {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-shERrGOBuM2rBzeB .error-icon{fill:#552222;}#mermaid-svg-shERrGOBuM2rB…

LabVIEW双光子成像系统:自主创新,精准成像,赋能科研

双光子成像系统:自主创新,精准成像,赋能科研 第一部分:概述 双光子成像利用两个低能量光子同时激发荧光分子,具有深层穿透、高分辨率、低光损伤等优势。它能实现活体深层组织的成像,支持实时动态观察&…

bagging框架

bagging 1 bagging介绍 Bagging的全称是Bootstrap Aggregating,其思想是通过将许多相互独立的学习器的结果进行结合,从而提高整体学习器的泛化能力 bagging框架流程:首先,它从原始数据集中使用有放回的随机采样方式抽取多个子集…

《机器学习数学基础》补充资料:仿射变换

本文是对《机器学习数学基础》 第 2 章 2.2.4 节齐次坐标系的内容拓展。 1. 名称的来源 仿射,是英文单词 affine 的中文翻译。 单词 affine,读音:[ə’faɪn]。来自于英语 affinity。英语词根 fin 来自于拉丁语 finis,表示“边…

冲刺一区!挑战7天完成一篇趋势性分析GBD DAY1-7

Day1. 公开数据库的挖掘太火热了,其中GBD数据库的挖掘又十分的火爆.那我就来挑战一篇GBD、一篇关于趋势性分析的GBD! GBD数据库挖掘是目前的四大刊常客,经常出现在顶级期刊上面。这个数据库亮点就是:可视化,统计学简单、而数据可…

掌握API和控制点(从Java到JNI接口)_36 JNI开发与NDK 04

4、 *.so的入口函数&#xff1a;JNI_OnLoad() VM (virtual machine)的角色 Java代码在VM上执行。在执行Java代码的过程中&#xff0c;如果Java需要与本地代码(*.so)沟通时&#xff0c; VM就会把*.so視为插件<Tn>而加载到VM里。然后让Java函数呼叫到这插件<Tn>里的…

Spring Bean 容器

技术成长&#xff0c;是对场景设计细节不断的雕刻&#xff01; 你觉得自己的技术什么时候得到了快速的提高&#xff0c;是CRUD写的多了以后吗&#xff1f;想都不要想&#xff0c;绝对不可能&#xff01;CRUD写的再多也只是能满足你作为一个搬砖工具人&#xff0c;敲击少逻辑流…

Maven全解析:从基础到精通的实战指南

概念&#xff1a; Maven 是跨平台的项目管理工具。主要服务基于 Java 平台的构建&#xff0c;依赖管理和项目信息管理项目构建&#xff1a;高度自动化&#xff0c;跨平台&#xff0c;可重用的组件&#xff0c;标准化的流程 依赖管理&#xff1a; 对第三方依赖包的管理&#xf…

【开源免费】基于SpringBoot+Vue.JS贸易行业crm系统(JAVA毕业设计)

本文项目编号 T 153 &#xff0c;文末自助获取源码 \color{red}{T153&#xff0c;文末自助获取源码} T153&#xff0c;文末自助获取源码 目录 一、系统介绍二、数据库设计三、配套教程3.1 启动教程3.2 讲解视频3.3 二次开发教程 四、功能截图五、文案资料5.1 选题背景5.2 国内…

高效接口限流:基于自定义注解与RateLimiter的实践

在高并发场景下&#xff0c;接口的流量控制是保证系统稳定性和提升性能的关键之一。通过实现接口限流&#xff0c;我们可以有效避免系统在访问高峰时发生崩溃。本文将详细介绍如何通过自定义注解和切面编程结合RateLimiter来实现接口的限流功能&#xff0c;以应对高并发请求。 …

nodejs:express + js-mdict 网页查询英汉词典,能播放声音

向 DeepSeek R1 提问&#xff1a; 我想写一个Web 前端网页&#xff0c;后台用 nodejs js-mdict, 实现在线查询英语单词 1. 项目结构 首先&#xff0c;创建一个项目目录&#xff0c;结构如下&#xff1a; mydict-app/ ├── public/ │ ├── index.html │ ├── st…

无人机PX4飞控 | PX4源码添加自定义uORB消息并保存到日志

PX4源码添加自定义uORB消息并保存到日志 0 前言 PX4的内部通信机制主要依赖于uORB&#xff08;Micro Object Request Broker&#xff09;&#xff0c;这是一种跨进程的通信机制&#xff0c;一种轻量级的中间件&#xff0c;用于在PX4飞控系统的各个模块之间进行高效的数据交换…

【IocDI】_存储Bean的五大类注解及getBean的使用

目录 1. Bean的存储 1.1 类注解 1.1.1 Controller&#xff1a;控制器存储 1.1.2 Service&#xff1a;服务存储 1.1.3 Repository&#xff1a;仓库存储 1.1.4 Component&#xff1a;组件存储 1.1.5 Configuration&#xff1a;配置存储 1.2 五大类注解之间的关系 2. get…

VLAN 基础 | 不同 VLAN 间通信实验

注&#xff1a;本文为 “ Vlan 间通信” 相关文章合辑。 英文引文&#xff0c;机翻未校。 图片清晰度限于原文图源状态。 未整理去重。 How to Establish Communications between VLANs? 如何在 VLAN 之间建立通信&#xff1f; Posted on November 20, 2015 by RouterSwi…

GRE阅读双线阅读 --青山学堂GRE全程班 包括 阅读、数学、写作、填空、背单词

新版GRE考试整体结构 section题量时间写作1篇issue30min语文S112道题(7道填空5道阅读)18min数学S112道题21min语文S215道题(7道填空8道阅读)23min数学S215道题26min Tips: 写作结束后&#xff0c;语文和数学的顺序不固定&#xff0c;2中可能&#xff1a; issue -> V ->…

5.5.1 面向对象的基本概念

文章目录 基本概念面向对象的5个原则 基本概念 面向对象的方法&#xff0c;特点时其分析与设计无明显界限。虽然在软件开发过程中&#xff0c;用户的需求会经常变化&#xff0c;但客观世界对象间的关系是相对稳定的。对象是基本的运行实体&#xff0c;由数据、操作、对象名组成…

Java_类加载器

小程一言类加载器的基础双亲委派模型核心思想优势 各类加载器的职责 类加载器的工作流程举例&#xff1a;如何在Java中使用类加载器启动类加载器、扩展类加载器与系统类加载器输出解释自定义类加载器 类加载器与类冲突总结 小程一言 本专栏是对Java知识点的总结。在学习Java的过…

开源音乐管理软件Melody

本文软件由网友 heqiusheng 推荐。不过好像已经是一年前了 &#x1f602; 简介 什么是 Melody &#xff1f; Melody 是你的音乐精灵&#xff0c;旨在帮助你更好地管理音乐。目前的主要能力是帮助你将喜欢的歌曲或者音频上传到音乐平台的云盘。 主要功能包括&#xff1a; 歌曲…

一、TensorFlow的建模流程

1. 数据准备与预处理&#xff1a; 加载数据&#xff1a;使用内置数据集或自定义数据。 预处理&#xff1a;归一化、调整维度、数据增强。 划分数据集&#xff1a;训练集、验证集、测试集。 转换为Dataset对象&#xff1a;利用tf.data优化数据流水线。 import tensorflow a…