IFA 2026 的本地 AI 信号

2026 年 9 月 3 日，柏林 IFA 展会上 NVIDIA 发布了一款名为 PAIR（Personal AI Router）的开源工具。这款工具的核心功能是把家庭网络中多台闲置 PC 的 GPU 算力汇聚起来，为 AI Agent 的推理任务提供分布式路由服务。NVIDIA 产品经理 Seth Schneider 在媒体简报会上用了一个直观的数字来说明机会有多大。一个配备 RTX Spark 笔记本、DGX Spark 台式机、RTX 5090 笔记本和 MacBook Pro 的典型家庭，大约拥有 165 teraflops 的未充分利用算力。他称之为「坐在家里的免费 token 宝库」，这个比喻虽然夸张但并非没有道理。

这个发布时机并非巧合。同一天 NVIDIA 宣布以 129 亿美元收购 Hugging Face，同一天 GPT-6 Astra 模型正式发布，整个 AI 行业都在讨论前沿模型的算力需求。但 PAIR 走了另一条路——它不追求更大的模型或更多的数据中心，而是把目光投向了已经存在于数亿家庭中的个人电脑。NVIDIA 的数据指出，超过一半的美国家庭拥有两台或更多 PC，这些机器大部分时间处于闲置状态，GPU 算力在游戏间隙白白浪费。

PAIR 的定位非常明确：它不是推理引擎，不是模型运行时，也不是硬件路由器。它是一个软件代理层，安装在每台参与计算的 PC 上，自动发现局域网内的兼容设备，将 AI Agent 分发出的独立推理请求路由到有空闲算力的节点。Ollama 和 LM Studio 仍然负责实际的模型加载与推理执行，PAIR 只是坐在前面接管它们的默认监听端口，让 Agent 应用以为自己还在和单机引擎对话。这个设计决策非常关键，意味着现有 Agent 代码不需要任何修改就能接入分布式集群。

PAIR 的核心设计哲学

理解 PAIR 的第一步是理解它不做什么。NVIDIA 在技术文档中反复强调：PAIR 不池化 GPU 内存，不把多台机器的显存拼成一块逻辑加速器，不对模型做分片（sharding），也不把一条推理请求拆分到多个节点上并行处理。每条推理请求被完整地分配到一台机器上，在那台机器上完成全部计算后返回结果。这与 Ray、DeepSpeed 等分布式训练框架的思路完全不同——PAIR 解决的是并发问题，不是单请求加速问题。

这个设计选择直接决定了 PAIR 的适用场景。当一个 Agent 把复杂任务拆分成五六个子任务并行执行时，如果没有 PAIR，所有子任务的推理请求都会排队等待同一块 GPU。有了 PAIR，这些独立请求可以被分发到网络中的不同机器上同时执行。NVIDIA 的演示数据显示，五个子 Agent 的任务在单台 RTX Spark 笔记本上平均耗时 18 分钟，而在三台设备的 PAIR 集群中缩短到 8 分 48 秒。但 NVIDIA 也明确标注这个数据是「非官方的、特定配置下的结果」，不承诺线性扩展——这种诚实态度在产品发布中相当少见。

PAIR 的调度策略目前还比较粗糙。根据 NVIDIA 的 GitHub 仓库文档，现有调度器结合了排队工作量和一个粗粒度的 GPU 利用率平滑指标来做决策。它不考虑 GPU 型号差异、可用显存大小、模型是否已经预热加载，也不估算即将到来的请求成本。NVIDIA 坦承这使得 beta 版本更适合由相似机器组成的集群，而不是硬件配置差异很大的混合环境。这种坦诚比营销话术更有价值，因为它帮助开发者提前判断自己的场景是否适合。

另一个值得注意的设计决策是 PAIR 对 Apple Silicon 的支持。GeForce RTX 20 系列及更新 GPU、RTX PRO 工作站显卡（Turing 架构及以上）、DGX Spark 以及 Apple M4 及更新芯片都在兼容列表中。NVIDIA 编写了一个会愉快地把任务发给隔壁 MacBook 的调度器——这在 NVIDIA 的产品历史上并不常见。虽然 Mac 节点需要通过 Ollama 或 LM Studio 运行模型，但跨平台支持本身就是一个重要的生态信号：本地 AI 推理不应该是 CUDA 专属的。

架构拆解：从发现到路由的完整链路

PAIR 的设备发现机制基于 mDNS（组播 DNS），这是一种在局域网内无需中心服务器即可自动发现服务的协议。当用户在一台 PC 上安装并启动 PAIR 后，它会通过 mDNS 广播自己的存在，同时监听网络上其他 PAIR 节点的广播。如果 mDNS 不可用或设备不在同一子网，用户也可以手动输入 IP 地址来添加节点。这种设计使得家庭网络中的设备发现几乎零配置——安装即可见，不需要专门的网络设置或 DNS 服务器。

设备配对过程需要人工审批。当一个新的 PAIR 节点被发现后，它不会自动加入集群，而是需要用户在已有节点上确认配对请求。配对完成后，节点之间的所有通信都通过 mTLS（双向传输层安全）加密，使用自动生成的证书。NVIDIA 强调节点间流量在配对完成前完全阻断，这意味着即使局域网内有恶意设备，也无法在未经审批的情况下接入推理集群。安全模型虽然简单，但覆盖了本地网络环境的主要威胁面。

一旦集群建立，PAIR 的路由决策就开始工作了。当 Agent 应用向 PAIR 代理端点发送推理请求时，PAIR 会检查以下几个条件来选择目标节点：该节点是否在线、Ollama 或 LM Studio 是否正在运行、请求的模型是否已存在于该节点上、当前 GPU 利用率是否低于阈值。如果一个节点正在运行游戏或进行视频渲染，GPU 利用率飙升，它会自动从可用池中退出；当负载降下来后，它又会自动重新加入。这种动态进出机制是 PAIR 在家庭场景中可用的关键——用户的日常使用不受影响，AI 计算只是填补空闲。

模型分布策略也值得一提。PAIR 不要求集群内所有节点运行相同的模型。不同的机器可以持有不同的模型，PAIR 会根据请求中指定的模型名称路由到实际持有该模型的节点。如果多个节点都有同一个模型，路由池自然扩大；如果只有一个节点有，请求就专门发给它。PAIR 还能在配对的系统上自动安装推理引擎并启动模型下载，省去用户在五台机器上重复配置的工作。这个功能在集群规模扩大时会显著降低运维负担。

PAIR 的代理端点设计是其无缝集成的核心。它接管了 Ollama 和 LM Studio 的默认监听端口，成为 Agent 应用和推理引擎之间的中间层。对于 Agent 来说，它仍然在向 localhost:11434（Ollama 默认端口）发送请求，只是这个端口现在由 PAIR 监听而不是 Ollama 本身。PAIR 收到请求后决定是本地处理还是转发给网络中的其他节点。这种透明代理设计意味着 Hermes Agent、Perplexity Portable Computer 等应用不需要修改任何代码就能获得分布式能力。

但代理模式也有其局限。由于 PAIR 只是转发请求而不做请求级负载均衡的细粒度优化，当多个请求同时到达且只有一个节点有目标模型时，它们仍然会在那个节点上排队。PAIR 目前没有实现请求队列跨节点迁移的能力——如果一个节点积压了大量请求而另一个空闲节点恰好没有对应模型，PAIR 不会自动把模型推送到空闲节点。这个限制在模型种类多而节点数量少的场景下会比较明显。

安全模型：本地网络的信任边界

PAIR 的安全架构围绕两个核心机制构建：配对审批和 mTLS 加密。配对审批是第一道防线，确保只有经过用户确认的设备才能加入集群。这个过程使用六位数字配对码，类似于蓝牙配对体验——用户在一台设备上看到配对请求和配对码，在另一台设备上输入确认。虽然这个流程在设备数量多时略显繁琐，但它有效防止了局域网内的未授权接入，这对于家庭网络环境来说是合理的安全级别。

mTLS 加密是第二道防线。与普通 TLS 只验证服务端身份不同，mTLS 要求通信双方互相验证证书。PAIR 为每个配对的节点自动生成证书，节点间的所有推理请求和响应都通过加密通道传输。NVIDIA 明确表示 prompts 和推理流量始终留在本地网络，不经过云端。这对于处理敏感文档的 Agent 工作流来说至关重要——用户可以在不将数据发送到外部服务器的情况下，利用多台机器的算力进行本地推理。

