MoE 推理部署实战：同样的 6GB 显存，你选速度还是能力？

副标题：三个模型、两组对比、一个三元 trade-off——MoE 在 6GB 家用卡上的真实表现

一、引子：纸上得来终觉浅

上一篇《大模型架构演进全景》从理论上梳理了 MoE 的设计思想：总参数大、激活参数小、每个 token 只走部分专家，用稀疏激活对抗"所有参数必须同时激活"这个假设。

但理论是理论，实际跑一个 MoE 模型，和看论文的感受完全不同。

尤其是 MoE 对"资源受限用户"的诱惑力是巨大的——“30B 模型只激活 3B，岂不是又快又强？” 如果这是真的，那买 H100 的人岂不是冤大头？

这篇文章的目标就是亲手验证这个说法。我们下载了三个模型，在GTX 1660 Ti（6GB）上跑了两组对比实验，还拉了同系列的 Dense 模型做公平对照。最终得到的结果跟网上流行的说法不完全一样——而这个"不一样"正是最有价值的部分。

二、三个参赛选手

我们从浩如烟海的模型中精心挑选了三员大将，构成一个"家族内对比 + 跨架构对比"的组合：

选型的理由：

• 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-7B（MoE，1.3B 激活）和Qwen3-8B（Dense，8.2B 激活）都完整加载到 GPU 上（-ngl=99），测标准 prompt processing（512 tokens）和 generation（128 tokens）。

结果

MoE 的生成速度是 Dense 的 4.3 倍。这个差距几乎和激活参数比（1.3B / 8.2B ≈ 15.8%）成反比——说明 MoE 的理论优势在显存充足的情况下确实成立。

Prompt processing 方面 MoE 也快了 3.2 倍。这里的关键仍然是激活参数量：即使 512 个 token 覆盖了大部分 expert，每个 expert 收到的 token 数比 Dense 模型少得多，总计算量还是更低。

延伸：不同 prompt 长度

MoE 在大 prompt 下依然保持 3x+ 优势，且 prompt processing 速度的衰减率和 Dense 相当。这说明 MoE 的 attention 开销和 Dense 一样（都是 attention 层），但 FFN 开销更小。长 prompt 下 attention 的 O(n²) 是两者共同的瓶颈。

最有意思的数据点：OLMoE CPU only

OLMoE -ngl=0 (纯 CPU): pp 307 t/s, tg 29 t/s OLMoE -ngl=99 (全 GPU): pp 476 t/s, tg 178 t/s

即使跑在 CPU 上，OLMoE 的 prompt processing（307 t/s）也比 8B Dense 在 GPU 上（148 t/s）快 2 倍——仍然是激活参数少的功劳。但 generation（29 t/s）比 GPU 慢了很多——因为 DDR4 带宽（~30 GB/s）相比于 GPU 显存带宽（~288 GB/s）差了近 10 倍。

四、对照实验②：当 MoE 遇到显存墙

上一节的结论很漂亮，但它有一个隐含的大前提：你的 MoE 模型必须能完整装进 GPU。

现在换 Qwen3-30B-A3B（17.4 GB）上场。6GB 显存装不下，只能靠-ngl（n-gpu-layers）把部分层卸载到 GPU：

关键发现：悲观 vs 乐观

悲观数据：30B MoE 在 6GB 卡上，最优 -ngl=12 时生成速度12.8 t/s——不到 8B Dense（40 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，收益递减：

-ngl=0→8: pp 38→79 t/s (+108%) ← 大飞跃，关键层上 GPU -ngl=8→12: pp 79→84 t/s (+6%) ← 已经开始平缓 -ngl=12→14: OOM ← 到极限了

原因在于 MoE 模型的参数分布。Qwen3-30B-A3B 每层约 0.8B 参数（其中 attention 约 0.2B + MoE FFN 约 0.6B）。前几层上 GPU 时，计算从 DDR4 搬到显存，收益巨大。但当大部分层已经在 GPU 上时，剩下的层计算受限于PCIe 3.0 传输带宽（~12 GB/s），多放几层的边际收益微乎其微。

一张表总结三组对比

五、能力对比：速度不是唯一指标

