企业官网建设流程全解析

前几年聊大模型，大家最关心的还是参数量：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 一张表看清三种架构的关键差异

这张表基本上就是三重架构的浓缩版。后续所有关于训练、推理、调优的讨论，都是围绕表里这几条差异展开的。

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，可能会被分到不同的专家。

拿一个常见设置举例：假设专家数量N=16，路由维度是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 问题排查速查表

这套排查思路，我是在多次“训练到一半发现模型变成傻子”的教训里总结出来的。对照速查表一步步查，基本能覆盖MoE落地过程中90%的坑。

我个人在实际操作中的体会是，架构选型真的不是追热点，而是算好账再动手。密度、稀疏、MoE各有各的甜区和死穴。如果你算力富余、团队工程能力强，直接训练MoE收益最大；如果预算有限，蒸馏和路由冻结这类轻量方案更容易落地。踩过几次坑之后，我养成了一个习惯：无论训练还是微调，每隔几百步就打印一次路由分布和专家使用率的统计，眼见为实，别等loss自己说话。

最后再分享一个小技巧。不管用的是哪个框架，你都可以直接读取模型文件里门控路由层的权重，把它的logits分布可视化出来。哪几个专家分数常年垫底，哪些token类型总是命中同一专家，一眼就能看明白。这个动作花不了十分钟，但能帮你提前发现“专家饿死”的苗头，比事后抢救划算太多了。