利用 Thunderbolt 5 的 Mac 集群运行本地大语言模型：惊艳的演示，不成熟的产品

🎧 Listen to this article

Apple 的 WWDC26 演示很难不让人喜欢。四台 Mac Studio、几根 Thunderbolt 线缆，以及一个约一万亿参数的模型，在桌面上而非数据中心里回答问题。在本文发布前一天，Apple 的机器学习团队公布了同一配置的新数据。

人们很容易得出这样的结论：买几台 Mac，把它们连接起来，就可以为公司运行私有 AI 服务。这项技术是真实存在的。但公开的错误报告却讲述了一个不那么完美的故事，尤其是当一台机器或一根线缆出现故障时会发生什么。

本指南将解释 Mac 集群的用途、工作原理、设置要求以及目前仍存在问题的环节。所有陈述均截至 2026 年 10 月 16 日，依据 Apple 官方页面和各项目的 GitHub 追踪器进行核对。

概览

它是什么： 通过 Thunderbolt 5 将 Apple 芯片 Mac 连接起来，使它们能够共同运行一个大型 AI 模型。
所需条件： macOS 26.2 或更高版本、Thunderbolt 5 Mac 和线缆，以及实际的软件配置。
有效之处： 合并内存以运行单台 Mac 无法容纳的模型，并且在 Apple 的测试中生成速度更快。
缺失之处： 节点故障时的文档化行为。公开报告描述了卡死和崩溃。

这个用来做什么？

AI 语言模型在运行时必须驻留在内存中。模型越大，所需内存越多。根据 Apple 的研究文章，单台 Mac Studio 的统一内存上限为 512 GB。如今一些开放模型所需的内存远不止于此。

在 WWDC26 会议中，Apple 在四台 M3 Ultra Mac 上运行了 Kimi 2.6，这是一个约 1 万亿参数的模型，8 位精度下大约需要 1 TB。单台 M3 Ultra 无法容纳它。

集群完成两件事：

它合并内存。 单台机器无法容纳的模型可以在多台机器上运行。
它可以提升速度。 Apple 报告称，在四台 Mac 上运行 270 亿参数模型时，token 速率接近单台 M3 Ultra 的 3 倍。

想象四个人抬一张沉重的沙发。他们一起能抬起一个人抬不动的东西，但前提是他们不断交流：“抬”、“转”、“停”。如果其中一个人突然松手，所有人都会遇到问题。在 Mac 集群中，这种持续的对话通过 Thunderbolt 线缆进行。

工作原理

Apple 的技术栈分为三层，如 WWDC26 会议所述：

基于 Thunderbolt 5 的 RDMA。 RDMA（远程直接内存访问）在 CPU 和操作系统几乎不参与的情况下，将数据从一台 Mac 的内存移动到另一台 Mac 的内存。这保持了低延迟。Apple 的技术说明 TN3205 指出，从 macOS 26.2 起，在配备 Thunderbolt 5 的 Apple 芯片 Mac 上可用。
JACCL。 Apple 提供的开源库，用于机器之间的组通信，例如汇总每个节点的部分结果。
MLX 和 MLX LM。 Apple 的机器学习框架及其语言模型工具。它们使用 JACCL 将模型拆分到多台机器上。

拆分模型有两种主要方式：

张量并行 将每一层切成片段，每台 Mac 一个。每个 token 的生成速度更快，但 Mac 在每一层都要通信，因此低延迟至关重要。
流水线并行 给每台 Mac 分配一组层，就像流水线一样。它对网络要求较低，但不会加快每个 token 的速度。Apple 指出并非所有模型都支持。

还有 exo，这是一个开源项目，位于此技术栈之上，增加了自动设备发现和调度功能。它的要求相同：macOS Tahoe 26.2 或更高版本。

仅插上线缆还不够

这是演示中快速略过的部分。根据 Apple 的技术说明、WWDC26 会议和 exo 的 README，以下是一个可工作的配置所需的条件。

1. 合适的硬件和布线

配备 Thunderbolt 5 的 Apple 芯片 Mac，以及支持 Thunderbolt 5 的线缆。
为了获得最低延迟，将每台 Mac 连接到其他所有 Mac（“全网状”）。三台 Mac 需要三根线缆；四台 Mac 需要六根。
端口很快就不够用。Apple 的说明展示了五台 Mac 以环形连接，数据必须由软件通过相邻节点转发，因为 Thunderbolt 上的 RDMA 本身无法路由流量。
exo 的 README 指出，Mac Studio 上以太网端口旁边的 Thunderbolt 5 端口不能使用。