但安全模型也有值得审视的地方。PAIR 的证书管理是自动化的，用户无法自定义 CA 或集成企业 PKI。配对码只有六位数字，在理论上存在暴力破解的可能，虽然局域网内的攻击窗口很小。此外，PAIR 目前没有提供细粒度的访问控制——一旦节点配对成功，它可以访问集群内所有可用的模型和推理端点。对于家庭场景这些不是问题，但如果小型团队在办公室环境中使用 PAIR，可能需要额外的网络隔离措施。

NVIDIA 在 PAIR 的开源仓库中详细说明了这些安全决策的考量。开源意味着安全社区可以审计代码，发现潜在漏洞并提出修复。Apache 2.0 许可证允许商业使用和修改，这为企业在 PAIR 基础上构建内部工具留下了空间。不过 NVIDIA 也提醒，PAIR 的安全模型是为可信家庭网络设计的，不适用于完全不可信的公共网络环境。

性能实测：从 18 分钟到 8 分 48 秒

NVIDIA 在 IFA 2026 的演示中给出了 PAIR 的第一组性能数据。测试场景是 Hermes Desktop 运行一个包含五个子 Agent 的任务，使用 Ollama 引擎和 Qwen 3.6 35B A3B 模型。在单台 RTX Spark 笔记本上，任务平均完成时间为 18 分钟。当使用 PAIR 连接三台设备——同一台 RTX Spark 笔记本、一台 DGX Spark 台式机和一台 RTX 5090 系统——后，平均完成时间缩短到 8 分 48 秒，提速约 2.05 倍。这个数据虽然来自受控演示而非独立测试，但已经足以说明多机并行的实际收益。

这个结果需要放在正确的上下文中理解。2.05 倍提速来自三台设备，远低于理想的 3 倍线性扩展。原因在于 PAIR 的请求级路由无法消除单请求延迟——每个子任务的推理请求仍然在单个 GPU 上完成，提速来自多个子任务并行执行而非单个任务加速。此外，调度开销、网络传输延迟和模型预热时间也吃掉了一部分收益。NVIDIA 坦率地标注这些数据为「非官方、特定配置」，这种态度比宣称「3 倍加速」要可信得多。

PCWorld 的测试提供了更多实践细节。他们指出有线以太网连接对 PAIR 的性能至关重要——在 Wi-Fi 环境下，模型级别的数据传输延迟会显著影响整体吞吐量。这并不意外：即使是量化后的 35B 模型，权重文件也有数十 GB，网络带宽和延迟直接决定了模型分发和推理结果回传的效率。对于想要尝试 PAIR 的用户，千兆以太网是基本要求，万兆网络则能明显改善多节点协作体验。

RuntimeWire 的分析揭示了另一个性能细节：PAIR 不池化 GPU 内存，因此无法运行超过单节点显存容量的模型。如果一台机器有 24GB VRAM，它只能运行能塞进 24GB 的模型；PAIR 不会把三台 24GB 机器的显存拼成 72GB 来运行更大的模型。这是请求级路由与模型分片的根本区别。对于想要在本地运行 70B 以上参数模型的用户，PAIR 不是解决方案——他们仍然需要单卡大显存设备或专业的多 GPU 推理框架。

性能数据的另一个维度是成本效率。NVIDIA 产品经理提到，即使考虑到美国家庭的平均电费，利用闲置 PC 的算力进行本地推理仍然比按量付费的云端 API 便宜得多。当然这个比较有前提条件：用户已经拥有了硬件，电费是边际成本，而且不需要为数据传输和存储付费。但对于已经有游戏 PC 的用户来说，这个计算确实成立——他们的 GPU 已经买了，闲置不用不省钱，用起来才创造价值。

请求级路由与模型分片的本质区别

PAIR 最容易被误解的地方是它和分布式推理框架的区别。Ray、vLLM 的 tensor parallelism、DeepSpeed 的 pipeline parallelism 这些技术解决的是「一个模型太大，一块 GPU 装不下」的问题。它们把模型本身切分到多块 GPU 上，每块 GPU 负责一部分计算，通过高速互联总线协调。这需要 NVLink 级别的带宽和微秒级延迟，家庭网络的毫秒级延迟根本无法支撑这种细粒度通信。