只看速度不公平——我们用同一个问题测试三个模型的回答质量：

提示词：“请用一句话解释什么是混合专家模型（MoE）”

OLMoE-1B-7B：

“混合专家模型（MoE）是一种将多个专家领域或专家模型联合整合的技术，旨在提高模型的智能和泛化能力。”

——定义笼统，像教科书第一句。不能说错，但也不够深入。

Qwen3-8B：

“混合专家模型（MoE）是一种机器学习模型架构，它结合了多个专家模型，每个专家负责处理不同的任务或数据子集，然后通过一个门控网络来决定哪个专家更适合当前的任务。”

——提到了"门控网络"这个关键机制，说明架构理解到位。同一系列的模型，训练质量高。

Qwen3-30B-A3B：

——输出质量和 Qwen3-8B 相当（同系列同训练），但因为 -ngl=12，首字延迟明显。

虽然只是单个样例，但结合模型规模来看，能力梯队很清晰：

能力: 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 (-ngl=12)

没有免费的午餐。你想要智能（30B），就要接受 13 t/s 的速度。你想要速度（OLMoE），就要接受较弱的能力。而 8B Dense 站在了中间的甜区——差不多够用的智能 + 41 t/s 流畅对话。

六、更深的视角：MoE 的瓶颈在哪里？

实验做完了，但有一个更根本的问题值得思考。

在 6GB 家用卡上，我们观察到的瓶颈是PCIe 传输（30B 参数装不下，只能 -ngl offload，CPU↔GPU 传输耗时）。但试想一下：如果把同样的 30B MoE 模型部署到一个 8×H100 的集群上呢？

瓶颈转移到了通信上。

Dense 模型的分布式通信

Dense 模型的分布式推理用ring all-reduce，通信模式是规律的、确定的：

GPU0 ── GPU1 ── GPU2 ── GPU3 ← 相邻 GPU 之间点对点同步 ↑ 确定且均匀的通信量

每层 attention 做完，一次 all-reduce 同步所有 GPU 上的结果。通信量和模型规模线性相关，且可预测。

MoE 模型的分布式通信：All-to-All

MoE 的分布式部署完全不同。每个 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-all

MoE 的通信模式是随机且不均匀的：

• 这次推理，GPU 0 可能需要和 GPU 1、2、3 都交换数据
• 下次推理，可能只和 GPU 2 交换
• 某些 expert 被频繁选中（热点），对应的 GPU 成为通信瓶颈

MoE 不是在消除瓶颈，而是在选择瓶颈

这个视角把整篇文章的发现串联了起来：

MoE 不是在和物理定律对抗——它只是在和"所有参数必须同时激活"这个假设对抗。

这个假设一旦被打破，你确实可以在 6GB 显存上跑 30B 模型。但瓶颈只是从"显存放不下"变成了"数据搬不过去"。MoE 没有消除瓶颈，它只是让你选择：你愿意用带宽换容量，还是反之？

七、总结：能力 × 速度 × 显存——三元 trade-off

回到文章开头的问题：同样的 6GB 显存，你选速度还是能力？

答案是不能兼得。我们看到了三个选择：

给不同用户的建议

如果你用 6GB 卡：

• 日常聊天 →8B Dense。40 t/s 流畅不卡顿，能力够用
• 需要高能力、可以忍受慢 →30B MoE (-ngl=12)。13 t/s 能看出卡顿，但确实能跑 30B
• 跑批量离线任务 →30B MoE (-ngl=12)。不在乎首字延迟，纯算力效率更高

如果你用 12-24GB 卡：

• MoE 的优势开始显现——可以全 GPU 跑更大的 MoE，3B 激活 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 3600
• RAM: 32GB DDR4
• Storage: NVMe SSD
• PCIe: 3.0 x16

软件环境

• llama.cpp commit d414db02 (7152)
• CUDA 11.x, cuBLAS backend
• Ubuntu 22.04

完整 Benchmark 数据

Qwen3-8B Q4_K_M (Dense):

Qwen3-30B-A3B Q4_K_M (MoE):

OLMoE-1B-7B-Instruct Q4_K_M (MoE):