在搭载苹果芯片（Apple silicon）的 Mac 上，MLX 让 AI 研究人员和开发者在本地私密环境中试验最新模型与方法，依托统一内存架构支持在自己的硬件上运行推理与微调。借助今天发布的最新版 MLX，我们可以在桌上运行参数近万亿的前沿模型 Muse Spark Open：在四台 Mac Studio 集群上生成速度超过每秒 36 个 token，高于普通人的平均阅读速度；从单台最高 512GB 统一内存的 Mac Studio 出发，还能通过 RDMA over Thunderbolt 驱动扩展到多台 Mac。

在搭载 Apple 芯片的 Mac 上，MLX 让 AI 研究人员和开发者能够在私有环境中本地试验最新的模型和方法。这个开源数组框架利用 Apple 芯片的统一内存架构，使任何人都可以在自己的硬件上运行新的推理和微调方法，并探索其他 AI 技术。在上一篇文章中，我们已介绍 M5 架构及其 GPU 神经加速器的优势。

我们展示了如何利用今天发布的最新版 MLX，直接在桌面上运行最新的前沿级模型——参数量近万亿的 Muse Spark Open。在四台 Mac Studio 组成的集群上，Muse Spark Open 的生成速度超过 36 tokens/秒（见图 1），远高于人类的平均阅读速度。

从单台 Mac Studio（最高 512GB 统一内存）起步，再通过基于雷雳（Thunderbolt）的 RDMA 驱动扩展到多台 Mac，以下是如今在 Mac Studio 上可运行的模型概览。

图 1 展示了 Muse Spark Open 在搭载 M5 Ultra 的 Mac Studio 上、上下文长度为 8,192 tokens 时的解码速度（tokens/秒），数值越高越好。其中报告了三种并行方案的性能：两台 Mac Studio 的流水线并行（2 M5 Pipeline），以及两台（2 M5 Tensor）和四台（4 M5 Tensor）Mac Studio 的张量并行。

我们使用 MLX LM 包（如先前文章所述）在 Mac Studio 上对几款流行的开放权重 LLM 进行了基准测试，并对比了两代 Mac Studio：最新发布的 M5 Ultra 和上一代的 M3 Ultra。M5 这一代配备了 GPU 神经加速器，支持专用的矩阵乘法运算，这对许多机器学习任务至关重要。

我们评估了三款前沿级模型（表 1），覆盖广泛的尺寸（单位为十亿参数，B）：新发布的 Muse Spark Open（816B）、Mistral Medium 3.5（128B）和 Qwen 3.8（27B）。Muse Spark Open 是混合专家（MoE）模型，在推理时仅激活部分专家（因而只激活部分参数），从而减少了计算量，我们在 NVFP4 精度下对其进行评估。Mistral Medium 3.5 和 Qwen 3.8 是稠密架构，推理时所有参数均被激活，我们分别在其原生浮点精度（FP8 和 BF16）下进行评估。

| 模型 | 总参数量 | 激活参数量 | 原生精度 | 评估精度 | | --- | --- | --- | --- | --- | | Muse Spark Open | 816B | 42B | BF16 | NVFP4 | | Mistral Medium 3.5 | 128B | 128B | FP8 | FP8 | | Qwen 3.8 | 27B | 27B | BF16 | BF16 |

表 1：评估中使用的语言模型。模型以多种精度格式发布；我们对 Qwen 3.8 和 Mistral Medium 3.5 采用其原生精度进行评估，对 Muse Spark Open 采用 4 位（NVFP4）精度。

我们的评估在不同上下文长度下测量了三项指标：首 token 时间（TTFT，单位秒）、生成吞吐量（单位 tokens/秒）和峰值功耗（单位瓦）。本次评估中的所有性能数据均通过 mlx_lm.benchmark 获得。例如，以 8,192 tokens 的上下文运行 Qwen 3.8 并生成 128 个 token，使用的命令如下：

