Apple MLX 分布式推理在 Mac Studio 上：Muse Spark Open 816B 在四台 Mac 上以每秒 36+ tokens 运行
Apple 的 ML 研究团队发布了一篇关于使用 MLX 和 RDMA 在 Mac Studio 上进行本地和分布式大型 LLM 推理的文章。头条结果：Muse Spark Open，一个接近万亿参数的模型，在四台搭载 M5 Ultra 的 Mac Studio 集群上每秒生成超过 36 个 tokens——远高于人类平均阅读速度——并且分布式功能依赖于 macOS 26.2 和 MLX v0.30.1 或更高版本中引入的 Thunderbolt 5 上的低延迟 RDMA。
这篇文章描述了 MLX（Apple 为 Apple silicon 开发的开源数组框架）如何通过利用统一内存，让研究人员在私有环境中本地运行前沿模型。这紧随 Apple ML 之前关于 M5 架构及其 GPU 神经加速器的文章之后。
Apple 基准测试的三个模型
Apple 使用 MLX LM 包和 mlx_lm.benchmark 工具评估了三个覆盖广泛尺寸范围的前沿模型。Muse Spark Open 是一个混合专家（MoE）模型，在推理时仅激活一部分专家（因此也仅激活一部分参数），从而减少计算量。Mistral Medium 3.5 和 Qwen 3.8 是密集架构，推理时所有参数都被激活。
| 模型 | 总参数 | 激活参数 | 原生精度 | 评估精度 |
|---|---|---|---|---|
| Muse Spark Open | 816B | 42B | BF16 | NVFP4 |
| Mistral Medium 3.5 | 128B | 128B | FP8 | FP8 |
| Qwen 3.8 | 27B | 27B | BF16 | BF16 |
Mistral Medium 3.5 和 Qwen 3.8 以其原生浮点精度进行评估。Muse Spark Open 以 4 位 NVFP4 精度进行评估。
单台 Mac Studio：M5 Ultra 对比 M3 Ultra
在配备 512GB 统一内存的单台 Mac Studio 上，M5 Ultra 的首 token 时间（TTFT）比上一代 M3 Ultra 快达 4.6 倍。Apple 将此归因于 M5 代中的 GPU 神经加速器，它支持专用的矩阵乘法运算。TTFT 是计算密集型的，因此专门的矩阵乘法硬件直接转化为更快的预填充。
解码速度则受内存带宽限制。配备 M5 Ultra 的 Mac Studio 拥有 1.2 TB/s 的统一内存带宽，高于 M3 Ultra 的 819 GB/s，Apple 报告称 token 生成速度因此提高了 1.6 倍。
Qwen 3.8 27B 和 Mistral Medium 3.5 128B 都能轻松容纳在配备 512GB 内存的单台 Mac Studio 上，在 65,536 token 的大上下文设置中分别占用高达 68GB 和 158GB。
峰值功耗保持在数百瓦范围内
Apple 报告称，在 65,536 token 上下文下，Qwen 3.8 和 Mistral Medium 3.5 推理时的峰值功耗，M3 Ultra 的 Mac Studio 约为 200W，M5 Ultra 的 Mac Studio 约为 300W。Apple 将其描述为“普通烤面包机所用功率的一小部分”，并认为这种适度的功耗意味着 Mac Studio 可以在任何家庭或办公环境中部署用于 AI 工作。
为什么 Muse Spark Open 无法在单台机器上运行
Muse Spark Open 以其原生 BF16 精度仅模型参数就需要超过 1.6TB 的内存。在 4 位 NVFP4 格式下，内存占用降至约 493GB，但加上推理期间中间计算所需的内存，该模型仍然无法在单台机器上运行。它需要跨多台 Mac Studio 计算机进行并行化。
流水线并行化：沿深度拆分模型
流水线并行化将模型的一半存储在一台 Mac Studio 上，另一半存储在另一台上。第一台机器执行模型前半部分的层，然后将输出发送到第二台机器，第二台机器执行后半部分。Apple 将这种方案描述为极其容易实现，只需对代码进行最少的更改。
流水线并行化下的解码速度与单台机器非常相似，因为层仍然按顺序评估，只需要交换两组层之间的中间输出。一个显著的例外是超大型上下文：在 65,536 tokens 时，流水线并行化的预填充速度比单节点快约 1.8 倍。MLX 将大型上下文分割成较小的块——在 Apple 的基准测试中为 8,192 tokens，由 --prefill-step-size 8192 设置——并在机器之间进行流水线预填充，因此当第二台机器计算块 k 的后半部分层时，第一台机器计算块 k + 1 的前半部分层。
张量并行化：沿宽度拆分模型
张量并行化将模型的宽度分布到多台计算机上。每台机器持有每一层的一部分，因此每层的计算是并行化的。Apple 指出，这比流水线并行化实现起来更复杂，并且涉及许多小的通信操作：对于每个输入 token 和每一层，输入必须广播，输出必须聚合。这使得非常低延迟的通信（如 MLX jaccl 支持的 Thunderbolt RDMA）对于该方法产生任何加速至关重要。
Apple 报告称，密集架构在多台计算机上的扩展性优于 MoE 模型。在机器数量较少时，张量并行化的通信开销可能会在非常大的上下文下抵消其部分计算优势——但仅限于预填充。这在 Muse Spark Open 上表现得很明显，其中专家输出的单独归一化增加了预填充通信，以至于在 65,536 tokens 时，两台机器的张量并行化落后于两台机器的流水线并行化。随着机器数量的增加，这种方法开始见效：四台 M5 Ultra 提供了最佳结果。解码不受影响，Muse Spark Open 在张量并行化下即使在大型上下文下也能保持显著的解码加速，与密集模型相当。
Apple 报告的基准测试结果
首 token 时间（秒），越低越好：
| 模型 | M3 Ultra | M5 Ultra | 2 M5 流水线 | 2 M5 张量 | 4 M5 张量 |
|---|---|---|---|---|---|
| Muse Spark Open | — | — | 8.4 | 8.2 | 4.8 |
| Mistral Medium 3.5 | 95.9 | 24.6 | 24.5 | 14.4 | 7.5 |
| Qwen 3.8 | 18.2 | 4.1 | 4.1 | 3.1 | 1.7 |
解码速度（每秒 tokens），越高越好：
| 模型 | M3 Ultra | M5 Ultra | 2 M5 流水线 | 2 M5 张量 | 4 M5 张量 |
|---|---|---|---|---|---|
| Muse Spark Open | — | — | 15.74 | 24.99 | 36.73 |
| Mistral Medium 3.5 | 4.95 | 7.70 | 7.70 | 13.69 | 23.37 |
| Qwen 3.8 | 12.46 | 19.69 | 19.44 | 33.27 | 50.89 |
Muse Spark Open 无法在单台机器上运行，因此其基线是双 M5 Ultra 流水线配置。解码速度是在上下文之后生成的 128 个 tokens 上测量的。
每个链路两根 Thunderbolt 线缆缩短了预填充时间
在 Apple 的设置中，Mac Studio 通过两根 Thunderbolt 线缆连接，以加倍链路带宽。对于在四台 M5 Ultra 上以 65,536 token 上下文运行的 Muse Spark Open，每个链路两根线缆将 TTFT 从单根线缆的约 50.5 秒缩短到 40.6 秒——这是 TTFT 表中报告的双线缆值，单线缆运行是额外的实验。
如何启动分布式作业和本地代理服务器
MLX 提供了 mlx.launch，一个用于在多个节点上启动作业的辅助命令。一个流水线并行基准测试运行如下：
mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
mlx_lm.benchmark --model mistralai/Mistral-Medium-3.5-128B -p 8192 -g 128 -b 1 --prefill-step-size 8192 --pipeline
--backend jaccl 选择 RDMA Thunderbolt 驱动后端。--env MLX_METAL_FAST_SYNCH=1 启用 MLX 的实验性功能，用于快速 CPU-GPU 同步，减少发起 Thunderbolt 通信的 CPU 与执行计算的 GPU 之间的通信开销。
对于本地代理编码，mlx_lm.server 可以加上 mlx.launch 前缀，以跨多台 Mac Studio 并行化计算：
mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
mlx_lm.server --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --port 8080
Apple 展示了如何通过 OpenAI 兼容的提供商配置，使用 baseURL: http://127.0.0.1:8080/v1 将 OpenCode 代理编码工具指向该本地服务器。
Hacker News 讨论补充了什么
关于这篇文章的 Hacker News 帖子吸引了 123 条评论，最有用的贡献是怀疑而非庆祝。
基准测试比较引起了最尖锐的批评
最实质性的批评涉及模型之间的精度不匹配。一位评论者认为 Apple“通过以 4 位精度对 Meta 的模型进行基准测试，而 Qwen 仅以原生 BF16（且未显示其他内容）进行基准测试，严重低估了 Qwen。”同一位评论者补充说，4 位“不是大多数用户会选择的量化方式”，并且 Muse Spark Open“甚至不在我如果拥有 512 GB M5 时会考虑的前 十 个模型之列。或者一个集群。”另一位评论者更直率地评价该模型：“一个 800B 的模型，性能远不如其他 300B 的模型。嗯……”
成本和价值问题主导了其余讨论
几位评论者将这篇文章视为昂贵硬件的营销。一位写道：“所以，Meta 将花费数百万/数十亿构建开放权重模型，然后人们将向 Apple 支付 20,000 美元来运行它们。对 Apple 来说似乎是一笔好交易。”另一位将其解读为产品发布信号：“准备在本月晚些时候推销那些非常昂贵的 Mac，是吗。”第三位直接指出了成本障碍：“这是一篇很好的文章，展示了发展方向，我相信 Mac Studio 在接下来的几代中会变得越来越强大，但就目前而言，对于本地设置来说太贵了。”
一位更乐观的评论者持长远眼光：“虽然目前 Mac Studio 不是预算设备，而且肯定比补贴订阅更贵，但有一天我们可以在商品硬件上运行这些模型的承诺令人兴奋。”
评论者报告了替代硬件的结果
一位评论者提供了其他模型在 Apple silicon 上的独立数据：“单台 M5 Ultra 配备 256GiB 可以很好地运行 DeepSeek 4.1 Flash 0910（约 3200 tok/s 预填充，约 45 tok/s）。M5 Max 配备 128GiB 也可以很好地运行 GLM 5.3 Flash。”他们补充说，他们在质量基准测试（如 MathArena Apex 和 GPQA Diamond）上对两者进行了基准测试，以验证质量与官方数字一致。
上下文大小和框架抱怨
一位评论者指出，头条新闻中的 15–36 tokens 每秒数字是在 8,192 token 上下文下测量的：“如今这远远不够用。”另一位反对将四台机器的集群描述为桌面设置，引用了 Apple 自己的说法，即“就在你的桌面上”运行模型，并指出：“不完全是普通人的‘桌面’，但仍然很酷。”第三位观察到，这篇文章讨论了 Meta 的技术，但除了代码引用外没有提及 Meta。一位评论者还指出了写作风格：“我——喜欢——一篇充满——破折号——的文章。”
关键要点
- Apple 的 MLX 分布式推理栈在四台搭载 M5 Ultra 的 Mac Studio 上以每秒超过 36 个 tokens 的速度运行 Muse Spark Open，这是一个 816B 参数的 MoE 模型，具有 42B 激活参数。
- 分布式功能依赖于 macOS 26.2 中引入的 Thunderbolt 5 上的 RDMA，以及 MLX v0.30.1 或更高版本，后者添加了
jaccl通信集合。 - 流水线并行化沿深度拆分模型，解码速度基本不变，但在 65,536 token 上下文下预填充速度提高约 1.8 倍。
- 张量并行化沿宽度拆分模型，对密集架构扩展性更好，并且从每个链路两根 Thunderbolt 线缆中受益匪浅。
- M5 Ultra 的 GPU 神经加速器比 M3 Ultra 提供快达 4.6 倍的 TTFT，而其 1.2 TB/s 的统一内存带宽（对比 819 GB/s）提供 1.6 倍的解码速度。
- 在 65,536 token 上下文下推理时，峰值功耗在 M3 Ultra 上约为 200W，在 M5 Ultra 上约为 300W。
- Hacker News 帖子中最强烈的批评是，Apple 以 4 位 NVFP4 对 Muse Spark Open 进行基准测试，而以原生 BF16 对 Qwen 3.8 进行基准测试，使得跨模型比较不公平。
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch