调查研究-194 Qwen3 MoE vs Dense 怎么选？2026 工程部署视角完整指南

Qwen3 MoE vs Dense 怎么选？2026 工程部署视角完整指南

TL;DR

• 场景：本地模型部署、AI Agent、实时语音对话、模型路由、Qwen3 系列选型
• 结论：Dense 适合实时主链路（稳定、可预测、低 p99），MoE 适合复杂慢路径（高质量、能力上限高）；最佳实践是分层使用——小 Dense 路由、中 Dense 实时、大 MoE 兜底复杂任务
• 产出：一张 6 维度评估指标清单 + 14 场景选型表 + 5 张配图解释

版本矩阵

最近做本地模型部署、AI Agent、语音对话或者模型路由时，很多人都会遇到一个问题：

Qwen 系列里有 Dense，也有 MoE。 到底应该选哪一种？

Dense 模型很好理解，例如Qwen3-8B、Qwen3-14B、Qwen3-32B。参数量是多少，每个 token 大体就走完整模型。

MoE 看起来更容易让人误判，例如Qwen3-30B-A3B、Qwen3-235B-A22B、Qwen3-Next-80B-A3B-Instruct。名字里的A3B或A22B表示每个 token 的激活参数量，而不是模型总权重大小。

这篇文章不从论文结构细节展开，而是从工程部署角度回答几个最实际的问题：

30B-A3B 到底是 30B，还是 3B？ MoE 是否一定比 Dense 更快？ active 参数少，是否就等于显存占用低？ 实时语音、Agent、模型路由、本地部署分别该怎么选？

先给结论：

Dense 更适合实时主链路。 MoE 更适合高质量慢路径和复杂任务。 小 Dense 做路由，中 Dense 做在线服务，大 MoE 做增强能力。

1. Dense 和 MoE 的核心差异

Dense 模型可以理解成：

每个 token 都走完整模型。

比如一个 14B Dense 模型，每生成一个 token，基本都要经过完整的 14B 参数计算。它的推理路径固定，行为稳定，部署生态成熟，显存和吞吐比较容易估算。

MoE，也就是 Mixture of Experts，可以理解成：

模型内部有很多专家，但每个 token 只激活其中一部分专家。

以Qwen3-30B-A3B为例，官方模型卡写的是约 30.5B 总参数、约 3.3B 激活参数、128 个专家、每次激活 8 个专家。它不是一个真正的 3B 模型，而是一个总容量接近 30B、单 token 激活计算量接近 3B 的稀疏模型。

再看Qwen3-Next-80B-A3B-Instruct，官方模型卡写的是 80B 总参数、3B 激活参数、512 个专家、每次激活 10 个专家，并且强调它面向更长上下文和更高参数效率。

所以，MoE 的关键不是"参数变少了"，而是：

总容量很大，但每次计算只用一部分。

这也是 MoE 让人觉得"很香"的原因。

2. 为什么 MoE 看起来很有吸引力？

传统 Dense 模型想提升能力，通常要整体变大。7B 不够，上 14B；14B 不够，上 32B；32B 不够，上 72B。

问题是，Dense 参数越大，每个 token 的计算成本就越高。推理延迟、显存压力、KV cache、并发成本、部署复杂度都会跟着上升。

MoE 给出的是另一种折中：

用更大的总参数容量承载知识和能力， 用较少的激活参数降低单 token 计算量。

这会带来三类优势。

第一，单位激活计算量下的能力可能更强。

30B-A3B不能简单等同于3B Dense。它每次只激活 3B 左右参数，但背后有 30B 级别的专家容量，因此在复杂问答、代码、推理、长文本、多语言任务上，往往会明显强于真正的小 Dense。

第二，高并发和大 batch 场景可能更有吞吐优势。

当推理框架对 MoE kernel、expert dispatch、batching、并行策略优化得比较好时，MoE 可以在较低激活计算量下提供不错的输出质量。对于后台总结、批量分析、离线 Agent 任务，这个优势很有价值。

第三，复杂任务上限更高。

复杂代码仓库分析、多轮 Agent 规划、长上下文知识总结、跨文档报告生成，这些任务往往需要更大的模型容量。MoE 的总参数容量会在这些任务上体现潜力。

