Qwen3 MoE vs Dense 怎么选2026 工程部署视角完整指南TL;DR场景本地模型部署、AI Agent、实时语音对话、模型路由、Qwen3 系列选型结论Dense 适合实时主链路稳定、可预测、低 p99MoE 适合复杂慢路径高质量、能力上限高最佳实践是分层使用——小 Dense 路由、中 Dense 实时、大 MoE 兜底复杂任务产出一张 6 维度评估指标清单 14 场景选型表 5 张配图解释版本矩阵功能 / 规格状态说明Qwen3-30B-A3B 总参数约 30.5B✅ 已验证305 亿总参数、33 亿激活参数、128 专家中激活 8 个、48 层Qwen3-235B-A22B 总参数约 235B✅ 已验证2350 亿总参数、220 亿激活参数原生 32K 上下文YaRN 扩展至 131KQwen3-Next-80B-A3B 总参数约 80B✅ 已验证800 亿总参数、30 亿激活参数、混合注意力、256K 上下文Qwen3 Dense 系列0.6B/1.7B/4B/8B/14B/32B✅ 已验证全部为 Apache 2.0 开源2025-04-29 发布Qwen3-30B-A3B 原生上下文 32K✅ 已验证YaRN 可扩展至 131KQwen3-235B-A22B 部署门槛约 4 张 H20⚠️ 待验证来源为新闻稿描述实际部署需结合量化与显存策略Qwen3-Next-80B-A3B 训练成本约为 Qwen3-32B 的 1/10✅ 已验证阿里官方博客披露MoE 显存 ≈ active 参数❌ 已证伪显存占用主要由总权重、KV cache、并发量决定不能按 active 估算MoE 低并发短请求一定比 Dense 快⚠️ 待验证取决于框架优化、batch 大小、调度开销需实测最近做本地模型部署、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 不够上 14B14B 不够上 32B32B 不够上 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 可以。复杂代码仓库分析、跨文件修改、自动修复、长上下文代码 AgentMoE 或专用代码模型更有优势。代码场景不要只看榜单要测仓库理解、工具调用准确率、patch 成功率、单测通过率和回滚能力。长文本总结和知识分析MoE 更值得考虑。长文本、多文档、知识密集型报告对模型容量要求更高。MoE 的大总容量在这类任务里更容易体现价值。但如果显存有限14B/32B Dense 加上 RAG、分块总结、缓存和任务拆解可能是更现实的方案。本地单卡部署显存紧张时优先 Dense。单卡环境最怕边界不清。Dense 配合量化容量规划更明确。MoE 虽然 active 参数低但总权重仍大部署前一定要确认框架、量化、offload 和上下文长度设置。7. 评估模型时不要只看榜单模型选型最忌讳只看 benchmark。榜单只能说明通用能力不能说明你的业务体验。真正要做工程选型应该建立自己的评估集。至少要评估六类指标。质量对话质量、工具调用准确率、格式稳定性、业务问答准确率 延迟TTFT p50/p90/p99、总耗时 p50/p90/p99、tokens/s、排队时间 并发c1/4/8/16/32 下分别测短回复、长回复、工具调用、复杂推理 显存基础显存、KV cache、峰值显存、OOM、swap/offload 稳定性12-24 小时压测、worker 重启、格式漂移、请求堆积、显存碎片 成本GPU 数量、单卡实例数、量化损失、多卡复杂度、运维和微调成本对于语音系统还要加入 ASR 转写后的非标准输入。真实语音不是工整书面句而是口语、省略、重复、断句不准、方言混杂。对于 Agent 系统还要把工具调用成功率、参数正确率、错误恢复率、任务完成率放进评估集。对于 MoE还要单独观察不同并发和 batch 下的吞吐与尾延迟。低并发快不代表高并发稳高并发吞吐好也不代表实时体验好。8. 一张实用选型表场景优先选择实时语音对话主链路Dense首 token 极敏感Dense机器人控制DenseFunction Calling 稳定输出Dense模型路由 / 意图分类小 Dense长文本总结MoE 或大 Dense复杂 Agent 规划MoE 或大 Dense代码仓库分析MoE 或专用代码模型高并发离线任务MoE 可考虑显存紧张小 Dense / 量化 DenseLoRA 微调Dense多卡部署且有工程优化能力MoE 可考虑追求部署简单Dense追求能力上限MoE 或大 Dense9. 我的建议不要用一个模型解决所有问题。更稳的工程答案是小模型负责判断。 中模型负责实时。 大模型负责复杂。 工具系统负责确定性执行。 缓存系统减少重复推理。 规则系统兜住高确定性场景。MoE 和 Dense 不是谁替代谁。Dense 的核心价值是稳定、简单、可预测、好部署适合作为在线主链路。MoE 的核心价值是大容量、低激活计算、高能力上限适合作为复杂任务和高质量慢路径。所以在大多数业务系统里真正合理的答案不是选 MoE 还是 Dense而是Dense 做主链路MoE 做增强链路。 小 Dense 做路由中 Dense 做实时大 MoE 做复杂任务。这才是更稳的 Qwen 模型工程选型。错误速查卡症状根因定位修复部署 30B-A3B 时 OOM以为显存按 3B 估算就够误把 active 参数当作总权重查看nvidia-smi加载后权重占用 ≈ 30B × 精度按总权重 KV cache 并发估算显存必要时量化或上 CPU offloadMoE 低并发短请求比 Dense 还慢调度 / 路由 / kernel 开销未被 batch 摊薄用 vLLM、SGLang profiler 看 expert dispatch 时延调大 batch、切换框架vLLM/SGLang、改用 Dense 处理实时短请求MoE 服务 p99 抖动大专家负载不均 路由抖动监控 expert load histogram 与 TTFT p99开启负载均衡 loss、专家并行、限制单专家并发或兜底路由长上下文高并发场景频繁 OOMKV cache 随上下文与并发线性增长监控 KV cache 占用百分比启用 PagedAttention、量化 KV、降并发或拆上下文MoE 微调后推理行为漂移router / 专家未参与或退化比对微调前后激活专家分布联合训练 router、增加负载均衡 loss、用兼容推理格式导出模型路由用大 MoE 反而更慢更贵分类任务不需要大模型能力测 c1 的 TTFT 与 tokens/s改用 0.6B-3B Dense 或规则 小模型混合Qwen3-235B-A22B 部署显存估错误信4 卡 H20 即可忽略精度与并发检查实际 GPU 显存、FP16/BF16/INT8 占用按精度 KV cache 并发重算必要时张量并行 量化Qwen3-Next-80B-A3B 推理框架不兼容混合注意力 MTP 架构新报 kernel 不支持、attention 报错升级 vLLM/SGLang 到支持 Qwen3-Next 的版本或回退到 30B-A3B
调查研究-194 Qwen3 MoE vs Dense 怎么选？2026 工程部署视角完整指南
Qwen3 MoE vs Dense 怎么选2026 工程部署视角完整指南TL;DR场景本地模型部署、AI Agent、实时语音对话、模型路由、Qwen3 系列选型结论Dense 适合实时主链路稳定、可预测、低 p99MoE 适合复杂慢路径高质量、能力上限高最佳实践是分层使用——小 Dense 路由、中 Dense 实时、大 MoE 兜底复杂任务产出一张 6 维度评估指标清单 14 场景选型表 5 张配图解释版本矩阵功能 / 规格状态说明Qwen3-30B-A3B 总参数约 30.5B✅ 已验证305 亿总参数、33 亿激活参数、128 专家中激活 8 个、48 层Qwen3-235B-A22B 总参数约 235B✅ 已验证2350 亿总参数、220 亿激活参数原生 32K 上下文YaRN 扩展至 131KQwen3-Next-80B-A3B 总参数约 80B✅ 已验证800 亿总参数、30 亿激活参数、混合注意力、256K 上下文Qwen3 Dense 系列0.6B/1.7B/4B/8B/14B/32B✅ 已验证全部为 Apache 2.0 开源2025-04-29 发布Qwen3-30B-A3B 原生上下文 32K✅ 已验证YaRN 可扩展至 131KQwen3-235B-A22B 部署门槛约 4 张 H20⚠️ 待验证来源为新闻稿描述实际部署需结合量化与显存策略Qwen3-Next-80B-A3B 训练成本约为 Qwen3-32B 的 1/10✅ 已验证阿里官方博客披露MoE 显存 ≈ active 参数❌ 已证伪显存占用主要由总权重、KV cache、并发量决定不能按 active 估算MoE 低并发短请求一定比 Dense 快⚠️ 待验证取决于框架优化、batch 大小、调度开销需实测最近做本地模型部署、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 不够上 14B14B 不够上 32B32B 不够上 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 可以。复杂代码仓库分析、跨文件修改、自动修复、长上下文代码 AgentMoE 或专用代码模型更有优势。代码场景不要只看榜单要测仓库理解、工具调用准确率、patch 成功率、单测通过率和回滚能力。长文本总结和知识分析MoE 更值得考虑。长文本、多文档、知识密集型报告对模型容量要求更高。MoE 的大总容量在这类任务里更容易体现价值。但如果显存有限14B/32B Dense 加上 RAG、分块总结、缓存和任务拆解可能是更现实的方案。本地单卡部署显存紧张时优先 Dense。单卡环境最怕边界不清。Dense 配合量化容量规划更明确。MoE 虽然 active 参数低但总权重仍大部署前一定要确认框架、量化、offload 和上下文长度设置。7. 评估模型时不要只看榜单模型选型最忌讳只看 benchmark。榜单只能说明通用能力不能说明你的业务体验。真正要做工程选型应该建立自己的评估集。至少要评估六类指标。质量对话质量、工具调用准确率、格式稳定性、业务问答准确率 延迟TTFT p50/p90/p99、总耗时 p50/p90/p99、tokens/s、排队时间 并发c1/4/8/16/32 下分别测短回复、长回复、工具调用、复杂推理 显存基础显存、KV cache、峰值显存、OOM、swap/offload 稳定性12-24 小时压测、worker 重启、格式漂移、请求堆积、显存碎片 成本GPU 数量、单卡实例数、量化损失、多卡复杂度、运维和微调成本对于语音系统还要加入 ASR 转写后的非标准输入。真实语音不是工整书面句而是口语、省略、重复、断句不准、方言混杂。对于 Agent 系统还要把工具调用成功率、参数正确率、错误恢复率、任务完成率放进评估集。对于 MoE还要单独观察不同并发和 batch 下的吞吐与尾延迟。低并发快不代表高并发稳高并发吞吐好也不代表实时体验好。8. 一张实用选型表场景优先选择实时语音对话主链路Dense首 token 极敏感Dense机器人控制DenseFunction Calling 稳定输出Dense模型路由 / 意图分类小 Dense长文本总结MoE 或大 Dense复杂 Agent 规划MoE 或大 Dense代码仓库分析MoE 或专用代码模型高并发离线任务MoE 可考虑显存紧张小 Dense / 量化 DenseLoRA 微调Dense多卡部署且有工程优化能力MoE 可考虑追求部署简单Dense追求能力上限MoE 或大 Dense9. 我的建议不要用一个模型解决所有问题。更稳的工程答案是小模型负责判断。 中模型负责实时。 大模型负责复杂。 工具系统负责确定性执行。 缓存系统减少重复推理。 规则系统兜住高确定性场景。MoE 和 Dense 不是谁替代谁。Dense 的核心价值是稳定、简单、可预测、好部署适合作为在线主链路。MoE 的核心价值是大容量、低激活计算、高能力上限适合作为复杂任务和高质量慢路径。所以在大多数业务系统里真正合理的答案不是选 MoE 还是 Dense而是Dense 做主链路MoE 做增强链路。 小 Dense 做路由中 Dense 做实时大 MoE 做复杂任务。这才是更稳的 Qwen 模型工程选型。错误速查卡症状根因定位修复部署 30B-A3B 时 OOM以为显存按 3B 估算就够误把 active 参数当作总权重查看nvidia-smi加载后权重占用 ≈ 30B × 精度按总权重 KV cache 并发估算显存必要时量化或上 CPU offloadMoE 低并发短请求比 Dense 还慢调度 / 路由 / kernel 开销未被 batch 摊薄用 vLLM、SGLang profiler 看 expert dispatch 时延调大 batch、切换框架vLLM/SGLang、改用 Dense 处理实时短请求MoE 服务 p99 抖动大专家负载不均 路由抖动监控 expert load histogram 与 TTFT p99开启负载均衡 loss、专家并行、限制单专家并发或兜底路由长上下文高并发场景频繁 OOMKV cache 随上下文与并发线性增长监控 KV cache 占用百分比启用 PagedAttention、量化 KV、降并发或拆上下文MoE 微调后推理行为漂移router / 专家未参与或退化比对微调前后激活专家分布联合训练 router、增加负载均衡 loss、用兼容推理格式导出模型路由用大 MoE 反而更慢更贵分类任务不需要大模型能力测 c1 的 TTFT 与 tokens/s改用 0.6B-3B Dense 或规则 小模型混合Qwen3-235B-A22B 部署显存估错误信4 卡 H20 即可忽略精度与并发检查实际 GPU 显存、FP16/BF16/INT8 占用按精度 KV cache 并发重算必要时张量并行 量化Qwen3-Next-80B-A3B 推理框架不兼容混合注意力 MTP 架构新报 kernel 不支持、attention 报错升级 vLLM/SGLang 到支持 Qwen3-Next 的版本或回退到 30B-A3B