mlx_lm.benchmark --model Qwen/Qwen3.8-27B -p 8192 -g 128 -b 1

在 Mac Studio 上本地运行 LLM 的一个流行用法，是在私有环境中运行智能体（agentic）体验，包括通常需要大上下文的智能体编码应用。因此我们报告了 8,192 和 65,536 两种上下文长度下的性能。原始 TTFT 和解码吞吐量分别列在表 2 和表 3 中。

Qwen 3.8 27B 和 Mistral Medium 3.5 128B 可以轻松放入单台 512GB 的 Mac Studio，在最大上下文（65,536 tokens）设置下分别占用最高 68GB 和 158GB 内存。在图 2 中，我们比较了它们在单台 512GB RAM 的 Mac Studio 上的推理性能，分别运行在 M3 Ultra 和 M5 Ultra 上。

首 token 时间（TTFT）本质上受计算能力限制，而这正是 M5 Ultra GPU 中神经加速器的用武之地：GPU 神经加速器对快速矩阵乘法的专用硬件支持，直接带来了 TTFT 的显著加速，相比 M3 Ultra 最高快 4.6 倍（见图 2）。这使得搭载 M5 Ultra 的 Mac Studio 成为处理超长上下文任务时的首选台式机。

图 2：单台 Mac Studio 上 M5 Ultra 相对于 M3 Ultra 基准（1.0 倍）的 TTFT 加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8 和 Mistral Medium 3.5 的 TTFT 加速情况。M5 Ultra GPU 神经加速器在计算受限的工作负载上表现出色。

生成速度（单位 tokens/秒）受内存带宽限制。M5 Ultra 芯片提供 1.2 TB/s 的统一内存带宽，高于 M3 Ultra 的 819 GB/s。这同样直接转化为生成速度的提升（见图 3），搭载 M5 Ultra 的 Mac Studio 报告的 tokens/秒 快了 1.6 倍。

图 3：单台 Mac Studio 上 M5 Ultra 相对于 M3 Ultra 基准（1.0 倍）的解码加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8 和 Mistral Medium 3.5 的解码加速情况。解码受内存带宽限制，而 M5 Ultra 的 1.2 TB/s 统一内存带宽（M3 Ultra 为 819 GB/s）是一项关键优势。

Mac Studio 在 LLM 推理方面也很节能（见图 4）：搭载 M3 Ultra 的 Mac Studio 峰值功耗约为 200W，搭载 M5 Ultra 的约为 300W——仅相当于一个普通烤面包机功耗的一小部分。更重要的是，这种适中的功耗意味着 Mac Studio 可以部署在任何家庭或办公室环境中进行 AI 工作。

图 4：在搭载 M3 Ultra 和 M5 Ultra 的 Mac Studio 上，以 65,536 tokens 的上下文长度对 Qwen 3.8 和 Mistral Medium 3.5 进行推理时的峰值功耗（单位瓦）。

虽然 Qwen 和 Mistral 模型都能放入单台 512GB RAM 的 Mac Studio，但 Muse Spark Open 仅模型参数在原生精度（BF16）下就需要超过 1.6TB 的 RAM。在 4 位量化（NVFP4）格式下，模型的内存占用降至约 493GB。加上推理过程中中间计算所需的内存，该模型无法放入单台机器，需要在多台 Mac Studio 之间进行并行化。

像 Muse Spark Open 这样超大的前沿级模型无法放入单台机器。不过，我们可以将模型的一半存储在另一台 Mac Studio 上，另一半存储在另一台上。然后我们可以跨两台计算机对模型推理进行流水线处理：第一台 Mac Studio 执行模型的前半部分层，然后将输出发送给第二台 Mac Studio，由后者执行后半部分。这种并行方案称为流水线并行（见图 5），实现起来极其简单，只需极少的代码改动。

图 5：跨多台计算机拆分大模型。MLX 支持两种跨计算机拆分大模型的方法。流水线并行是按深度拆分模型，而张量并行是按宽度拆分模型。

