英伟达开源的 Personal AI Router（PAIR）瞄准了一个很实际的问题：家里或小型工作室可能有多台带 GPU 的电脑，但本地 AI 推理通常只能使用其中一台。PAIR 会在局域网内发现兼容设备，将它们组织起来处理本地推理请求，并沿用 Ollama、LM Studio 等开发者已经熟悉的工具链。
这不等于把多台消费级电脑瞬间变成一台共享显存的服务器。更准确地说，PAIR 提供的是设备发现和请求路由能力：每个节点仍然独立加载、运行模型，路由层负责选择合适的机器。
哪些设备可以加入
来源信息列出的重点设备包括：
- GeForce RTX 20 系及更新显卡
- RTX Pro
- DGX Spark
- Apple M4 及更新芯片
这让混合设备集群成为可能。例如，台式机负责较大的模型，Mac 承担轻量模型或嵌入任务，另一台游戏电脑在空闲时提供额外吞吐量。
不过，设备“能够加入”不代表它们能以相同速度处理同一个模型。显存或统一内存容量、量化格式、推理后端、网络带宽和散热条件，都会影响实际调度。部署前至少要回答三个问题：
- 每台机器能稳定加载哪些模型？
- 各节点是否安装了相同的模型名称和版本？
- 请求失败或节点休眠时，路由层如何重试？
PAIR 解决的是路由，不是共享显存
理解这一边界很重要。假设局域网里有三台机器，每台都运行 Ollama，PAIR 可以发现这些服务并把不同请求分配过去，从而提升并发能力或利用率。但如果一个模型必须占用 40 GB 显存，四台各有 12 GB 显存的电脑未必能直接联合加载它。
因此，PAIR 更适合以下场景：
- 多名开发者共享本地代码助手或聊天模型
- 批量摘要、分类和结构化提取
- 将聊天、嵌入、视觉模型放在不同节点
- 根据机器负载或模型可用性分发请求
- 不希望把内部文档和提示词发往公网 API
它带来的主要收益通常是请求级并行、设备利用率和统一入口，而不是模型级分布式计算。
动手检查局域网里的 Ollama 节点
PAIR 的具体安装和配置应以项目发布的文档为准。即使暂时不接入 PAIR，也可以先验证各节点的 Ollama 服务、模型和网络是否准备好。
在每台节点上安装并启动 Ollama，然后确认服务能够响应：
curl http://127.0.0.1:11434/api/tags
如果需要让局域网中的路由器访问 Ollama，可以这样启动服务。请将监听范围和防火墙规则限制在可信局域网，不要把端口直接暴露到互联网：
OLLAMA_HOST=0.0.0.0:11434 ollama serve
接着在管理机上创建 nodes.txt，把地址替换为自己的局域网 IP：
192.168.1.21:11434
192.168.1.22:11434
192.168.1.23:11434
下面的脚本可以逐台检查节点是否在线，并打印已经安装的模型。它只依赖 Bash 和 curl，可直接用于接入 PAIR 前的连通性排查：
#!/usr/bin/env bash
set -u
while IFS= read -r node; do
[[ -z "$node" ]] && continue
printf '\n== %s ==\n' "$node"
if response=$(curl --silent --show-error --fail \
--connect-timeout 2 --max-time 5 \
"http://${node}/api/tags"); then
printf '%s\n' "$response"
else
echo "unreachable"
fi
done < nodes.txt
保存为 check-nodes.sh 后运行：
chmod +x check-nodes.sh
./check-nodes.sh
还可以直接向某个节点发起一次非流式推理，用来确认模型名称、内存和推理后端均正常。运行前把 IP 和模型名改成该节点实际安装的值：
curl http://192.168.1.21:11434/api/generate \
-H 'Content-Type: application/json' \
-d '{
"model": "qwen2.5:7b",
"prompt": "用三句话解释什么是请求路由。",
"stream": false
}'
如果这些基础检查不稳定，接入路由层后只会更难定位问题。先确保每个节点能够独立完成推理，再处理自动发现和调度。
部署时最容易忽略的边界
局域网并不天然安全。Ollama 等本地服务如果监听所有网卡，而网络中又存在访客设备、IoT 设备或不可信终端，模型接口和输入数据就可能被未授权访问。至少应使用主机防火墙划分允许访问的 IP，并通过独立 VLAN 或可信子网隔离推理节点。
模型一致性也是常见问题。同一个模型名称可能对应不同量化版本，导致输出质量、内存占用和速度不一致。建议为节点记录模型摘要、量化格式、上下文长度和后端版本，而不只是记录名称。
此外，不要只观察平均响应时间。家庭电脑可能进入睡眠状态、被游戏抢占显存，或者因温度限制而降频。实际运行时应关注首 token 延迟、完整请求耗时、失败率、队列长度和节点失联次数。
是否值得采用
PAIR 适合已经拥有多台兼容设备、希望数据留在本地，并且工作负载可以拆成独立请求的团队或个人。开始时不要急着接入所有机器，可以先选两台硬件差异较小的节点，统一 Ollama 或 LM Studio 版本和模型，再验证路由、故障恢复及性能。
上线前可以按这份清单检查：
- 每台节点能够独立完成目标模型推理
- 节点使用固定地址或可靠的局域网名称解析
- 推理端口只允许可信设备访问
- 模型名称、版本和量化格式有明确记录
- 节点休眠、离线和显存不足时有降级策略
- 性能测试覆盖并发请求，而不只是单次生成
如果目标是提升多个本地请求的吞吐量，PAIR 的设备发现和路由思路很契合；如果目标是让多台小显存机器共同承载一个超大模型，则需要先确认其是否支持所需的模型切分或分布式推理方式，不能仅凭“集群”二字作判断。