남는 PC를 묶어 로컬 AI를 돌리기 전에, 에이전트 작업부터 나눠야 하는 이유

로컬 AI를 쓰다 보면 성능보다 먼저 막히는 순간이 있다. 모델이 느린 것이 아니라, 하나의 GPU에 여러 요청이 한꺼번에 몰리는 때다. 긴 문서 요약을 돌리는 동안 코드 검토용 에이전트까지 기다리게 하거나, 가족의 게임용 PC가 쉬고 있는데도 작업용 PC 하나만 계속 바쁘게 두는 식이다.

NVIDIA가 9월 3일 베타로 공개한 NVIDIA PAIR(Personal AI Router)는 이 문제를 겨냥한다. 같은 로컬 네트워크에서 호환되는 컴퓨터를 찾고, 독립적인 AI 추론 요청을 여유가 있는 장비로 보낸다. Ollama와 LM Studio를 지원하며, 장비가 들어오거나 빠질 때도 구성을 조정한다고 NVIDIA는 설명한다.

이번 소식에서 볼 만한 지점은 여러 PC를 묶는 기술 자체보다, 로컬 에이전트의 병목을 어떻게 정의하느냐에 있다. 한 대의 더 큰 GPU를 사기 전에 작업을 나눌 수 있는지, 데이터가 장비 사이를 오가도 되는지, 실제 대기 시간이 줄었는지를 확인해야 한다.

PAIR가 하는 일과 하지 않는 일

PAIR는 이름과 달리 네트워크 장비가 아니라 오픈소스 소프트웨어다. NVIDIA와 The Verge의 설명에 따르면, 로컬 네트워크의 호환 장비를 연결하고 에이전트 워크플로의 독립적인 추론 요청을 분산하는 역할을 한다. 지원 대상에는 RTX 20 시리즈 이후 GeForce RTX, Turing 이후 RTX PRO, DGX Spark, Apple M4 이후 실리콘이 포함된다. 베타는 Windows, macOS, Linux에서 제공된다.

중요한 제한도 있다. PAIR가 하나의 거대한 모델을 여러 PC의 메모리에 나누어 올려 주는 도구라는 뜻은 아니다. 발표에서 강조한 사용 방식은 복잡한 일을 작은 작업으로 쪼갤 때, 서로 의존하지 않는 요청을 다른 장비로 보내는 것이다. 예를 들어 받은편지함 분류, 여러 문서의 초안 비교, 독립된 코드 저장소의 정적 점검처럼 결과를 나중에 합칠 수 있는 일은 후보가 될 수 있다.

반대로 앞 단계의 출력이 다음 단계의 입력인 긴 연쇄 작업, 한 모델의 긴 컨텍스트를 계속 유지해야 하는 대화, 단일 대형 모델이 특정 VRAM을 반드시 요구하는 작업은 분산만으로 해결되지 않는다. 이 경우에는 작업 분할 때문에 생기는 전달 비용과 결과 취합 오류가 이득을 넘을 수 있다.

성능 숫자는 내 워크로드와 분리해서 읽기

NVIDIA는 llama.cpp에서 GeForce RTX 5090 기준 최대 1.9배 처리량 향상, vLLM에서 RTX PRO 6000 Blackwell Workstation Edition 기준 1.2배, DGX Spark 두 대 기준 최대 1.4배를 제시했다. Wccftech도 NVIDIA가 공개한 SpeedBench-Coding 8K Throughput과 AIPerf 기반 결과를 정리했다. 이는 커널 최적화, speculative decoding, prefill 가속, FlashInfer의 XQA attention kernel 같은 변경을 포함한 수치다.

다만 이 숫자를 개인 환경의 체감 속도로 바로 옮기기는 어렵다. 에이전트 작업 시간에는 모델이 토큰을 생성하는 시간 외에도 파일을 읽는 시간, 검색과 API 호출 대기, 도구 실행, 사람 검토가 들어간다. 특히 NAS나 소형 PC를 함께 쓸 경우 네트워크 지연과 디스크 I/O가 더 먼저 병목이 될 수 있다. 발표의 최대 수치는 가능성의 상한에 가깝고, 도입 판단은 자신의 작업 로그에서 해야 한다.

로컬 모델 설정을 쉽게 하는 흐름도 같이 발표됐다. NVIDIA는 Hermes Agent, OpenClaw, Perplexity Portable Computer에 Windows용 간소화된 로컬 모델 설정을 제공한다고 밝혔다. Hermes의 경우 GPU를 감지해 적절한 모델과 설정을 고르고, 통합 llama.cpp 및 NVIDIA 최적화를 이용하는 방식으로 소개됐다. Linux 지원은 곧 제공될 예정이라고 했으므로, Linux 환경에서는 이미 쓸 수 있다고 전제하면 안 된다.