2. 所有设备软件一致

exo 要求所有设备上的 macOS 版本完全一致，甚至包括 beta 构建号。
Apple 表示，每台 Mac 都需要 MLX 和你要运行的程序，且每台机器上的路径相同，此外还需要它们之间的 SSH 访问权限。

3. 开启 RDMA

Apple 的技术说明描述了从 macOS 恢复模式启用 RDMA 的方法：

# In macOS Recovery: Utilities → Terminal
rdma_ctl enable
# then reboot into macOS

WWDC26 会议展示了另一种方法：在系统设置中搜索“RDMA”，打开“通过 Thunderbolt 启用 RDMA”，然后重新启动。你看到哪种方法可能取决于你的 macOS 版本，因此请在自己的机器上确认。

然后确认链路已启用：

ibv_devices    # lists RDMA interfaces such as rdma_en2
ibv_devinfo    # each connected port should show PORT_ACTIVE

只有当两端的 Mac 都启用了 RDMA 时，端口才会变为活动状态。

4. 网络和电源设置

禁用 Thunderbolt Bridge（系统设置 → 网络 → Thunderbolt Bridge → 设为不活跃）。Apple 警告说，当线缆形成环路时，该桥接可能会无限转发流量并浪费 CPU。
禁用空闲睡眠。 Thunderbolt 不支持网络唤醒（Wake-on-LAN），因此处于睡眠状态的 Mac 会退出集群。
启用自动登录 和 “断电后自动启动”，这样集群无需有人在键盘旁就能恢复。

5. 配置并启动

MLX 包含一个辅助工具，可检查 SSH、检测 Mac 的布线方式并写入主机文件。使用 --auto-setup 标志时，它还会禁用 Thunderbolt Bridge 并配置每条链路。如果不使用该标志，它会打印出命令供你查看。以下内容来自 WWDC26 会议，带有示例主机名：

mlx.distributed_config 
    --hosts mac-0,mac-1,mac-2,mac-3 
    --output "cluster-jaccl.json" 
    --env MLX_METAL_FAST_SYNCH=1 
    --auto-setup 
    --backend jaccl

mlx.launch --hostfile "cluster-jaccl.json" -- 
    /remote/path/to/mlx_lm.chat --model "<model-name>" --max-tokens 2048

为了通过 API 将模型提供给其他应用，Apple 的研究文章在 mlx.launch 下运行 mlx_lm.server --port 8080。

Apple 展示了什么，以及它没说什么

Apple 于 2026 年 10 月 15 日发布的研究文章报告称，Muse Spark Open（一个 8160 亿参数、420 亿活跃参数的模型）在四台 M5 Ultra Mac Studio 上以 8,192 token 的上下文生成了超过每秒 36 个 token。细节很重要：

该模型以 4 位 NVFP4 精度评估，而非完整的 BF16 精度，且文章未报告输出质量。
基准测试使用批大小 1 和 128 个生成的 token。这意味着一次仅一个用户，而非一个团队。
Apple 将其启动命令中使用的 MLX_METAL_FAST_SYNCH=1 设置描述为实验性 MLX 功能。

缺席的内容同样能说明问题。WWDC26 会议记录和研究文章都没有使用“生产”或“稳定”这两个词。Apple 并未承诺生产就绪性。它也没有解释当某些东西出现故障时会发生什么。认为这是成品的感觉来自于演示看起来有多么流畅。

错误追踪器显示了什么

以下报告来自开源 MLX 和 exo 项目中的个人用户。它们不能告诉我们问题发生的频率，有些可能会随着新版本发布而改变。但它们描述了真实硬件上的具体故障。

报告	描述内容	截至 2026 年 10 月 16 日的状态
MLX #3910	当对等节点在操作中途消失时，JACCL 会永远等待：没有错误，没有超时。在四台 M3 Ultra Mac 上测试。	开放
MLX #4192	在操作中途拔掉 Thunderbolt 线缆会导致两端进程崩溃。	开放
MLX #3162	用户实测每设备约 100 个内存区域的限制可能会限制扩展到更多 Mac。	开放
exo #1843	在 macOS 26.4 上，exo 1.0.69 在一台没有其他设备的 Mac 上启动时反复崩溃。	开放
MLX #4485	JACCL 在两台 Mac 配置上启动时崩溃。报告者使用了开发分支。	已于 2026 年 10 月 1 日关闭

