NVIDIA PAIR 评测：本地 AI 路由与 AMD ROCm 支持缺口

NVIDIA Personal AI Router（PAIR）是为彼此独立的 AI 推理请求设计的本地控制平面。它会发现网络中的电脑，检查每个节点能够提供的 engine 与模型，观察任务负载和 GPU 压力，再把每个新请求转发给一个合格节点。智能体仍然连接熟悉的 Ollama 或 OpenAI 兼容 endpoint。

可以把它想成管理家中一堆 AI 电脑的 Kubernetes，但要加一个重要限定。PAIR 不是容器编排器，不会汇集 VRAM，也不会把多块 GPU 变成一块巨型 GPU。它把完整推理任务放到完整模型副本上。这很适合五个子智能体同时抢一块 GPU 的情况，就像鸽子争一根薯条。它不能让一个过大的模型突然跨五台机器运行。

对于刚推出的 Beta，PAIR 的架构出奇清晰，缺口也同样明显。NVIDIA 验证了 RTX、DGX Spark 和 Apple M4+，却没有 AMD Strix Halo。我因此给编程智能体一个具体任务：添加 ROCm 10 与 Strix Halo 支持。文章发布时，这仍是工程工作流，并非上游正式支持。本文会说明 PAIR 已经能做什么、源代码如何处理 AMD，以及一个可信移植在采购硬件前必须证明什么。

NVIDIA PAIR 是什么？

NVIDIA PAIR 开源仓库面向同一网络中的兼容 Windows、Linux 与 macOS 电脑。PAIR 发现节点、管理受支持的 engine，并提供兼容 Ollama 与 OpenAI 的代理 endpoint。仓库采用 Apache 2.0 许可证。发布的桌面程序通过 Electron 界面管理一组小型 Go 服务。

一个请求会经过以下路径：

1. 应用调用本机 PAIR 代理，通常仍使用原来预期的端口。
2. 代理解析 engine 与所请求的模型。
3. 没有运行该 engine 或没有准确模型的节点被排除。
4. 其余节点按照 scheduler 状态排序。
5. 一个节点执行完整请求，响应沿同一路径流式返回。

PAIR 官方架构文档把模型资格与负载排序分开。Scheduler 不感知模型，只按照待处理工作和由平滑 GPU 利用率转换而来的粗粒度压力值排序。代理随后只在声明拥有目标模型的节点上应用这个顺序。功能资格与当前压力由此保持清晰边界。

PAIR 会合并 GPU 或拆分一个模型吗？

不会。每个推理请求从开始到结束都在一个节点上运行。当工作负载包含独立调用时，PAIR 可以提高整体吞吐。它不能汇集 GPU 内存、切分模型层、拆分正在执行的请求，也不会在 dispatch 后迁移请求。

这一区分能避免关键词混淆和昂贵的架构误判。如果模型副本能够装进单台机器，瓶颈是排队，就选择 PAIR。如果模型本身装不下，需要的是模型并行。如果真正约束来自供应商策略、预算或云端回退，则应选择网关。

NVIDIA PAIR 能让多智能体快多少？

NVIDIA 的 PAIR 发布演示使用 Hermes Desktop、五个子智能体、Ollama 与 Qwen 3.6 35B A3B。官方报告称，一台 RTX Spark 笔记本平均需要 18 分钟，由该笔记本、DGX Spark 和 RTX 5090 组成的三设备集群平均需要 8 分 48 秒。

这代表该演示的总时间减少 51%，不是通用的 2 倍承诺。NVIDIA 明确把它称为非正式、特定配置的结果。并行程度、模型副本、engine 设置、网络、prompt 形态和节点可用性都会改变结果。正确的商业指标是目标延迟下每个验收任务的成本，而不是 PAIR 界面显示了多少块 GPU。

Scheduler 也有明确限制。GPU 型号、可用 VRAM、实测请求延迟、模型是否已加载以及预计请求大小都不参与评分。每个待处理 workload 都只算一个。在混合设备集群里，小 GPU 与大 GPU 如果利用率相同，会得到相同压力值。作为 Beta 这很合理，但企业试点必须建立自己的路由与尾延迟证据。

为什么 AMD Strix Halo 不是经过验证的 PAIR 节点？

答案比“PAIR 屏蔽 AMD”更复杂。PAIR 本身可以在受支持的 x64 操作系统上运行，Ollama 也已在 Linux GPU 表格中列出 Ryzen AI Max。真正缺少的是从硬件发现、遥测、engine 行为到支持政策的完整验证链。

NVIDIA 的 PAIR 已知问题页面说明，没有 NVIDIA 驱动的 Linux 机器可以按名称列出 AMD 或 Intel 图形设备，却不会显示 GPU 内存或利用率。Windows 上的集成或统一内存 GPU 可能显示过低数值，因为 PAIR 只统计专用 GPU 内存。NVIDIA 表示内存显示不会直接决定路由，但缺失的利用率会削弱 scheduler 对当前压力的判断。