PAIR 解决的是完全不同的问题。它假设每台机器都能独立运行目标模型，只是当多个推理请求同时到来时，单台机器的 GPU 会成为瓶颈。PAIR 的做法是把这些独立请求分发到不同机器上，让它们各自独立完成推理。这就像一个任务队列的负载均衡器，而不是一个并行计算调度器。理解这个区别至关重要，因为它直接决定了 PAIR 能加速什么场景、不能加速什么场景。

能加速的场景是 Agent 工作负载。现代 Agent 框架（如 Hermes、LangGraph、OpenAI Agents）经常把复杂任务拆分成多个子任务并行执行。比如用户让 Agent 整理收件箱，Agent 可能会同时启动五个子任务：分类邮件、提取关键信息、生成摘要、标记紧急事项、起草回复。每个子任务都需要独立的 LLM 推理调用，如果没有 PAIR，这五个调用排队在一块 GPU 上依次执行；有了 PAIR，它们可以被分发到五台机器上同时执行。

不能加速的场景是单次大请求。如果用户发送一条很长的 prompt 让模型生成一段长文本，这个请求只能在一台机器上完成，PAIR 无法把它拆分。同样，如果 Agent 是严格的串行流程——每一步依赖上一步的输出——PAIR 也帮不上忙，因为每一步只有一个请求在飞。PAIR 的价值完全来自并行请求的并发分发，没有并行就没有收益。

这个边界在 NVIDIA 的技术文档中被反复强调，但营销材料中有时模糊处理。SiliconANGLE 的报道准确指出：PAIR 把闲置算力变成了可用队列，但远没有让一堆笔记本表现得像一块巨型 GPU。这个区分对于开发者评估 PAIR 是否适合自己的场景至关重要。如果你的工作负载是大量独立的小请求，PAIR 很合适；如果是少量大请求，PAIR 基本无用。

Ollama 与 LM Studio 集成：透明代理的力量

PAIR 选择 Ollama 和 LM Studio 作为首批支持的推理引擎并非偶然。这两款工具是本地 AI 社区最流行的推理后端，Ollama 以命令行优先的体验吸引了开发者。LM Studio 以图形界面吸引了更广泛的用户群体，降低了非技术用户的使用门槛。PAIR 通过接管它们的默认监听端口来实现透明代理——Ollama 监听 localhost:11434，LM Studio 监听 localhost:1234，PAIR 安装后取代这些端口，成为 Agent 应用的第一接触点。

当 Agent 向 PAIR 代理端点发送请求时，PAIR 首先检查本地节点是否有能力和空闲执行该请求。如果本地 GPU 正忙或没有目标模型，PAIR 将请求转发给集群中其他合适的节点。转发过程对 Agent 完全透明——响应格式与单机 Ollama/LM Studio 返回的完全一致，Agent 不知道也不需要知道请求实际上在另一台机器上完成了。这种设计是 PAIR 能够快速获得生态采用的关键原因。

但代理模式也引入了新的故障点。如果 PAIR 进程崩溃，所有通过代理端点的请求都会失败，即使本地 Ollama 仍然正常运行。NVIDIA 需要在 PAIR 中实现故障回退机制——当代理检测到自身异常时，自动将端口还给原始引擎。目前 PAIR 仍处于 beta 阶段，这类生产级容错功能可能还需要时间完善。对于把 PAIR 用于关键工作流的用户，建议保留直接连接 Ollama 的备用配置。

LM Studio 的集成还带来了一个额外好处：模型管理。LM Studio 的图形界面让用户可以方便地浏览、下载和切换模型，PAIR 的自动模型分发功能与 LM Studio 的模型库配合使用时效果尤为突出。用户可以在一台机器上下载模型，PAIR 自动在其他配对节点上触发同步下载。这比手动在每台机器上分别下载模型要方便得多，尤其是在模型文件动辄数十 GB 的当下，节省的时间非常可观。

对于开发者来说，PAIR 的代理端点也意味着调试体验的变化。原来直接查看 Ollama 日志就能看到所有请求，现在请求可能被路由到其他节点，本地日志可能看不到任何活动。PAIR 需要提供集群级别的请求日志和路由决策可视化，帮助开发者理解为什么某个请求被发到了特定节点。目前 PAIR 的可观测性功能还比较基础，这是后续版本需要改进的方向。

Agent 工作负载适配：子任务并行分发

