NVIDIA PAIR：把家里闲置的 RTX、Mac 和 DGX 拼成一个 AI 集群

NVIDIA PAIR：把家里闲置的 RTX、Mac 和 DGX 拼成一个 AI 集群

你的游戏 PC 在打游戏，隔壁的 DGX Spark 正在闲着。

多 Agent 工作流已经成了常态：一个 lead agent 把任务拆成几份，派给多个 subagent 并行处理，用户自己也可能同时开着好几个 Agent 会话。这种 breadth-first 的做法确实快，但瓶颈也很明显——从 Agent 视角看这是一个任务，从推理层看它是几十个独立的模型调用。如果这些调用全部涌向同一台机器上的同一个推理引擎，它们就在排队抢同一个 GPU 的执行槽位。

9 月 3 日，NVIDIA 发布了 Personal AI Router（PAIR） 的 beta 版（v0.1.1，开源）。思路很直接：你家里网络上的其他机器——RTX 台式机、DGX Spark、M4 以后的 Mac——大概率有兼容的算力在闲着。PAIR 把它们组成一个"个人 AI 集群"，把每个独立的推理请求路由到有空闲的节点上。提示词、文件、Agent 上下文全部留在你的局域网里。

本文提纲

1. 它是什么：一个路由器，不是新引擎
2. 工作原理：发现、配对、代理、调度
3. 实测：五子代理任务，18 分钟到 8 分 48 秒
4. 诚实边界：它不做什么
5. 系统要求与上手

它是什么：一个路由器，不是新引擎

先说清楚 PAIR 不是什么：它不是新的推理引擎。模型仍然由 Ollama 或 LM Studio 在被选中的机器上执行。PAIR 做的事情是发现参与进来的系统、跟踪每台机器是否准备好接活、把独立的任务调度出去、再把响应送回发起请求的应用。

这个定位很克制，但克制得聪明。跨普通家庭网络做真正的分布式推理（把一个模型切成几份分摊到多台机器）会被延迟和带宽拖垮，得不偿失。PAIR 做的是工作负载级别的并发——每个请求被分配到一个符合条件的节点，从头到尾在那台机器上执行完。请求不跨机，GPU 不合并，VRAM 不池化。

对 Agent 来说体验是零改动的。PAIR 的 proxy 直接接管 Ollama 和 LM Studio 的默认端口，Agent harness 继续用它本来就认识的接口发请求，base URL 都不用改。PAIR 收到请求后识别引擎和模型需求，选一个符合条件的节点执行，响应经原路流回。Agent 看到的始终是一个连接，背后的调度对它完全透明。

工作原理：发现、配对、代理、调度

整条链路分四步：

MERMAID_BLOCK_0

发现与配对。每台兼容机器装好 PAIR 后，通过 mDNS 自动发现局域网里的其他节点（也可以手动按 IP 添加）。用户批准配对请求后，节点间通信全部走 MTLS 加密——配对建立之前，节点之间的通信是被完全阻断的。

准备引擎和模型。每个参与节点跑一个受支持的推理引擎（Ollama 或 LM Studio），PAIR 能帮你远程装引擎、发起模型下载。有意思的一个设计：各节点的模型不必统一。A 机器放 Qwen，B 机器放 Llama 都行，PAIR 按模型所在位置路由；同一模型装到更多节点上，只是给调度器一个更大的候选池。

调度决策。对每个新请求，调度器综合五个因素：节点是否在线且就绪、受支持的引擎是否启用、请求的模型在这台机器上是否存在、当前节点和引擎的负载（活跃任务数）、GPU 当前的占用情况（比如是不是正在跑游戏或创作软件）。后面这条特别贴近家庭场景——游戏 PC 一进游戏，调度器就自动绕开它。

弹性进出。家庭硬件不是机房：笔记本会睡眠、会合盖、会离开网络，游戏 PC 随时可能被前台应用征用 GPU。节点可以在就绪时加入可用池，需要时随时退出，不需要把家变成一台 7×24 常开的推理服务器。这是 PAIR 和"小型数据中心"思路最大的分歧点——它按家里设备的真实使用节奏来调度。

实测：五子代理任务，18 分钟到 8 分 48 秒

NVIDIA 用 Hermes Desktop + Ollama 做了一个演示：任务是对一个合成家庭收件箱做分析，产出一份有据可查的"周日重置计划"——哪些事今晚必须做、哪些本周做、哪些以后做、哪些不用做。Hermes 负责任务分解、委派和综合，五个 specialist subagent 各自审一部分证据。

跑的模型是 Qwen 3.6 35B A3B，结果：

配置	平均完成时间
单台 RTX Spark 笔记本	18 分钟
三机集群（RTX Spark 笔记本 + DGX Spark + RTX 5090）	8 分 48 秒

差不多 2 倍提速。NVIDIA 自己也标注得很清楚：这是非官方的、特定配置的演示，不是通用 benchmark，更不是线性扩展的承诺。实际收益取决于工作负载的并行度、模型、引擎设置、硬件和网络。

另外有个值得表扬的细节：PAIR 的 Jobs 视图是推理实际跑在哪里的 ground truth。Hermes 的 Agent 数和 PAIR 的 job 数是两个不同的度量——一个 Agent 可能产生多次模型请求。多机执行的结论只有 PAIR 遥测显示任务确实分布在多个节点时才能宣称。这种对度量的较真，在产品宣传里不多见。

诚实边界：它不做什么

官方文档里"PAIR does not"这一节写得很明白：

• 不合并 GPU、不把 VRAM 池化成一块更大的显存
• 不做模型分片，不把单个推理请求拆到多台机器

对应的，收益小的场景也很直白：高度顺序的任务、由一次超长模型调用主导的工作负载、或者集群里只有一台机器装了所需模型的配置——这些情况 PAIR 帮不上太多忙。官方建议用端到端完成时间、排队情况、输出质量和实际观测到的路由分布来衡量自己的工作负载。

换句话说，PAIR 赌的是未来 Agent 工作负载的形态：大量并发的独立小请求，而不是单次巨型调用。从多 Agent 编排的演进方向看，这个赌注不算激进。

系统要求与上手

项目	要求
GPU	GeForce RTX 20 系及以上、RTX PRO 工作站卡（Turing 架构起）、DGX Spark/GB10、Mac M4 及以上
内存	8 GB 起
磁盘	建议 20 GB 以上
系统	Windows 11、DGX OS、Ubuntu、macOS Tahoe
网络	运行时不需要联网，下载模型时需要

三步上手：下载安装（Windows/macOS/Linux 都有 x86 和 ARM 包）→ 局域网内配对设备 → 跑你现有的 AI 应用和 Agent。

项目在 GitHub 开源，可以看代码、提 issue、给路由、发现、引擎集成这些模块贡献改进。

顺带一提定位差异：如果你想要的是把一台机器变成完整的私有 AI 服务器（聊天、RAG、工作流全套），前几天聊过的 ODS 是那个方向的答案；PAIR 解决的是另一个问题——你已经有好几台机器、已经在跑 Agent，缺的是把它们拧成一股绳的那层调度。两者甚至可以叠着用，PAIR 官方支持的 Ollama 和 LM Studio 正是这类本地栈里的常见引擎。

家里的第二台机器，从今天起有了新工作。

---

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。