源代码把 Linux 边界写得很清楚。Linux GPU 检测器首先调用 nvidia-smi。如果工具不存在，它会回退到通用 PCI 发现，只能得到适配器名称，没有 VRAM 总量、稳定遥测关联键或动态利用率。Windows 已使用厂商无关的 DXGI 与 Performance Data Helper 计数器。因此，最大的硬件专用缺口在 Linux 遥测和统一内存解释。

真正的 ROCm 10 与 Strix Halo 移植需要什么？

修改硬件 allowlist 远远不够。贡献需要在 AMD 工具缺失时保持现有行为，避免让遥测故障演变成路由故障，并真实表示 Strix Halo 的内存模型。

1. 用稳定标识发现 AMD 设备。AMD SMI CLI 支持 JSON 输出、UUID、BDF 地址、GFX 利用率与内存指标。Collector 可以可靠关联静态和动态样本，无需解析面向人的表格。
2. 限制采集时间。遵循现有 timeout、每秒后台采样、freshness 和最后有效值模式。卡死的驱动不能阻塞 node-info 服务。
3. 按统一内存的本质处理它。Strix Halo 的 gfx1151 GPU 共享大容量 LPDDR5X 池。只读专用 VRAM 会低估容量，而把全部系统内存当作可用值又会高估 engine 的安全分配能力。界面应标注数值来源。
4. 分开遥测与 engine 支持。PAIR 识别 AMD GPU 不等于 Ollama 或 LM Studio 能正确运行目标模型。版本、驱动、backend、上下文和模型架构仍是独立门槛。
5. 测试混合集群。覆盖 NVIDIA 与 AMD 共存、过期 AMD SMI 输出、工具缺失、真实零利用率、多适配器、休眠与重启，以及模型只存在于一个节点的情况。

ROCm 10.0.0 发布说明包含更多推理、工具与 profiling 工作，并改善 gfx1151 的 profiler 支持。这是有用基础设施，但 ROCm 主版本升级不是 PAIR 兼容证书。PAIR、AMD SMI、驱动、engine 和模型必须共同匹配。

Engine 层尤其需要谨慎。Ollama GPU 支持页面在 Linux 表格中列出 Ryzen AI Max+ 395、Max 390 与 Max 385，并记录 ROCm 和 Vulkan 两条路径。当前支持约定仍写 ROCm v7，而不是 ROCm 10。因此，ROCm 10 上的 PAIR 实验必须维护明确 engine 矩阵，不能假设遥测移植会自动升级推理 backend。

PAIR 足够保护企业私密数据吗？

当应用、engine、模型来源和节点都在本地时，PAIR 会让推理流量留在本地网络。已配对节点使用固定证书和双向 TLS。代理只从 loopback 接受明文请求，未配对机器不能以集群成员身份访问入口。

本地不等于不可见。架构文档说明，节点遥测使用未认证明文，因此同一子网里的机器可以读取 hostname、硬件清单和利用率。配对过程先通过明文传输短 PIN，再固定证书。应使用可信且分段的网络，检查防火墙暴露，保护每台机器，并避免在日志中记录敏感请求正文。处理受监管或客户数据时，还需要威胁建模、保留政策、补丁责任和事件响应流程。

企业什么时候应该使用 NVIDIA PAIR？

购买下一块 GPU 前的七步 PAIR 试点

1. 定义可验收任务。记录质量、工具调用正确性、上下文长度和 timeout，不只看每秒 token。
2. 测量单节点基线。记录排队、首 token、总完成时间、功耗和失败率。
3. 复制一个模型。把完全相同的模型放到两个节点上，让路由真正有选择。
4. 加入真实并发。重放实际工作流会产生的子智能体数量和组合。
5. 观察放置结果。确认 Jobs 界面、GPU 遥测与 engine 日志对执行节点的记录一致。
6. 主动破坏集群。让笔记本休眠、停止 engine、删除模型，并用其他应用占满 GPU。
7. 比较完整替代方案。在把闲置硬件当作免费资源之前，使用本地模型与 API 盈亏平衡框架。

如果试点处理专有代码或文档，应把路由决策与评估、访问控制和回滚连接起来。Twinsoft AI 案例研究展示了 AI 工作流如何成为生产系统，技术栈决策指南则避免一个有趣组件替整个架构做决定。

来源与方法

本文于 2026 年 9 月 4 日核对 NVIDIA 仓库、架构、发布演示和已知问题文档，以及上文链接的 AMD SMI、ROCm 10 与 Ollama 当前文档。我们检查了 Linux 和 Windows 遥测实现与 scheduler 源代码，但没有复现 NVIDIA benchmark，也不声称计划中的 AMD 工作已经合并、受支持或完成。产品支持变化很快，试点应固定 PAIR 版本、驱动、engine 与模型。