如 MLX 分布式文档所述，MLX 支持不同的并行方案。这些方案依赖于快速的机器间通信：macOS 26.2 引入了基于雷雳 5（Thunderbolt 5）的低延迟 RDMA 驱动，而 MLX（v0.30.1 及更高版本）构建在该驱动之上，并为不同的并行方案提供了新的通信集合（jaccl，发音同“jackal”）。在我们的设置中，两台 Mac Studio 用两根雷雳线缆连接（以使链路带宽翻倍），提供了 jaccl 所使用的基于雷雳的 RDMA 链路。主机设置完成后，MLX 提供了 mlx.launch 这一辅助命令，用于跨多个节点启动任务：

mlx.launch --hostfile hostfile.json --backend jaccl -- env MLXMETALFASTSYNCH=1 -- \ mlxlm.benchmark --model mistralai/Mistral-Medium-3.5-128B -p 8192 -g 128 -b 1 --prefill-step-size 8192 --pipeline

在该命令中，--backend jaccl 指定了基于雷雳的 RDMA 驱动后端。--env MLXMETALFAST_SYNCH=1 标志启用了一项实验性的 MLX 功能，用于快速的 CPU-GPU 同步，从而减少 CPU（发起雷雳通信）和 GPU（执行计算）之间的通信开销。

总体而言，使用流水线并行的解码推理速度（见图 7）与单台机器非常接近，因为各层仍然是顺序执行的。通信开销也非常低，因为只需交换两组层之间的中间输出。

但有一个现象十分显著：在超长上下文（我们的基准中为 65,536 tokens）下，流水线并行在预填充（prefill）阶段最终比单节点更快——最高约 1.8 倍（见图 6）。这是因为 MLX 将大上下文切分为更小的块（此处为 8,192 tokens，由 --prefill-step-size 8192 设定），并跨机器对预填充进行流水线处理：当第二台机器计算第 k 个块的较后层时，第一台机器计算第 k+1 个块的较前层，因此连续的块在时间上重叠。为了实现更好的计算并行化，我们接下来转向张量并行。

图 6：两台采用流水线并行的 M5 Ultra 相对于单台 M5 Ultra 基准（1.0 倍）的 TTFT 加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8 和 Mistral Medium 3.5 的 TTFT 加速情况。将上下文切分（此处切分为 8,192-token 的块）使 MLX 能够跨两台机器重叠计算——因此在 65,536 时有加速，而在 8,192 时没有。

图 7：两台采用流水线并行的 M5 Ultra 相对于单台 M5 Ultra 基准（1.0 倍）的解码加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8 和 Mistral Medium 3.5 的解码加速情况。流水线并行基本上不改变解码速度。

张量并行（见图 5）将 LLM 的“宽度”分布到多台计算机上，这与按模型“深度”分布模型的流水线并行不同。此时每台机器持有模型每一层的一部分，从而使单层的计算被并行化。若实现高效，张量并行能提高推理速度。然而，张量并行的实现比流水线并行更复杂：每一层都必须并行化，这增加了代码复杂性。该方案还涉及许多小的通信操作：对于每个输入 token 和每一层，都必须广播输入并聚合输出。因此，像 MLX jaccl 所支持的雷雳 RDMA 这样的极低延迟通信技术，对于该方法能否带来加速至关重要。

借助 MLX 的高级 mlx.launch 辅助工具，可以轻松切换到张量并行。这些 Mac Studio 计算机以雷雳网状结构连接，每对机器之间用两根雷雳线缆点对点链接。假设主机已设置好，我们只需通过以下命令跨多台机器启动基准测试：

mlx.launch --hostfile hostfile.json --backend jaccl -- env MLXMETALFASTSYNCH=1 -- \ mlxlm.benchmark --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 -p 8192 -g 128 -b 1

