两台 Mac 拼成推理池，加机器不加内存

11 月 11 日，Apple 通过子公司 Claris 放出了 Harbor 的预览，两台用雷雳 5 连起来的 Mac 能自动组网，把各自的内存汇成一块统一的推理资源。这件事方向我有兴趣，但不用等预览资格，手边两台 Mac 今天就能用 Ollama 拼出同款逻辑。

先把一个误区说清楚，省得后面白算账。

热榜上那篇文章讲得挺清楚，所谓显存池是吞吐和容量层面的逻辑聚合，不是物理合并。你在客户端只面对一个统一端点，调度层把请求轮流转给后面几台机器，每台机器在自己的内存里各加载一份权重。

好处有两个，容量叠加、单台挂了不中断。代价也很明确，每台各存一份权重，总内存占用是台数的倍数。

一台 7B 模型大约四点五 GB，两台就是九 GB，不是四点五。想省内存只能换更小的模型或者做量化，堆机器省不出内存。

第一步，每台机器把服务暴露到局域网。默认只听本机，所以要显式指定。

bash 复制代码

export OLLAMA_HOST=0.0.0.0:11434
ollama serve

这时从另一台机器上 curl 一下标签接口，能返回 JSON 就通了。

第二步，每台拉同一个模型。同一台先拉完，再把权重目录拷过去，走雷雳比走 Wi-Fi 快得多。

第三步，写一个调度层把几台编成一个端点。调度逻辑不复杂，轮询选节点，连续失败三次就摘掉，恢复后自动加回，加上在途请求上限，防止把一个节点压垮。

那篇文章附了一个零依赖的脚本，思路就是这样。我这边多做了一件事，按模型名路由，配额按节点权重分配，一台强一台弱的话，强的接七成流量。

绑定地址。 默认只听 localhost，忘了设环境变量的话，服务起得好好的，别的机器就是连不上。这是最常见的明明起来了却不可达。

防火墙。 macOS 默认拦 11434 端口，要在防火墙选项里给 Ollama 放行。放行之前所有跨机请求都是静默超时，排查的时候先 curl 确认端口通不通，别急着查应用。

常驻。 靠终端窗口挂着的服务，ssh 一断就没了。长期跑用 launchd 配一个常驻项。

睡眠。 Mac 合盖就断，笔记本尤其明显。要么关睡眠，要么别把笔记本当常驻节点。

主机名解析。 .local 在 macOS 上偶发解析慢，跨机调用直接用 IP 或者固定 hostname。

冷启动。 模型没加载时第一次请求要等几秒。上线前预热一次，别让第一个用户替你等。

那篇文章给了一组实测，单台机器跑 7B，单条请求平均解码约每秒三十八个 token，四路并发时单路掉到二十二，聚合吞吐八十八。

接上第二台走轮询之后，四路并发被均摊，单路回到三十五，聚合吞吐一百五左右。

这组数字要看清它测的是什么。它测的是吞吐，不是单请求延迟。单台空闲时单路最快，加机器不会让一条请求变快，只会让并发时每条不那么慢。想压低单请求延迟，加机器没用，得换更好的硬件或者更小的模型。

内存账。 权重是倍数增长，所以这套只适合单台装得下的模型。模型大到单台内存吃紧，堆机器解决不了，那是换硬件的事。

延迟账。 池化只改善吞吐和可用性，不改善单请求延迟。要求极低延迟的场景，老老实实单机。

运维账。 多一台机器就多一份防火墙、常驻、睡眠、模型同步的活。两台还能手工管，五台就得写脚本了。

反过来，它适合的场景很清楚。团队里有几台闲置 Mac，模型单台装得下，数据不能出网，并发不高但要稳。这四条对上，拼一下很划算。

云上按 token 计费，量一大账单就不好看；自家闲置机器的电费几乎可以忽略。合同、代码、病历这类文本不想因为调一次接口就送到别人服务器上，本地跑完即焚最省心。

Harbor 把这条路包装成了产品，好处是省事，代价是等。Ollama 这套拼法土一点，但今天就能用，而且哪台机器跑什么模型、流量怎么分，全在你自己手里。

一句经验收尾。本地池化这件事，别被「统一显存池」这个名字骗了，它更像一个入口后面几间后厨，而不是一块更大的内存。想清楚你要的是容量、吞吐还是延迟，三笔账算下来，答案通常很清楚。

这一批还有两篇，一篇讲六个 Agent 生产事故暴露出的机制接缝，一篇讲容器退出码 137 怎么判断成因。感兴趣的关注一下。