4 台 Mac 跑出 31.9 tokens/sExo 分布式 AI 推理集群搭建与调优实操【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exoExo 是一个分布式 AI 推理框架它把闲置的 Mac、笔记本、台式机自动组成一个 AI 推理集群让单台机器装不下的 Qwen3 235B、DeepSeek 671B 这类大模型可以分片并行跑在多台设备上。本文以一台 M3 Ultra Mac Studio 集群的实测数据为线索讲清楚它的架构为什么这么设计、四节点集群怎么搭、RDMA 与 TCP 的性能差距从何而来以及哪些参数决定你能不能跑、跑得有多稳。先给结论加机器真的会变快多数人在多机跑大模型这件事上的直觉是单节点塞不下就多分几台能跑就行速度大概率会被网络通信拖慢。Exo 的实测数据打破了这个预期。在 4 台 M3 Ultra Mac Studio每台 512GB 内存上跑 Qwen3 235B8-bit 量化张量并行走 RDMA 的 Exo 达到 31.9 tokens/s同一硬件上走 TCP 的方案只有 15.2 tokens/s差距接近一倍。更有意思的是趋势从 2 节点扩到 4 节点RDMA 路线继续提速26.2 → 31.9而 TCP 路线不升反降17.2 → 15.2。这组数字说明两件事第一节点间通信成本足够低时张量并行的收益会超过通信的开销横向扩展是正收益第二通信层RDMA 对 TCP对最终吞吐的影响比很多人以为的大。这两点直接解释了它后面的架构选择。为什么需要 Exo本地跑大模型卡点基本只有两个单台机器装不下。235B 参数的模型 8-bit 量化后权重就要 200GB 级别再加上 KV cache 和运行时的临时内存远超多数消费级设备的内存上限。装得下也跑不快。单设备内存不够时只能上更激进的量化精度损失或者干脆放弃。把设备组成集群是第三条路模型按层或按张量切分每台机器只存自己那份分片集群总内存 各节点内存之和。Exo 的定位就是做这条路的胶水层——自动发现设备、自动算放置方案、自动管理集群状态你只需要在每台设备上把进程跑起来。它基于 MLX 做推理后端macOS 上用 GPULinux 上目前是 CPU并兼容 OpenAI Chat Completions 等主流接口格式现有客户端工具基本可以直接接。Exo 的架构状态可重放通信可丢失从上面的性能反推设计Exo 的架构核心是两条原则状态管理用事件溯源。集群状态是一个不可变对象State任何变化都记录为事件通过纯函数apply()作用到状态上。Master 负责给事件排序、加索引并广播Worker 应用这些带索引的事件。好处是任何节点崩溃重启后重放事件序列就能恢复出一致的集群状态不需要额外的状态同步机制。消息传递风格借鉴 Erlang。节点之间没有中心化的 RPC只有类型化的发布/订阅主题Worker 把事件发给 MasterLOCAL_EVENTSMaster 向全体 Worker 广播索引后的事件GLOBAL_EVENTS命令、选举消息、连接状态各自走独立主题。每个进程只通过消息与外界打交道进程崩溃不会传染。消息层由 Rust 实现zenoh 点对点网络 gossip 发现通过 PyO3 绑定暴露给 Python 侧。落到组件上Exo 是五个子系统每台运行 exo 的节点上都有--no-worker可以关掉 Worker跑纯协调节点子系统职责Master集群状态排序与广播模型放置决策Worker模型下载、资源采集、任务调度管理 Runner 生命周期Runner独立进程中执行推理MLX 引擎崩溃隔离APIFastAPI 服务兼容 OpenAI / Claude / Ollama 等接口格式Electionbully 算法做主节点选举Master 挂了自动换人不脑裂值得单独说 Runner推理进程和 Master/Worker 进程隔离加载一个大模型是重内存、长生命周期的操作放在独立进程里模型 OOM 或引擎崩溃只会丢掉这个任务不会把整台节点拖垮。自动发现与放置算法组网不需要手工配置每台设备启动后通过 gossip 协议发现同网段的同伴自动形成全连接拓扑。之后你加入一台新机器、拔走一台拓扑图会实时更新。放置placement是 Master 的活给定一个模型它基于实时的拓扑视图——每台设备的剩余内存、每条链路的延迟与带宽——计算出把模型切到哪里、怎么切流水线并行还是张量并行的最优方案。同一个模型往往有多种合法放置方式API 支持先预览全部方案再选择这是后文/instance/previews的来历。搭建一个四节点集群安装、启动与 RDMA 配置搭建过程本身很简单难点全在硬件前提上。以下以 macOS 为例。1. 安装每台节点都要做git clone https://gitcode.com/GitHub_Trending/exo8/exo cd exo uv sync2. 启动并组网uv run exo启动后在http://localhost:52415打开 dashboard 和 API。四台机器各跑一次它们会自动发现彼此dashboard 中央会出现全连接的拓扑图右侧列出各节点的内存占用、温度、功耗以及已加载的模型实例3. 配置 RDMA性能关键项RDMA over Thunderbolt 是 macOS 26.2 新增的能力要求 Thunderbolt 5 硬件M4 Pro / M4 Max / M3 Ultra 级别机型。启用步骤关机后长按电源键 10 秒进恢复模式在实用工具 → 终端里执行rdma_ctl enable重启。几条硬件上的硬约束踩过的都是坑集群内每台设备必须物理直连其余所有设备全互联不是星型过交换机线缆必须支持 TB5 速率所有设备的 macOS 版本要完全一致连 beta 版本号都要一致否则 RDMA 端口可能互相发现不了Mac Studio 上紧邻网口的那个 TB5 口不可用换一根线的问题别怀疑软件。满足以上条件后 Exo 会自动接管剩余配置。实测数据RDMA 与 TCP 差在哪这张拓扑图本身就是监控面板每个节点标注了内存占用172.5GB/512GB约 34%、温度35~38°C和功耗13~15W四条链路构成全连接拓扑。也就是说集群的体检报告是实时可视化的不需要再搭 Prometheus 那一套。回到性能。RDMA 的收益本质来自两点绕过内核协议栈直接读写对端内存设备间延迟降低约 99%TB5 提供的高带宽让张量并行每层之间的 all-reduce 通信几乎免费。这也是为什么 4 节点 RDMA 能继续加速而 TCP 会掉头向下——通信开销的增长速度超过了并行收益。大模型的可用性上这套 4×512GB 的配置实测能同时加载DeepSeek v3.1 671B8-bit张量并行 MLX RDMAKimi K2 Thinking原生 4-bit张量并行Qwen3 235B8-bit即前文基准图的配置内置模型之外还可以从 HuggingFace 社区按需拉取curl -X POST http://localhost:52415/models/add \ -H Content-Type: application/json \ -d {model_id: mlx-community/my-model}注意配置里带trust_remote_code的模型默认拒绝加载需要显式开启——这是安全设计除非你确认信任来源否则别开。API四种接口格式一套实例生命周期Exo 的 API 同时暴露四种兼容格式OpenAI Chat Completions、Claude Messages、OpenAI Responses、Ollama。现有客户端把 base URL 指到http://localhost:52415就能用OpenWebUI 这类工具走 Ollama 格式即可接入。核心端点完整参考 docs/api.mdGET /v1/models— 模型列表?statusdownloaded过滤已下载POST /v1/chat/completions— 聊天补全支持流式、tools、logprobsPOST /instance/DELETE /instance/{id}— 实例的创建与销毁POST /place_instance— 让服务端按自身放置逻辑决定模型落到哪些节点实例的生命周期值得注意创建是异步命令返回的只是命令确认。正确姿势是创建后轮询GET /instance/await?model_id...SSE 流收到type: ready再发推理请求。想先看方案再动手用GET /instance/previews?model_id...它会列出所有合法放置及每种方案的内存增量挑一个再提交。一次最小请求长这样curl -N -X POST http://localhost:52415/v1/chat/completions \ -H Content-Type: application/json \ -d { model: mlx-community/Llama-3.2-1B-Instruct-4bit, messages: [{role: user, content: 你好}], stream: true }端点实现集中在 src/exo/master/api.py想扩展接口或对接自己的后端时从这里入手最快。调优与避坑先容量再网络最后才是阈值按影响大小排序三件事内存容量是第一约束。决定的是能不能跑。算账方式模型权重的分片大小 ≤ 单节点可用内存四节点跑 235B 时每台约吃 173GB见拓扑图约 34% 占用。放不下就加节点或换低比特量化没有别的绕法。模型下载目录可通过EXO_MODELS_DIRS指到外置 SSDEXO_MODELS_READ_ONLY_DIRS可以挂 NFS 共享预下载好的权重省掉每台重复下载。RDMA 优先。决定的是跑得多快实测约 2 倍吞吐差距。代价是硬件门槛TB5、全互联、系统版本完全一致和布线复杂度。节点少、带宽要求不高的场景走 TCP/Thunderbolt Bridge 起步也完全可用。给资源设阈值盯住拓扑图。决定的是跑不跑得稳。持续观察每节点内存占用、温度、功耗三个指标内存占比如长期贴着上限KV cache 没有余量长上下文请求会直接失败。另外两个实用手段EXO_LIBP2P_NAMESPACE给集群命名空间隔离同一网段跑多套集群开发/生产不会互相串协调节点不需要推理时加--no-worker启动把内存省给数据面。这套方案适合谁私有化部署数据不出内网现有 OpenAI 格式客户端零改造接入这是它相对云端 API 最硬的差异点。研究与实验验证张量并行、放置策略、不同网络拓扑对吞吐的影响bench/exo_bench.py提供了 prefill/decode 分段的压测工具命名空间隔离让实验集群互不干扰。资源受限环境手头是几台大内存但没顶级 GPU的闲置设备时横向堆内存是比单台升级更便宜的扩容方式自动发现又把运维成本压到了最低。它的边界同样清楚macOS 之外Linux目前只能跑 CPUGPU 支持还在路上RDMA 红利集中在 Apple 的 TB5 硬件上。如果你的主力是 Linux 集群可以关注项目进展或者先用 TCP 模式验证工作流。小结Exo 把多设备跑大模型里最脏的活——设备发现、放置计算、状态一致性、主节点选举——用事件溯源加 Erlang 风格消息传递这套组合拳收掉了用户侧只剩每台装一个、跑起来两件事。实测数据表明这条路不只是能跑4 节点 RDMA 下 Qwen3 235B 做到 31.9 tokens/s且加节点持续提速。如果你有一批大内存设备躺在角落这大概是目前本地分布式 AI 推理里最省事的一条路。【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 4 台 Mac 跑出 31.9 tokens/s：Exo 分布式 AI 推理集群搭建与调优实操
4 台 Mac 跑出 31.9 tokens/sExo 分布式 AI 推理集群搭建与调优实操【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exoExo 是一个分布式 AI 推理框架它把闲置的 Mac、笔记本、台式机自动组成一个 AI 推理集群让单台机器装不下的 Qwen3 235B、DeepSeek 671B 这类大模型可以分片并行跑在多台设备上。本文以一台 M3 Ultra Mac Studio 集群的实测数据为线索讲清楚它的架构为什么这么设计、四节点集群怎么搭、RDMA 与 TCP 的性能差距从何而来以及哪些参数决定你能不能跑、跑得有多稳。先给结论加机器真的会变快多数人在多机跑大模型这件事上的直觉是单节点塞不下就多分几台能跑就行速度大概率会被网络通信拖慢。Exo 的实测数据打破了这个预期。在 4 台 M3 Ultra Mac Studio每台 512GB 内存上跑 Qwen3 235B8-bit 量化张量并行走 RDMA 的 Exo 达到 31.9 tokens/s同一硬件上走 TCP 的方案只有 15.2 tokens/s差距接近一倍。更有意思的是趋势从 2 节点扩到 4 节点RDMA 路线继续提速26.2 → 31.9而 TCP 路线不升反降17.2 → 15.2。这组数字说明两件事第一节点间通信成本足够低时张量并行的收益会超过通信的开销横向扩展是正收益第二通信层RDMA 对 TCP对最终吞吐的影响比很多人以为的大。这两点直接解释了它后面的架构选择。为什么需要 Exo本地跑大模型卡点基本只有两个单台机器装不下。235B 参数的模型 8-bit 量化后权重就要 200GB 级别再加上 KV cache 和运行时的临时内存远超多数消费级设备的内存上限。装得下也跑不快。单设备内存不够时只能上更激进的量化精度损失或者干脆放弃。把设备组成集群是第三条路模型按层或按张量切分每台机器只存自己那份分片集群总内存 各节点内存之和。Exo 的定位就是做这条路的胶水层——自动发现设备、自动算放置方案、自动管理集群状态你只需要在每台设备上把进程跑起来。它基于 MLX 做推理后端macOS 上用 GPULinux 上目前是 CPU并兼容 OpenAI Chat Completions 等主流接口格式现有客户端工具基本可以直接接。Exo 的架构状态可重放通信可丢失从上面的性能反推设计Exo 的架构核心是两条原则状态管理用事件溯源。集群状态是一个不可变对象State任何变化都记录为事件通过纯函数apply()作用到状态上。Master 负责给事件排序、加索引并广播Worker 应用这些带索引的事件。好处是任何节点崩溃重启后重放事件序列就能恢复出一致的集群状态不需要额外的状态同步机制。消息传递风格借鉴 Erlang。节点之间没有中心化的 RPC只有类型化的发布/订阅主题Worker 把事件发给 MasterLOCAL_EVENTSMaster 向全体 Worker 广播索引后的事件GLOBAL_EVENTS命令、选举消息、连接状态各自走独立主题。每个进程只通过消息与外界打交道进程崩溃不会传染。消息层由 Rust 实现zenoh 点对点网络 gossip 发现通过 PyO3 绑定暴露给 Python 侧。落到组件上Exo 是五个子系统每台运行 exo 的节点上都有--no-worker可以关掉 Worker跑纯协调节点子系统职责Master集群状态排序与广播模型放置决策Worker模型下载、资源采集、任务调度管理 Runner 生命周期Runner独立进程中执行推理MLX 引擎崩溃隔离APIFastAPI 服务兼容 OpenAI / Claude / Ollama 等接口格式Electionbully 算法做主节点选举Master 挂了自动换人不脑裂值得单独说 Runner推理进程和 Master/Worker 进程隔离加载一个大模型是重内存、长生命周期的操作放在独立进程里模型 OOM 或引擎崩溃只会丢掉这个任务不会把整台节点拖垮。自动发现与放置算法组网不需要手工配置每台设备启动后通过 gossip 协议发现同网段的同伴自动形成全连接拓扑。之后你加入一台新机器、拔走一台拓扑图会实时更新。放置placement是 Master 的活给定一个模型它基于实时的拓扑视图——每台设备的剩余内存、每条链路的延迟与带宽——计算出把模型切到哪里、怎么切流水线并行还是张量并行的最优方案。同一个模型往往有多种合法放置方式API 支持先预览全部方案再选择这是后文/instance/previews的来历。搭建一个四节点集群安装、启动与 RDMA 配置搭建过程本身很简单难点全在硬件前提上。以下以 macOS 为例。1. 安装每台节点都要做git clone https://gitcode.com/GitHub_Trending/exo8/exo cd exo uv sync2. 启动并组网uv run exo启动后在http://localhost:52415打开 dashboard 和 API。四台机器各跑一次它们会自动发现彼此dashboard 中央会出现全连接的拓扑图右侧列出各节点的内存占用、温度、功耗以及已加载的模型实例3. 配置 RDMA性能关键项RDMA over Thunderbolt 是 macOS 26.2 新增的能力要求 Thunderbolt 5 硬件M4 Pro / M4 Max / M3 Ultra 级别机型。启用步骤关机后长按电源键 10 秒进恢复模式在实用工具 → 终端里执行rdma_ctl enable重启。几条硬件上的硬约束踩过的都是坑集群内每台设备必须物理直连其余所有设备全互联不是星型过交换机线缆必须支持 TB5 速率所有设备的 macOS 版本要完全一致连 beta 版本号都要一致否则 RDMA 端口可能互相发现不了Mac Studio 上紧邻网口的那个 TB5 口不可用换一根线的问题别怀疑软件。满足以上条件后 Exo 会自动接管剩余配置。实测数据RDMA 与 TCP 差在哪这张拓扑图本身就是监控面板每个节点标注了内存占用172.5GB/512GB约 34%、温度35~38°C和功耗13~15W四条链路构成全连接拓扑。也就是说集群的体检报告是实时可视化的不需要再搭 Prometheus 那一套。回到性能。RDMA 的收益本质来自两点绕过内核协议栈直接读写对端内存设备间延迟降低约 99%TB5 提供的高带宽让张量并行每层之间的 all-reduce 通信几乎免费。这也是为什么 4 节点 RDMA 能继续加速而 TCP 会掉头向下——通信开销的增长速度超过了并行收益。大模型的可用性上这套 4×512GB 的配置实测能同时加载DeepSeek v3.1 671B8-bit张量并行 MLX RDMAKimi K2 Thinking原生 4-bit张量并行Qwen3 235B8-bit即前文基准图的配置内置模型之外还可以从 HuggingFace 社区按需拉取curl -X POST http://localhost:52415/models/add \ -H Content-Type: application/json \ -d {model_id: mlx-community/my-model}注意配置里带trust_remote_code的模型默认拒绝加载需要显式开启——这是安全设计除非你确认信任来源否则别开。API四种接口格式一套实例生命周期Exo 的 API 同时暴露四种兼容格式OpenAI Chat Completions、Claude Messages、OpenAI Responses、Ollama。现有客户端把 base URL 指到http://localhost:52415就能用OpenWebUI 这类工具走 Ollama 格式即可接入。核心端点完整参考 docs/api.mdGET /v1/models— 模型列表?statusdownloaded过滤已下载POST /v1/chat/completions— 聊天补全支持流式、tools、logprobsPOST /instance/DELETE /instance/{id}— 实例的创建与销毁POST /place_instance— 让服务端按自身放置逻辑决定模型落到哪些节点实例的生命周期值得注意创建是异步命令返回的只是命令确认。正确姿势是创建后轮询GET /instance/await?model_id...SSE 流收到type: ready再发推理请求。想先看方案再动手用GET /instance/previews?model_id...它会列出所有合法放置及每种方案的内存增量挑一个再提交。一次最小请求长这样curl -N -X POST http://localhost:52415/v1/chat/completions \ -H Content-Type: application/json \ -d { model: mlx-community/Llama-3.2-1B-Instruct-4bit, messages: [{role: user, content: 你好}], stream: true }端点实现集中在 src/exo/master/api.py想扩展接口或对接自己的后端时从这里入手最快。调优与避坑先容量再网络最后才是阈值按影响大小排序三件事内存容量是第一约束。决定的是能不能跑。算账方式模型权重的分片大小 ≤ 单节点可用内存四节点跑 235B 时每台约吃 173GB见拓扑图约 34% 占用。放不下就加节点或换低比特量化没有别的绕法。模型下载目录可通过EXO_MODELS_DIRS指到外置 SSDEXO_MODELS_READ_ONLY_DIRS可以挂 NFS 共享预下载好的权重省掉每台重复下载。RDMA 优先。决定的是跑得多快实测约 2 倍吞吐差距。代价是硬件门槛TB5、全互联、系统版本完全一致和布线复杂度。节点少、带宽要求不高的场景走 TCP/Thunderbolt Bridge 起步也完全可用。给资源设阈值盯住拓扑图。决定的是跑不跑得稳。持续观察每节点内存占用、温度、功耗三个指标内存占比如长期贴着上限KV cache 没有余量长上下文请求会直接失败。另外两个实用手段EXO_LIBP2P_NAMESPACE给集群命名空间隔离同一网段跑多套集群开发/生产不会互相串协调节点不需要推理时加--no-worker启动把内存省给数据面。这套方案适合谁私有化部署数据不出内网现有 OpenAI 格式客户端零改造接入这是它相对云端 API 最硬的差异点。研究与实验验证张量并行、放置策略、不同网络拓扑对吞吐的影响bench/exo_bench.py提供了 prefill/decode 分段的压测工具命名空间隔离让实验集群互不干扰。资源受限环境手头是几台大内存但没顶级 GPU的闲置设备时横向堆内存是比单台升级更便宜的扩容方式自动发现又把运维成本压到了最低。它的边界同样清楚macOS 之外Linux目前只能跑 CPUGPU 支持还在路上RDMA 红利集中在 Apple 的 TB5 硬件上。如果你的主力是 Linux 集群可以关注项目进展或者先用 TCP 模式验证工作流。小结Exo 把多设备跑大模型里最脏的活——设备发现、放置计算、状态一致性、主节点选举——用事件溯源加 Erlang 风格消息传递这套组合拳收掉了用户侧只剩每台装一个、跑起来两件事。实测数据表明这条路不只是能跑4 节点 RDMA 下 Qwen3 235B 做到 31.9 tokens/s且加节点持续提速。如果你有一批大内存设备躺在角落这大概是目前本地分布式 AI 推理里最省事的一条路。【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考