저예산 프라이빗 AI: 4GB RTX 3050에서 구동되는 다기능 LLM

최근 AI 연구의 발전으로, 우리는 데이터 공유와 토큰 비용을 피하면서 자신의 기기에서 실제로 프라이빗 AI (Private AI)를 실행하는 것을 꿈꿀 수 있게 되었습니다. 결과가 100% 완벽하지는 않지만, 일상적인 작업에는 놀라울 정도로 유능합니다.

다음은 Local AI가 직접 그린 프로젝트의 아키텍처 다이어그램 (Architecture diagram)입니다:

이 포스트에서 저는 4GB VRAM을 가진 단일 NVIDIA RTX 3050 노트북 GPU를 사용하여 어떻게 작동하는 로컬 AI (Local AI)를 구현했는지, 그리고 여러분도 어떻게 할 수 있는지 단계별로 설명하겠습니다.

요구 사항 (The Requirements)

프로젝트를 시작하기 전에 현실적인 목표를 설정하는 것이 매우 중요합니다. 엔트리급 하드웨어에서 전체 로컬 스택 (Local stack)을 실행한다는 것은 유용성과 리소스 제약 사이의 균형을 맞추는 것을 의미했습니다.

이 설정을 위한 저의 목표 요구 사항은 다음과 같습니다:

• 동시 사용 (Concurrent Usage): LAN 상에서 2~4명의 로컬 사용자 지원
• 이미지 생성 (Image Generation): 주당 15~20회 생성
• 언어 지원 (Language Support): 다국어 능력
• 실시간 데이터 (Real-Time Data): 라이브 웹 검색 통합
• 사용 사례 (Use Cases): 레시피 및 여행 계획 보조
• 비전 (Vision): 이미지 분석 및 멀티모달 (Multimodal) 이해
• 개발 (Development): 경미한 코딩 보조
• 접근성 (Accessibility): 집 안의 기기 전체에서 LAN을 통해 완전히 접근 가능
• 개인정보 보호 및 비용 (Privacy & Cost): 100% 오프라인 — 클라우드 의존성이나 토큰 비용 없음

🛠️ 사양 및 제약 사항 (The Specs & Constraints)

• 하드웨어 (Hardware): RTX 3050 (4 GB VRAM), 16 GB 시스템 RAM.
• 목표 부하 (Target Load): 개인 홈 네트워크에서 2~4명의 동시 로컬 사용자.
• 기능 (Features): LLM 추론 (Reasoning), 자체 호스팅 웹 검색 (SearXNG), 역지오코딩 (Reverse geocoding), 이미지 생성/편집 (ComfyUI).
• 핵심 과제 (Core Challenge): 4 GB VRAM은 LLM과 디퓨전 모델 (Diffusion model)을 동시에 로드하여 유지하기에 충분한 메모리가 아닙니다.

전제 조건 (Prerequisite)

이 솔루션은 사전에 설정해야 하는 세 가지 주요 거대 시스템을 기반으로 작동합니다 --

1. llama.cpp - 해당 페이지의 지침을 따라 준비하십시오.
2. ComfyUI - 단 한 번의 pip install로 설치 가능합니다. 단순한 서버 기능만으로도 충분하며, 그 외 다른 것은 필요하지 않습니다.
3. SearXNG - 하나의 docker 컨테이너 설치와 json 형식 활성화가 필요하며, 이는 가이드에서 확인할 수 있습니다.
4. Nginx - 선택 사항 (Optional)

요약 (TL;DR)

시간이 부족하여 빠르게 준비하고 싶다면, 이 링크를 따르십시오 - Local AI.

🏗️ 상위 수준 시스템 아키텍처 (High-Level System Architecture)

전체 스택은 개발용 머신에서 로컬로 실행됩니다. 저는 Nginx를 사용하여 오케스트레이터 (chat-webui.py)를 호스팅했습니다. 오케스트레이터는 다시 세 개의 백본 서버인 llama.cpp, ComfyUI, SearXNG에 연결됩니다.

LAN 장치들 ---> Nginx (chat.local) ---> chat-webui.py (Port 3001)
                                            │
               ┌────────────────────────────┼────────────────────────────┐
...

도전 과제 (The Challenges)

제 컴퓨터가 할 수만 있었다면, 저에게 반항했을 것입니다. 이 시스템은 단 한 명의 사용자를 위한 것이라 할지라도 서버 부하를 견디도록 설계되지 않았습니다. 그럼에도 불구하고 저는 이를 강행했습니다. 당연히 결과가 따랐습니다:

• 시스템은 AI 실행 측면에서 심각한 하드웨어 제한을 가집니다.
• 의미 있는 작업을 전체 버전으로 실행하려면 최소 8 GB의 VRAM이 필요합니다.
• VRAM을 LLM 추론 (inference)에 완전히 사용하면, 이미지 생성을 위한 여유 메모리가 없습니다.
• 채팅 세션 동안 GPU를 지속적으로 사용하면 기기가 열 설계 (thermal design) 범위를 벗어나게 됩니다.
• LLM을 지속적으로 사용하면 시스템 RAM 점유율이 서서히 높아져 시스템을 완전히 재부팅해야 합니다.
• 갑작스러운 시스템 실패, OOM (Out of Memory) 충돌, 갑작스러운 중단

엔지니어링 솔루션 (Engineering Solutions)

1. 사용 가능한 모델 찾기

사용 가능한 LLM (Large Language Model) 모델을 실행하는 데 있어 가장 큰 문제는 Edge AI (엣지 AI) 솔루션을 추진하기 위해 노력하는 수많은 천재들에 의해 이미 해결되었습니다. 저는 모델을 로드할 때와 이후 관련 종속성(dependencies)을 로드할 때 제 메모리 용량을 초과하지 않는 모델을 선택하기만 하면 되었습니다. 몇 가지 모델을 시도하며 며칠 동안 로컬에서 실행해 본 끝에, 최종적으로 Gemma4 E2B IT를 선택하게 되었습니다.

저의 모든 요구 사항을 염두에 두고 다음과 같은 모델들을 시도해 보았습니다.

1. Qwen3.5 9B - 매우 훌륭하지만, CPU/GPU 분할 문제로 인해 제 기기에서는 매우 느렸습니다.
2. Qwen3 VL 4B - 적절한 속도로 잘 작동했지만, 추론(reasoning) 과정이 너무 길어 시간을 많이 잡아먹었습니다. 결국 제외했습니다.
3. Gemma4 E4B - 동일한 문제로, 잘 작동은 했으나 일상적인 대화를 나누기에는 너무 느렸습니다.
4. Gemma4 E2B IT - 상당히 괜찮은 속도(초당 35~45 토큰)로 매우 잘 작동하며, 네이티브 다국어 지원(native multi-lingual support)을 갖추고 있고 기본적인 추론도 수행합니다.

이미지 생성(image generation)의 경우에도 여러 모델을 번갈아 가며 사용했습니다.

1. Realistic - 매우 빨랐지만 정확도가 떨어졌습니다.
2. SD 1.5 - 이미지가 정확하지는 않았지만 매우 빨랐습니다.
3. SD 3.5 - 생성된 이미지 대부분이 합성된 느낌(synthetic feel)이 강했습니다.
4. Z-Image-Turbo - VRAM 예산에 적합하며, 준수한 이미지를 생성하고 Img2Img(Image-to-Image) 워크플로우도 지원합니다. 참고: Img2Img 워크플로우는 실제 사진에서는 아직 잘 작동하지 않지만, 기존 이미지를 편집하는 것은 잘 작동합니다. 예를 들어, 고양이를 그려달라고 요청한 뒤 흑백 이미지를 갈색과 흰색으로 다시 색칠해달라고 하면 꽤 괜찮게 작동합니다.

2. 동적 VRAM 스와핑 및 상태 머신 (Dynamic VRAM Swapping & State Machine)

llama-server와 ComfyUI는 둘 다 충돌 없이 4GB VRAM을 동시에 공유할 수 없기 때문에, 저는 백엔드 오케스트레이터(backend orchestrator) 내부에 자동화된 상태 머신(state machine)을 구축했습니다:

1. 사용자가 이미지를 요청하면, 백엔드(backend)가 도구 호출(tool call)을 가로챕니다.
2. llama-server에 언로드(unload) 호출을 보내 GPU VRAM을 완전히 해제합니다.
3. ComfyUI가 --lowvram 모드를 사용하여 생성 워크플로(generation workflow)를 실행합니다.
4. 완료되면 VRAM이 정리되고, LLM이 GPU 메모리로 자동 다시 로드(reload)됩니다.
5. LLM은 다음 작업이 있는지 확인한 후 응답을 다시 보냅니다.

3. 온도 모니터링 및 RAM 비우기 루프 (Thermal Monitoring & RAM Evacuation Loop)

데모에서 무언가를 보여주는 것과 화요일 오후에 운영 환경(production)에서 시스템이 실패하는 것 사이에는 차이가 있습니다.

위에서 언급한 두 단계를 통해 전체 시스템은 데모 준비가 완료되지만, 24/7로 구동하고 싶다면 시스템 상태(system health)를 계획해야 합니다. 저의 경우, 두 가지 특별한 주의 사항이 필요했습니다:

1. 온도 루프 (Thermal Loop): 백그라운드 데몬(background daemon)이 10초마다 nvidia-smi를 폴링(poll)합니다. GPU 온도가 85°C에 도달하면, 온도가 65°C 미만으로 떨어질 때까지 활성 모델들을 언로드(unload)합니다.
2. RAM 비우기 (RAM Evacuation): 시스템 RAM 사용량이 **95%**에 도달하면, 진행 중인 작업들을 안전하게 재큐(re-queue)하고, 서비스를 재시작하며, 재개하기 전에 메모리를 플러시(flush)합니다.

이제 UI에는 온도 과부하 또는 RAM 과부하에 대한 경고 메시지가 표시됩니다. 바로 이 지점에서 여러분은 사용자 기반(user base)을 고려해야 합니다. 만약 대규모 사용자 기반을 보유하고 있다면, 이런 트릭을 사용할 수 없습니다.

4. 도구 호출 및 멀티 테넌트 큐 (Tool Calling & Multi-Tenant Queue)

처음에는 python 구현체를 보고 저를 비판할 수도 있습니다. FastAPI 시대에 여전히 싱글 스레드 큐(single threaded queues)를 사용하고 있다고요.

하지만 이것이 설계의 일부가 되어야 하는 이유는 다음과 같습니다. 만약 제가 여러 쿼리를 동시에 실행할 수 있도록 사용자 제한을 풀었다면, 각 쿼리마다 새로운 LLM 추론(LLM Inference) 스레드를 생성해야 했을 것입니다(ollama와 같은 도구들의 표준 방식). 게다가 그 요청들 중 하나나 두 개가 이미지 생성을 포함하고 있다면, 제 서버는 즉시 충돌(crash)할 것입니다.

따라서, 저는 다음과 같은 방식으로 사용자가 한 번에 여러 요청을 보내는 것을 차단합니다:

• _llm_pool (1 Worker): 메모리 스래싱 (memory thrashing)을 방지하기 위해 엄격한 단일 LLM 추론 (single-LLM inference)을 강제합니다.
• _tool_pool (2 Workers): SearXNG 쿼리 실행 또는 Nominatim을 통한 역지오코딩 (reverse geocoding)과 같은 병렬 도구 호출 (parallel tool calls)을 동시에 처리합니다.

🚀 스택 실행 방법

1. llama-server 시작 (CUDA 활성화):

~/local-ai/llama.cpp/build/bin/llama-server \
    --host 0.0.0.0 --port 8081 \
    --models-dir ~/local-ai-files/my-models/ \
...

2. Low-VRAM 모드로 ComfyUI 시작:

cd ~/local-ai/ComfyUI && source venv/bin/activate
python main.py --lowvram

3. 오케스트레이션 (Orchestration) WebUI 실행:

cd ~/git/local-ai && python chat-webui.py

상세한 설치 단계 및 기타 사용 방법은 TL;DR을 확인해 주세요.

아키텍처 개요

향후 개선 범위

다음은 계획된 몇 가지 활동입니다. 이를 언제 어떻게 처리할지는 확실하지 않지만, 달성하게 되면 계속 소식을 알려드리겠습니다.

• Android 네이티브 앱 지원
• LLM을 에이전틱 워크플로우 (agentic workflow)로 확장
• 작동 가능한 오디오 인터페이스 (Audio Interface)
• 인터넷을 사용하여 나의 프라이빗 AI (Private AI)에 연결

💭 배운 점

제한된 하드웨어에서 성능을 쥐어짜는 과정은 시스템 한계, 동시성 잠금 (concurrency locks), 그리고 메모리 수명 (memory lifetimes)에 대해 깊이 생각하게 만듭니다. 강력한 도구를 만들기 위해 항상 거대한 클라우드 인프라가 필요한 것은 아닙니다. 때로는 세심한 리소스 관리 (resource management)만으로도 충분합니다.