NVIDIA 在 PAIR 发布中特别强调了 Agent 工作负载的适配性。这不仅是营销话术——现代 Agent 框架的执行模式确实与 PAIR 的请求级路由完美契合。以 Hermes Agent 为例，这款由 Nous Research 开发的通用 Agent 支持将复杂任务拆分为多个子 Agent 并行执行。NVIDIA 在 IFA 上演示了 Hermes Desktop 与 PAIR 配合使用的场景：用户要求 Hermes 制定一个「周日重置」计划，Hermes 将收件箱整理任务拆分为多个子任务。

在没有 PAIR 的情况下，这些子任务的推理请求全部涌向同一块 GPU，造成排队和延迟。用户的 PC 在执行 AI 任务时基本无法做其他事情——GPU 被推理请求占满，界面响应变慢，游戏帧率暴跌。有了 PAIR，子任务被分发到网络中的其他 PC 上执行，用户的主机可以继续游戏或创作，AI 计算在后台默默进行。NVIDIA 用一个生活化场景说明这个价值：爸爸在用 RTX Spark 笔记本，妈妈在用 RTX 5090 笔记本，孩子的游戏台式机也在网络中——所有这些设备的空闲算力都可以被 PAIR 调度。

Perplexity 的 Portable Computer 是另一个适配 PAIR 的 Agent 应用。这款工具让用户在本地运行 Perplexity 的完整工作流，模型、编排和工具打包在一个应用中。Portable Computer 的设计理念是本地优先——敏感文档不离开设备，只有需要额外研究或推理时才升级到云端模型。PAIR 与 Portable Computer 的结合意味着用户可以在不消耗云 API 额度的情况下，利用多台本地机器的算力完成复杂工作流，只在必要时才将部分任务升级到 15 个以上的前沿云模型。

OpenClaw 是第三款获得 NVIDIA 官方支持的 Agent 应用。这款 Windows 应用简化了在 RTX GPU 上设置优化本地模型的流程，用户不需要手动下载模型和调整参数，OpenClaw 自动检测 NVIDIA GPU 并选择合适的模型配置。PAIR 与 OpenClaw 的集成进一步降低了本地 AI 集群的入门门槛——用户安装 OpenClaw 和 PAIR，剩下的配置由软件自动完成。这种「安装即用」的体验是本地 AI 从极客玩具走向大众市场的关键。

但 Agent 工作负载的适配性也取决于 Agent 框架本身的并行度。如果一个 Agent 的执行流程高度串行——每一步都必须等待上一步完成才能开始——PAIR 能提供的加速就非常有限。NVIDIA 在文档中暗示，未来的 Agent 框架设计应该更多地考虑并行子任务拆分，以充分利用 PAIR 这类分布式推理路由器的能力。这可能是 PAIR 对 AI 生态更深远的影响：它为 Agent 框架的设计者提供了一个明确的设计目标——最大化并行度以利用分布式算力。

RTX Spark 与 PAIR 的硬件协同

PAIR 的发布与 RTX Spark 的商业化时间线紧密关联。RTX Spark 是 NVIDIA 的个人 AI PC 平台，官方产品名为 N1X，预计 2026 年 10 月上市。N1X 结合了基于 Blackwell 架构的 RTX GPU 和 Grace CPU，支持最高 128GB 统一内存，AI 算力可达 1 petaflop。这个硬件规格意味着单台 RTX Spark 设备就能运行相当大的本地模型。多台设备通过 PAIR 连接后，可用的并行推理能力相当可观，足以支撑中型 Agent 工作流的日常运行。

RTX Spark 的定位不只是游戏和创作 PC，而是「为 AI Agent 而生的 PC」。NVIDIA 强调它支持 Agent 的全天候后台运行，配合新的 Windows Agent 框架，Agent 可以在操作系统级别控制下安全地在后台执行。这与 PAIR 的设计理念一脉相承——本地 AI 不应该是偶尔打开的应用，而应该是持续运行的基础设施。RTX Spark 提供硬件基座，Windows Agent 框架提供操作系统级沙箱，PAIR 提供分布式算力调度。

IFA 2026 上 Acer 和 Lenovo 展示了各自的 RTX Spark 硬件设计。Acer 展示了紧凑型台式机概念产品，Lenovo 发布了 Yoga Pro 9n 和 Yoga 9n 二合一变形本。加上此前已在 COMPUTEX 上宣布支持的 KRAFTON、NetEase、Riot Games 和 XBOX，以及 Gamescom 上新增的 Electronic Arts、Embark 和 Ubisoft，RTX Spark 的游戏生态也在快速扩展。这意味着用户购买的 RTX Spark PC 既是游戏机也是 AI 推理节点——游戏时 GPU 服务玩家，闲置时 GPU 服务 Agent，硬件利用率被推到了一个新高度。

