M3 Ultra本地推理Qwen3-Coder-Next 80B模型，MLX对比llama.cpp性能实测

最近，国产大模型的开源进展令人瞩目，Qwen系列在代码能力上表现尤为出色，已能媲美甚至在某些场景超越国际顶级模型。最新发布的 Qwen3-Coder-Next 更是将参数规模提升至 80B MoE（总参80B，激活参数仅3B），并提供了长达 256K 的上下文支持，堪称当前本地可运行的最强编码模型之一。但一个现实问题摆在眼前：如此庞大的模型，真的能在消费级硬件上流畅运行吗？正好手头有一台顶配的 Mac Studio M3 Ultra（80核GPU，512GB统一内存），便借此机会进行了一次详尽的本地推理性能测试，对比对象是目前最主流的两个推理框架：MLX（苹果官方优化框架）和 llama.cpp（社区通用推理引擎）。

测试结果有些出人意料。先说核心结论：在同一台M3 Ultra 512GB机器上，运行相同的 Qwen3-Coder-Next 80B MoE 模型，MLX 在生成速度（Tokens Per Second）上全面、大幅领先于 llama.cpp。

更具体地看，在三种主流量化方式下的平均性能对比，MLX的优势非常明显。可以说，对于最影响实际体验的打字/出代码速度，MLX 比 llama.cpp 快了约 50% 到 63%。即便是理论上最“公平”的 BF16 原生精度，MLX 的领先幅度也接近一半。这已不是简单的优化差距，更像是底层架构差异的直接体现。

真正决定一个模型是否“可用”，往往不是其极限速度，而是随着上下文长度增加，生成速度的衰减曲线。以下是 4bit量化 下，两个框架的上下文长度与生成速度（t/s）对比：

MLX 4bit 表现（抗衰减能力较强）

• 0.5K → 73 t/s
• 1K → 72 t/s
• 4K → 71 t/s
• 16K → 66 t/s
• 32K → 62 t/s
• 64K → 55 t/s
• 128K → 46 t/s

可以看到，在 128K 的超长上下文下，MLX 仍能保持 46 tokens/s 的速度，这对于编写代码、执行 Agent 任务、分析大型项目或长文档来说，体验已经相当流畅。

llama.cpp Q4_0 表现

• 0.5K → 43 t/s
• 1K → 43 t/s
• 4K → 43 t/s
• 16K → 40 t/s
• 32K → 39 t/s
• 64K → 36 t/s
• 128K → 31 t/s

在相同 128K 上下文下，llama.cpp 的速度降至 31 t/s，已经能感受到明显的“卡顿感”。

内存占用方面（以4bit为例），MLX 在 128K 上下文下约为 58.5GB。8bit 和 BF16 模式下，内存需求则急剧上升（8bit ≈ 98GB，BF16 ≈ 173GB）。这也解释了为何需要 512GB 内存的 M3 Ultra 才能充分发挥这个 256K 上下文 80B MoE 模型的潜力——普通 MacBook Pro（即使是 M4 Max 128GB）在长上下文下极易耗尽内存。

测试环境与复现方法

为了方便复现与验证，以下是本次测试的具体环境与步骤：

• 硬件：Mac Studio M3 Ultra（80核GPU）+ 512GB 统一内存
• 系统：macOS 最新版
• MLX 版本：mlx-lm 0.30.6
• llama.cpp 版本：b7960（使用 llama-server 模式）
• 模型：Qwen3-Coder-Next 80B MoE（256K上下文，支持 GGUF & safetensors 格式）
• 量化：官方发布的 Q4_0 / Q8_0 / BF16 版本

启动命令示例：

MLX 方式

uv run benchmark -- llamacpp Qwen3-Coder-Next-Q8_0 --contexts 0.5,1,2,4,8,16,32,64,128 --port 9000

llama.cpp 方式
先启动服务：

llama-server -m ~/models/Qwen3-Coder-Next-Q4_0.gguf --host 127.0.0.1 --port 9000 -ngl 99

再运行基准测试：

uv run benchmark -- llamacpp Qwen3-Coder-Next-Q4_0 --contexts 0.5,1,2,4,8,16,32,64,128 --port 9000

性能差异原因分析

为什么在这个特定场景下，MLX 能拉开如此大的差距？个人分析可能存在以下几个关键原因（仅供参考）：

1. MLX 对 Metal API 的深度定制优化：MLX 底层专为 Apple Silicon 的统一内存架构设计，其内核融合、内存拷贝和任务调度都进行了极致优化，能更充分地发挥硬件潜力。
2. MoE 模型的特殊性：80B MoE 模型的实际激活参数虽只有 3B，但其路由计算、专家选择等逻辑对内存访问模式要求极高。MLX 在这部分的调度策略似乎更为高效。
3. llama.cpp 对 MoE 的支持仍在快速演进：llama.cpp 对 MoE 架构的支持是近一年才逐步完善的，在面对“超大上下文+超大MoE”这种组合场景时，其内核融合、内存布局等方面的优化可能尚未完全到位。
4. 对统一内存的极致利用：512GB 的超大统一内存允许 MLX 将更多中间状态和 KV Cache 保留在高速内存中，减少了因内存换页带来的性能损耗，这对于 计算密集型 的大模型推理至关重要。

总结与选择建议

客观来看，两个框架各有侧重：

• 如果你追求极致的兼容性、最丰富的模型格式支持以及最活跃的社区生态，llama.cpp 仍然是首选。
• 如果你的主战场是 Apple Silicon 设备，并且主要运行 MoE 类或超长上下文的大模型，那么当前 MLX 能提供明显更优的体验和性能。

至少在当下，MLX 在 M 系列芯片上运行这类“巨无霸”级代码模型的推理效率确实优势显著。当然，llama.cpp 的迭代速度有目共睹，未来的版本很可能大幅缩小甚至反超这一差距。对于热衷于本地部署大模型的开发者来说，持续关注并参与到 云栈社区 的相关讨论中，是跟上技术演进、优化自身实践的好方法。