图 8 和图 9 展示了使用两台或四台搭载 M5 Ultra 的 Mac Studio 时，相对于单台机器基准（对于 Muse Spark Open，则是流水线并行基准）所获得的加速。稠密架构在多台计算机上的扩展性更好，这一点十分突出。

图 8：两台或四台采用张量并行的 M5 Ultra 相对于单台 M5 Ultra 基准（1.0 倍；Muse Spark Open 的基准为两台机器的流水线配置）的 TTFT 加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8、Mistral Medium 3.5 和 Muse Spark Open 的 TTFT 加速情况。Muse Spark Open 无法放入单台机器，因此其基准是两台 M5 Ultra 的流水线配置。

图 9：两台或四台采用张量并行的 M5 Ultra 相对于单台 M5 Ultra 基准（1.0 倍；Muse Spark Open 的基准为两台机器的流水线配置）的解码加速比。该图展示了在上下文长度为 8,192 和 65,536 tokens 时，针对 Qwen 3.8、Mistral Medium 3.5 和 Muse Spark Open 的解码加速情况。Muse Spark Open 无法放入单台机器，因此其基准是两台 M5 Ultra 的流水线配置。

在机器数量较少时，张量并行的通信开销可能会抵消其在超长上下文下的一部分计算优势，不过这仅适用于预填充阶段。这在 Muse Spark Open 上有所体现：专家输出的独立归一化增加了一些预填充通信，足以让在超长上下文（65,536 tokens）下，两台机器的张量并行落后于两台机器的流水线并行。然而，随着机器数量的增加，这种方法会带来回报，正如四台 M5 Ultra 的情况所示。解码不受影响：Muse Spark Open 在张量并行下即使在长上下文中也能保持显著的解码加速，可与 Qwen 3.8 和 Mistral Medium 3.5 等稠密模型相媲美。

双线缆网状结构在预填充阶段也带来了回报，此时能感受到额外的链路带宽。对于在四台 M5 Ultra 上以 65,536-token 上下文运行的 Muse Spark Open，每条链路使用两根线缆将 TTFT 从约 50.5 秒（单线缆）降至 40.6 秒——表 2 中报告的是双线缆的数值，单线缆的运行是一项额外实验。

| 模型 | 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 |

表 2：Qwen 3.8、Mistral Medium 3.5 和 Muse Spark Open 在上下文长度为 8,192 和 65,536 tokens 时的首 token 时间（TTFT，单位秒）。数值越低越好。我们报告了单台 M3 Ultra、单台 M5 Ultra、两台 M5 Ultra（流水线和张量并行）以及四台 M5 Ultra（张量并行）的数据。

| 模型 | 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 |

表 3：Qwen 3.8、Mistral Medium 3.5 和 Muse Spark Open 在上下文长度为 8,192 和 65,536 tokens 时的解码速度（tokens/秒）。数值越高越好。我们报告了单台 M3 Ultra、单台 M5 Ultra、两台 M5 Ultra（流水线和张量并行）以及四台 M5 Ultra（张量并行）的数据。解码速度是在上下文之后生成的 128 个 token 上测得的。

最近，Mac 上的智能体 AI 获得了巨大的关注，智能体编码工具在开发者中得到了广泛采用。借助 MLX，为这些工具提供本地支持只需用 mlx_lm.server 工具启动一个服务器。例如，在 8080 端口上运行 Muse Spark Open 的服务器启动命令如下：

mlx.launch --hostfile hostfile.json --backend jaccl -- env MLXMETALFASTSYNCH=1 -- \ mlxlm.server --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --port 8080

与 mlxlm.benchmark 一样，mlxlm.server 辅助工具也可以加上 mlx.launch 前缀，以跨多台 Mac Studio 并行计算。在此基础上，可以使用 OpenCode 等工具启用智能体 AI，并可轻松配置为使用该本地 LLM 服务器：