작업을 나누기 전에 정할 세 가지

여러 장비를 연결하면 처리량은 늘 수 있지만 운영 대상도 늘어난다. 작은 실험에서는 다음 세 가지를 먼저 적어 두는 편이 낫다.

1. 독립적인 요청의 경계

분산 후보는 서로의 중간 결과를 즉시 필요로 하지 않는 작업이다. 예를 들어 주간 회고 자료에서 일정, 메일, 작업 목록을 각각 추출한 뒤 마지막에 한 번만 합치는 구조는 나누기 쉽다. 반면 한 에이전트가 수정한 파일을 다음 에이전트가 테스트하고 다시 고치는 흐름은 순서와 작업 디렉터리의 상태가 중요하다. 이 작업을 무리하게 동시에 돌리면 속도보다 충돌 확인 시간이 늘어난다.

2. 데이터의 이동 범위

로컬 실행은 데이터를 클라우드에 보내지 않는 선택지가 될 수 있지만, 여러 로컬 장비를 쓰면 데이터가 다른 PC로 이동한다. The Verge는 PAIR가 여섯 자리 코드로 장비를 페어링하고 mTLS로 양방향 신뢰 채널을 구성한다고 보도했다. 전송 암호화는 필요한 조건이지만, 충분한 조건은 아니다. 어느 장비가 문서 원본을 받을 수 있는지, 장비에 남는 로그와 캐시는 무엇인지, 가족이나 팀이 함께 쓰는 PC를 작업 풀에 넣어도 되는지를 별도로 정해야 한다.

3. 중단해도 되는 작업인지

PAIR는 장비가 네트워크에 새로 들어오거나 빠질 때 적응하도록 설계됐다. 실제 환경에서는 노트북이 절전 모드로 들어가고, 데스크톱은 다른 사람이 사용하기 시작하며, 게임이나 영상 편집이 GPU 자원을 가져갈 수 있다. 그래서 분산 대상은 중단 뒤 재시도해도 되는 읽기 전용 분석이나 초안 생성부터 시작하는 것이 안전하다. 외부 시스템에 변경을 쓰는 작업은 결과 확인과 재개 기준을 갖춘 뒤에 다뤄야 한다.

작게 검증하는 방법

장비를 더 사거나 모든 에이전트 작업을 바꾸기 전에는 두 대로 한 주만 비교해 볼 수 있다.

먼저 현재 한 대에서 수행하는 반복 작업 하나를 고른다. 예를 들어 여러 Markdown 문서에서 할 일을 추출하는 작업처럼 입력과 결과가 명확한 것이 좋다.
작업을 독립된 두세 묶음으로 나누고, 전체 완료 시간뿐 아니라 각 요청의 대기 시간, 재시도 횟수, 결과 취합에 쓴 시간을 기록한다.
민감하지 않은 샘플 데이터로 시작한 뒤, 어떤 장비가 어떤 파일을 받았는지와 중단 시 남는 상태를 확인한다. 이 기록이 없으면 속도가 빨라져도 운영 가능성을 판단하기 어렵다.

평가 기준도 단순하다. 두 대를 썼을 때 총 완료 시간이 줄었는지, 주 작업 PC의 반응성이 유지됐는지, 결과가 한 대에서 처리했을 때와 같은지 확인하면 된다. 병렬 요청이 적거나 도구 대기 시간이 대부분인 작업이라면 PAIR를 추가해도 이득이 작을 수 있다. 그때는 모델 서버보다 작업 순서나 도구 호출 횟수를 줄이는 편이 더 낫다.

로컬 AI의 다음 과제는 장비 수가 아니라 운영 방식

이번 발표는 로컬 AI가 단일 PC의 모델 실행에서 여러 장비의 작업 배치로 넓어지고 있음을 보여 준다. 동시에 여러 컴퓨터를 쓴다고 에이전트가 자동으로 빨라지거나 안전해지는 것은 아니다. 병렬화 가능한 요청, 데이터 이동의 허용 범위, 실패 뒤 재개 방법이 정리되어 있어야 분산의 이점이 남는다.

개인 NAS나 여러 PC를 이미 운영하는 환경이라면 PAIR는 흥미로운 실험 재료다. 다만 첫 목표는 ‘집 안의 AI 클러스터’를 만드는 일이 아니라, 하나의 반복 작업에서 기다림을 줄이면서도 결과와 데이터 경계를 설명할 수 있는지 확인하는 데 두는 편이 좋다.