로컬 멀티 GPU의 첫걸음은 '클러스터'가 아니다
멀티 GPU라고 하면 곧바로 랙 서버, InfiniBand, Kubernetes, 분산 스케줄러 같은 단어가 떠오른다. 하지만 로컬 LLM을 처음 굴리는 단계에서는 그보다 훨씬 현실적인 질문이 먼저다. "내 책상 밑 PC에 꽂힌 두 장의 그래픽카드를 이 도구가 어떻게 나눠 쓰는가?"
대형 언어모델을 로컬에서 실행할 때 가장 먼저 부딪히는 벽은 여전히 VRAM이다. 70B급 모델을 4비트로 양자화해도 모델 가중치만 수십 GB가 필요하고, 여기에 KV 캐시와 컨텍스트 버퍼가 더해진다. 그래서 RTX 4090 24GB 한 장으로는 70B 모델이 아슬아슬하거나 아예 올라가지 않는 일이 흔하다. 이때 두 번째 GPU는 "더 빠르게 만들기 위한 장치"라기보다 "아예 실행 가능하게 만드는 장치"에 가깝다.
로컬 도구의 세계에서는 크게 두 가지 방식이 반복해서 등장한다. 하나는 레이어 단위로 모델을 나누는 방식이다. 예를 들어 GPU 0이 앞쪽 레이어를 계산하고, GPU 1이 뒤쪽 레이어를 계산한다. 데이터는 순서대로 다음 GPU로 넘어간다. 다른 하나는 텐서, 즉 행렬 계산 자체를 여러 GPU에 쪼개 맡기는 방식이다. 후자는 GPU들이 동시에 일하지만 서로 자주 통신해야 하므로 인터커넥트 성능에 더 민감하다.
소비자용 PC에서는 대부분 PCIe를 통해 GPU가 연결된다. NVLink가 없는 RTX 40/50 시리즈 환경에서는 레이어 분할이 오히려 더 안정적이고 예측 가능한 경우가 많다. 그래서 이번 장의 핵심은 단순하다. 로컬 환경에서는 복잡한 클러스터를 먼저 배우기보다, llama.cpp, Ollama, ExLlamaV2, LM Studio, KoboldCpp가 모델을 어떤 방식으로 쪼개는지 이해하는 것이 먼저다.
llama.cpp: 가장 직접적으로 조종할 수 있는 도구
llama.cpp는 로컬 LLM 생태계의 엔진룸 같은 존재다. GGUF 모델을 다루는 수많은 도구가 내부적으로 llama.cpp의 기능을 사용하거나 영향을 받는다. 멀티 GPU에서도 마찬가지다. llama.cpp는 NVIDIA CUDA, AMD ROCm, Vulkan, Metal 등 여러 백엔드를 지원하며, 다중 GPU 환경에서 모델 일부를 여러 장치에 배치할 수 있다1.
가장 자주 쓰는 옵션은 -ngl 또는 긴 이름인 --n-gpu-layers다. 이 옵션은 몇 개의 레이어를 GPU로 올릴지 정한다. -ngl 0이면 GPU를 거의 쓰지 않고, -ngl 999처럼 큰 값을 주면 가능한 모든 레이어를 GPU에 올리려 한다. 실제 레이어 수보다 큰 값을 넣어도 "전부 GPU에 올려라"라는 의도로 널리 사용된다.
llama-server \
-m /models/llama-3.1-70b.Q4_K_M.gguf \
-c 8192 \
-ngl 999이 명령은 모델 레이어를 가능한 한 GPU에 올린다. GPU가 한 장뿐이라면 한 장에 최대한 싣고, 부족하면 일부가 CPU/RAM으로 밀려난다. GPU가 여러 장이면 llama.cpp는 설정에 따라 모델을 나눠 올릴 수 있다.
여기서 중요한 옵션이 --split-mode와 --tensor-split이다. 이름이 조금 헷갈릴 수 있다. --tensor-split은 "진짜 텐서 병렬만 수행한다"는 뜻이라기보다, 여러 GPU에 모델을 어떤 비율로 배치할지 알려주는 옵션으로 이해하는 편이 안전하다. 실제 계산 방식은 --split-mode에 따라 달라진다.
대표적인 분할 모드는 다음처럼 이해하면 된다.
--split-mode layer: 레이어를 GPU별로 나눠 배치한다. 소비자용 PCIe 멀티 GPU에서 가장 무난한 출발점이다.--split-mode row: 행렬의 행 방향으로 계산을 나눠 여러 GPU가 더 동시에 일하게 한다. 통신량이 늘 수 있어 환경에 따라 빠르거나 느릴 수 있다.--tensor-split: 각 GPU에 어느 정도 비율로 모델을 배치할지 지정한다. VRAM이 다른 GPU를 섞어 쓸 때 특히 중요하다.
예를 들어 RTX 4090 24GB 두 장으로 70B GGUF 모델을 실행한다면 다음처럼 시작할 수 있다.
CUDA_VISIBLE_DEVICES=0,1 llama-server \
-m /models/llama-3.1-70b.Q4_K_M.gguf \
-c 8192 \
-ngl 999 \
--split-mode layer \
--tensor-split 24,24--tensor-split 24,24는 두 GPU에 같은 비중으로 모델을 나누라는 뜻이다. 꼭 합이 1이나 100일 필요는 없다. 1,1처럼 써도 같은 의미로 해석되는 경우가 많지만, 실전에서는 VRAM 크기를 그대로 적는 편이 직관적이다.
혼합 GPU에서는 이 옵션이 더 중요해진다. 예를 들어 RTX 4090 24GB와 RTX 3060 12GB를 함께 쓴다면 2:1에 가까운 비율이 자연스럽다.
CUDA_VISIBLE_DEVICES=0,1 llama-server \
-m /models/qwen2.5-72b.IQ3_XXS.gguf \
-c 8192 \
-ngl 999 \
--split-mode layer \
--tensor-split 24,12이때 큰 GPU가 더 많은 레이어를 맡는다. 다만 "VRAM 합계가 36GB니까 36GB 모델이 무조건 돈다"라고 생각하면 곤란하다. KV 캐시, CUDA/ROCm 런타임 오버헤드, 임시 계산 버퍼, 디스플레이가 차지하는 메모리까지 모두 고려해야 한다. 특히 12GB 카드가 보조 GPU로 들어가면 그 카드의 남은 VRAM이 전체 실행 가능 여부를 결정하는 약한 고리가 되기도 한다.
row 모드는 흥미롭지만 실험이 필요하다. 텐서 계산을 더 잘게 나누기 때문에 이론상 GPU 활용률이 좋아질 수 있다. 그러나 PCIe 통신이 느리거나 GPU 성능 차이가 크면 오히려 병목이 드러난다.
CUDA_VISIBLE_DEVICES=0,1 llama-server \
-m /models/llama-3.1-70b.Q4_K_M.gguf \
-c 8192 \
-ngl 999 \
--split-mode row \
--tensor-split 24,24 \
--main-gpu 0--main-gpu는 주 GPU를 지정한다. 모드와 버전에 따라 KV 캐시나 임시 버퍼 배치에 영향을 줄 수 있으므로, 여러 조합을 벤치마크해보는 것이 좋다. 결론적으로 llama.cpp는 "자동으로 편하게"보다는 "내가 직접 맞춰가며"에 가깝다. 대신 그만큼 학습하기 좋다. VRAM이 어디서 터지는지, 어느 GPU가 쉬고 있는지, 컨텍스트를 늘리면 무엇이 느려지는지를 가장 잘 보여주는 도구이기 때문이다.
Ollama: 편하지만, 자동화의 한계를 알아야 한다
Ollama는 로컬 LLM 입문자에게 가장 친절한 도구 중 하나다. 모델 이름을 입력하면 다운로드, 실행, API 서버 구동까지 대부분 알아서 처리한다. 멀티 GPU에서도 기본 방향은 같다. Ollama는 사용 가능한 GPU를 감지하고, 가능한 경우 모델을 GPU에 올리려 한다. 공식 문서에 따르면 NVIDIA 환경에서는 CUDA_VISIBLE_DEVICES로 사용할 GPU 범위를 제한할 수 있고, AMD ROCm 환경에서는 ROCR_VISIBLE_DEVICES를 사용할 수 있다2.
가장 단순한 실행은 다음과 같다.
ollama run llama3.1:70bGPU가 두 장 있고 모델이 한 장에 들어가지 않는다면, Ollama는 내부 스케줄러와 백엔드를 통해 가능한 GPU 자원을 사용하려 한다. 사용자가 --tensor-split 24,24 같은 세부 비율을 직접 넘기는 방식은 아니다. 그래서 Ollama는 "우선 실행해보고, 안 되면 제어 범위를 좁히는" 도구에 가깝다.
특정 GPU만 쓰고 싶다면 Ollama 서버를 시작하기 전에 환경 변수를 지정한다.
CUDA_VISIBLE_DEVICES=0,1 ollama serve세 장의 GPU가 있는 시스템에서 0번과 1번만 Ollama에 넘기고, 2번은 Stable Diffusion이나 다른 작업에 남겨두는 식으로 쓸 수 있다. NVIDIA GPU 번호는 부팅이나 드라이버 상태에 따라 헷갈릴 수 있으므로, 운영 환경에서는 nvidia-smi -L로 확인한 UUID를 사용하는 편이 더 안전하다.
Ollama에는 여러 GPU에 더 넓게 분산하도록 유도하는 OLLAMA_SCHED_SPREAD 환경 변수가 알려져 있다. 기본 스케줄링은 가능한 한 적은 GPU에 모델을 올려 통신 오버헤드를 줄이려는 방향일 수 있다. 반대로 큰 모델을 여러 GPU에 강제로 펼치고 싶다면 다음처럼 실행한다.
OLLAMA_SCHED_SPREAD=true CUDA_VISIBLE_DEVICES=0,1 ollama serve그 뒤 다른 터미널에서 모델을 실행한다.
ollama run llama3.1:70bOllama의 장점은 분명하다. 설치가 쉽고, 모델 관리가 편하고, OpenAI 호환 API처럼 붙여 쓰기도 쉽다. 하지만 세밀한 멀티 GPU 튜닝에는 한계가 있다. 어느 GPU에 몇 개 레이어를 둘지, 혼합 GPU에서 정확히 몇 GB씩 쓸지, 레이어 분할과 행 분할을 비교할지 같은 실험은 llama.cpp를 직접 쓰는 편이 낫다.
그래서 Ollama는 이런 상황에 잘 맞는다. 8B, 14B, 32B급 모델을 빠르게 테스트하고 싶을 때, 로컬 챗봇을 간단히 띄우고 싶을 때, 또는 멀티 GPU 설정을 깊게 파고들기 전에 "일단 되는지" 확인하고 싶을 때다. 반면 70B 모델을 48GB VRAM에 아슬아슬하게 맞추거나, 24GB+12GB처럼 비대칭 구성을 정교하게 다뤄야 한다면 더 직접적인 도구가 필요해진다.
ExLlamaV2: EXL2와 고속 양자화 추론
ExLlamaV2는 "NVIDIA GPU에서 양자화 모델을 빠르게 돌리자"는 목적이 뚜렷한 도구다. 특히 EXL2 포맷이 핵심이다. EXL2는 모델 전체를 고정된 4비트로만 압축하는 방식이 아니라, 레이어와 텐서별로 비트율을 조절해 평균 비트율을 맞추는 양자화 형식이다. 쉽게 말해 중요한 부분에는 조금 더 많은 비트를 쓰고, 덜 민감한 부분은 더 강하게 압축해 품질과 용량 사이의 균형을 맞춘다. ExLlamaV2는 2비트에서 8비트 사이의 혼합 비트율을 활용할 수 있는 EXL2 형식을 지원하는 것으로 알려져 있다3.
멀티 GPU에서는 --gpu-split 또는 줄여서 --gs 옵션이 자주 등장한다. 이 옵션은 GPU별로 얼마만큼의 VRAM을 할당할지 지정한다.
python exllamav2/server.py \
--model /models/llama-3.1-70b-exl2 \
--gpu-split 24,2424GB GPU 두 장이면 위처럼 같은 비율로 나눈다. 24GB와 12GB 조합이라면 다음처럼 쓴다.
python exllamav2/server.py \
--model /models/qwen2.5-72b-exl2 \
--gpu-split 24,12ExLlamaV2가 빛나는 상황은 비교적 명확하다. GGUF 생태계의 범용성보다 NVIDIA GPU에서의 빠른 양자화 추론이 더 중요할 때, EXL2로 잘 양자화된 모델을 확보했을 때, 그리고 단일 사용자 또는 소수 동시 요청에서 높은 토큰 생성 속도를 원할 때다. 반대로 CPU 오프로딩이 필요하거나, AMD/Apple Silicon까지 넓게 지원해야 하거나, 최신 모델 아키텍처 지원이 GGUF 쪽에 먼저 들어온 상황이라면 llama.cpp 계열이 더 편할 수 있다.
실전에서는 같은 모델이라도 GGUF Q4_K_M과 EXL2 4.0bpw가 완전히 같은 품질과 속도를 내지 않는다. 그래서 "포맷 이름"보다 "내가 쓰려는 모델이 해당 포맷으로 얼마나 잘 양자화되어 있는가"가 중요하다. 70B급 모델을 로컬에서 진지하게 쓰기 시작하면, 결국 같은 모델의 GGUF와 EXL2를 둘 다 받아서 비교해보게 된다.
LM Studio: GUI 뒤에 있는 GPU 제어판
LM Studio는 그래픽 인터페이스 중심의 로컬 LLM 도구다. 모델 검색, 다운로드, 채팅, 서버 모드까지 한 화면에서 처리할 수 있어 입문자에게 인기가 많다. 예전에는 "예쁜 llama.cpp 래퍼"처럼 이해해도 크게 틀리지 않았지만, 최근 버전에서는 GPU 제어 기능이 점점 세밀해지고 있다.
LM Studio 0.3.14는 멀티 GPU 환경을 위한 제어 기능을 도입했다. 특정 GPU를 켜고 끄거나, GPU 할당 전략을 고르거나, 모델 가중치를 전용 GPU 메모리에만 올리도록 제한하는 기능이 포함되었다4. 이 기능은 로컬 사용자에게 꽤 중요하다. Windows 환경에서는 전용 VRAM이 부족할 때 "공유 GPU 메모리"라는 이름으로 시스템 RAM이 섞여 들어갈 수 있는데, 이 상태가 되면 속도가 크게 떨어진다. 겉으로는 GPU를 쓰는 것처럼 보여도 실제로는 PCIe를 건너 시스템 메모리를 들락날락하는 셈이다.
LM Studio에서 멀티 GPU를 다룰 때는 다음 순서로 접근하는 것이 좋다. 먼저 GPU 설정 창에서 모든 GPU가 보이는지 확인한다. 그다음 작은 모델을 하나 로드해 nvidia-smi 또는 작업 관리자에서 VRAM 사용량이 어느 GPU에 올라가는지 본다. 마지막으로 70B급 모델처럼 한 장에 들어가지 않는 모델을 로드하며 GPU별 할당이 어떻게 달라지는지 확인한다.
LM Studio의 강점은 실험의 문턱을 낮춘다는 점이다. 명령행 옵션을 외우지 않아도 GPU를 끄고 켜며 비교할 수 있다. 반대로 약점은 자동화와 GUI가 내부 동작을 가릴 수 있다는 점이다. "왜 이 GPU에는 3GB만 올라갔지?", "왜 컨텍스트를 늘리니 갑자기 느려졌지?" 같은 질문에 답하려면 결국 백엔드 로그와 VRAM 모니터링을 같이 봐야 한다.
KoboldCpp: 이야기 생성과 서버 기능에 강한 llama.cpp 계열
KoboldCpp는 GGML/GGUF 모델을 쉽게 실행하기 위한 올인원 서버 소프트웨어다. KoboldAI API 엔드포인트, KoboldAI Lite UI, 각종 로컬 생성 기능을 함께 제공하며, 내부적으로 llama.cpp 계열의 장점을 적극 활용한다5. 소설 작성, 롤플레잉, 캐릭터 대화, 장기 메모리 같은 기능을 중요하게 여기는 사용자에게 특히 익숙한 도구다.
멀티 GPU 관점에서 KoboldCpp는 llama.cpp를 더 사용하기 쉬운 형태로 감싼 도구라고 보면 된다. GPU 레이어 수를 지정하고, CuBLAS나 CLBlast 같은 가속 백엔드를 선택하며, GGUF 모델을 로드한다. GUI 런처를 통해 설정할 수도 있고, 명령행으로 실행할 수도 있다.
예를 들어 CUDA 빌드에서 GPU 레이어를 적극적으로 올리는 식의 실행은 다음과 비슷한 형태가 된다.
koboldcpp \
--model /models/llama-3.1-70b.Q4_K_M.gguf \
--usecublas \
--gpulayers 999다만 KoboldCpp에서 멀티 GPU 세부 제어가 어느 정도까지 가능한지는 사용하는 버전과 빌드 옵션에 따라 달라진다. 따라서 "KoboldCpp에서 안 되면 llama.cpp에서도 안 된다"라기보다, 먼저 KoboldCpp의 편한 UI로 시도하고, 한계에 부딪히면 llama.cpp 원본 명령으로 내려가 세부 옵션을 조정하는 방식이 좋다.
KoboldCpp의 진짜 가치는 추론 엔진 자체보다 사용 경험에 있다. 이야기 생성용 프롬프트, 월드 인포, 캐릭터 카드, 웹 UI가 중요하다면 KoboldCpp는 여전히 매력적이다. 반면 4장 이상의 GPU로 최대 처리량을 뽑아 API 서버를 운영하려는 목적이라면 다음 장에서 다룰 vLLM, SGLang, TensorRT-LLM 같은 프로덕션 엔진이 더 적합하다.
단일 GPU에 들어가면 굳이 나누지 말자
멀티 GPU를 처음 성공시키면 누구나 같은 유혹을 느낀다. "8B 모델도 두 장으로 나누면 더 빨라지지 않을까?" 대부분의 경우 답은 아니다.
작은 모델이 이미 한 장의 GPU에 온전히 들어간다면, 두 번째 GPU를 쓰는 순간 통신 비용이 추가된다. 레이어 분할에서는 중간 활성값이 GPU 사이를 넘어가야 하고, 텐서 분할에서는 더 자주 결과를 합쳐야 한다. 이 비용은 공짜가 아니다. 실제 로컬 멀티 GPU 벤치마크에서도 한 장에 들어가는 작은 모델은 GPU를 늘릴수록 오히려 토큰 속도가 조금씩 떨어지는 사례가 보고된다6.
따라서 로컬 도구를 비교할 때는 다음 기준으로 실험해야 한다.
모델이 한 장의 GPU에 완전히 들어가는가?
CPU/RAM 오프로딩이 발생하지 않는가?
같은 컨텍스트 길이와 같은 양자화 포맷으로 비교했는가?
프롬프트 처리 속도와 토큰 생성 속도를 따로 봤는가?
nvidia-smi,nvtop,rocm-smi등으로 실제 VRAM 배치를 확인했는가?
특히 프롬프트 처리, 즉 prefill 단계와 토큰 생성, 즉 decode 단계는 병목이 다르다. 긴 문서를 한 번에 넣는 작업에서는 프롬프트 처리 속도가 중요하고, 채팅처럼 한 토큰씩 이어서 받는 작업에서는 decode 속도가 체감 성능을 좌우한다. 어떤 도구는 prefill이 빠르고, 어떤 도구는 decode가 안정적이다. "초당 토큰 수" 하나만 보고 결론을 내리면 잘못된 선택을 하기 쉽다.
도구별 선택 기준
로컬 멀티 GPU 도구를 고를 때는 "무엇이 가장 빠른가"보다 "내 목적에 맞는 불편함은 무엇인가"를 물어야 한다. 모든 도구는 각자 다른 불편함을 갖고 있다.
llama.cpp는 가장 투명하다. -ngl, --split-mode, --tensor-split, --main-gpu를 바꿔가며 GPU 배치를 직접 확인할 수 있다. GGUF 모델 지원도 넓고, CPU 오프로딩까지 유연하다. 대신 사용자가 알아야 할 것이 많다.
Ollama는 가장 편하다. 모델 이름만으로 실행하고, API 서버로 붙이기 쉽다. 다만 멀티 GPU를 세밀하게 조정하기 어렵고, 자동 판단이 내 의도와 다를 수 있다.
ExLlamaV2는 NVIDIA GPU와 EXL2 모델이 준비되어 있을 때 강력하다. 고속 양자화 추론이 목적이라면 훌륭한 선택이다. 하지만 포맷과 하드웨어 선택지가 상대적으로 좁다.
LM Studio는 실험과 사용 경험이 좋다. GUI에서 GPU를 켜고 끄며 모델을 로드할 수 있고, 로컬 채팅 환경을 빠르게 만들 수 있다. 대신 깊은 튜닝에는 로그와 백엔드 이해가 필요하다.
KoboldCpp는 창작형 사용성에 강하다. 캐릭터, 스토리, KoboldAI 생태계를 쓰는 사람에게 적합하다. 멀티 GPU 극한 성능보다는 편리한 로컬 서버와 UI가 장점이다.
첫 실험 시나리오
가장 추천하는 첫 실험은 같은 모델을 세 가지 방식으로 실행해보는 것이다. 예를 들어 24GB GPU 두 장이 있다면 32B 모델 하나와 70B 모델 하나를 준비한다. 32B 모델은 단일 GPU에 들어갈 가능성이 높고, 70B 모델은 두 장이 필요할 가능성이 높다.
먼저 32B 모델을 GPU 0 하나에서 실행한다.
CUDA_VISIBLE_DEVICES=0 llama-server \
-m /models/qwen2.5-32b.Q4_K_M.gguf \
-c 8192 \
-ngl 999그다음 같은 모델을 두 GPU에 나눠 실행한다.
CUDA_VISIBLE_DEVICES=0,1 llama-server \
-m /models/qwen2.5-32b.Q4_K_M.gguf \
-c 8192 \
-ngl 999 \
--split-mode layer \
--tensor-split 24,24아마 큰 차이가 없거나 오히려 단일 GPU가 더 빠를 수 있다. 이 결과가 중요하다. 멀티 GPU는 마법의 가속 버튼이 아니라는 사실을 몸으로 확인하는 순간이다.
마지막으로 70B 모델을 실행한다.
CUDA_VISIBLE_DEVICES=0,1 llama-server \
-m /models/llama-3.1-70b.Q4_K_M.gguf \
-c 8192 \
-ngl 999 \
--split-mode layer \
--tensor-split 24,24이번에는 단일 GPU에서 실패하던 모델이 올라간다. 속도는 기대보다 폭발적이지 않을 수 있다. 하지만 CPU 오프로딩으로 1~3 tok/s를 보던 모델이 완전히 VRAM 안에 들어가 15~30 tok/s 수준으로 움직인다면, 체감은 완전히 달라진다. 멀티 GPU의 첫 번째 승리는 "더 빠름"이 아니라 "가능해짐"이다.
다음 단계로 넘어가기 전에
이번 장에서 본 도구들은 대부분 로컬 단일 노드에 초점을 맞춘다. PC 한 대 안에 GPU가 두 장 또는 네 장 있고, 그 안에서 모델을 어떻게 쪼개 올릴지 다룬다. 이 단계에서는 Kubernetes도, 멀티 노드 클러스터도, 복잡한 로드밸런서도 필요 없다.
하지만 사용자가 한 명이 아니라 여러 명이 되고, 동시 요청이 늘어나고, OpenAI 호환 API를 안정적으로 제공해야 하는 순간 이야기가 달라진다. 그때는 단순히 모델을 "올리는" 도구가 아니라 요청을 "처리하는" 추론 엔진이 필요하다. 배치 처리, KV 캐시 관리, 텐서 병렬, 파이프라인 병렬, 스케줄링이 전면에 등장한다.
그러니 지금은 이렇게 정리하자. 로컬에서 멀티 GPU를 시작하려면 먼저 llama.cpp로 원리를 확인하고, Ollama나 LM Studio로 편하게 써보며, EXL2가 필요한 경우 ExLlamaV2를 검토한다. KoboldCpp는 창작형 사용 경험이 중요할 때 좋은 선택이다. 그리고 모델이 한 장에 들어간다면 굳이 나누지 않는다. 이 단순한 원칙만 지켜도 멀티 GPU 시행착오의 절반은 줄어든다.
참고
1Multi-GPU and Distributed Inference | ggml-org/llama.cpp | DeepWiki
3ExLlamaV2: 일반 GPU에서 로컬 LLMs를 실행하기 위한 빠른 추론 라이브러리
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.