멀티 GPU LLM 구축 로드맵

출발점은 "가장 큰 모델"이 아니라 "가장 알맞은 시스템"이다

멀티 GPU LLM 구축에서 가장 흔한 착각은 "VRAM을 많이 모으면 더 좋은 시스템이 된다"는 생각이다. 물론 VRAM은 중요하다. 모델 가중치가 올라가야 하고, 긴 프롬프트와 대화 이력을 담는 KV 캐시도 필요하며, 동시 요청이 늘어나면 같은 모델이라도 메모리 요구량이 갑자기 커진다. 하지만 실제 운영에서 더 중요한 질문은 따로 있다.

"내가 해결하려는 문제는 무엇이고, 그 문제에 필요한 품질·속도·비용·보안 수준은 어디인가?"

개인 실험용 챗봇에 405B 모델을 억지로 올릴 필요는 없다. 반대로 사내 수천 명이 쓰는 RAG 시스템을 노트북 한 대의 7B 모델로 버티게 만들 수도 없다. 멀티 GPU는 목표가 아니라 수단이다. 단일 GPU에서 양자화와 컨텍스트 조절로 해결되는 문제라면 거기서 멈추는 것이 맞고, 모델이 들어가지 않거나 처리량이 부족할 때 비로소 듀얼 GPU, 4GPU 워크스테이션, 8GPU 서버, 멀티 노드 클러스터로 넘어가야 한다.

특히 KV 캐시는 끝까지 따라다니는 숨은 비용이다. KV 캐시는 이전 토큰들의 Key와 Value를 저장해 다음 토큰 생성 때 재계산을 피하게 해주는 메모리이며, 대략 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 컨텍스트 길이 × 배치 수 × 바이트 수에 비례해 커진다. 즉 컨텍스트 길이를 두 배로 늘리거나 동시 요청을 두 배로 늘리면 KV 캐시도 거의 두 배가 된다.¹ 모델 파일 크기만 보고 "48GB면 되겠지"라고 판단하면, 실제 서비스에서는 첫 번째 긴 문서 요약 요청에서 바로 OOM을 만날 수 있다.

이제 필요한 것은 장비 자랑이 아니라 로드맵이다. 어디서 시작하고, 언제 확장하고, 무엇을 기록해야 하며, 미래 기술이 바꿀 지점을 어떻게 대비할지 정리해보자.

다섯 가지 시나리오별 권장 아키텍처

LLM 시스템은 사용 목적에 따라 완전히 다른 모양이 된다. 아래 다섯 가지 시나리오는 대부분의 구축 계획을 분류하는 좋은 기준이다.

개인 로컬 실험의 최우선 가치는 "바로 돌려보는 속도"다. 이때는 GGUF 모델과 llama.cpp 계열 도구가 강하다. 듀얼 RTX 3090이나 4090 같은 소비자용 조합으로 70B Q3/Q4 모델을 시도할 수 있지만, 목표는 빠른 응답보다 "한 장에 안 들어가는 모델을 겨우 올리는 것"에 가깝다. PCIe 기반 소비자 멀티 GPU는 통신 오버헤드가 있으므로, 작은 모델을 굳이 나누면 오히려 느려질 수 있다.²

소규모 팀 API는 "개발자가 쓰기 쉬운 엔드포인트"가 중요하다. 이 단계부터는 OpenAI 호환 API, 스트리밍 응답, 토큰 사용량 로그, 간단한 인증, 재시작 스크립트가 필요하다. 모델이 단일 GPU에 들어간다면 vLLM 단일 인스턴스로 시작하고, 70B 이상이 필요하거나 동시 요청이 늘어나면 tensor parallel 또는 pipeline parallel을 붙인다.

사내 RAG는 모델 크기보다 컨텍스트 설계가 더 중요하다. 질문 하나에 문서 조각 20개를 무작정 붙이면 작은 모델도 느려지고 큰 모델도 비싸진다. 검색 품질, 리랭킹, 중복 제거, 프롬프트 압축이 먼저이고, 그다음에 긴 컨텍스트 모델과 KV 캐시 최적화를 붙여야 한다. 동일한 시스템 프롬프트나 문서 prefix가 반복된다면 prefix caching과 KV 캐시 관리가 큰 차이를 만든다.³

고동시성 SaaS는 "좋은 모델 하나"보다 "트래픽을 흘려보내는 구조"가 중요하다. 간단한 요청은 작은 모델로 보내고, 어려운 요청만 큰 모델로 올리는 라우팅이 비용을 크게 줄인다. GPU 서버 한 대가 아니라 모델 게이트웨이, 큐, 캐시, 모니터링, 장애 시 우회 경로가 함께 설계되어야 한다.