一项用于检测故障对等节点的拟议修复，MLX 拉取请求 #4530，增加了健康检查和可配置的超时时间（默认 600 秒）。它未被合并就被关闭。Apple 自己的技术说明还列出了硬性限制，包括每设备最多 10 个连接（“队列对”）。

节点故障时会发生什么？

这是企业服务必须回答的问题，而相关报告并不令人放心：

作业可能会无声卡死。 在 #3910 中，拔掉线缆后所有机器都冻结了。一分钟后再插回去也没有恢复任何东西。只有重新启动作业才行。
可能难以停止。 同一份报告称，正常的关闭信号被忽略，只有强制终止才有效，而在 macOS 上，这可能导致内存一直被锁定，直到重新启动。
可能在没有任何触发的情况下失败。 同一报告者观察到在服务约 75 小时后出现第二次卡死，原因不明。在 #4192 中，一位运行五台 M3 Ultra Mac 的用户报告在生产环境中发生了两次崩溃，链路自行断开。崩溃的机器约有 140 GB 内存被锁定，其端口直到重新启动才恢复。
链路几乎没有内置保障。 Apple 的说明解释说，发送完成并不确认数据完整到达，因为 Thunderbolt 在硬件层面不确认交付。连接属于“不可靠”类型，因此检测问题的工作留给了软件。

在我查阅的资料中，没有找到文档化的故障转移机制。如果一台 Mac 宕机，整个作业似乎会随之停止或卡死。

那么，它准备好用于生产了吗？

本节是基于上述证据的编辑判断。

对于研究、开发、私人实验或演示，Mac 集群是真实存在、能力强大且值得探索的。但对于同事依赖的常驻服务，公开报告中关于卡死、崩溃和手动恢复的问题是一个严重缺口，而我找到的任何信息都没有表明这些问题已得到解决。

如果你仍想在此基础上构建，采取一些预防措施是明智的：

固定版本。 锁定确切的 macOS 和 MLX 版本，仅在测试后更新。
故意破坏它。 拔掉一根线缆、关闭一个节点，在用户发现之前观察会发生什么。
自动化恢复。 在作业周围放置一个看门狗，可以检测卡死并重新启动。
保留后备方案。 单台 Mac 上的较小模型可以在集群重新启动期间保持服务运行。
重新检查追踪器。 当你阅读本文时，上述问题可能已得到修复。

关键要点

从 macOS 26.2 开始，Thunderbolt 5 集群让 Mac 可以合并内存并运行单台 Mac 无法容纳的模型。
设置不仅仅需要线缆：每台 Mac 都要启用 RDMA、软件版本一致、采用全网状或规划好的环形连接、关闭 Thunderbolt Bridge 并禁用睡眠。
Apple 公布的数据是使用 4 位模型的单用户基准测试，且 Apple 并未声称生产就绪。
公开报告描述了当链路或节点故障时出现无声卡死和崩溃，且没有文档化的故障转移。
目前它是一个出色的实验室工具。在向任何人承诺可靠服务之前，请严格测试故障场景。

资料来源

Apple Machine Learning Research — Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio
Apple Developer — Explore distributed inference and training with MLX (WWDC26)
Apple Developer — TN3205: Low-latency communication with RDMA over Thunderbolt
GitHub (ml-explore/mlx) — JACCL MeshImpl::recv spins forever on peer loss — silent hang, no timeout (#3910)
GitHub (ml-explore/mlx) — JACCL segfaults in tbt_post_recv when a Thunderbolt cable is unplugged mid-collective (#4192)
GitHub (ml-explore/mlx) — Hardware Bottleneck: AppleThunderboltRDMA hard limit of 100 MRs caps JACCL multi-node scaling (#3162)
GitHub (ml-explore/mlx) — JACCL segfaults in mx.distributed.init(backend="jaccl") on 2-node Mac-Mac (#4485)
GitHub (ml-explore/mlx) — Report a dead peer in JACCL instead of spinning forever (PR #4530)
GitHub (exo-explore/exo) — Crash loop on startup: EXO's own virtual Thunderbolt interfaces trigger false peer detection (#1843)
GitHub (exo-explore/exo) — exo: Run frontier AI locally (README)

标签: AI benchmarks Large Language Models (LLM)MLX