NVIDIA PAIR는 집에 있는 GPU를 합쳐주지 않는다

NVIDIA가 Personal AI Router(PAIR)를 Apache-2.0으로 공개했다. "집 안의 여러 컴퓨터에 로컬 추론을 분산한다"는 설명 때문에, 맥미니 몇 대를 묶어서 큰 모델을 올리는 그림을 떠올리기 쉽다. 그런 도구가 아니다.

PAIR가 푸는 병목은 VRAM이 아니라 큐다. 로컬 추론이 막혀 있다면 먼저 내 병목이 둘 중 어느 쪽인지부터 구분해야 한다. 모델이 메모리에 안 올라가서 막힌 거라면 PAIR는 답이 아니다.

확인된 것

README에 예외적으로 명확하게 적혀 있다.

PAIR routes each independent request to one node. It does not pool GPU memory, combine GPUs into a larger logical GPU, shard one model across machines, or split an in-flight inference request between nodes.

— NVIDIA/Personal-AI-Router README

정리하면 이렇다.

• 요청 하나는 노드 한 대에서 시작해서 그 노드에서 끝난다. 수명 동안 이동하지 않는다.
• 엔진은 Ollama와 LM Studio. 리눅스에서는 vLLM, SGLang도 지원한다.
• 앱 쪽에는 OpenAI/Ollama 호환 엔드포인트 하나로 보인다. 클라이언트 코드는 안 고쳐도 된다.
• Windows 11 / Linux / macOS, x64와 arm64를 섞어서 한 클러스터로 묶을 수 있다.
• 노드 연결은 6자리 PIN.
• 라이선스 Apache-2.0. 추론 엔진과 모델 라이선스는 별개.

스케줄링 정책도 문서가 스스로 한계를 적어뒀다. 큐에 쌓인 작업량 + 거칠게 평활한 GPU 사용률 신호, 이 두 가지만 본다. GPU 종류도, 남은 메모리도, 모델이 이미 올라와 있는지(warm)도, 요청이 무거운지도 보지 않는다. 그래서 문서는 성능이 비슷한 머신끼리 묶는 쪽을 권한다.

NVIDIA가 낸 수치는 하나다. 서브에이전트 5개짜리 작업이 RTX Spark 노트북 한 대에서 18분, RTX Spark + DGX Spark + RTX 5090 3대 클러스터에서 8분 48초. (NVIDIA 기술 블로그)

내 판단

1. 2.05배는 상한에 가까운 수치이고, 일반화되지 않는다.

3대로 2.05배. 나쁘지 않아 보이지만 조건을 보면 이 워크로드는 PAIR에 가장 유리하게 짜인 형태다. 이미 5개로 쪼개져 있고, 서로 독립적이고, 동시에 던질 수 있다. 5개를 3대에 나누면 최소 2라운드가 필요하니 이론 상한이 대략 2.5배다. 즉 2.05배는 "잘 나온 케이스"지 평균이 아니다.

내 파이프라인이 순차라면 — 1단계 결과를 받아야 2단계를 던지는 구조라면 — 이득은 0이다. 노드를 3대로 늘려도 한 번에 한 요청만 돌기 때문이다. 단일 요청의 응답 시간은 PAIR로 절대 줄어들지 않는다. 대화형 코딩 어시스턴트처럼 내가 한 번에 하나씩 물어보는 용도라면 얻는 게 없다.

2. 벤치마크 구성이 자기 권고와 어긋난다.

문서는 비슷한 성능의 머신끼리 묶으라고 하는데, 정작 대표 수치는 RTX Spark + DGX Spark + RTX 5090이라는 이기종 3대에서 나왔다. 두 문장 다 NVIDIA가 쓴 것이다. 판단은 내가 한다 — 저 정책으로 이기종을 묶으면 느린 노드에 무거운 요청이 꽂히는 경우가 생기고, 그때 전체 체감 시간은 가장 느린 노드가 정한다. 벤치마크 숫자를 내 집 구성(5090 한 대 + 맥미니 두 대 같은)에 그대로 옮겨 기대하면 안 된다.

3. 그래서 실제로 해야 할 일은 도구 설치가 아니라 측정이다.

동시성 1로 던졌을 때와 동시에 N개 던졌을 때의 p50 응답 시간을 비교해보면 된다. N을 올릴 때 선형에 가깝게 나빠지면 큐 병목이고, PAIR가 정확히 그 문제를 푼다. 동시성 1에서 이미 느리거나 모델 로드부터 실패하면 VRAM 병목이고, 그땐 양자화를 낮추거나 모델을 줄이거나 클라우드로 빼는 게 맞다. PAIR를 깔아도 그 노드 한 대의 한계는 그대로다.

모르는 것

• 노드가 4대, 6대로 늘어날 때 스케줄러가 어떻게 버티는지에 대한 수치는 없다. 공개된 건 3대 사례 하나뿐이다.
• 라우터 자체가 추가하는 오버헤드(디스커버리, 프록시 홉)가 짧은 요청에서 얼마나 비중을 차지하는지도 공개되지 않았다.
• 6자리 PIN 페어링이 홈 네트워크를 공유하는 환경에서 충분한지는 내가 판단할 근거가 없다. 다만 이 도구를 깐다는 건 로컬 네트워크에 인증 약한 추론 엔드포인트를 하나 여는 일이라는 점은 분명하다. 공용 와이파이나 여러 사람이 쓰는 망이라면 넣기 전에 한 번 생각할 값어치가 있다 — 이건 확인이 아니라 내 추측이다.

한 문장

PAIR는 "GPU를 합쳐주는 도구"가 아니라 "여러 요청을 여러 대로 흩어주는 도구"다. 내 워크로드가 이미 병렬로 쪼개져 있지 않다면, 이 소식으로 바뀌는 건 아무것도 없다.