초대형 연구용 추론은 개인 장비 감각으로 접근하면 안 된다. 여기서는 GPU 개수보다 GPU 사이의 연결이 더 중요해진다. 텐서 병렬은 각 레이어 안의 계산을 여러 GPU가 동시에 나눠 처리하므로 빠른 인터커넥트가 필요하다. NVLink나 NVSwitch가 없는 PCIe 환경에서 TP=4, TP=8을 기대하면 계산보다 통신에 시간을 쓰게 된다. 반면 파이프라인 병렬은 레이어 묶음을 순서대로 나누기 때문에 PCIe나 멀티 노드 환경에서도 비교적 현실적이다.⁴

확장은 계단처럼, 되돌릴 수 있게 한다

멀티 GPU 구축은 한 번에 최종형으로 가면 실패하기 쉽다. 좋은 로드맵은 "다음 단계로 넘어갈 명확한 조건"과 "돌아올 수 있는 기준"을 함께 가진다.

0단계에서는 무조건 계산부터 한다. 모델 가중치, KV 캐시, 런타임 오버헤드를 더하고, VRAM의 10~20%는 남긴다. 단일 GPU에서 할 수 있는 최적화는 생각보다 많다. 모델을 Q4나 AWQ/GPTQ로 낮추고, 컨텍스트를 실제 필요한 길이로 제한하고, KV 캐시를 FP8이나 Q8로 줄이고, max batch와 max sequence를 조절한다. 많은 경우 "멀티 GPU가 필요하다"는 결론은 "컨텍스트를 128K로 잡아놓았다"는 설정 실수에서 나온다.

1단계 듀얼 GPU는 70B 모델을 로컬에서 다루고 싶을 때 가장 현실적인 입구다. 소비자용 GPU라면 llama.cpp의 layer split이나 Ollama의 자동 분산처럼 통신량이 적은 방식이 편하다. vLLM을 쓴다면 동일 GPU 두 장에서 tensor parallel을 시도할 수 있지만, PCIe 환경에서는 선형 성능 향상을 기대하지 않는 것이 좋다. vLLM 계열 문서와 벤치마크들은 PagedAttention, continuous batching, tensor parallel을 강점으로 설명하지만, PCIe와 NVLink 사이의 효율 차이도 분명히 지적한다.⁵

2단계 4GPU 워크스테이션은 "연구실 책상 위의 작은 서버"에 가깝다. 이 단계에서는 메인보드 PCIe 레인, 케이스 슬롯 간격, 전원공급장치, 배기 흐름이 모델 선택만큼 중요하다. 4개의 GPU를 꽂았는데 실제로는 x16/x4/x4/x4로 동작한다면 텐서 병렬 성능은 기대보다 크게 떨어질 수 있다. 이 구간에서는 한 모델을 4장에 나누는 것과, 2장씩 두 모델을 독립 서빙하는 것 중 어느 쪽이 더 이득인지 반드시 측정해야 한다.

3단계 8GPU 서버는 프로덕션과 연구가 만나는 구간이다. 여기서는 TP=8, TP×PP 조합, MoE expert parallel, FP8 추론, prefix caching, speculative decoding 같은 선택지가 열린다. 하지만 동시에 NCCL 오류, 드라이버 버전, 컨테이너 런타임, GPU 토폴로지, 장애 복구 같은 운영 문제가 전면에 등장한다.

4단계 멀티 노드 클러스터는 마지막 수단이자 별도의 전문 영역이다. 멀티 노드에서는 GPU 통신뿐 아니라 노드 간 네트워크, 모델 파일 배포, 캐시 이동, 스케줄링, 장애 격리가 성능을 좌우한다. Apache Spark 기반 배치 추론처럼 데이터 처리가 중심인 경우에는 각 executor에서 모델을 직접 중복 로드하는 방식보다, 노드별 추론 서버를 띄우고 CPU 작업과 GPU 서빙을 분리하는 구조가 더 안정적일 수 있다.⁶

하나의 의사결정 매트릭스로 묶기

실제 구축 회의에서는 "어떤 GPU를 살까?"보다 "어떤 조합을 선택할까?"가 더 어렵다. 다음 매트릭스는 모델 선택부터 운영 플랫폼까지 한 번에 이어 보는 방법이다.

이 표의 핵심은 세로 방향의 일관성이다. 예를 들어 개인 실험용인데 128K 컨텍스트, 70B FP16, Kubernetes, 멀티 노드 클러스터를 동시에 고르면 과하다. 반대로 고동시성 SaaS인데 Ollama 하나를 screen 세션에서 띄우고 운영한다면 언젠가 반드시 무너진다.

좋은 설계는 "가장 비싼 선택"이 아니라 "서로 맞는 선택"이다. 32B Q4 모델, 8K 컨텍스트, vLLM 단일 GPU, 간단한 API 게이트웨이가 70B 멀티 GPU보다 더 좋은 제품 경험을 줄 수 있다. RAG 품질이 좋고 요청 라우팅이 잘 되어 있다면 더더욱 그렇다.