{ "$schema" : "https://opencode.ai/config.json" , "model" : "meta-models/Muse-Spark-Open-816B-A42B-NVFP4" , "provider" : { "mlx" : { "npm" : "@ai-sdk/openai-compatible" , "name" : "Local MLX" , "options" : { "baseURL" : "http://127.0.0.1:8080/v1" } , "models" : { "meta-models/Muse-Spark-Open-816B-A42B-NVFP4" : { "name" : "Muse Spark Open 816B (MLX)" } } } } }

许多其他的本地智能体 AI 体验也可以通过类似方式实现。

在过去一年中，我们在 MLX 中进行了几项关键创新，以便更轻松、更高效地在最新的 Apple 芯片上本地运行最先进的 LLM。这些创新包括对 M5 系列芯片 GPU 中神经加速器的软件支持、使用基于雷雳的 RDMA 在多台 Mac 之间进行低延迟通信，以及对混合专家（MoE）等近期流行架构的高效实现。这些创新各自都有所帮助，但正是它们与最新 Apple 芯片的结合——搭载 M5 Ultra 的 Mac Studio、M5 Ultra GPU 中的神经加速器、512GB 统一内存以及基于雷雳 5 的 RDMA——如今让我们能够在本地运行像 Muse Spark Open 这样参数量超过 800B 的模型，其启动（首 token 时间）速度最高可达上一代 Mac Studio 的 4.6 倍。

讨论围绕苹果展示在 Mac Studio 上本地运行近万亿参数 Muse Spark Open 的文章展开：多数人质疑这是苹果借 Meta 开源模型为高价 Mac 站台的营销，所选模型跑分不公平且竞争力不足；少数人认可它代表了未来在普通硬件上运行大模型的前景，但都承认当前设备价格过高、尚不实用。

认为文章是苹果借 Meta 开源模型推销高价硬件的营销

• 认为这是苹果与 Meta 的联合营销，却几乎不提 Meta：有人讽刺整篇稿子讲 Meta 技术，却只在代码引用里出现 Meta；还有人指出，Meta 投入巨资做开源模型，用户却要花约两万美元买苹果硬件来运行，苹果显然是在为即将推出的昂贵 Mac 造势、变现。（较多人）
• 需要引用时，只用一句中文意译： > 整篇新闻稿都在讲 Meta 的技术，却除了代码引用外几乎不提 Meta，实在滑稽。（@janderson215）

认为 Muse Spark 跑分不公平、模型本身缺乏竞争力

• 指出文章用 4-bit 量化后的 Meta 模型对比原生 BF16 的 Qwen，量化方式并非多数用户选择；即便有 512GB M5 或 Mac Studio 集群，Muse Spark 也进不了考虑前十。还有人补充，该约 800B 模型表现远不如 300B 级模型，且 15–36 tok/s 的成绩仅基于 8,192 token 上下文，对如今的应用来说太短、实用性存疑。（较多人）
• 需要引用时，只用一句中文意译： > 他们把 Meta 的 Muse Spark 量化到 4-bit，却只拿原生 BF16 的 Qwen 对比，这种量化大多数用户都不会选。（@peri-cl）

看好本地运行大模型的前景，但认为当前 Mac Studio 过于昂贵

• 认为文章展示了未来方向：虽然现在 Mac Studio 不是便宜设备、价格高于补贴订阅，本地部署目前也太贵，但将来能在普通硬件上跑这些模型的前景令人兴奋；有人直呼很酷，并询问能否把 Muse 适配成决策模型。（少数人）
• 需要引用时，只用一句中文意译： > 虽然 Mac Studio 现在不是便宜设备，也比补贴后的订阅更贵，但将来能在普通硬件上跑这些模型，这一前景令人兴奋。（@pdp）

有价值的补充

• 单台 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 等质量基准验证过效果与官方一致。（@liuliu）
• 功耗方面，Mac Studio 峰值约 200W（M3 Ultra）到 300W（M5 Ultra），只有普通烤面包机的一小部分，能效是本地部署的一个亮点。（@throwworhtthrow）