18분이 8분 48초가 됐다: NVIDIA PAIR는 노는 GPU를 엔드포인트 하나로 묶는다

책상 위에 노트북 한 대, 옆방에 게이밍 PC 한 대, 창고에 뜯지도 않은 미니 워크스테이션 한 대. 로컬 모델을 굴려 본 팀이면 익숙한 그림이다. 에이전트가 서브에이전트 다섯을 만들어 일을 쪼개는 순간 요청은 다섯 개가 된다. 실행 슬롯은 노트북 한 대에만 있다. 나머지 두 대는 그동안 화면 보호기를 돌린다.

NVIDIA가 9월 3일 베를린 IFA 2026에서 이 상황을 겨냥한 도구를 내놨다. Personal AI Router, 줄여서 PAIR다. 무료이고 소스가 공개돼 있다. 하는 일은 하나다. 로컬 네트워크에 있는 여러 대를 찾아 짝을 지어 두고, 들어오는 추론 요청마다 지금 받을 수 있는 기계 하나를 골라 넘긴다.

NVIDIA가 공개한 시연 수치는 이렇다. Hermes Desktop이 서브에이전트 다섯을 만들어 합성 받은편지함을 분석하는 작업을 Qwen 3.6 35B A3B로 돌렸을 때, RTX Spark 노트북 한 대는 평균 18분이 걸렸다. 같은 작업을 RTX Spark 노트북과 DGX Spark와 RTX 5090 세 대를 묶은 PAIR 클러스터에 던지자 평균 8분 48초로 떨어졌다.

한 줄 정리

로컬 네트워크의 여러 기계를 추론 엔드포인트 하나처럼 쓰게 해 주는 무료 라우터가 나왔고, 에이전트 쪽 코드는 한 줄도 고칠 필요가 없다.

한눈에 보기

이름	NVIDIA Personal AI Router (PAIR), 베타
가격	무료, 오픈소스
OS	Windows, macOS, Linux
하드웨어	GeForce RTX 20 시리즈 이상, RTX PRO 워크스테이션 GPU, DGX Spark, Apple M4 이상
엔진	Ollama, LM Studio
연결	mDNS 자동 탐색, 사용자 승인 후 mTLS 암호화
시연	서브에이전트 5개 작업, 1대 18분 대 3대 8분 48초

새 API가 아니라 포트를 가로챈다

PAIR가 채택한 방식은 얌전하다. 새 클러스터 API를 만들어 모든 에이전트 하네스에 붙이라고 요구하지 않는다. 대신 Ollama와 LM Studio가 쓰는 기본 포트를 프록시가 먼저 차지하고 실제 엔진은 그 뒤로 한 칸 밀려난다. 에이전트 입장에서는 늘 쓰던 로컬 주소로 요청을 보냈을 뿐이다.

요청이 들어오면 PAIR가 엔진과 모델 요구사항을 읽고 후보 노드를 추린 다음 한 대를 고른다. 고른 노드가 그 요청을 처음부터 끝까지 실행하고 응답은 같은 통로로 돌아간다. 어느 기계가 무엇을 처리했는지는 Jobs 화면에 남는다.

여기서 오해하기 쉬운 대목을 NVIDIA가 직접 못 박아 뒀다. PAIR는 GPU를 합치지 않는다. VRAM을 모아 더 큰 가속기 하나로 만들지 않고, 모델 하나를 여러 대에 쪼개 얹지도 않는다. 요청 하나는 노드 하나에서 시작해 거기서 끝난다. 24GB 카드 세 장이 있어도 72GB짜리 모델은 여전히 못 돌린다.

후보가 되는 조건은 생각보다 빡빡하다

노드가 요청을 받으려면 네 가지를 통과해야 한다. 켜져 있고 짝이 지어져 있을 것, 지원 엔진이 활성화돼 있을 것, 요청된 그 모델 태그가 그 기계에 실제로 있을 것, 지금 작업량과 GPU 사용률이 여유가 있을 것.

세 번째가 실무에서 제일 걸린다. 20GB짜리 모델을 세 대에서 후보로 쓰려면 세 대에 각각 20GB를 내려받아 둬야 한다. 노드마다 다른 모델을 두고 모델 위치에 따라 라우팅하는 것도 된다. 그러면 같은 모델로 병렬 처리하는 효과는 사라진다. 속도를 사는 값이 디스크와 관리 품이다.

지원 목록에서 눈여겨볼 항목은 Apple M4 이상이다. NVIDIA가 낸 도구인데 맥이 들어가 있다. RTX 카드가 한 장도 없고 M4 맥북과 맥 미니만 있는 팀도 후보라는 뜻이다. 콘텐츠나 마케팅을 하는 소규모 팀 사무실이 대개 그 구성이다. 디자이너 맥 스튜디오는 렌더링이 없는 시간대에 놀고 있고 회의실 구석 맥 미니는 화면 공유용으로만 켜져 있다.

집이나 사무실 기계는 데이터센터와 다르게 움직인다는 전제도 설계에 들어가 있다. 게임을 켜면 GPU가 바빠지고 노트북은 뚜껑을 닫으면 사라진다. PAIR는 노드가 준비되면 풀에 들어오고 아니면 빠지는 걸 정상으로 본다. 대신 그만큼 실행 시간이 매번 달라진다.

anyAX 관점

8분 48초라는 숫자가 매력적이지만 그 숫자가 나온 조건을 같이 봐야 한다. 서브에이전트 다섯이 서로 독립적으로 돌아가는 작업이었다. NVIDIA도 이건 일반 벤치마크가 아니고 선형 확장을 약속하지도 않는다고 본문에 적어 뒀다.

그래서 사무실에 안 쓰는 맥북 두 대가 있는 팀이 먼저 계산할 것은 GPU 개수가 아니다. 지금 우리 워크플로가 동시에 던지는 독립 요청이 몇 개인가. 회의록 요약 하나를 긴 호출로 돌리는 팀이라면 세 대를 묶어도 18분이 18분이다. 반대로 상품 설명 200개를 한 번에 돌리거나 문서 더미를 나눠 검토하는 구조라면 이미 병렬이고 PAIR가 바로 먹힌다. 도구가 아니라 작업의 모양이 이득을 정한다.

두 번째로 볼 것은 값이 아니라 위치다. PAIR는 프롬프트와 추론 트래픽을 로컬 네트워크 안에 두도록 설계됐다. 계약서 초안이나 미공개 상품 기획을 다루는 팀이 API 청구서를 줄이려고 로컬을 만지작거리다 결국 "그럴싸한 결과가 안 나와서" 접는 일이 흔한데, 이번 발표는 그 포기 지점 중 하나였던 "한 대로는 느려서"를 걷어 낸다. 남은 포기 지점은 여전히 모델 품질이다. 그건 라우터가 못 고친다.

정리하면 오늘 할 일은 다운로드가 아니다. 지난달 로그를 열어 동시에 나간 요청 수를 세어 보는 쪽이 먼저다. 그 수가 1이면 이 소식은 아직 우리 것이 아니다.