NVIDIA Personal AI Router（PAIR）现已进入 Beta 阶段。它的目标不是让某一张 GPU 突然拥有更多显存，而是把局域网中多台电脑的推理能力组织起来，自动将 AI 请求分发到合适的节点。对于会同时触发多个模型调用的本地多智能体系统，这种调度方式尤其有价值：规划、检索、编码和审查任务不必再排队挤占同一张 GPU。
PAIR 解决的是“请求拥塞”，不一定是“单模型太大”
理解 PAIR 时，需要区分两类问题：
- 单个请求放不下：模型本身超过一张 GPU 的显存，需要模型切分、量化、CPU 卸载或张量并行。
- 并发请求太多：每个模型或请求都能独立运行，但同时到达后会让一张 GPU 排队、爆显存或明显降速。
PAIR 主要针对后者。来源摘要强调，它面向本地多智能体 AI 工作负载，并将多个独立模型调用分配到局域网中的不同电脑。摘要没有说明 PAIR 会把单次推理跨机器切分，因此不应直接把它当作分布式训练框架或跨节点显存聚合方案。
一个典型的本地 Agent 流程可能同时包含：
- 规划模型拆解任务；
- 检索模型整理上下文；
- 代码模型生成实现；
- 审查模型检查结果；
- 嵌入模型更新本地知识库。
如果这些调用全部指向同一台工作站，即使每次推理都不大，也容易形成队列。PAIR 的价值在于把“该请求交给哪台机器”从 Agent 应用中剥离出来，让上层工作流面向一个统一的调度入口。
哪些环境更适合部署
PAIR 比较适合已经拥有多台本地计算设备的团队或个人实验室，例如：
- 一台高显存工作站负责较大的生成模型；
- 两台桌面电脑处理轻量模型、嵌入或重排序任务；
- 多个 Agent 并行运行，调用之间基本相互独立；
- 数据不希望离开内网，但单机 GPU 又成为并发瓶颈。
它不一定适合只有单一、串行请求的应用。若绝大多数时间只有一个模型调用，增加路由层反而会带来网络延迟、配置成本和新的故障点。
调度效果还取决于节点是否同构。不同电脑的 GPU、显存、模型副本和推理速度可能完全不同。简单轮询容易把大请求发给小显存节点，因此真正有用的路由器通常还需要感知节点能力、当前负载和模型可用性。来源摘要只确认 PAIR 会自动分发请求，没有披露具体调度策略，实际测试时应重点观察这些行为。
用一个最小代理验证多节点调度思路
下面的示例不是 PAIR 的官方 API 或配置，而是一个可以直接改造的验证工具。假设两台局域网电脑已经运行兼容 OpenAI Chat Completions 接口的本地模型服务，这个 Python 代理会把请求发送给当前进行中请求最少的节点。
先创建 requirements.txt：
fastapi==0.115.8
httpx==0.28.1
uvicorn[standard]==0.34.0
再创建 router.py：
import asyncio
import os
import httpx
from fastapi import FastAPI, Request
from fastapi.responses import Response
workers = [
item.rstrip("/")
for item in os.environ.get(
"WORKERS",
"http://192.168.1.21:8000,http://192.168.1.22:8000",
).split(",")
if item.strip()
]
if not workers:
raise RuntimeError("WORKERS must contain at least one model server")
app = FastAPI()
in_flight = {worker: 0 for worker in workers}
lock = asyncio.Lock()
client = httpx.AsyncClient(timeout=120.0)
async def acquire_worker() -> str:
async with lock:
worker = min(workers, key=lambda item: in_flight[item])
in_flight[worker] += 1
return worker
async def release_worker(worker: str) -> None:
async with lock:
in_flight[worker] -= 1
@app.post("/{path:path}")
async def proxy(path: str, request: Request) -> Response:
worker = await acquire_worker()
try:
upstream = await client.post(
f"{worker}/{path}",
content=await request.body(),
headers={"content-type": request.headers.get("content-type", "application/json")},
)
return Response(
content=upstream.content,
status_code=upstream.status_code,
media_type=upstream.headers.get("content-type"),
headers={"x-selected-worker": worker},
)
finally:
await release_worker(worker)
@app.on_event("shutdown")
async def shutdown() -> None:
await client.aclose()
将 WORKERS 中的地址改成实际模型服务器地址，然后启动代理：
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export WORKERS="http://192.168.1.21:8000,http://192.168.1.22:8000"
uvicorn router:app --host 0.0.0.0 --port 9000
发送一个测试请求：
curl -i http://127.0.0.1:9000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "local-model",
"messages": [
{"role": "user", "content": "Write a Python function that validates an IPv4 address."}
],
"stream": false
}'
响应头中的 x-selected-worker 可以帮助确认请求被分配到了哪个节点。并行执行多次 curl，就能观察多个独立请求是否被分散处理。
这个示例只用于理解和压测：它没有实现健康检查、认证、流式响应、失败重试、模型亲和性和显存感知调度。生产环境应由 PAIR 或成熟网关承担这些职责，而不是直接部署这个简化代理。
Beta 阶段应重点验证什么
引入 PAIR 前，可以建立一组贴近真实 Agent 工作流的测试，而不是只测单请求 token 速度：
- 并发吞吐：同时运行 5、10、20 个模型调用，记录整体完成时间。
- 尾延迟：观察 P95、P99 延迟，确认慢节点是否拖累任务链。
- 模型路由：检查请求是否只被发送到已加载对应模型的电脑。
- 节点故障：关闭一台机器后，确认新请求能否继续处理。
- 数据边界：确认提示词、检索文档和生成结果只在可信内网传输。
- 网络开销：大上下文请求可能受 Wi-Fi 或千兆网络限制，最好比较有线连接。
- 资源隔离：避免推理任务耗尽日常工作电脑的显存和系统内存。
还需要注意安全边界。局域网并不天然可信，模型端口和路由入口不应无认证地暴露给整个办公网络。至少应使用主机防火墙限制来源地址，并根据实际部署能力增加身份认证、TLS 和访问日志。
采用建议
PAIR 最值得尝试的场景，是“已有多台机器、已有并行 Agent、单机经常拥塞”。部署时先选择两个节点和一条真实工作流做小规模验证，测量引入前后的吞吐、尾延迟与失败率，再决定是否扩大资源池。
不要只看 GPU 利用率。对于多智能体系统，真正重要的是整条任务链能否更快、更稳定地完成。如果 PAIR 能让独立调用分散执行，同时保持模型选择正确、故障可控和数据不出内网，它就能把零散的个人计算设备变成一个更实用的本地 AI 推理池。