我实测了：将密集27B模型换成30B-A3B MoE模型如何改变本地并发上限（与先前测试相同平台，仅改变一个变量）
摘要
作者在MacBook Pro上测试并比较了密集与MoE AI模型的并发性能，发现由于每个token的内存带宽使用更低，MoE模型的扩展性显著更好。
两天前我发布了一个实测的并发上限：在我的MacBook Pro M3 Max上，两个本地代理共享一个内存总线，同时访问一个模型，而在27B密集模型上，无论添加多少代理，总吞吐量在接近20 tok/s时趋于平稳。我在科技界认识了几十年的好友给了我一个我未曾测试的警示：密集模型是最坏情况，因为每个token都需要从内存中重新读取所有27B的权重。而专家混合（MoE）模型每个token只激活约3B参数，因此每个token移动的内存只是一小部分，应该能为第二个槽位留出空间，从而真正受益。所以我对一个MoE模型运行了完全相同的36负载屏障同步矩阵。这是对我过去3天多一直在进行的实验的补充。相同的MLX服务器、相同的提示、相同的机器，只改变了一个变量：密集模型Qwen 3.8 27B → MoE模型Qwen3-30B-A3B，两者都是4位。结果（总吞吐量，所有代理求和，在1/2/4/8个并发代理下）：密集27B：16.6 / 20.8 / 19.9 / 19.1 ← 趋于平稳 MoE 30B-A3B：58.1 / 95.0 / 122.8 / 158.6 ← 持续增长 8个代理时每个代理的解码速率：密集模型每个3.9 tok/s，MoE模型每个21.6 tok/s。八个MoE代理每个仍然胜过一个孤独的密集代理（17.4 tok/s）。8个代理时首个token的时间：密集模型32.2秒，MoE模型0.8秒。这一列数据解释了为什么繁忙的本地模型感觉卡顿，而MoE模型基本消除了这种感觉。当我保留'Misses'时，有人鼓掌，所以这次我也保留... 诚实的修正我保留了：在狭窄的解码密集型K=2单元（短提示，长输出）中，两个模型扩展性大致相同，密集模型1.57倍 vs MoE模型1.55倍。差距只在完整扫描和绝对速度上显现。一个单元差点误导了我。机制一句话：解码受内存带宽限制；密集模型移动约27B参数/token，MoE模型移动约3B，因此MoE为下一个并发流留下了更多固定带宽预算。
相似文章
3.6-27B 发布：Dense 与 MoE 差距正迅速缩小
最新 3.6-27B 版本显示，MoE 在代码任务及长上下文场景中正快速逼近 Dense 模型，尽管 Dense 整体仍领先。
Qwen 35B-A3B MoE 与 27B dense 本地编码测试对比：速度快约 4 倍，质量差距远小于预期
一项本地实验，在代码维护任务上比较 Qwen 35B-A3B MoE 和 Qwen 27B dense，发现 MoE 模型速度快约 3.9 倍，且质量差距比预期更小。
我通过从SSD流式传输MoE专家权重，在36 GB MacBook上运行35B–480B编码模型——自包含应用，并且我也公开了那些*失败*的基准测试
Slipstream 通过从SSD而非RAM流式传输MoE专家权重，使得在36 GB MacBook上运行大型编码模型（35B–480B）成为可能。基准测试显示，35B模型约13–19 tok/s，118B模型约2.8 tok/s，并诚实报告了失败的方法。
4x RTX 3090 上的 Qwen3.5-27B、Qwen3.5-122B 和 Qwen3.6-35B —— MoE 模型在严格全局规则下的表现困境
潜水多年的老用户，首次发帖。在 4 张 RTX 3090 上对三款 Qwen 模型分别进行了 20 多个会话的实时智能体工作测试——**Qwen3.5-27B** 稠密模型、**Qwen3.5-122B-A10B** MoE 和 **Qwen3.6-35B-A3B** MoE。以下数据均解析自持续真实负载下的 vLLM 日志，而非合成基准测试。**本文所有数据的关键负载背景：** 测试框架是一个多智能体编排器，同时运行 1-6 个并发的 OpenCode 会话，Prompt 长度为 30-60k token，并且强制执行**严格的 Bash 允许列表
对密集模型 gemma-4-31b-it 与 MoE 模型 gemma-4-26b-a4b-it 进行基准测试，验证成本降低在实际中是否成立
一项对 Gemma 密集模型（31B）与 MoE 模型（26B）的实际基准测试显示，MoE 模型每次查询速度快 25.5%，成本低 20%，且质量相同，验证了理论上的成本节约。