同样是几百亿参数的大模型，有的每个 token 都全员上工，有的每次只叫醒一小队专家——前者叫稠密模型，后者叫 MoE。结论先行：单卡部署、显存紧张、追求延迟稳定，选稠密；并发量大、追求极限性价比、能接受负载波动，选 MoE。
差异一：参数怎么花
稠密模型每次前向传播，所有参数都参与计算，激活参数等于总参数。MoE 把网络拆成一群专家加路由器，每层只挑几个专家干活，单次计算量由激活参数决定，总参数可以做得很大。Kimi、DeepSeek 的旗舰版本都采用 MoE 结构，正是看中「总参数撑容量、激活参数控成本」这笔账；而不少 7B 到 30B 级小模型坚持稠密路线，因为规模还没到分工划算的临界点。
差异二：显存与速度的性格
稠密模型的开销是恒定的：每个 token 的计算量、显存读取量完全可预测，延迟曲线平，压测好做。MoE 的开销随路由波动：这个 token 叫醒的专家多，下个可能少，负载不均时延迟会抖，工程上要额外做专家并行和负载均衡。MoE 的共享专家是干嘛的那篇讲的恒定在岗角色，就是为了给这波动垫一层底。选型时若对响应稳定性要求严，稠密的确定性本身就是卖点。
差异三：质量表现与适用场景
同计算量下，MoE 靠更大的总参数通常能拿到更好的知识容量；同总参数下，稠密模型往往在需要深度推理的任务上更稳，因为每个参数都被充分训练。批量离线任务、显存宽裕，MoE 的性价比突出；实时对话、小团队自托管，稠密更省心。自部署权重和调 API 怎么选那篇讲的取舍，在这里换了个形式重演：MoE 的复杂度是自托管才需要操心的，调 API 时用户只管效果。
两条路摊开比，差别集中在这五行。
| 对比项 | 稠密模型 | MoE |
|---|---|---|
| 参数怎么花 | 激活参数等于总参数，全员上工 | 每层只挑几个专家，总参数大、激活参数小 |
| 显存占用 | 总参数小，更容易塞进消费级硬件 | 专家参数全得驻留，一张 24GB 的卡可能连加载都困难 |
| 延迟表现 | 计算量与显存读取恒定，延迟曲线平 | 随路由波动，负载不均时会抖 |
| 质量表现 | 需要深度推理的任务上更稳 | 同计算量下知识容量更好，但同类问题可能不稳 |
| 适合的部署 | 单卡、小团队自托管、实时对话 | 多卡集群加专家并行、批量离线任务 |
两条路对照表
- 总参数与激活参数：稠密相等，MoE 相差数倍到数十倍
- 延迟：稠密恒定，MoE 随负载波动
- 显存：MoE 总参数大，反而更吃显存，别被「省算力」误导
- 选型一句话：小显存求稳选稠密，大并发求性价比试 MoE
一个常见误解要拆掉
「MoE 省算力所以更省资源」是半句话：它省的是单 token 的计算量，不省显存——所有专家参数都得驻留显存，总参数大反而更吃内存。这也是 MoE 模型动辄需要多卡分布的原因。真正决定选哪条的，是你的部署形态：单卡能跑，稠密；多卡集群加专家并行，才轮到 MoE 登场。
再补一笔显存账：MoE 的总参数大，权重全得驻留显存，一张 24GB 的卡可能连加载都困难；同能力档位的稠密模型总参数小，反而更容易塞进消费级硬件。这也是为什么个人玩家手里的单卡机器，跑的多是稠密小模型，MoE 的舞台在服务器集群。
反过来也有反着用的情况：显存富余的推理服务器跑稠密大模型，图的是每个参数都被喂饱的稳定输出；边缘设备上跑小 MoE，图的是总参数撑起来的知识面。两条路没有高下，只有匹配。
换个问法再问稠密模型与MoE三句
- MoE 的回答质量一定更好吗？：同等推理预算下通常更好，但要看任务——路由波动可能让同一类问题质量不稳，稳定性敏感的场景先实测。
- 小模型能做 MoE 吗？：能，但分工收益有限，还要背专家并行的复杂度，小规模场景稠密更划算。
- 调用 API 时还要关心这个区别吗？：要的少了，延迟和价格已由服务方摊平；但要理解为什么同价不同速，可以参考推理模型和普通模型差在哪那篇的时间账。
收束一句：一条大路胜在稳，一组分工胜在省，先看显存和 SLA，再看参数量。
