企业官网建设流程全解析

4台Mac拼AI集群跑235B大模型：exo分布式推理实战

【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo

最近折腾 exo 这个项目，目的是做 AI 集群管理：把几台 Apple Silicon 设备自动拼成一个推理集群，让 235B 这种单机装不下的大模型能本地跑起来。这篇文章记录我实际跑通它的过程：官方 benchmark 里，4 台 M3 Ultra Mac Studio 跑 Qwen3-235B 做到 31.9 tokens/s，而单台 llama.cpp 走 TCP 只有 20.4——多出来的机器不是白白吃掉通信开销，而是真的让速度变快了。

🧩 四台 Mac Studio 如何变成一台超算

先说痛点：一台 Mac Studio 顶配 512GB 统一内存，235B 模型 8-bit 量化后勉强塞得下，但更大的模型（671B）根本放不下；而传统的多机方案（比如 llama.cpp 走 TCP 网络）扩机器往往反而更慢，通信开销吃掉了算力红利。

exo 的思路是把每台设备当集群成员：跑上 exo 的机器自动互相发现，不用手动配任何网络参数。下面是 4 台机器的实际拓扑视图，每台设备的内存占用、温度、功耗都实时可见：

但注意一个前提：张量并行要求所有节点两两直连，不是星型接一台交换机就行。这是后面 RDMA 部分所有麻烦的根源。

下面是 exo 内置的集群管理 dashboard，4 台 512GB 的机器同时挂着 DeepSeek v3.1（8-bit）和 Kimi-K2-Thinking（4-bit）两个实例：

⚡ RDMA 在 macOS 恢复模式里怎么开

exo 最激进的部分是对 RDMA over Thunderbolt 5 的支持（macOS 26.2 起提供该能力）。RDMA 让网卡直接读写对端内存，绕过内核协议栈，官方说法是设备间延迟降低 99%——这也是多机反而更快的那个数字的来源。

开启方式有点绕：关机 → 长按电源键 10 秒进恢复模式 → 打开终端执行：

rdma_ctl enable

然后重启。但文档里列了几条硬性约束，踩了任何一条集群都组不起来：

• 集群内每台设备必须与其他所有设备 TB5 直连（全网格）；
• 线缆必须是 TB5 规格；
• Mac Studio 上网口旁边的那个 TB5 口不能用，我第一台机器就是栽在这里；
• 所有设备的 macOS 版本必须逐字符一致（连 beta 版本号都要一样），版本不一致时 RDMA 端口互相发现不了。

如果你只是从源码跑，还要再执行tmp/set_rdma_network_config.sh，它会关掉 Thunderbolt Bridge 并给每个 RDMA 口配 DHCP。嫌麻烦的话可以用 macOS 桌面应用（brew install --cask exo），它会自动装网络配置 profile，代价是系统会弹权限请求。

🔀 拓扑感知自动并行：切法怎么选

RDMA 解决"传得快"，另一个问题是"怎么切"。手动分片老方案里你得自己决定哪层放哪台机器；exo 的放置逻辑是拓扑感知的——它基于实时采集的设备资源和每条链路的延迟/带宽，在管道并行（按层切开，各机各跑一段）和张量并行（每层切开，并行算）之间选一个，/instance/previews接口会列出所有合法切法及每种切法在各节点上的内存增量，让你先预览再创建。

官方给的张量并行收益：2 台设备约 1.8 倍加速，4 台约 3.2 倍。下面是 Jeff Geerling 在 4×M3 Ultra 上测的 Qwen3-235B，蓝色是 llama.cpp 走 TCP，黄色是 exo 走 RDMA：

这张图比 56% 那个数字更说明问题：单节点时两者接近（20.4 vs 19.5），但节点一多，TCP 方案不升反降（4 节点掉到 15.2），exo 则一路升到 31.9。通信开销是不是瓶颈，扩节点这件事会直接替你回答。

不确定自己集群上哪种切法好时，仓库里带了bench/exo_bench.py，可以对同一模型在 pipeline/tensor 两种 sharding 下分别测 prefill 和生成吞吐，数字是服务端计时，默认冷缓存，方便对比。

💻 从 clone 到第一次 chat completion

跑通的最小路径很短。macOS 上先装 Xcode（提供 Metal 工具链）、uv、node、Rust nightly，然后：

git clone https://gitcode.com/GitHub_Trending/exo8/exo cd exo/dashboard && npm install && npm run build && cd .. uv run exo

起来之后 dashboard 和 API 都在http://localhost:52415。用 API 走一遍完整流程：先 GET/instance/previews?model_id=...看切法，挑一个 placement POST 到/instance创建实例（注意创建是异步的，要对着/instance/await的 SSE 流等到ready才能发推理请求），然后 POST/v1/chat/completions开聊。

对已有工具链最友好的一点是：它同时兼容 OpenAI Chat Completions、Claude Messages、OpenAI Responses 和 Ollama 四套接口格式，意味着你现有的客户端改个 base_url 就能指向集群。集群状态、事件流也可以直接查，类型定义在 src/exo/master/api.py，事件日志和/events接口是排障时用得最多的两个入口。

🚧 适用边界：什么时候别选它

说实话，exo 目前的舒适区很明确：Apple Silicon + TB5 内网小集群。几个硬限制：

• Linux 上目前只跑 CPU，GPU 支持还在路线图上（CUDA 在 Tier 1 计划里），想在 Linux 生产环境用还不现实；
• RDMA 要求 TB5 硬件（M4 Pro/Max、M3 Ultra 这一批）+ macOS 26.2+，老机器只能退回普通网络，多机加速的故事就不成立了；
• 全网格直连意味着 4 台机器要 6 根 TB5 线，规模再往上拓扑成本是平方级涨的；
• 它本质是个"你自己机房里的信任集群"，没有多租户、鉴权这些能力，EXO_LIBP2P_NAMESPACE只是用来在同网段隔离多个集群的。

所以如果你的需求是"一台机器装不下、但 2~4 台 TB5 设备能装得下"的推理负载，exo 目前是这个形态里完成度最高的开源方案之一。

留个问题给你：如果你手上有 4 台 M3 Ultra，你会直接上张量并行博那 3.2 倍，还是先保守用管道并行把 671B 铺起来？或者更实际的做法——两种切法都跑一遍 exo-bench，让[master/placement.py](https://link.gitcode.com/i/e6ca959eec1e0c43ba5ac979fda60d38)的预览结果和你自己的数据吵一架。

【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo