단일 6GB GPU에서 50개의 AI 에이전트 워크포스를 실행하는 방법

Build-in-public. 이것은 6GB의 VRAM에서 약 50개의 로컬 AI 에이전트 (AI agents)를 실행하는 실제 아키텍처(architecture)입니다 — 하나의 GPU 락 (GPU lock), 퇴거 와치독 (eviction watchdog), 리소스 거버너 (resource governor), 그리고 모델 라우터 (model router)로 구성됩니다. 원래 제 블로그에 게시된 내용입니다.

제가 가장 자주 받는 질문은 "6GB 노트북 GPU에서 그렇게 많은 에이전트를 실행할 방법은 없다"라는 취지의 질문입니다. 솔직한 답변은 이렇습니다: 당신이 상상하는 방식으로는 아닙니다. 저는 50개의 모델을 동시에 실행하지 않습니다. 저는 한 번에 하나의 모델을 매우 의도적으로 실행하며 — 엔지니어링의 대부분은 추론 (inference)이 아니라 스케줄링 (scheduling)에 관한 것입니다. 실제 아키텍처는 다음과 같습니다.

엄격한 제약 조건: 6GB의 VRAM

6GB의 VRAM을 가진 단일 소비자용 GPU (consumer GPU)는 사용 가능한 양자화 (quantization) 수준에서 대략 하나의 7B-파라미터 (7B-parameter) 모델을 수용할 수 있습니다. 두 개를 동시에 돌린다고요? 스래싱 (thrashing)이 발생합니다 — GPU가 스와핑 (swapping)을 시작하고, 지연 시간 (latency)이 폭발하며, 결국 드라이버 메모리 부족 (out-of-memory) 오류가 전체 시스템을 다운시킬 수 있습니다. 저도 정확히 그 문제로 데스크톱이 멈춘 적이 있습니다.

그래서 첫 번째 설계 규칙은 자연스럽게 도출되었습니다: 어떤 순간에도 GPU에는 오직 하나의 무거운 모델만 허용된다는 것입니다.

제약이 심해 보일 수 있습니다. 하지만 그렇지 않습니다 — 제가 실행하는 것 중 지연 시간 (latency)에 민감한 것은 거의 없기 때문입니다. 오전 7시에 게시되는 블로그 포스트는 그것이 6시 52분에 생성되었는지 6시 58분에 생성되었는지 상관하지 않습니다. 당신의 AI 워크포스 (AI workforce)가 채팅창이 아니라 배치 시스템 (batch system)이라는 점을 받아들이면, 문제의 형태가 완전히 바뀝니다.

군중이 아닌 락 (Lock)

GPU가 필요한 모든 에이전트는 먼저 락 (lock)을 획득해야 합니다. 이는 다음과 같은 단순한 파일 기반 큐 (file-based queue)입니다:

1. FIFO (First-In-First-Out) 순서
2. PID 기반 소유권
3. 충돌된 작업이 줄을 영원히 막지 않도록 하는 스태일 락 (Stale-lock) 감지

만약 에이전트가 타임아웃 (timeout) 내에 락을 얻지 못하면, 작업이 쌓이는 대신 우아하게 건너뛰고 다음 예정된 실행 시에 다시 시도합니다.

따라서 50개의 에이전트가 있을 때 실제로 일어나는 일은 다음과 같습니다: 하루 동안 수십 개의 cron으로 스케줄링된 Python 워커 (Python workers)들이 깨어나고, 모델이 필요한 워커들은 모델을 위해 질서 정연하게 줄을 섭니다. 플릿 (fleet)은 거대하지만, GPU 경합 (contention)은 항상 정확히 하나입니다. 그것이 비결입니다. 이것은 "50개의 모델"이라기보다 "매우 바쁜 워크스테이션 하나를 정중하게 공유하는 50명의 직원"에 가깝습니다.

퇴거 및 VRAM 와치독 (Watchdog)

잠금(lock) 장치가 있더라도, 유휴(idle) 모델들은 VRAM에 계속 남아 있습니다. 그래서 작은 모니터링 도구가 몇 분마다 GPU 사용량을 확인하고, 사용량이 임계값(threshold)을 넘어서면 유휴 모델을 퇴거(evict)시킵니다. 밤사이 더 무거운 작업을 위해 GPU를 비워두고 싶을 때는 이 임계값이 자동으로 낮아져서, 낮 동안 사용하던 모델들이 더 빨리 밀려나게 됩니다.

별도의 리소스 거버너(resource governor)는 파편화(fragmentation), 캐시 압박(cache pressure), 스왑 스래싱(swap thrashing)을 감시하며, 상황이 드라이버 OOM(Out-of-Memory) 프리즈(freeze) 상태로 치닫기 전에 완만한 조치(컨텍스트 축소)에서 단호한 조치(강제 퇴거)까지 단계적으로 대응합니다.

네 가지 핵심 구성 요소:

하나의 잠금(lock)이 모든 무거운 GPU 작업을 직렬화(serialize)합니다.

퇴거 모니터(eviction monitor)는 유휴 모델이 너무 오래 머물 때 VRAM을 확보합니다.

리소스 거버너(resource governor)는 스래싱(thrashing)을 조기에 포착하여 시스템이 위험에 처하기 전에 조치를 취합니다.

모델 라우터(model router)는 에이전트가 특정 모델을 지정하는 대신 "작업 X를 위한 모델"을 요청할 수 있게 하여, 작업에 적합한 크기의 모델이 선택되도록 합니다.

라우터가 진정한 돌파구입니다

에이전트들은 7B 모델을 사용하도록 하드코딩(hardcode)하지 않습니다. 대신 라우터에 작업에 적합한 모델을 요청하며, 라우터가 다음과 같이 결정합니다: 빠른 분류를 위해 CPU에서 실행되는 아주 작은 모델, 실제 작성을 위한 7B 모델, 또는 상황이 적절할 때 더 큰 작업을 위한 무료 클라우드 티어(cloud tier) 등입니다.

이 단일 계층 덕분에 사양이 낮은 컴퓨터(potato)를 사용하든 워크스테이션을 사용하든 동일한 에이전트를 변경 없이 실행할 수 있습니다. 라우터가 하드웨어의 차이를 흡수하기 때문입니다. 더 강력한 기기에서는 더 높은 동시성(concurrency)과 더 큰 모델을 사용할 수 있게 해주고, 사양이 낮은 기기에서는 작은 로컬 모델에 의존하며 실행 속도(cadence)를 조절합니다. 코드는 동일하지만, 장비는 달라집니다.

로컬 우선(local-first) 방식이 노력할 가치가 있는 이유