从MLA到DeepSeekMoE：DeepSeek系列大模型架构演进与技术拆解

很多人聊大模型架构的时候总喜欢从Transformer开始铺开但真正把架构演进讲透的恰恰要看国内开源模型这几年的实操路线。我自己的感受是2024年初那会儿大家还在卷榜单到了年底风向就变了变成卷单次推理成本、卷训练效率、卷上下文长度。而贯穿这条线最典型、也最值得拆解的样本非DeepSeek系列莫属。这个东西是什么简单说DeepSeek系列是一套从通用大模型底座到推理增强模型的开源体系覆盖了Dense模型、MoE模型、纯强化学习推理模型以及蒸馏小模型。它能解决什么问题往大了说是“用更低的算力门槛跑出可用的模型效果”往小了说是“给研究者和业务方一套能直接用、能二次开发的权重和架构参考”。适合谁看如果你在选开源底座、准备做长上下文应用、想搞清楚MLA和DeepSeekMoE到底怎么省显存或者单纯想了解国内开源模型这几代架构是怎么一步步走到今天的这篇梳理应该对你有用。1. 起点为什么开源大模型的架构史绕不开DeepSeek系列先说个背景。早期国内开源模型的做法多数是沿着公开论文的路线把已有结构复现一遍加上更大数据量、更多训练步骤效果是有的但架构维度的原创贡献不多。DeepSeek系列打破这个局面的方式不是靠一次性堆出多大的参数而是连续几代都在关键结构上做了“减法”和“针对性加法”尤其是2024年之后几乎每代版本都会在某个工程环节上给出可验证的改进这就让它的演变史天然具备很高的学习价值。1.1 从“能用”到“好用”DeepSeek版图的三个阶段我把这一整个系列大致分三个阶段来看。第一阶段是早期Dense基线阶段。这个阶段的模型结构本身没有太多反常规设计主要价值在于验证了团队的数据配方和训练稳定性让后续做架构改动时有一个靠谱的对照基线。如果你去翻那个时期的开源信息会发现模型的发布节奏、推理部署的友好程度、开放的协议范围已经比同期很多项目要规范这为后来开发者愿意跟进打下了基础。第二阶段是MoE与注意力重构阶段。这里出现了两个关键的架构创新一个是把KV Cache压缩进低秩潜空间的MLA另一个是细粒度专家加共享专家的DeepSeekMoE。这两个结构同时上线直接改变了同等参数规模下推理速度和显存占用之间的权衡关系。你可以理解为同样一个模型别人推理时要带全量的长上下文记忆它只用带一小包压缩后的记忆推理效率和成本自然就拉开了。第三阶段是推理增强与RL路线阶段。模型从“会生成”进化到“会先想后答”。这一阶段的重心不在底座结构而在训练范式。R1系列把强化学习直接应用到基础模型上甚至尝试了完全去掉监督微调、只靠规则奖励驱动推理能力涌现的极端路线。这部分和之前架构改进叠加起来形成了完整的能力闭环。1.2 先建立整体坐标关键版本与架构节点速览在深入逐层拆解前我习惯先拉一张时间线帮助大家把每个版本对应到具体的架构变化上。下面这张表汇总了几个关键节点后面每个小节都会围绕表格里的具体改动展开。阶段核心模型版本总参数量激活参数量注意力结构前馈网络结构训练/推理亮点早期基线DeepSeek 67B67B67B标准MHADense开源权重、稳定训练基线架构突破DeepSeek-V2236B21BMLADeepSeekMoE推理速度提升、训练成本下降规模与效能DeepSeek-V3671B37BMLADeepSeekMoE升级版FP8训练、无辅助损失负载均衡推理范式DeepSeek-R1系列671B推理、多个蒸馏尺寸随版本变化MLADeepSeekMoE纯强化学习路线、蒸馏小模型持续演进V3.1/V3.2系列等保持/扩大随版本变化MLA持续优化MoE微调MTP集成、多模态扩展、开放协议调整这张表的信息密度已经不小了但真正有意思的是每一个格子里藏着的“为什么”。下面我拆开讲。2. 第一把刀MLA如何重构Attention的缓存与训练MLA的全称是Multi-head Latent Attention这个名字乍一看有点学术但它的核心动机特别朴素Transformer推理的时候KV Cache太占显存了。长上下文场景下显存基本都被缓存吃掉了留给计算和Batch的空间越来越少导致单卡能服务的并发请求数量上不去。2.1 标准MHA的KV Cache瓶颈到底有多大先算一笔账。标准多头注意力中每个Token对应K和V两组向量假设隐藏层维度是5120头数是40每个头的维度是128那么在推理时每存一个Token的KV就要占用2乘5120个float16参数也就是约20KB。听起来不多但如果上下文长度推到1万Token单条请求的KV Cache就是200MB再乘上并发Batch是32就是6.4GB。这还只是一个请求批次模型本身的权重还要占一大块显存。我实际部署长上下文模型时最直观的感受就是显存不是被模型吃掉的是被Token缓存吃掉的。有人会说把精度从FP16降到INT8不就行了吗这能缓解但缓存体积的增速问题还在序列越长缓存线性膨胀Batch一大直接爆显存。所以要真正解决问题得从结构上把“每个Token要存多少KV”这个基数降下来MLA做的事情就是这个。2.2 潜空间压缩把KV投影到一个低秩空间里MLA的思路是对KV做联合低秩压缩。它不是把每个Token的完整K和V都存下来而是先学习一个小投影矩阵把原始的K和V压缩到一个维度低得多的潜向量里。推理时只需要缓存这个潜向量到实际计算注意力分数的时候再通过投影矩阵恢复出对应的K和V。这里有一个细节值得注意直接压缩K和V之后RoPE位置编码的注入方式会变得麻烦。RoPE是通过旋转矩阵对K和Q作用来编码位置的如果K已经被压缩成潜向量再对它做旋转操作数学上就不等价了。MLA的解法是在压缩后的潜空间里先不注入位置信息只针对最终恢复出的K做位置编码相关的变化同时Q侧也做相应的配合。这样既保住了RoPE的表现力又避免了对压缩向量直接做旋转带来的维度不匹配问题。实际效果就是位置信息保住了但缓存量大幅下降。2.3 长上下文和并发吞吐的实际提升从实践角度看MLA带来的收益在长上下文场景最明显。DeepSeek-V2发布时的测试数据显示因为KV Cache小了推理时显存占用显著降低相同的显存预算下能容纳更大的Batch单位时间能处理的Token数量随之上升。这还没有算上训练阶段的收益训练时同样要存储反向传播需要的中间变量压缩KV之后这部分显存开销也能降下来意味着可以在同样规模集群上跑更大的模型或者把训练序列长度拉得更长。我在自己的部署实验中的体会是MLA这类结构的价值不在于刷分而是在于让“长上下文”从可演示变成可商用。如果你需要做几万字文档的逐字分析或是在同一会话里反复让模型翻找一段代码传统MHA结构很容易在上下文拉长后出现显存和速度双降的问题MLA模型在线上的表现会稳不少。注意MLA压缩的是KV缓存维度但如果你用了量化推理框架要确认框架是否对MLA做了针对性优化。早期有些优化库直接按标准MHA的缓存格式来写算子跑MLA模型时反而会有兼容性问题甚至无法推理或速度下降。部署前最好先用目标推理框架实测一遍缓存尺寸。3. 第二把刀DeepSeekMoE把稀疏专家做到极致MLA解决的是缓存和注意力开销但模型规模能不能继续往上扩还得看前馈网络这块怎么设计。传统Dense模型每个Token都要过所有参数参数量大了计算量跟着线性增长。MoE的思路是让每个Token只激活一小部分专家用稀疏激活换取超大参数量。3.1 细粒度专家与共享专家的设计逻辑DeepSeekMoE相比早期MoE方案有两个核心变化。第一个是专家切得更细。过去常见的做法是把FFN切分成8个或16个同等大小的专家每个Token经过路由选2个左右。DeepSeekMoE把专家数量做得更多、单个专家做得更小然后在同样的激活预算下选更多专家。这样做的好处是专家组合的灵活性更高Token可以同时从更多不同方向的“专业小组”中获取信息而不是被限制在少数大专家之间做硬选择。这个逻辑很像团队协作与其让每个成员都是大而全的通才不如培养一大批更细分的小组任务来了之后按需组合出最合适的小分队。第二个是设置了共享专家。所谓共享专家就是每个Token都会无条件经过的那部分专家可以理解为通用常识和通用语法的处理器。这部分参数不参与路由竞争保证了模型即便在专业化分工很强的情况下仍然有一个稳定的通用处理通道。共享专家和细粒度路由专家结合起来等于在“通用能力”和“专业化能力”之间做了显式的结构分工。3.2 负载均衡从辅助损失到无辅助损失MoE模型最让人头疼的问题之一是负载不均衡训练时如果路由总是偏爱某几个专家其他专家就变成了摆设参数量虽大实际利用率却不高。早期方案通常在损失函数里加一个辅助损失通过惩罚负载不均衡来约束路由。但辅助损失会影响主任务的梯度方向加多了模型质量下降加少了专家利用率又上不去。DeepSeek-V3在负载均衡策略上做了一个很巧妙的调整。它放弃了传统辅助损失改用专家级bias——每个专家维护一个可学习的偏移量路由计算时对每个专家的分数加上这个偏移量推理时不加。训练中根据每个专家的负载反馈动态调整这些bias负载高的专家下一次就先少路由一些负载低的专家则多给一点机会。这样做的好处是训练时的主任务梯度不受额外损失项干扰同时通过bias的自动调节来兜底负载均衡。我在实际训练MoE模型时也复现过类似的思路确实比辅助损失那种“绑着手脚跳舞”的感觉要顺畅。3.3 V2到V3的参数量进化对比把V2和V3放在一起看三个数字变化最能说明问题总参数量从236B涨到671B激活参数量从21B涨到37B而推理时实际需要的显存和算力并没有按总参数量的比例去涨。这就是稀疏激活的威力。总参数量给足模型记忆容量激活参数量控制单Token计算成本。对开发者来说这意味着可以在单机多卡甚至单卡量化后运行一个参数总量很大的模型而体验却接近一个比它小得多的Dense模型。配置项DeepSeek-V2参数设计DeepSeek-V3参数设计总参数量236B671B激活参数量21B37B专家总数160含共享专家256含共享专家路由范围更广每Token路由专家数68共享专家数21显式共享专家 更精细的细粒度分配这个表格来自我对公开技术信息的整理个别数字可能随后续版本更新有微调但核心趋势很清楚DeepSeek系MoE走的是“更多更小的专家 更灵活的路由组合”的路子而不是简单堆大专家。提示如果你要基于DeepSeekMoE做二次开发建议先确认自己的部署框架是否完整支持细粒度专家路由。很多框架早期只适配了8个或16个专家的固定拓扑遇到160/256个专家、每Token路由6/8个的配置要么加载慢要么路由逻辑被强行简化影响效果。选框架前多看几个issue比跑起来再排错省心得多。4. 训练工程与优化组合拳FP8、DualPipe、MTP模型结构很重要但同等结构下能不能把集群效率跑上去才是决定项目是否可行的关键。DeepSeek系列在训练工程上的几个选择是很多人容易忽略、但实际分量非常重的部分。4.1 FP8混合精度从训练到推理的算力释放FP8是一种8位浮点格式相比传统的FP16/BF16数据位宽减半计算单元在同样芯片面积上可以获得更高吞吐。但FP8的难点是动态范围有限容易溢出或损失精度。DeepSeek-V3的做法是全流程关键地方采用FP8混合精度同时在具体算子层面做了精细处理哪些层、哪些矩阵乘法用FP8哪些主梯度累加过程保留更高精度这些都有明确的策略。我看到的实际效果是训练成本比传统混合精度方案有明显下降同时模型最终效果并没有因低精度训练而缩水。这种工程层面的细微取舍比模型结构创新更考验团队的工程积累。4.2 DualPipe双向流水线怎么压缩空闲等待大规模训练里流水线并行常出现一个问题GPU在计算当前微批次的同时还得等待前一层的通信和计算完成导致大量空闲气泡。DualPipe的思路是设置两条方向相反的流水线一条从前向后计算另一条从后向前计算把一个设备上的计算和通信重叠起来。用大白话讲就是原来只有一个方向的车流现在双向都有车单个时间片里排队等待的空白被另一方向的计算填充了整个集群的利用率自然更高。这项技术和FP8是配套的DualPipe减少了空闲等待FP8降低了单次计算和通信的数据量两者叠在一起才能在有限带宽的集群上把671B参数规模的训练任务压进可接受的成本区间。4.3 MTP多Token预测让模型一次学会多走一步MTP模块是我个人觉得最有意思的架构附加项。标准训练方式是一个Token一个Token地做预测也就是给定前文预测下一个Token。MTP做的事情是让Transformer主模型在每一层不仅参与预测下一个Token还额外叠加一个小模块去预测再下一个Token相当于让模型每一层都带着“多往前看一步”的任务意识。这个设计的直接收益是训练效率提升同一个样本在训练时贡献了更多的监督信号模型能更快地学到长程依赖。同时MTP模块还可以在推理时当作一个草稿模型来配合投机解码让生成速度进一步提升。到了V3.2版本这部分结构又被进一步整合优化整体上仍然延续了“低成本多产出”的工程哲学。4.4 为什么工程组合拳比单项技术更有参考价值单独看FP8或DualPipe都不是全新概念但把它们组合起来并且在超大规模模型上验证有效的完整方案这个参考价值是稀缺的。以前开源生态里最缺的就是这种“从理论到数千卡集群落地的全套recipe”DeepSeek系列等于把这份recipe公开出来了。虽然我们大多数开发者没有上千卡集群去复现全套但可以从中提取出适合自身规模的单项改进比如长序列训练时怎么调流水线并行和通信重叠比如用FP8量化时哪些模块可以激进、哪些必须保守。这些经验放到中小规模场景里一样能发挥作用。5. R1与推理范式重构纯强化学习路线带来的连锁反应如果说V系列的MLA和MoE是在“节省资源”这条路上做文章那R1系列解决的则是“推理能力从哪来”的问题。这一波的影响范围其实已经超出了DeepSeek系列本身对整个开源模型社区的训练方法论都产生了冲击。5.1 R1-Zero去掉SFT直接上RL的激进实验传统训练大模型的推理能力通常走“预训练—监督微调—强化学习”的链路监督微调用人工标注的推理步骤来教模型一步一步思考。R1-Zero做了一个大胆的实验完全跳过监督微调阶段用基础模型直接进入强化学习只通过规则奖励来引导。规则奖励就是可以写程序判断的客观标准比如答案数学上是否正确、代码能不能通过编译和测试而不是靠奖励模型打分。结果很有意思模型确实“涌现”出了长链思考、自我修正、反复验证等推理行为而且有些思考过程比人工标注的还复杂。这说明监督微调不是推理能力涌现的必要条件强化学习本身就能驱动模型发展出推理策略。当然纯RL阶段也暴露出可读性差、输出格式混乱、语言混杂等问题所以R1正式版本选择在纯RL之前加入一个冷启动阶段用少量高质量数据把模型带到一个相对稳定的起点再交给RL去大踏步优化。5.2 GRPO把策略优化的算力开销打下来R1系列训练用的强化学习算法是GRPO它的全称是Group Relative Policy Optimization。传统PPO算法训练时为了让策略更新有依据需要额外用一个Critic模型去估计状态价值函数这个估计过程非常耗资源。GRPO的替代思路是对于同一个问题让当前策略模型生成一组多个回答直接用这一组回答内部的相对优劣来计算收益而不需要单独的Critic模型来估计绝对价值。这个思路的朴素之处在于我们不需要知道一个回答“绝对有多好”只要知道它在同一批样本里面“相对有多好”就够了。数学上GRPO对一组输出做归一化得到一个baseline然后用这个baseline去计算策略梯度。省掉一个和主模型规模相当的Critic等于把训练显存和算力预算直接压缩了一大截。这是R1系列能在有限资源下做大规模RL的关键因素之一。5.3 蒸馏与开源生态的连锁反应R1系列另一个带火的动作是蒸馏。蒸馏的含义是让一个小模型去模仿大模型的输出分布或推理轨迹从而把推理能力压缩到更小的参数量里。DeepSeek系列开源了多个蒸馏尺寸模型这些模型把671B大模型推理“悟”出来的思考过程教给了小模型。社区随后也出现了各种基于蒸馏数据再训练或直接微调的衍生模型。这个动作的生态意义大于单纯的技术意义。它让很多只有消费级显卡的个人开发者也能本地运行一个具有初步长链推理能力的模型直接改变了开源模型“只能玩、不能用”的刻板印象。我自己在16G显存的环境下测试过蒸馏小尺寸模型处理逻辑推理和代码纠错类任务体验已经比同体量的通用模型好不少虽然比不了完整版本但日常辅助写代码已经够用。6. 架构迭代背后的开源哲学与普通开发者的应对前面几节基本是按时间线和技术线来梳理的但如果只看到结构和算法容易忽略一个更重要的事实这些架构能快速传播、快速被验证开源协议和开放策略起了很大作用。6.1 开放权重带来的生态扩散与同行压力DeepSeek系列不是第一个开放权重的但它把“开放权重”推向了新的竞争高度。过去开放权重通常意味着给一个可加载的模型文件配套的细节——数据配方、训练梯度、RL奖励设计、工程调优记录——往往不在开放范围。DeepSeek系列的做法是连技术报告里的细节都尽量写得可复现像FP8、DualPipe、MLA的实现要点社区里很快就能找到第三方复现和讨论。这种透明度让同行面临的压力不再是“你比我差多少”而是“你什么时候跟上”。这种生态扩散的一个直接后果是Open-R1这类社区复现项目出现了。社区不再满足于直接使用别人训好的模型而是希望把R1的整个训练链路——包括数据、奖励、RL流程——在开放环境下重新跑一遍。这比单纯下载权重更进一步等于把之前只属于少数研究团队的RL联邦训练经验也公共化了。6.2 从纯研究到可复现路线的迁移我以前也困惑过为什么很多论文里的模型效果很好自己复现却很拉胯。后来我发现大多数问题出在“论文隐藏了大量工程细节”。DeepSeek系列在这个问题上的处理方式很有参考性每个关键结构改变都给出足够清晰的动机和效果对比关键工程环节尽量公开配置和实现思路让后来者能踩在自己的肩膀上而不是重新踩坑。这个“可复现优先”的路线让它的架构演变史不仅是一份技术记录更成为一份可以照着学习的课程大纲。6.3 部署与选型时的个人经验与避坑参考最后分享一些我用DeepSeek系列模型时的选型经验免得大家在实际部署时来回折腾。如果你的核心场景是长上下文文档理解、超长代码库问答优先选带MLA的版本因为长序列下显存占用和并发能力差别很大。如果你拿来做在线服务、对成本敏感优先考虑蒸馏小尺寸版本再根据效果决定是否升级到更大版本。如果你要做二次微调建议先搞清楚你的训练框架对DeepSeekMoE的路由逻辑支持到哪一步很多框架对256专家支持并不好。如果只是做实验验证想法不需要完整复现训练直接用官方公开的模型权重和推荐推理参数就行没必要重训。注意量化部署时如果模型用到了MLA和细粒度专家路由建议先验证量化后的输出与BF16版本的关键case是否一致。MoE结构下注意力模块和路由模块都比较敏感有的量化方案在主模型上没问题但一碰到MoE就出现专家选择漂移导致输出质量明显下滑。别急着上线先跑一批针对性测试再决定。7. 后续演进方向与我的观察到了这一步整个DeepSeek系列的架构演变逻辑已经比较清晰了。剩下的问题是这个系列下一步还会往哪里走以及这些方向对普通从业者有什么启示。从已经能看到的信息来看方向大约有三个。一是结构本身的继续瘦身和优化MLA和MoE的组合还有不少可调空间比如更激进的KV压缩策略、更灵活的路由历史依赖。二是训练范式进一步往RL和多阶段递进方向发展R1-Zero的纯RL实验证明了强化学习的潜力后续大概率会出现更多关于奖励设计、自博弈、多智能体协作的训练尝试。三是多模态化文本之外还有图像、代码、音频等输入输出形式如何把MLA这种高效注意力结构复用到多模态任务中是一个值得跟进的观察点。对我个人来说这套演变史最值得借鉴的地方不是某一次具体的结构改动而是每一代版本都清晰回答了同一个问题在计算资源有限的前提下我做哪个改动受益最大早期答案是省缓存中期答案是省激活计算再往后是省训练显存最后是省RL的额外模型开销。每一次“省”都踩在了当时最痛的资源瓶颈上。把这个逻辑用到自己的项目里也会很有启发不要先问“该不该上最新结构”而要问“我现在最缺的是显存、算力、数据还是推理稳定性”然后去找对应那一步已经验证过的架构或方法用最小代价做验证。这种带着资源约束去选择架构的工作方式可能才是这个系列给从业者最大的参考价值。