稠密、稀疏与MoE：大模型架构演进的底层逻辑

前几年聊大模型大家最关心的还是参数量70亿、130亿、1800亿好像谁参数多谁就更有底气。但从去年开始圈内聊天的风向明显变了“稠密”“稀疏”“MoE”这些架构名词高频出现在各种技术分享里成了真正绕不开的话题。如果你去看各个团队发布的新模型会发现不少都在强调“总参数多少、激活参数多少”而不是单一报一个总规模数字——这意味着架构层面的竞争已经不只是“堆规模”而是在重新设计参数参与的干活方式。这篇内容想帮你把三件事彻底理清楚稠密、稀疏、MoE到底是怎么设计的它们各自解决了什么问题、代价又在哪里以及落到实际训练、微调、部署时哪些参数和操作真正决定成败。适合算法工程师、大模型部署同学以及对Transformer底层机制感兴趣、想搞明白“为什么MoE能省钱”的研究者。不夸张地说这三套架构思路基本定义了大模型接下来的演进方向值得花点时间吃透。1. 三重架构的基本盘先搞懂它们差在哪1.1 稠密架构全员参与一次推理谁都不能少稠密架构是大家最早接触、也是最“直觉”的一种设计。以标准Transformer为基础的大模型每一层、每一个参数在一次前向推理里都会被激活并参与计算。所谓“稠密”就是指参数与计算完全绑定模型权重有多大单次推理的浮点运算量就有多大。这种设计的最大好处是简单、可控。训练过程稳定优化器状态清晰分布式并行方案也相当成熟。比如张量并行、流水线并行、数据并行基本围绕稠密结构做了大量工程优化踩坑资料也多。正因如此主流大模型的早期版本几乎全是稠密路线能力强、通用性好各类任务一视同仁地处理。但稠密架构有个绕不开的痛点推理算力与参数量严格成正比。参数涨10倍计算量就涨10倍显存占用也同步涨。我见过很多团队把模型从70亿做到130亿之后成本曲线几乎是垂直往上飞。更尴尬的是参数涨到一定程度时能力增益开始递减——花了双倍的钱效果只多了一点点这就是业界常说的“边际收益递减”。拿生活场景打个比方稠密模型就像一个“全员会议”不管这次任务跟谁相关所有部门的人都来参加。信息同步充分但沟通成本极高业务线上只有一两个部门真正干活其他人都在陪坐却被同样计算进会议成本里。1.2 稀疏架构不是所有参数都要上场稀疏架构的核心思想是在计算过程中只激活一小部分参数而不是全部。这个概念本身并不新鲜学术上很早就有参数稀疏、梯度稀疏、激活稀疏等不同分支。在大模型语境下大家讨论最多的其实是“激活稀疏”或者“条件计算”——根据输入内容动态决定哪些参数参与这次计算。这么做最直接的收益是把“模型容量”和“计算开销”解耦。容量可以做得很大但单次推理只走一小部分参数计算成本就能大幅下降。代价是模型必须学会“怎么选参数”这本身需要额外的决策机制。如果选得不好能力可能还不如一个参数更小的稠密模型。还是拿会议来类比这次不是全员开会而是由“主管”判断“这个需求该找谁”只拉对应团队进会议室。省时省力但前提是主管得足够聪明否则该来的没来、不该来的来了项目照样翻车。1.3 MoE把“稀疏”工程化的那套玩法MoE全称Mixture of Experts翻译过来是“混合专家”是目前大模型领域做稀疏化最主流、最落地的一套工程方案。它的结构可以拆成两部分一堆“专家子网络”加上一个“门控路由”。前向计算时对于每个token门控路由先算一遍得分挑出得分最高的Top-k个专家然后把token只送进这几个专家里计算其他专家完全不参与。这里有个关键概念要拎清楚总参数 vs 激活参数。MoE模型的总参数是所有专家的权重加在一起但单次推理实际参与计算的只有被路由选中的少数专家这部分称为激活参数。平时人们说“一个200B总参数的MoE模型激活参数只有20B推理成本和20B稠密模型接近”说的就是这个意思。正是因为“容量”和“计算量”实现了分离MoE可以在总参数上做得非常大去记住更多知识、拟合更复杂的模式同时又不用承担与之匹配的天量计算成本。这个设计在商业上极具吸引力也是MoE能在短短一两年内从论文走向生产环境的最根本原因。1.4 一张表看清三种架构的关键差异维度稠密架构稀疏架构广义MoE架构参数激活方式每次推理全部激活部分参数按需激活门控路由选择Top-k专家激活总参数与激活参数相等可以解耦解耦明显常见几十B总参数配几B激活参数训练难度低工程成熟中需要额外决策机制高路由训练和负载均衡是难点推理算力与总参数量线性相关与激活参数量相关与激活参数量相关但路由有额外开销显存占用全部参数需常驻依稀疏策略而定所有专家都需常驻显存或外存扩展性瓶颈明显成本陡增中等强易扩展到百B/千B级典型痛点算力贵、边际收益低决策质量不稳定通信开销、专家失衡、微调易跑偏这张表基本上就是三重架构的浓缩版。后续所有关于训练、推理、调优的讨论都是围绕表里这几条差异展开的。2. 为什么稀疏化成了必选项算力账与技术逻辑2.1 稠密模型撞上两堵墙算力墙与内存墙先聊算力墙。稠密模型做一次推理需要计算的浮点操作数约等于两倍参数量乘以序列长度。假设一个70B稠密模型生成一个token理论上就需要约140G FLOPs的计算量。到了1800B量级一次前向就是3.6T FLOPs。单张加速卡再强也扛不住这种线性增长。内存墙是另一层麻烦。训练时参数量、优化器状态、梯度全部要住进显存。拿70B稠密模型举例仅Adam优化器状态就要占用超过800GB这还只是参数本身不算激活值和通信缓冲。就算把算力解决掉显存也不够分。所以稠密路线继续走大参数本质上是在跟芯片的算力和显存容量赛跑。芯片迭代速度有限模型规模却不能停于是架构必须想办法挑出参数来用。2.2 MoE的“规模自由”总参数和激活参数解耦是关键MoE的价值不在于“省掉了预测能力”而在于把知识的“存储”和“运算”拆成了两件事。专家网络里的权重相当于知识库平时只是静静躺在显存里真正参与计算的只是被路由激活的那部分权重。这就好比公司有一个巨大的资料库平时扫描存档不需要所有员工去读只有被检索到的资料才会被翻阅。总参数撑起记忆容量激活参数决定计算成本。于是你会发现某MoE模型总参数明明已经上千亿但部署时消耗的计算资源和推理延迟跟一个几十B的稠密模型差不多。这在商业上意味着“把模型做大”不再等于“把成本做大”。也是为什么越来越多厂商宁愿把规模推上千亿也要走稀疏化。另外从数据角度看不同token需要的能力空间本来就不同。一个“的”字和一个专业术语调用的知识范围差异极大让所有专家每次同时上场本质上是一种巨大的资源浪费。MoE相当于让模型学会了按输入内容动态分配计算资源。2.3 现实里的三条落地路线在真实项目中稀疏化并非只有“从零训练一个大MoE”这一条路。我见过大量团队按下面三种方式进入稀疏化各有适用场景。路线一是从零训练一个MoE模型。成本最高、周期最长但上限也最高。适合有大算力集群、目标是把模型做成平台级底座的大团队。路线二是做稠密到稀疏的蒸馏把一个训练好的稠密大模型的知识蒸馏进一个规模相当的MoE模型里用少量数据就能让MoE快速继承能力特别适合预算有限的小团队。路线三是“稠密升级为MoE”在原有稠密模型的主干网络上并联几个专家分支并用少量数据教会门控路由步骤相对温和算是一种增量改造。这三条路没有绝对优劣关键看起点和资源。大多数团队的实际体感是蒸馏路线最稳妥从零训练收益最大但风险也最大。3. MoE核心机制拆解路由、专家与负载均衡3.1 门控路由谁来决定token进哪个专家MoE的门控路由本质是一个线性层加Softmax再加上Top-k筛选。它的输入是当前token的隐层表示输出是每个专家门上的得分。路由在MoE中通常不是按“序列”做决策而是按“token”做决策同一句话里的不同token可能会被分到不同的专家。拿一个常见设置举例假设专家数量N16路由维度是hidden_size那么门控就是一个[hidden_size, N]的矩阵。每个token进来后先算出每个专家的得分再取Top-2的两个专家把分数归一化后作为权重token的输出就是这两个专家的加权和。实际操作时很多人会忽略一个细节如果两个被选中的专家得分都很接近路由的“自信度”其实不高如果得分差距很大说明路由决策非常明确。这个信息可以在训练时用起来——得分熵低的时候多学习熵高的时候避免强学。这类技巧在论文里不常写但实测对稳定微调很有帮助。3.2 负载均衡为何是生死线负载均衡是MoE工程里最核心、也最容易翻车的环节。如果路由老是把大多数token分给某几个专家其他专家几乎吃不到数据训练就会退化成一个“伪稠密”模型真正在学的只有几个专家而且这几个专家还会因为负载过高导致优化不稳定。这种现象叫“路由崩溃”或“专家饿死”是MoE训练里最经典的失败模式。为了对抗它主流做法是给训练目标加上辅助loss。最通用的负载均衡loss是把每个专家被分配到的token比例和平均路由概率做乘积任何一个方向偏离均衡都会增加惩罚。这个loss不需要太重的权重浅一点就够但少了它模型很容易自己跑偏。负载均衡同样要在推理阶段关注。如果你部署的MoE模型出现过某些卡显存占用特别高、某些卡几乎空闲大概率就是专家负载不均导致的。生产中可以用“专家使用率”这个指标做监控统计一段时间内每个专家被激活的token占比如果分布方差过大就该回头检查路由状态了。3.3 从粗粒度到细粒度专家结构在演进早期的MoE设计倾向于设置少量但规模较大的专家比如8个或者16个每个专家内部是一整个FFN层。后来开发者发现专家太“粗”有个问题每个专家需要覆盖的知识面太宽相互之间职责边界模糊路由难以做出清晰选择。于是出现了细粒度专家的思路把专家数量做得更多比如128甚至256个每个专家规模更小、职责更聚焦。细粒度带来的好处是组合方式更灵活路由能在更多候选里挑选出最匹配的专家组合训练效率也更高。不过专家数量上去了路由矩阵的参数量和通信量也会跟着涨工程上需要做取舍。另一个常见的结构优化是把专家拆成“共享专家”和“非共享专家”两组。共享专家被所有token无条件调用负责通用的基础模式非共享专家通过路由选择调用负责特定领域或任务的精细处理。这种组合的好处是基础能力不会因为路由偶尔误判而丢失稳定性更好在很多MoE开源模型里都能看到类似设计。3.4 训练时必须盯住的几个核心超参第一个是Top-k值。多数模型用Top-1或Top-2。Top-1计算效率最高但专家之间的协同能力弱Top-2信息交互更充分可解释性和性能通常更好代价是计算量翻倍。新手不要一上来就调大k值先用Top-2跑通流程最稳。第二个是专家数量。从经验看专家数量不是越多越好。对同等规模而言专家多了单个专家训练数据变少反而学不到位。通常的做法是总参数量固定时先确定激活参数规模再根据单卡显存倒推专家规模与数量。第三个是容量因子与token溢出的处理方式。MoE训练通常会给每个专家设定一个最大token容量超过容量的token会被标记为“溢出”在训练阶段丢弃或走残差连接。容量因子设太小真实数据频繁溢出信息丢失严重设太大计算量上升稀疏化收益缩水。正常区间在1.05到1.25之间具体多少还得靠实验看。4. 训练、微调与部署的实操要点4.1 训练MoE并行策略不能再照搬稠密那套MoE训练的分布式策略比稠密模型复杂关键是引入了专家并行。所谓专家并行就是把不同专家拆分到不同GPU上每个GPU只放一部分专家。计算时token首先走前面的共享层做完计算后通过all-to-all通信把token批量发送到目标专家所在的设备专家算完再由另一轮all-to-all把结果收集回来。这两次all-to-all通信是MoE训练最主要的性能瓶颈。专家数量越多、单次batch里涉及到的token分布越散通信量就越大。实操时我会看两个指标一个是每轮通信耗时占比如果超过30%就要考虑调整专家数量或优化并行方案另一个是通信秩的利用情况尽量把发往同一专家的token聚合在一起减少小包通信。另外显存估算要特别小心。很多人会用“激活参数”去算显存这是错的。不管token只激活几个专家所有专家权重都必须常驻显存或高速外存因为没有专家会预先知道哪些token会被路由到它。也就是说一个200B总参数的MoE光权重按2字节存储保守就需要400GB训练时加上优化器状态和梯度单机多卡几乎是必然选择。4.2 微调MoE最容易踩的坑微调MoE和微调稠密模型的体感差别很大。最容易被忽略的一件事是微调数据只要稍微带偏路由分布就会整体迁移。比如你只拿数学数据做指令微调模型可能大量地把token分给某个“数学专家”其他专家的权重几乎冻结。表面看下游指标不错但模型的通用能力明显衰退后面再做其他任务时表现大幅下滑。所以微调时第一个建议是保证数据均衡。如果领域数据集中至少混合一部分通用数据让路由始终保留基本盘。第二个建议是谨慎更新路由层。LoRA微调通常只改低秩矩阵这时候路由层如果是冻结的专家内部的适配会更聚焦稳定性反而高。实验显示在中小规模微调场景下冻结路由比放开训练更稳尤其在指令微调这种轻度场景。还有一个经验微调过程中监控专家使用率。如果使用率分布和预训练末期差异太大说明模型出现“灾难性遗忘”式的路由重排。这时候要把学习率降低或者回退到数据混合比例更接近原始分布的状态。4.3 推理部署单机GPU怎么跑起来部署MoE推理重点也在显存策略。单机多卡时我推荐的做法是把共享层和路由层做张量并行复制专家做设备分布放置也就是每个GPU只放部分专家。推理算token时通过通信把token送到对应专家所在设备算完再收回来。如果单卡显存实在放不下全部专家还有一个很土的技巧把使用率最低的一批专家卸载到内存并把这些专家在路由表中的得分强制设为一个较小值或者直接屏蔽。绝大多数token根本不会命中它们卸载后对效果影响很小但显存能省下一大块。这个做法在服务端推理特别实用。还有一点容易被忽视MoE在低并发条件下并不一定比同激活参数的稠密模型快。因为路由计算、专家间通信都是有开销的。只有把batch size拉上去之后通信成本摊薄稀疏化的算力优势才会真正显现。所以你如果只是做低并发的私有化部署MoE未必能带来想象中那么大的提效选型时要把并发量一起算进账里。4.4 蒸馏与压缩MoE也可以“反向”喂稠密模型一个很反直觉但好用的思路训练一个MoE模型然后把它的知识蒸馏回一个小体量稠密模型。疯狂吗一点不。因为MoE总参数可以做得非常大知识容量远大于同计算量的稠密模型蒸馏相当于把一个大容量老师的知识压缩进一个低计算成本的学生里最后留下的是“精华版”能力。实操时一般用MoE模型作为教师对一批数据同时出logits然后用温度缩放过的KL散度作为辅助loss让学生模型逼近教师输出。如果你还要保留中间特征还可以在某一层输出上做特征对齐。多个经验表明MoE蒸馏出来的稠密模型在相同参数规模下普遍比直接训练的稠密模型效果更好推理成本也更可控。这里面的trade-off是显存和训练时间蒸馏一个MoE到稠密相当于额外多跑一遍教师模型的推理整体训练成本依然不低。但它换来的是生产环境里极低的部署成本对于线上服务来说是一笔很划算的账。5. 常见问题排查与避坑实录5.1 路由崩溃或专家饿死模型能力停在原地现象是loss不降或者某个阶段后指标持续低迷。排查时直接看路由侧的统计量每个专家实际接收的token数以及路由得分的熵。如果大部分token集中到少数专家且熵明显偏低基本就是路由崩溃。修复手段有三个第一调大负载均衡loss的权重但注意不要过大否则模型会为了“均衡”而牺牲精度第二在路由的Softmax上加一点温度让概率分布更平滑第三如果是微调阶段出现的重点检查数据混合比例加入更多通用语料。5.2 推理吞吐时好时坏延迟忽高忽低MoE推理偶发出现高延迟往往不是因为模型计算量变大而是因为一个batch里不同token被路由到不同专家导致同一时刻各GPU上的计算负载差异很大。某张卡接到一个大batch其他卡却在等数据整体就慢了下来。解决办法一般从调度下手按专家分布对batch动态拆分把路由结果均衡地分配给各设备。某些框架已经有成熟的MoE推理内核能对这类专家并行场景做专门优化。如果条件不允许退一步的办法是调低batch size减少通信抖动。这不是最优解但实测能稳定不少。5.3 显存算得刚好一训练就OOM很多人估算MoE显存时只算总参数和优化器忽略了专家并行时的临时通信缓冲、计算图中间激活值以及KV cache。尤其是专家并行时每个token要在发送前后各复制一份隐层表示序列越长这份临时缓冲越夸张。常规应对有几种设置更小的流水线切分、启用重计算、把优化器状态切到CPU下放。其中重计算是我最推荐的虽然增加了一点点计算量但显存压力大幅减轻。如果只是推理则严格按上文的方法做专家卸载。5.4 微调之后通用能力反而往下掉这个坑很隐蔽。模型在下游任务上分数变高但跑通用benchmark明显变笨。原因是微调数据引导路由过多地流向某几个专家其他专家长期不更新知识固化甚至被“饿死”。解决思路有三层第一微调数据尽量混合5%-10%的通用语料锁住基础能力第二把路由层冻结让数据只改动专家内部参数第三使用渐进式微调小学习率、短步数每次微调后都看一次路由分布变化一旦异常立刻回滚。5.5 问题排查速查表问题现象主要原因推荐解法训练loss不降路由崩溃专家利用率不均衡调负载均衡loss权重或加路由温度部分GPU显存溢出专家负载不均或临时缓冲过大动态调度batch开启重计算推理偶发高延迟专家跨设备通信抖动按专家分布切batch降低batch size微调后通用能力退化数据迁移导致路由偏向混入通用数据冻结路由层多卡利用率低all-to-all通信占比过高减少专家数量或优化通信缓冲这套排查思路我是在多次“训练到一半发现模型变成傻子”的教训里总结出来的。对照速查表一步步查基本能覆盖MoE落地过程中90%的坑。我个人在实际操作中的体会是架构选型真的不是追热点而是算好账再动手。密度、稀疏、MoE各有各的甜区和死穴。如果你算力富余、团队工程能力强直接训练MoE收益最大如果预算有限蒸馏和路由冻结这类轻量方案更容易落地。踩过几次坑之后我养成了一个习惯无论训练还是微调每隔几百步就打印一次路由分布和专家使用率的统计眼见为实别等loss自己说话。最后再分享一个小技巧。不管用的是哪个框架你都可以直接读取模型文件里门控路由层的权重把它的logits分布可视化出来。哪几个专家分数常年垫底哪些token类型总是命中同一专家一眼就能看明白。这个动作花不了十分钟但能帮你提前发现“专家饿死”的苗头比事后抢救划算太多了。