Mac Studio 上用 MLX 与 RDMA 分布式推理大模型

在本地跑前沿大模型，通常意味着要面对显存不足、算力不够的尴尬。Apple 在 MLX 框架上的最新更新给出了另一种思路：把多台 Mac Studio 用 Thunderbolt 5 的 RDMA 驱动连起来，让近万亿参数的模型也能在桌面上流畅推理。

据 Apple MLX 团队发布的技术文章，一套四台 Mac Studio 组成的集群运行 816B 参数的 Muse Spark Open，解码速度超过 36 tokens/s，明显高于人类平均阅读速度。这不是概念验证，而是已经可以在最新版 MLX 中复现的结果。

单机推理：M5 Ultra 的两项硬指标

Apple 在 Mac Studio 上用 mlx_lm.benchmark 评估了三款模型：816B 的 Muse Spark Open（MoE 架构，NVFP4 量化）、128B 的 Mistral Medium 3.5（FP8）和 27B 的 Qwen 3.8（BF16）。后两者都能装进单台 512GB 内存的 Mac Studio，在 65536 tokens 的大上下文场景下分别占用约 158GB 和 68GB 内存。

衡量推理体验的两个核心指标——首 token 延迟（TTFT）和解码速度——在 M5 Ultra 上都有明显提升。TTFT 基本是计算瓶颈，而这正是 M5 Ultra GPU 神经加速器发挥作用的地方，其专用的矩阵乘法硬件把 Qwen 3.8 和 Mistral Medium 3.5 的 TTFT 最多提升了 4.6 倍。解码则是内存带宽瓶颈，M5 Ultra 的统一内存带宽从 M3 Ultra 的 819 GB/s 提升到 1.2 TB/s，解码速度相应快了 1.6 倍。

功耗数据也值得一提：M3 Ultra 版 Mac Studio 推理峰值功耗约 200W，M5 Ultra 约 300W，远低于很多人对"跑大模型"的能耗想象。这种功耗水平意味着它可以直接部署在普通家庭或办公环境中，不需要专门的机房散热。

首 token 延迟（TTFT）与解码速度是衡量大模型推理体验的两个关键指标，但二者背后的硬件瓶颈截然不同。TTFT 指从用户发出请求到模型吐出第一个 token 所经历的时间，主要由预填充（prefill）阶段决定——模型需要一次性处理全部输入上下文，计算量随上下文长度呈近线性增长，因此是典型的计算瓶颈，依赖 GPU 的矩阵乘法吞吐能力。解码速度则指生成后续每个 token 的速率，此阶段每步只需处理一个 token，计算量极小，但需要把模型权重和 KV 缓存从内存搬到计算单元，因此是典型的内存带宽瓶颈。理解了这一点就能明白 M5 Ultra 的两项提升为何分别来自不同硬件：GPU 神经加速器强化算力以缩短 TTFT，1.2 TB/s 统一内存带宽加快数据搬运以提升解码速度。

当模型装不下：两种并行策略的分工

Muse Spark Open 是这次测试中最极端的案例。816B 参数即便量化到 4-bit（NVFP4），模型本身也要占约 493GB 内存，再加上推理时的中间计算开销，单台机器根本放不下。必须跨机器拆分。

MLX 提供了两条路径。流水线并行（pipeline parallelization）按深度切分：第一台 Mac Studio 执行前半部分网络层，把输出传给第二台执行后半部分。实现改动极小，解码速度与单机几乎没有差别，因为各层仍然是顺序执行的。但在大上下文场景下，流水线并行反而能超过单机——MLX 把 65536 tokens 的上下文切成 8192 tokens 的块，两台机器分别处理相邻块的先后层，形成时间上的重叠，预填充（prefill）最多快了约 1.8 倍。

张量并行（tensor parallelization）则按宽度切分，每台机器持有每一层的一部分，层内计算被并行化。这种方式能真正提升推理速度，但实现复杂度高得多：每个 token、每一层都需要广播输入、聚合输出，通信操作又多又碎。没有 Thunderbolt RDMA 这样的低延迟链路，张量并行的收益会被通信开销吃掉。