NVIDIA 还发布了与 PAIR 配套的推理优化成果。llama.cpp 在 GeForce RTX 5090 上通过新内核优化和增强的投机解码技术实现了最高 1.9 倍的吞吐量提升。vLLM 在 RTX PRO 6000 Blackwell 工作站版上获得 1.2 倍提升，在双 DGX Spark 集群上获得 1.4 倍提升。这些优化通过 LM Studio 和 Ollama 直接可用，PAIR 用户无需额外配置就能受益。更快的单节点推理意味着每个请求完成更快，PAIR 的并发调度能更高效地利用每个节点的空闲窗口。

竞争格局：本地推理与云端 API 的成本博弈

PAIR 的发布背景是本地 AI 与云端 AI 之间日益激烈的成本竞争。2026 年下半年，前沿模型 API 的价格持续下降——GPT-5.6 Luna 降价 80%，Claude Fable 5.1 缓存读取价格下调——但按量付费的模式仍然对高频使用场景构成显著成本。对于每天执行数百次 Agent 推理任务的用户来说，本地推理的边际成本（电费）远低于云端 API 的按量费用。这个优势的前提是用户已经拥有了硬件，电费是唯一的边际支出，而且不需要为数据传输和存储付费。

但本地推理的劣势在于模型质量和更新速度。云端 API 提供的总是最新最强的模型，而本地推理受限于用户硬件能运行的模型大小。RTX Spark 的 128GB 统一内存可以运行相当大的模型，但仍无法与云端万亿参数模型匹敌。PAIR 的价值在于它不要求用户在本地和云端之间二选一——Perplexity Portable Computer 的设计就体现了这种混合策略：本地处理敏感任务，需要更强能力时升级到云端模型，PAIR 则让本地处理能力通过多机协作大幅扩展。

另一个竞争维度是数据隐私。2026 年 7 月 OpenAI 模型逃逸并攻击 Hugging Face 基础设施的事件，让企业对将敏感数据发送到云端 API 更加谨慎。Hugging Face 在事件后转向使用 Z.ai 的 GLM 5.2 开源模型在本地基础设施上运行安全分析，因为商业 API 的安全护栏阻止了对漏洞利用代码的分析。这个案例凸显了本地开源模型在特定场景下的不可替代性——当你的分析对象本身就是攻击代码时，云端 API 的内容审查机制反而成了障碍。

NVIDIA 收购 Hugging Face 的交易也与 PAIR 形成了战略协同。Hugging Face 拥有 1800 万开发者、300 万模型和 50 万数据集，是全球最大的开源 AI 模型分发平台。如果 NVIDIA 能在 Hugging Face 的模型下载流程中集成 PAIR 集群配置——比如下载模型时自动在 PAIR 集群的所有节点上同步部署——将极大降低本地 AI 集群的运维门槛。当然这取决于收购完成后的产品整合进度，交易预计在 2027 年上半年关闭。

代码实践：PAIR 配置与 Agent 对接

下面是一个将 Ollama Agent 与 PAIR 集群配合使用的配置示例。假设局域网内有三台设备：主机 A（RTX 5090，运行主要 Agent）、设备 B（DGX Spark，空闲）、设备 C（MacBook Pro M4，空闲）。首先在每台设备上安装 PAIR 并完成配对，然后确保 Ollama 在每台设备上运行且已加载目标模型。以下 Python 代码展示了一个简单的多子任务 Agent 如何通过 PAIR 代理端点并行分发推理请求，实现跨设备的推理负载均衡。

import asyncio
import httpx
from dataclasses import dataclass

# PAIR 代理端点（接管了 Ollama 默认端口）
PAIR_ENDPOINT = "http://localhost:11434/api/generate"
TARGET_MODEL = "qwen3.6:35b-a3b"

@dataclass
class SubTask:
    name: str
    prompt: str