但问题也正在这里：MoE 的优势不是免费拿到的。

3. 最大误区：active 参数不等于显存占用

很多人看到30B-A3B，第一反应是：

那部署成本是不是接近 3B？

不是。

A3B主要说明每个 token 激活约 3B 参数，描述的是计算量侧的概念。它不等于模型完整权重只有 3B，也不等于显存需求可以按 3B 估算。

MoE 的专家参数虽然不是每次都参与计算，但通常仍然要加载到显存或内存里。除非你明确使用了 CPU offload、专家卸载、量化、专家并行、分层缓存等方案，否则显存压力不能简单按 active 参数下降。

工程上要注意四个坑。

第一，显存主要看总权重、精度、KV cache 和并发。

模型加载后，权重本身就会占空间。上下文越长、并发越高，KV cache 越大。很多时候真正打爆显存的不是单次前向计算，而是长上下文和高并发叠加。

第二，部署复杂度更高。

MoE 会涉及 router、expert dispatch、expert parallel、负载均衡、通信开销、kernel 支持、显存布局等问题。Dense 的路径固定，MoE 的路径更动态，对框架成熟度更敏感。

第三，低并发短请求不一定更快。

MoE 的理论 FLOPs 更低，但实际速度还要看调度开销、内存访问、batch 大小和框架优化。对于实时短请求，如果 batch 很小，MoE 不一定能把优势发挥出来。

第四，p99 延迟更难压。

实时链路最怕尾延迟。Dense 的计算路径固定，p50、p90、p99 更容易预测。MoE 的专家路由和调度更复杂，尾延迟更容易受负载、路由分布和内存访问影响。

所以，MoE 不能只看名字里的A3B。更准确的说法是：

active 参数影响单 token 计算量。 总参数、精度、上下文、并发和部署策略共同决定真实显存与延迟。

4. Dense 的工程价值：稳定、简单、可预测

Dense 看起来没有 MoE 新，但它在工程系统里非常重要。

它的优势不是"更先进"，而是：

稳定、简单、可估算、好调优。

第一，推理路径固定。

每个 token 都走同样的网络结构，延迟更稳定。对于语音机器人、客服对话、工具调用、机器人控制这类在线系统，稳定比峰值能力更重要。

第二，部署生态成熟。

vLLM、SGLang、TensorRT-LLM、llama.cpp、MLX、Ollama、LM Studio、Transformers、量化工具、LoRA 工具，对 Dense 的支持通常更成熟，问题更容易定位。

第三，显存和性能更容易估算。

7B、14B、32B Dense 配合 FP16、INT8、INT4，大致需要多少显存、能跑多少上下文、能承受多少并发，工程上更容易做容量规划。

第四，微调路径更直接。

如果要做 LoRA、QLoRA、领域微调、工具调用格式微调、业务风格微调，Dense 的训练和部署路径更清楚。MoE 微调还要考虑 router、专家选择、专家退化、负载均衡和推理兼容性。

第五，更适合在线主链路。

实时语音对话、意图识别、Function Calling、机器人控制、短问答，这些场景不一定需要最强模型，但一定需要稳定输出、稳定延迟和稳定格式。

5. 不是二选一，而是分层使用

在真实 AI 应用里，最稳的方案通常不是"只用一个最大模型"，而是模型分层。

一个可落地的架构可以这样设计：

0.5B-3B Dense：意图识别、模型路由、工具调用预判 7B-14B Dense：实时对话、普通问答、机器人控制、Function Calling 30B-A3B / 80B-A3B / 235B-A22B MoE：复杂推理、长文档、代码分析、后台任务 云端大模型：极复杂、低频、高价值兜底任务

这样做的好处很直接：

实时链路足够快。 复杂任务质量足够高。 成本可控。 每一层都能独立替换。

小 Dense 不需要"聪明到什么都能做"，它只需要快、稳、便宜，能做分类和路由。

中 Dense 不需要在所有 benchmark 上赢，它需要在用户真实请求里首 token 快、p99 稳、工具调用格式稳定。

大 MoE 也不需要进入所有请求。它可以作为增强链路，处理"详细分析一下"“总结这批文档”“帮我规划方案”"分析代码仓库"这类慢任务。

