副标题三个模型、两组对比、一个三元 trade-off——MoE 在 6GB 家用卡上的真实表现一、引子纸上得来终觉浅上一篇《大模型架构演进全景》从理论上梳理了 MoE 的设计思想总参数大、激活参数小、每个 token 只走部分专家用稀疏激活对抗所有参数必须同时激活这个假设。但理论是理论实际跑一个 MoE 模型和看论文的感受完全不同。尤其是 MoE 对资源受限用户的诱惑力是巨大的——“30B 模型只激活 3B岂不是又快又强” 如果这是真的那买 H100 的人岂不是冤大头这篇文章的目标就是亲手验证这个说法。我们下载了三个模型在GTX 1660 Ti6GB上跑了两组对比实验还拉了同系列的 Dense 模型做公平对照。最终得到的结果跟网上流行的说法不完全一样——而这个不一样正是最有价值的部分。二、三个参赛选手我们从浩如烟海的模型中精心挑选了三员大将构成一个家族内对比 跨架构对比的组合模型架构总/激活参数量化后大小来源Qwen3-8BDense8.2B / 8.2B4.7 GB同系列 Dense 基线OLMoE-1B-7BMoE (64 experts, top-8)6.9B /1.3B3.9 GBAI2, Apache 2.0Qwen3-30B-A3BMoE (128 experts, top-8)30.5B /3.0B17.4 GBQwen3 同系列 MoE选型的理由Qwen3-8B 和 Qwen3-30B-A3B 来自 Qwen3 同系列能力基线一致对比公平。30B MoE 和 8B Dense 都来自通义千问 3 代训练数据、对齐策略相同——速度差异就是架构差异。OLMoE-1B-7B 是唯一能完全装进 6GB 显存的 MoE 模型Q4_K_M 仅 3.9 GB可以和 Qwen3-8B 做全 GPU 下的纯净架构对比。Qwen3-30B-A3B 代表了真实世界——很多用户会选它但 6GB 卡装不下必须 -ngl 部分卸载。三、对照实验①全 GPU 下MoE 到底有多快这是最干净的一组对比把OLMoE-1B-7BMoE1.3B 激活和Qwen3-8BDense8.2B 激活都完整加载到 GPU 上-ngl99测标准 prompt processing512 tokens和 generation128 tokens。结果模型架构激活参Prompt 512Generation 128相对速度OLMoE-1B-7BMoE1.3B476 t/s178 t/s4.3xQwen3-8BDense8.2B148 t/s41 t/s—MoE 的生成速度是 Dense 的 4.3 倍。这个差距几乎和激活参数比1.3B / 8.2B ≈ 15.8%成反比——说明 MoE 的理论优势在显存充足的情况下确实成立。Prompt processing 方面 MoE 也快了 3.2 倍。这里的关键仍然是激活参数量即使 512 个 token 覆盖了大部分 expert每个 expert 收到的 token 数比 Dense 模型少得多总计算量还是更低。延伸不同 prompt 长度Prompt 长度OLMoE (MoE)Qwen3-8B (Dense)512476 t/s148 t/s2048435 t/s131 t/sMoE 在大 prompt 下依然保持 3x 优势且 prompt processing 速度的衰减率和 Dense 相当。这说明 MoE 的 attention 开销和 Dense 一样都是 attention 层但 FFN 开销更小。长 prompt 下 attention 的 O(n²) 是两者共同的瓶颈。最有意思的数据点OLMoE CPU onlyOLMoE -ngl0 (纯 CPU): pp 307 t/s, tg 29 t/s OLMoE -ngl99 (全 GPU): pp 476 t/s, tg 178 t/s即使跑在 CPU 上OLMoE 的 prompt processing307 t/s也比 8B Dense 在 GPU 上148 t/s快 2 倍——仍然是激活参数少的功劳。但 generation29 t/s比 GPU 慢了很多——因为 DDR4 带宽~30 GB/s相比于 GPU 显存带宽~288 GB/s差了近 10 倍。四、对照实验②当 MoE 遇到显存墙上一节的结论很漂亮但它有一个隐含的大前提你的 MoE 模型必须能完整装进 GPU。现在换 Qwen3-30B-A3B17.4 GB上场。6GB 显存装不下只能靠-ngln-gpu-layers把部分层卸载到 GPU-nglPrompt 512Generation 128VRAM 占用说明038 t/s9.3 t/s~0 GB纯 CPUDDR4879 t/s11.9 t/s~2 GB8 层 GPU 30 层 CPU1080 t/s11.8 t/s~3 GB边际收益开始减弱1284 t/s12.8 t/s~4 GB⭐6GB 卡最优值14OOM (pp128)12.9 t/s~5.5 GB短 prompt 勉强可用16❌ 加载失败❌6 GB显存溢出关键发现悲观 vs 乐观悲观数据30B MoE 在 6GB 卡上最优 -ngl12 时生成速度12.8 t/s——不到 8B Dense40 t/s的三分之一。理论预测的3B 激活比 8B 快在 offload 场景下完全失效。乐观数据12.8 t/s 虽然慢但它确实能跑。纯 CPU 推理 30B Dense 是不可能的30B × 4 bytes 120 GB 内存还要算。而 MoE 通过 -ngl 部分卸载让 6GB 卡用 12.8 t/s 跑起了一个 30B 模型。为什么 -ngl 越高收益越低每多放一层到 GPU收益递减-ngl0→8: pp 38→79 t/s (108%) ← 大飞跃关键层上 GPU -ngl8→12: pp 79→84 t/s (6%) ← 已经开始平缓 -ngl12→14: OOM ← 到极限了原因在于 MoE 模型的参数分布。Qwen3-30B-A3B 每层约 0.8B 参数其中 attention 约 0.2B MoE FFN 约 0.6B。前几层上 GPU 时计算从 DDR4 搬到显存收益巨大。但当大部分层已经在 GPU 上时剩下的层计算受限于PCIe 3.0 传输带宽~12 GB/s多放几层的边际收益微乎其微。一张表总结三组对比模型显存策略PromptGeneration综合体验OLMoE-1B-7B(MoE)✅ 全 GPU476 t/s178 t/s飞快但不聪明 Qwen3-8B(Dense)✅ 全 GPU148 t/s41 t/s流畅且聪明 ✅Qwen3-30B-A3B(MoE)⚠️ -ngl1284 t/s13 t/s聪明但慢 五、能力对比速度不是唯一指标只看速度不公平——我们用同一个问题测试三个模型的回答质量提示词“请用一句话解释什么是混合专家模型MoE”OLMoE-1B-7B“混合专家模型MoE是一种将多个专家领域或专家模型联合整合的技术旨在提高模型的智能和泛化能力。”——定义笼统像教科书第一句。不能说错但也不够深入。Qwen3-8B“混合专家模型MoE是一种机器学习模型架构它结合了多个专家模型每个专家负责处理不同的任务或数据子集然后通过一个门控网络来决定哪个专家更适合当前的任务。”——提到了门控网络这个关键机制说明架构理解到位。同一系列的模型训练质量高。Qwen3-30B-A3B——输出质量和 Qwen3-8B 相当同系列同训练但因为 -ngl12首字延迟明显。虽然只是单个样例但结合模型规模来看能力梯队很清晰能力: OLMoE(1.3B) Qwen3-8B(8B) Qwen3-30B(30B cap) 速度: 178 t/s 41 t/s 13 t/s 显存: 3.9 GB 4.7 GB 17.4 GB (-ngl12)没有免费的午餐。你想要智能30B就要接受 13 t/s 的速度。你想要速度OLMoE就要接受较弱的能力。而 8B Dense 站在了中间的甜区——差不多够用的智能 41 t/s 流畅对话。六、更深的视角MoE 的瓶颈在哪里实验做完了但有一个更根本的问题值得思考。在 6GB 家用卡上我们观察到的瓶颈是PCIe 传输30B 参数装不下只能 -ngl offloadCPU↔GPU 传输耗时。但试想一下如果把同样的 30B MoE 模型部署到一个 8×H100 的集群上呢瓶颈转移到了通信上。Dense 模型的分布式通信Dense 模型的分布式推理用ring all-reduce通信模式是规律的、确定的GPU0 ── GPU1 ── GPU2 ── GPU3 ← 相邻 GPU 之间点对点同步 ↑ 确定且均匀的通信量每层 attention 做完一次 all-reduce 同步所有 GPU 上的结果。通信量和模型规模线性相关且可预测。MoE 模型的分布式通信All-to-AllMoE 的分布式部署完全不同。每个 token 选 8 个不同的 expert而 expert 分散在不同 GPU 上GPU 0: expert 0-31 GPU 1: expert 32-63 GPU 2: expert 64-95 GPU 3: expert 96-127 Token 我爱编程 → Router 选了 expert #7, #42, #81 ↓ ↓ ↓ GPU0 GPU1 GPU2 ↓ ↓ ↓ GPU0 需要从 GPU1 和 GPU2 收结果 → 这不是 ring all-reduce而是 all-to-allMoE 的通信模式是随机且不均匀的这次推理GPU 0 可能需要和 GPU 1、2、3 都交换数据下次推理可能只和 GPU 2 交换某些 expert 被频繁选中热点对应的 GPU 成为通信瓶颈MoE 不是在消除瓶颈而是在选择瓶颈这个视角把整篇文章的发现串联了起来部署场景瓶颈原因6GB 家用卡-ngl offloadPCIe 带宽30B 参数放不下CPU↔GPU 来回搬数据中心集群8×H100Interconnect 带宽All-to-all 通信随机模式热点 expert单卡显存充足计算量这是 MoE 真正的优势场景MoE 不是在和物理定律对抗——它只是在和所有参数必须同时激活这个假设对抗。这个假设一旦被打破你确实可以在 6GB 显存上跑 30B 模型。但瓶颈只是从显存放不下变成了数据搬不过去。MoE 没有消除瓶颈它只是让你选择你愿意用带宽换容量还是反之七、总结能力 × 速度 × 显存——三元 trade-off回到文章开头的问题同样的 6GB 显存你选速度还是能力答案是不能兼得。我们看到了三个选择选择代表模型优点代价 速度优先OLMoE-1B-7B小 MoE178 t/s飞一般的速度能力较弱✅ 均衡之选Qwen3-8BDense41 t/s 流畅 能力够用模型规模受限 智能优先Qwen3-30B-A3B大 MoE offload30B 模型的能力仅 13 t/s首字延迟高给不同用户的建议如果你用 6GB 卡日常聊天 →8B Dense。40 t/s 流畅不卡顿能力够用需要高能力、可以忍受慢 →30B MoE (-ngl12)。13 t/s 能看出卡顿但确实能跑 30B跑批量离线任务 →30B MoE (-ngl12)。不在乎首字延迟纯算力效率更高如果你用 12-24GB 卡MoE 的优势开始显现——可以全 GPU 跑更大的 MoE3B 激活 vs 8B Dense 的加速比 3-4x 会体现在生成速度上但要用同系列对比Qwen3-8B vs Qwen3-30B-A3B 全 GPU 才能公平如果你用 H100 集群MoE 的优势在于模型容量而非速度瓶颈从带宽转向了 all-to-all 通信效率expert 负载均衡和 NVLink 拓扑设计比模型选择更重要这篇和上篇的关系架构演进篇讲了 MoE 为什么存在——从 Dense 到 MoE 的技术演进。这一篇讲了 MoE 存在了你用起来是什么体验——理论落地到真实硬件上的样子。两篇连起来看就是一个完整的叙事“MoE 不是免费的午餐。它在理论上绕过了‘所有参数必须同时激活’的限制但在部署时把瓶颈从‘显存大小’转移到了‘带宽传输’上。你能不能享受到 MoE 的红利取决于你的硬件配置落在了 trade-off 曲线的哪一端。”附录实验环境与数据硬件环境GPU: NVIDIA GeForce GTX 1660 Ti (6GB GDDR6, Turing, compute 7.5)CPU: AMD Ryzen 5 3600RAM: 32GB DDR4Storage: NVMe SSDPCIe: 3.0 x16软件环境llama.cpp commit d414db02 (7152)CUDA 11.x, cuBLAS backendUbuntu 22.04完整 Benchmark 数据Qwen3-8B Q4_K_M (Dense):-nglPrompttg128备注99pp128: 151 t/s40.4 t/s99pp512: 149 t/s40.4 t/s99pp2048: 131 t/s39.9 t/sAttention O(n²) 开始显现Qwen3-30B-A3B Q4_K_M (MoE):-nglpp512tg128VRAM038.0 t/s9.3 t/s~0 GB878.6 t/s11.9 t/s~2 GB1080.2 t/s11.8 t/s~3 GB1283.7 t/s12.8 t/s~4 GB14OOM (pp256)12.9 t/s~5 GBOLMoE-1B-7B-Instruct Q4_K_M (MoE):-nglpp512tg128备注0307 t/s29.3 t/s纯 CPU99476 t/s178 t/s全 GPU99, pp2048435 t/s175 t/s长 prompt