처음부터 운영 자산을 남긴다

실험을 많이 했는데 남는 것이 "그때는 됐는데 지금은 안 된다"뿐이라면, 그것은 구축이 아니라 소비다. 멀티 GPU 시스템은 기록을 남겨야 자산이 된다. 첫날부터 다음 네 가지를 저장하자.

첫째, 벤치마크 기록이다. 모델명, 체크포인트 해시, 양자화 형식, 컨텍스트 길이, 입력 토큰 수, 출력 토큰 수, 동시 요청 수, TTFT, tokens/sec, p50/p95/p99 지연시간, GPU별 VRAM 사용량, GPU utilization, 전력 사용량을 함께 남긴다. 단일 프롬프트 속도만 적으면 서비스 성능을 예측할 수 없다. 짧은 질의, 긴 RAG 질의, 코드 생성, JSON 구조화 출력처럼 실제 업무를 대표하는 프롬프트 세트를 만들어야 한다.

둘째, 설정 파일이다. docker run 한 줄, vllm serve 옵션, llama-server 옵션, 환경 변수, CUDA_VISIBLE_DEVICES, NCCL 관련 변수, 컨테이너 이미지 태그, 드라이버 버전, CUDA 버전, 커널 버전까지 저장한다. 병렬화 설정은 모델의 일부처럼 취급해야 한다. TP=2에서 TP=4로 바꾸면 부동소수점 연산 순서와 통신 방식이 달라져 결과가 미세하게 달라질 수 있기 때문이다.

셋째, 장애 로그다. OOM, NCCL timeout, CUDA illegal memory access, 토큰 스트리밍 중단, 특정 길이 이상에서만 발생하는 timeout, 팬 속도 상승 후 thermal throttling 같은 사건을 날짜와 설정과 함께 남긴다. 장애 로그는 창피한 기록이 아니라 다음 구매 결정을 막아주는 보험이다.

넷째, 비용 데이터다. 장비 구매가, 중고 감가, 전기요금, 클라우드 시간당 비용, 월간 토큰 처리량, 토큰당 비용, 장애 대응 시간까지 계산한다. "로컬이 싸다"와 "클라우드가 싸다"는 고정된 진리가 아니다. 24시간 항상 켜두는 내부 API라면 로컬 서버가 유리할 수 있고, 월말에만 몰리는 배치 작업이라면 클라우드 spot 인스턴스가 더 나을 수 있다.

실무에서는 아래와 같은 간단한 기록 포맷만으로도 충분히 큰 차이가 난다.

run_id: 2026-05-06-llama70b-q4-dual4090
model: meta-llama/Llama-3.1-70B-Instruct
quantization: AWQ or GGUF Q4_K_M
framework: vLLM 0.x or llama.cpp build hash
hardware: 2x RTX 4090, PCIe 4.0 x8/x8
parallelism: tensor_parallel_size=2 or split_mode=layer
context_length: 8192
concurrency: 1, 8, 32
metrics:
  ttft_ms_p50: 0
  output_tps_total: 0
  latency_ms_p95: 0
  gpu_vram_gb: [0, 0]
  power_watts: 0
notes: OOM, throttling, 품질 이슈, 설정 변경 이유

이 파일이 쌓이면 조직의 추론 인프라 지도가 된다. 다음 GPU를 살 때, 모델을 바꿀 때, 클라우드로 넘길 때 감이 아니라 데이터로 결정할 수 있다.

미래 변화: VRAM 벽은 사라지지 않고 모양이 바뀐다

앞으로 멀티 GPU LLM 운영은 다섯 방향으로 변할 가능성이 크다.

첫째, FP8과 FP4가 기본 선택지로 내려온다. H100 이후 세대와 Blackwell 계열에서는 FP8 추론, NVFP4/MXFP4 같은 더 낮은 정밀도 형식이 모델 가중치와 KV 캐시 양쪽에서 점점 중요해진다. TensorRT-LLM과 DGX Spark 계열 자료에서도 커널 퓨전, 효율적인 메모리 레이아웃, FP8·FP4 계열 양자화가 처리량과 지연시간 개선의 핵심으로 다뤄진다.⁷ 다만 낮은 정밀도는 공짜가 아니다. 요약, 분류, 간단한 Q&A에서는 차이가 작아도, 수학 추론이나 긴 문서 근거 질의에서는 품질 검증이 필요하다.