这比所有请求都丢给一个大模型更健康。

6. 不同场景怎么选？

实时语音对话

优先 Dense。

语音链路通常是：

ASR -> LLM -> TTS -> 播放

用户最敏感的是首包延迟和尾延迟。LLM 首 token 慢，用户会觉得机器人迟钝；p99 抖动大，体验会忽快忽慢。

所以实时语音主链路更适合 7B/14B Dense。MoE 可以作为复杂问题兜底，但不建议一开始就放在每轮对话主路径上。

AI Agent

看 Agent 类型。

轻量 Agent，比如查订单、调业务 API、控制设备、查知识库，小 Dense 或中 Dense 足够。复杂 Agent，比如代码修改、多轮规划、长上下文分析、多工具编排，MoE 或更大 Dense 更值得考虑。

但 Agent 稳不稳，不只取决于模型。工具设计、上下文管理、状态机、错误恢复、可观测性、测试集同样关键。

模型路由和意图识别

优先小 Dense。

模型路由本质上更接近分类任务。它需要快、稳、便宜、格式固定。0.5B-3B Dense，甚至规则加小模型混合，通常比大 MoE 更合理。

代码生成和代码 Agent

简单代码问答、局部函数生成、解释代码，中 Dense 可以。复杂代码仓库分析、跨文件修改、自动修复、长上下文代码 Agent，MoE 或专用代码模型更有优势。

代码场景不要只看榜单，要测仓库理解、工具调用准确率、patch 成功率、单测通过率和回滚能力。

长文本总结和知识分析

MoE 更值得考虑。

长文本、多文档、知识密集型报告，对模型容量要求更高。MoE 的大总容量在这类任务里更容易体现价值。

但如果显存有限，14B/32B Dense 加上 RAG、分块总结、缓存和任务拆解，可能是更现实的方案。

本地单卡部署

显存紧张时优先 Dense。

单卡环境最怕边界不清。Dense 配合量化，容量规划更明确。MoE 虽然 active 参数低，但总权重仍大，部署前一定要确认框架、量化、offload 和上下文长度设置。

7. 评估模型时，不要只看榜单

模型选型最忌讳只看 benchmark。

榜单只能说明通用能力，不能说明你的业务体验。真正要做工程选型，应该建立自己的评估集。

至少要评估六类指标。

质量：对话质量、工具调用准确率、格式稳定性、业务问答准确率 延迟：TTFT p50/p90/p99、总耗时 p50/p90/p99、tokens/s、排队时间 并发：c=1/4/8/16/32 下分别测短回复、长回复、工具调用、复杂推理 显存：基础显存、KV cache、峰值显存、OOM、swap/offload 稳定性：12-24 小时压测、worker 重启、格式漂移、请求堆积、显存碎片 成本：GPU 数量、单卡实例数、量化损失、多卡复杂度、运维和微调成本

对于语音系统，还要加入 ASR 转写后的非标准输入。真实语音不是工整书面句，而是口语、省略、重复、断句不准、方言混杂。

对于 Agent 系统，还要把工具调用成功率、参数正确率、错误恢复率、任务完成率放进评估集。

对于 MoE，还要单独观察不同并发和 batch 下的吞吐与尾延迟。低并发快，不代表高并发稳；高并发吞吐好，也不代表实时体验好。

8. 一张实用选型表

9. 我的建议

不要用一个模型解决所有问题。

更稳的工程答案是：

小模型负责判断。 中模型负责实时。 大模型负责复杂。 工具系统负责确定性执行。 缓存系统减少重复推理。 规则系统兜住高确定性场景。

MoE 和 Dense 不是谁替代谁。Dense 的核心价值是稳定、简单、可预测、好部署，适合作为在线主链路。MoE 的核心价值是大容量、低激活计算、高能力上限，适合作为复杂任务和高质量慢路径。

所以在大多数业务系统里，真正合理的答案不是"选 MoE 还是 Dense"，而是：

Dense 做主链路，MoE 做增强链路。 小 Dense 做路由，中 Dense 做实时，大 MoE 做复杂任务。

这才是更稳的 Qwen 模型工程选型。

错误速查卡