Apple 用 jaccl 通信集合（MLX v0.30.1 起支持，基于 macOS 26.2 引入的 Thunderbolt 5 RDMA 驱动）来支撑这两种并行。mlx.launch 命令让切换并行策略只需要改一个参数。

**MoE（Mixture of Experts，混合专家）**是一种稀疏激活的模型架构：模型包含多个并行的"专家"子网络，但每个 token 只被路由到其中少数几个专家进行计算，其余参数处于闲置状态。这使得 MoE 模型可以拥有极大的总参数量（如 816B），实际每步激活的参数量却远小得多，从而在保持推理成本可控的前提下提升模型容量。代价是 MoE 对通信更敏感——专家分散在不同设备上时，token 需要被路由并汇聚，专家输出还需按路由权重归一化后再合并，这些额外操作在分布式推理中会引入可观的通信开销。这正是文章中 Muse Spark Open 在少机场景下扩展性不如稠密模型的核心原因。

规模效应：张量并行加机器才划算

张量并行的收益跟机器数量强相关。在两台 M5 Ultra 上，通信开销在超大上下文下会抵消一部分计算收益，Muse Spark Open 在 65536 tokens 时两台张量并行甚至不如两台流水线并行。但加到四台机器后局面反转：Muse Spark Open 的解码速度从两台流水线的 15.74 tokens/s 提升到四台张量的 36.73 tokens/s，Qwen 3.8 从 19.44 提升到 50.89 tokens/s。

连接方式同样影响性能。测试采用双 Thunderbolt 线缆组网，每对机器之间用两根线相连以翻倍链路带宽。对 Muse Spark Open 在四台 M5 Ultra、65536 tokens 上下文下，双线把 TTFT 从约 50.5 秒压到 40.6 秒，预填充阶段对带宽的敏感度可见一斑。

一个有趣的观察是：稠密模型（Qwen 3.8、Mistral Medium 3.5）在多机扩展上表现比 MoE 模型更好。Muse Spark Open 的专家输出需要单独归一化，额外引入了预填充通信开销，这在机器数量少时尤其明显。

NVFP4 与 FP8 是两种低精度数值格式，用于在几乎不损失模型精度的前提下压缩显存占用、提升计算效率。FP8 用 8 位浮点表示每个权重，相比传统的 FP16/BF16 直接减半显存。NVFP4 则更进一步，用 4 位浮点（约 16 个可表示数值），并配合分组缩放策略来补偿极低精度带来的误差，典型压缩比可达 FP16 的四分之一。以 816B 参数的 Muse Spark Open 为例，若用 FP16 存储需超过 1.6TB 显存，而 NVFP4 量化后仅约 493GB，才使四台 Mac Studio 的分布式部署成为可能。量化格式的选择直接影响能跑多大模型、需要几台机器，是本地推理方案设计的关键一环。

本地大模型的实际意义

这套方案真正的价值不在于跑分，而在于它改变了大模型推理的部署边界。512GB 内存的单台 Mac Studio 可以承载 128B 级别的稠密模型，用于需要长上下文的 agentic coding 场景；四台组网则能触及近万亿参数的 MoE 模型。全程在私有环境中运行，数据不出本地。

对于需要处理敏感数据、又希望用上前沿模型的团队，这种"桌面集群"的路径值得认真评估。它的门槛不在机架和制冷，而在于你是否愿意接受 Apple 生态的软件栈约束。

更多技术细节和完整基准数据可参考 MLX 官方文档与 MLX distributed 文档。

背景补充

**RDMA（Remote Direct Memory Access，远程直接内存访问）**是一种允许一台计算机直接读写另一台计算机内存的技术，数据搬运绕过双方的操作系统和 CPU，由网卡硬件直接完成。传统网络通信需要经过内核协议栈、多次内存拷贝和 CPU 中断处理，延迟高、占用 CPU 资源；RDMA 把这套流程卸载到硬件，可实现微秒级延迟和极低的 CPU 开销。Apple 在 macOS 26.2 中引入的 Thunderbolt 5 RDMA 驱动，把这一能力带到了消费级 Mac 上，使得多台 Mac Studio 之间的 AllReduce、广播等集合通信足够快，张量并行这类通信密集的策略才真正具备实用价值——这也是整套"桌面集群"方案能够成立的技术基石。