둘째, Wide-EP가 MoE 운영의 중심이 된다. MoE 모델은 전체 파라미터는 거대하지만 토큰마다 일부 expert만 활성화한다. 이 구조에서는 전문가를 여러 GPU에 어떻게 배치하느냐가 중요하다. 단순 TP만 쓰면 KV 캐시가 중복되거나 expert 통신이 비효율적일 수 있다. 앞으로는 expert parallel과 data parallel을 섞어, 요청은 나누고 expert는 넓게 펼치는 방식이 더 흔해질 것이다.

셋째, prefill-decode disaggregation이 장문 서비스의 표준 패턴이 될 수 있다. LLM 추론은 긴 프롬프트를 처음 읽는 prefill 단계와 토큰을 하나씩 뽑는 decode 단계의 성격이 다르다. prefill은 대량 행렬 연산과 긴 컨텍스트 처리가 중요하고, decode는 낮은 지연시간과 KV 캐시 접근이 중요하다. 두 단계를 서로 다른 GPU 풀로 분리하고 KV 캐시를 넘겨주는 구조가 성숙하면, RAG와 장문 reasoning 서비스의 비용 구조가 크게 바뀐다.

넷째, KV cache offloading은 "비상용"에서 "설계 요소"로 올라온다. 지금도 CPU RAM이나 NVMe로 KV 캐시를 넘기는 방식은 가능하지만, 지연시간 증가가 부담이다. 그러나 캐시 압축, 계층형 메모리, 캐시 인식 라우팅이 발전하면 모든 요청을 비싼 HBM 안에만 붙잡아두지 않아도 된다. 최근 KV 캐시 최적화 연구들은 eviction, compression, hybrid memory, 새로운 attention, 조합 전략으로 이 문제를 다룬다.⁸

다섯째, heterogeneous cluster가 현실화된다. 모든 노드가 같은 GPU일 필요는 점점 줄어들 수 있다. 예를 들어 H100/B200 노드는 큰 모델과 긴 prefill을 담당하고, L40S나 RTX PRO급 노드는 작은 모델 라우팅과 embedding, reranking을 맡고, Mac mini나 소형 AI 노드는 사내 보조 작업과 캐시·전처리를 담당할 수 있다. 이때 중요한 것은 "서로 다른 장비를 억지로 하나의 거대한 GPU처럼 묶는 것"이 아니라, 각 장비가 잘하는 일을 분리하는 것이다.

최종 로드맵: 작게 시작하고, 숫자로 확장하라

멀티 GPU LLM 구축의 가장 안전한 순서는 다음과 같다.

먼저 업무를 정의한다. 챗봇인지, RAG인지, 코드 생성인지, 배치 요약인지, 외부 사용자 API인지에 따라 필요한 모델과 지연시간이 달라진다. 다음으로 평가셋을 만든다. 모델을 고르기 전에 "이 정도 답변이면 충분하다"를 판단할 질문 묶음이 있어야 한다. 그다음 단일 GPU에서 가장 작은 쓸 만한 모델을 돌린다. 여기서 컨텍스트, 양자화, KV 캐시, batching을 조절하며 기준 성능을 만든다.

그 기준을 넘어서야 할 때만 듀얼 GPU로 간다. 듀얼 GPU에서도 먼저 모델을 올리는 데 성공하고, 그다음 처리량을 본다. 그다음 4GPU, 8GPU, 멀티 노드로 올라간다. 각 단계마다 같은 프롬프트, 같은 설정 기록, 같은 비용 계산을 남긴다. 그래야 "확장했더니 정말 좋아졌는가?"를 알 수 있다.

마지막으로, 큰 모델은 언제나 매력적이지만 좋은 시스템은 대개 균형에서 나온다. 작은 모델을 빠르게 쓰고, 어려운 요청만 큰 모델로 보내고, RAG로 지식을 보강하고, KV 캐시를 아끼고, GPU가 놀지 않게 batching하며, 장애가 나도 복구되는 구조를 만드는 것. 그것이 멀티 GPU LLM 구축의 진짜 목적이다.

가장 큰 모델을 억지로 돌리는 사람은 언젠가 VRAM 벽에 막힌다. 목적에 맞는 시스템을 설계하는 사람은 그 벽을 계단으로 바꾼다.

참고

¹KV Cache Optimization: Serve 10x More Users on the Same GPU (2026)

²Multi-GPU Local AI: Run Models Across Multiple GPUs

³LLM 서빙과 KV Cache, vLLM

⁴Multi-GPU LLM Inference: TP vs PP vs EP Parallelism Guide (2026)

⁵vLLM Multi-GPU Documentation — Tensor Parallelism Setup & Configs (2026)

⁶Accelerate Deep Learning and LLM Inference with Apache Spark in the Cloud

⁷TensorRT-LLM | NVIDIA/dgx-spark-playbooks | DeepWiki

⁸KV Cache Optimization Strategies for Scalable and Efficient LLM Inference - arXiv.org