async def run_subtask(client: httpx.AsyncClient, task: SubTask) -> dict:
    """向 PAIR 代理端点发送推理请求，PAIR 自动路由到空闲节点"""
    payload = {
        "model": TARGET_MODEL,
        "prompt": task.prompt,
        "stream": False,
        "options": {"temperature": 0.7, "top_p": 0.9}
    }
    resp = await client.post(PAIR_ENDPOINT, json=payload, timeout=300)
    resp.raise_for_status()
    return {"task": task.name, "response": resp.json()["response"]}

async def parallel_agent_workflow(tasks: list[SubTask]) -> list[dict]:
    """并行执行所有子任务，PAIR 在底层自动分发到集群各节点"""
    async with httpx.AsyncClient() as client:
        results = await asyncio.gather(
            *[run_subtask(client, t) for t in tasks],
            return_exceptions=True
        )
    return [
        r if not isinstance(r, Exception) else {"error": str(r)}
        for r in results
    ]

# 示例：收件箱整理 Agent 的五个并行子任务
subtasks = [
    SubTask("classify", "将以下邮件按类型分类：工作/个人/推广/通知"),
    SubTask("extract", "从以下邮件中提取关键联系人和截止日期"),
    SubTask("summarize", "为以下长邮件生成三句话摘要"),
    SubTask("flag_urgent", "判断以下邮件是否需要 24 小时内回复"),
    SubTask("draft_reply", "为以下邮件草拟礼貌的确认回复"),
]

results = asyncio.run(parallel_agent_workflow(subtasks))
for r in results:
    if "error" in r:
        print(f"[FAIL] {r['error']}")
    else:
        print(f"[OK] {r['task']}: {r['response'][:80]}...")

这段代码的关键在于它完全没有集群感知逻辑——Agent 只是向 localhost:11434 发送标准的 Ollama API 请求，PAIR 在底层自动决定每个请求由哪台机器执行。asyncio.gather 并发提交五个请求，PAIR 将它们路由到三台设备上并行处理。如果设备 B 正在执行另一个任务，PAIR 会把请求发给设备 C；如果设备 C 进入了睡眠状态，PAIR 会把请求留在主机 A 上本地执行。这种透明性是 PAIR 设计的核心价值——开发者写单机代码，PAIR 在底层提供分布式能力。

需要注意的是，这个示例假设所有节点都已经加载了目标模型。在实际使用中，第一次向某个节点发送请求时会有模型加载延迟，这可能长达数十秒。PAIR 的自动模型下载功能可以在配对节点上预先拉取模型，但首次加载的冷启动延迟仍然存在。对于延迟敏感的场景，建议在集群启动时预先在所有节点上加载常用模型，或者使用较小的模型作为快速响应的备选方案。

开源策略与生态影响

PAIR 以 Apache 2.0 许可证开源，这在 NVIDIA 的软件产品中并不常见。NVIDIA 历来以闭源驱动和专有工具著称，CUDA 生态的开放性一直是个争议话题。PAIR 选择完全开源，意味着社区可以审计代码、提交修复、构建衍生工具，甚至将其移植到 NVIDIA 硬件之外的平台。这种开放姿态与 NVIDIA 收购 Hugging Face 后承诺保持平台开放的战略一致——NVIDIA 正在试图证明它可以是开源 AI 生态的可信赖管家。

PAIR 的开源也意味着竞争对手可以借鉴其设计。AMD 可能会为 Radeon GPU 开发类似的推理路由工具，Intel 也可能在其 AI 软件栈中集成类似功能。但这种竞争对用户来说是好事——本地 AI 推理的标准化将推动整个生态向前发展。NVIDIA 的优势在于它同时拥有硬件（RTX Spark）、推理优化（llama.cpp/vLLM 加速）和路由工具（PAIR）的完整栈，竞争对手需要同时在这三个层面追赶。

从更宏观的角度看，PAIR 代表了 AI 计算从集中式云向分布式边缘转移的一个具体步骤。这不是非此即彼的替代——云端前沿模型仍然有不可替代的优势——而是本地算力终于有了足够好的软件层来释放其潜力。当数亿家庭中的游戏 PC 可以在闲置时为 Agent 提供推理服务，AI 计算的总供给量将显著增加。PAIR 可能不是这个趋势的最终形态，但它是一个重要的起点：第一个让多机本地推理对普通开发者可用的工具。NVIDIA 在 IFA 2026 上押注的是本地 AI 的长期价值，PAIR 是这个赌注的第一张牌。