멀티 GPU를 쓰기 전에 먼저 확인할 것들

멀티 GPU는 '업그레이드'가 아니라 '복잡도'다

대형 언어모델을 로컬에서 처음 돌려보면, 가장 먼저 부딪히는 벽은 대개 연산 성능이 아니라 VRAM이다. 모델 파일을 다운로드하고, 실행 명령을 입력하고, 잠시 설레는 마음으로 기다리다 보면 어느 순간 차갑게 뜨는 메시지가 있다. CUDA out of memory. GPU가 느려서가 아니라, 모델과 실행에 필요한 메모리가 GPU 안에 들어가지 않는다는 뜻이다.

이때 많은 사람이 자연스럽게 생각한다. "GPU를 하나 더 꽂으면 되지 않을까?"

절반은 맞고, 절반은 위험한 생각이다. 멀티 GPU는 분명히 큰 모델을 가능하게 만든다. 24GB GPU 한 장에는 올라가지 않던 70B 모델이 24GB GPU 두 장에서는 실행될 수 있다. 80GB GPU 한 장으로는 빠듯하던 모델이 네 장으로 나누면 훨씬 넉넉해진다. 하지만 멀티 GPU는 단순히 VRAM을 더하는 마법이 아니다. GPU 사이에 데이터를 주고받아야 하고, 프레임워크 설정이 복잡해지며, 전력·발열·드라이버·메인보드·PCIe 레인 같은 현실적인 문제가 한꺼번에 따라온다.

중요한 원칙은 이것이다. 멀티 GPU는 먼저 선택하는 기술이 아니라, 단일 GPU 최적화를 충분히 시도한 뒤에도 해결되지 않을 때 꺼내는 카드다.

이 장에서는 "언제 멀티 GPU가 필요한가?"라는 질문을 차분히 판단해보려 한다. 모델 크기만 보고 결정하면 안 된다. 같은 70B 모델이라도 FP16으로 실행하는지, INT4로 양자화하는지, 컨텍스트를 4K로 쓸지 128K로 쓸지, 동시에 몇 명의 사용자를 받을지에 따라 필요한 VRAM은 완전히 달라진다.

먼저 물어야 할 질문: 정말 그 모델이어야 하는가

멀티 GPU를 고민하기 전에 가장 먼저 던져야 할 질문은 "이 모델을 꼭 써야 하는가?"이다. 조금 허무하게 들릴 수 있지만, 실제 현장에서는 이 질문 하나가 수백만 원에서 수천만 원의 비용을 아껴준다.

예를 들어 단순한 고객 문의 분류, 짧은 문서 요약, 정해진 양식의 이메일 작성, 사내 FAQ 검색 보조 같은 작업에 반드시 70B 모델이 필요한 것은 아니다. 잘 고른 8B나 14B 모델이 더 빠르고, 더 저렴하고, 운영하기 쉬울 수 있다. 특히 도메인이 좁은 업무라면 범용 70B 모델보다 해당 분야 데이터로 튜닝된 7B~32B 모델이 더 안정적인 답을 줄 때도 많다.

대형 모델은 힘이 세다. 하지만 힘이 센 만큼 무겁다. 매번 트럭을 몰고 편의점에 갈 필요가 없듯, 매번 70B나 405B 모델을 꺼낼 필요는 없다. 로컬 LLM 구축에서 가장 좋은 설계는 "가장 큰 모델을 돌리는 설계"가 아니라 "목표 품질을 만족하는 가장 작은 모델을 빠르고 안정적으로 돌리는 설계"다.

실제로 모델 메모리의 기본 계산은 단순하다. 파라미터 수에 파라미터당 바이트 수를 곱하면 대략적인 가중치 메모리가 나온다. FP16/BF16은 파라미터당 2바이트, INT8은 1바이트, INT4는 0.5바이트로 보면 된다. 그래서 70B 모델은 FP16에서 가중치만 약 140GB, INT4에서는 약 35GB가 된다.¹ 하지만 이것은 시작점일 뿐이다. 여기에 KV 캐시, 활성값, 프레임워크 오버헤드, 메모리 단편화가 붙는다.

모델 크기별로 보는 멀티 GPU 필요성

멀티 GPU가 필요한지 판단할 때는 모델 크기를 네 구간으로 나누면 이해하기 쉽다. 35B 이하, 70B INT4, 70B FP16, 그리고 405B 이상이다. 물론 실제 모델 구조와 양자화 방식에 따라 숫자는 흔들리지만, 이 구간 구분은 하드웨어 예산을 세울 때 매우 유용하다.

35B 이하 모델: 대개 단일 GPU 최적화부터

35B 이하 모델은 멀티 GPU를 고민하기 전에 단일 GPU 최적화를 먼저 시도해야 하는 구간이다. 7B~9B 모델은 4비트 양자화 기준으로 8GB GPU에서도 실행 가능한 경우가 많고, 13B 모델은 12GB~16GB VRAM에서 현실적인 선택지가 된다. 27B~35B 모델은 4비트 양자화 기준으로 대략 16GB~24GB급 VRAM이 필요하므로, RTX 3090·4090 같은 24GB 카드나 32GB급 GPU에서는 충분히 시도해볼 만하다.²

다만 "35B 이하 = 무조건 단일 GPU 가능"은 아니다. FP16으로 32B 모델을 올리려면 가중치만 약 64GB가 필요하다. 이 경우에는 소비자용 단일 GPU로 어렵고, 48GB 이상의 워크스테이션 GPU나 멀티 GPU가 필요할 수 있다. 그러나 로컬 추론의 현실적인 출발점은 보통 FP16이 아니라 Q4, Q5, Q8 같은 양자화 모델이다. 따라서 35B 이하에서는 먼저 다음을 확인하는 편이 좋다.

• Q4 또는 Q5 양자화 모델로 품질이 충분한가

• 최대 컨텍스트를 실제 필요한 길이로 줄일 수 있는가

• 같은 작업을 더 작은 도메인 특화 모델이 처리할 수 있는가

• 단일 24GB 또는 32GB GPU로 실행 가능한 추론 도구가 있는가

이 구간에서 멀티 GPU를 쓰는 것은 보통 "필요"라기보다 "실험"에 가깝다. 특히 모델이 이미 한 장의 GPU에 들어간다면, 두 장으로 나누는 순간 오히려 느려질 가능성이 있다. 이에 대해서는 뒤에서 자세히 설명하겠다.

70B INT4: 소비자용 멀티 GPU의 대표적인 경계선

70B 모델은 로컬 LLM 사용자들이 멀티 GPU를 본격적으로 고민하게 되는 대표적인 지점이다. 70B 모델을 INT4로 양자화하면 가중치만 약 35GB다. 여기에 KV 캐시와 실행 오버헤드를 더하면 실제로는 40GB대 중후반을 예상하는 것이 안전하다. Llama 3 계열 70B 모델도 4비트 양자화에서 대략 35~40GB 이상의 VRAM을 요구하는 것으로 자주 계산된다.³

이 말은 24GB GPU 한 장으로는 어렵고, 32GB GPU 한 장도 컨텍스트와 백엔드에 따라 빠듯할 수 있다는 뜻이다. 반면 48GB 워크스테이션 GPU 한 장이나 24GB GPU 두 장은 70B INT4 모델을 실행할 수 있는 후보가 된다. 그래서 듀얼 RTX 3090, 듀얼 RTX 4090, 혹은 48GB급 RTX 6000 Ada/L40S 같은 카드가 이 구간에서 자주 거론된다.

하지만 여기서도 멀티 GPU가 유일한 답은 아니다. 만약 70B INT4를 꼭 써야 하는 이유가 "품질"이라면, 먼저 32B급 최신 모델이나 도메인 특화 모델과 비교해야 한다. 코딩, 수학, 한국어 문서 요약, 법률 문서 검색처럼 과제가 명확하다면 70B 범용 모델보다 32B 특화 모델이 더 나은 비용 대비 성능을 낼 수 있다.

70B INT4에서 멀티 GPU는 다음 조건일 때 설득력이 커진다.

• 24GB 또는 32GB 단일 GPU에 모델과 KV 캐시가 들어가지 않는다.

• 48GB 이상 단일 GPU를 사는 것보다 24GB GPU 두 장을 구성하는 편이 비용상 유리하다.

• 약간의 설정 복잡도와 통신 오버헤드를 감수할 수 있다.

• 긴 컨텍스트나 동시 요청 때문에 40GB대 VRAM으로도 여유가 부족하다.

반대로 단일 48GB GPU가 예산 안에 들어오고, 운영 안정성이 중요하다면 멀티 GPU보다 큰 단일 GPU가 더 좋은 선택일 수 있다. 한 장짜리 GPU는 GPU 간 통신도, 파이프라인 분할도, 카드별 발열 차이도 없다. 단순함은 운영에서 강력한 성능이다.

70B FP16: 멀티 GPU가 사실상 필수인 구간

70B 모델을 FP16 또는 BF16으로 실행하려면 가중치만 약 140GB가 필요하다. 이 숫자에는 KV 캐시도, 활성값도, CUDA나 추론 엔진의 오버헤드도 들어 있지 않다. 실제 운영에서는 이보다 훨씬 넉넉한 VRAM이 필요하다.¹

이 구간은 소비자용 멀티 GPU의 영역을 넘어서는 경우가 많다. 24GB GPU 여섯 장을 합치면 이론상 144GB가 되지만, 실제로는 각종 오버헤드와 분할 비효율 때문에 안정적인 운영이 어렵다. 또한 소비자용 메인보드에서 여러 장의 GPU를 충분한 PCIe 대역폭으로 연결하는 것도 쉽지 않다.

70B FP16은 보통 A100 80GB, H100 80GB, H200 141GB 같은 데이터센터급 GPU를 여러 장 사용하는 쪽으로 판단해야 한다. 예를 들어 2장의 80GB GPU에 70B FP16을 나누면 가중치만 GPU당 약 70GB가 들어간다. 남는 공간은 약 10GB뿐이므로 긴 컨텍스트나 높은 동시성에는 빠듯하다. 4장의 80GB GPU를 쓰면 가중치가 GPU당 약 35GB로 줄어 KV 캐시와 배치 공간이 훨씬 넉넉해진다.⁴

즉, 70B FP16을 쓰고 싶다면 질문이 바뀐다. "멀티 GPU가 필요한가?"가 아니라 "몇 장이 필요한가?"가 된다.

405B 이상 모델: 단일 노드도 부족할 수 있다

405B 이상 모델은 완전히 다른 체급이다. 405B 모델은 FP16 기준으로 가중치만 약 810GB가 필요하고, INT4로 낮춰도 약 200GB 이상이 필요하다.⁴ 여기에 KV 캐시와 오버헤드가 더해진다. 이 정도가 되면 듀얼 24GB 같은 소비자용 구성은 출발선에도 서기 어렵다.

이 구간에서는 멀티 GPU가 아니라 멀티 노드, 즉 여러 대의 GPU 서버를 묶는 클러스터까지 고려하게 된다. 단일 서버 안의 4장 또는 8장 GPU로 해결할 수 있는지, 여러 서버 사이에 InfiniBand나 고속 이더넷을 붙여야 하는지, 모델을 텐서 병렬·파이프라인 병렬·전문가 병렬로 어떻게 나눌지까지 설계해야 한다.

또한 405B 이상에서는 "로컬에서 반드시 직접 돌려야 하는가?"라는 질문도 냉정하게 해야 한다. 연구 재현성, 데이터 보안, 모델 커스터마이징, 장기적 비용 절감 같은 이유가 분명하다면 자체 클러스터가 의미 있다. 하지만 가끔 실험하거나 데모를 만드는 정도라면 클라우드 GPU나 API 사용이 훨씬 합리적일 수 있다.

모델 가중치보다 무서운 것: KV 캐시와 컨텍스트

앞 장에서 VRAM 계산을 다뤘다면, 여기서는 의사결정 관점에서 다시 강조하고 싶다. 많은 사람이 모델 가중치만 보고 "들어가겠다"라고 판단한다. 그러나 실제 추론에서는 모델이 읽고 생성하는 토큰의 흔적도 VRAM에 남는다. 이것이 KV 캐시다.

LLM은 한 토큰씩 다음 토큰을 생성한다. 이때 이전 토큰들의 attention 계산 결과 중 key와 value를 저장해두면, 매번 처음부터 다시 계산하지 않아도 된다. 덕분에 생성 속도는 빨라지지만, 저장 공간이 필요하다. KV 캐시는 레이어 수, KV 헤드 수, 헤드 차원, 시퀀스 길이, 배치 크기, 데이터 타입에 비례해서 커진다. 일반적인 형태의 계산식은 다음과 같다.⁵

KV 캐시 메모리 ≈ 2 × 레이어 수 × 배치 크기 × 시퀀스 길이 × KV 헤드 수 × 헤드 차원 × 바이트 수

여기서 중요한 것은 모든 항목이 거의 선형으로 증가한다는 점이다. 컨텍스트를 8K에서 32K로 늘리면 KV 캐시도 대략 4배가 된다. 동시에 처리하는 요청 수를 1개에서 8개로 늘리면 KV 캐시도 8배가 된다. 모델 가중치는 한 번 올라가면 고정되어 있지만, KV 캐시는 사용 방식에 따라 계속 커진다.

예를 들어 70B 모델을 4비트로 줄여 가중치가 약 35GB가 되었다고 하자. "48GB면 충분하겠네"라고 생각할 수 있다. 짧은 컨텍스트에 단일 사용자라면 가능할 수 있다. 하지만 32K 컨텍스트, 여러 동시 요청, FP16 KV 캐시를 쓰기 시작하면 여유 공간은 순식간에 사라진다. 실제로 긴 컨텍스트에서는 KV 캐시가 모델 가중치만큼이나 중요한 VRAM 소비자가 된다.⁶

그래서 멀티 GPU를 결정하기 전에 반드시 확인해야 한다. 내가 필요한 것은 큰 모델인가, 긴 컨텍스트인가, 많은 동시 사용자인가? 이 셋은 모두 VRAM을 요구하지만 해결 방식이 다르다.

멀티 GPU 없이 먼저 시도할 수 있는 방법들

멀티 GPU로 가기 전에는 비용이 낮고 복잡도가 작은 방법부터 차례로 시도해야 한다. 좋은 최적화는 GPU를 추가하지 않고도 문제를 해결한다.

더 작은 모델을 고른다

가장 단순하지만 가장 강력한 방법이다. 70B 모델을 실행하려는 이유가 막연히 "더 똑똑할 것 같아서"라면, 먼저 32B나 14B 모델을 실제 작업으로 평가해야 한다. 최근의 작은 모델들은 생각보다 강하다. 특히 코딩, 수학, 번역, 도메인 질의응답처럼 특정 능력에 집중한 모델은 파라미터 수가 작아도 훌륭한 결과를 낸다.

작은 모델의 장점은 VRAM만이 아니다. 로딩이 빠르고, 응답이 빠르고, 장애가 적다. 같은 GPU에서 더 많은 동시 요청을 처리할 수 있고, 긴 컨텍스트를 조금 더 여유 있게 쓸 수도 있다. 모델 크기가 줄면 운영 전체가 가벼워진다.

도메인 특화 모델을 쓴다

범용 모델은 넓은 세상을 상대하기 위해 많은 지식을 담는다. 하지만 우리가 필요한 일이 좁다면, 그 넓이가 오히려 낭비가 될 수 있다. 사내 규정 검색, 의료 문서 분류, 법률 판례 요약, 개발 문서 질의응답처럼 영역이 분명하다면 도메인 특화 모델이나 작은 모델에 RAG를 결합하는 방식이 더 효율적일 수 있다.

예를 들어 사내 문서를 바탕으로 답변하는 챗봇이라면 모델 자체가 모든 지식을 외울 필요가 없다. 검색 시스템이 관련 문서를 찾아주고, 모델은 그 문서를 읽고 답을 구성하면 된다. 이 경우 거대한 70B 모델보다 빠른 8B~32B 모델이 더 실용적일 수 있다.

양자화를 적용한다

양자화는 멀티 GPU를 피할 수 있는 가장 강력한 도구다. FP16에서 INT8로 낮추면 가중치 메모리가 절반으로 줄고, INT4로 낮추면 대략 4분의 1 수준이 된다. 70B 모델이 FP16에서는 약 140GB지만 INT4에서는 약 35GB가 되는 이유다.¹

물론 양자화는 공짜가 아니다. 정밀도를 낮추기 때문에 일부 작업에서 품질이 떨어질 수 있다. 특히 복잡한 추론, 수학, 코드 생성, 긴 문맥에서 미묘한 차이가 나타날 수 있다. 하지만 현대적인 GPTQ, AWQ, GGUF 계열 4비트 양자화는 일반적인 챗봇, 요약, 질의응답 작업에서 꽤 좋은 품질을 보여준다. 따라서 "FP16이 아니면 안 된다"는 요구가 명확하지 않다면, 먼저 Q4나 Q5 모델을 테스트하는 것이 합리적이다.

최대 컨텍스트를 줄인다

많은 추론 도구는 모델이 지원하는 최대 컨텍스트를 그대로 쓰도록 설정할 수 있다. 하지만 모델이 128K 컨텍스트를 지원한다고 해서 매번 128K를 잡아야 하는 것은 아니다. 컨텍스트는 일종의 책상 크기다. 책상이 크면 많은 문서를 펼칠 수 있지만, 그만큼 공간 비용이 든다.

실제 서비스에서 사용자가 평균 2K~4K 토큰만 입력한다면 max context를 32K나 128K로 열어둘 이유가 없다. 최대 컨텍스트를 줄이면 KV 캐시 예산이 줄어들고, 같은 GPU에서 더 안정적으로 운영할 수 있다. 긴 문서 처리가 필요하다면 전체 문서를 한 번에 밀어 넣기보다 청크 분할, 검색, 요약 캐시, 계층적 요약 같은 구조를 먼저 고민해야 한다.

KV 캐시 dtype을 낮춘다

모델 가중치만 양자화할 수 있는 것이 아니다. KV 캐시도 낮은 정밀도로 저장할 수 있다. FP16/BF16 KV 캐시를 FP8로 낮추면 KV 캐시 메모리를 줄일 수 있고, 일부 최신 하드웨어에서는 더 낮은 정밀도의 KV 캐시도 활용된다. NVIDIA는 Blackwell GPU에서 NVFP4 KV 캐시가 FP8 대비 KV 캐시 메모리를 약 50% 줄이고, 긴 컨텍스트와 큰 배치에서 이점을 줄 수 있다고 설명한다.⁷

다만 KV 캐시 양자화는 하드웨어와 추론 엔진 지원이 중요하다. 모든 GPU와 모든 프레임워크에서 같은 방식으로 동작하지 않는다. 또한 품질 민감도가 높은 작업에서는 실제 데이터로 검증해야 한다. 그래도 긴 컨텍스트 때문에 VRAM이 터지는 상황이라면, GPU를 추가하기 전에 반드시 확인해볼 만한 선택지다.

모델이 한 장에 들어가면, 나누지 않는 것이 빠를 때가 많다

멀티 GPU를 처음 접하면 "GPU가 두 장이면 두 배 빠르겠지"라고 기대하기 쉽다. 하지만 LLM 추론에서는 자주 그렇지 않다. 특히 모델이 이미 단일 GPU에 들어간다면, 멀티 GPU로 나누는 순간 오히려 느려질 수 있다.

이유는 단순하다. 한 장의 GPU 안에서 계산할 때는 데이터가 GPU 내부의 초고속 VRAM과 연산 유닛 사이를 오간다. 하지만 두 장 이상의 GPU로 나누면 중간 결과를 GPU 사이에서 주고받아야 한다. 이때 통로는 NVLink나 PCIe다. GPU 내부 메모리 대역폭은 초당 수백 GB에서 1TB를 넘기도 하지만, 소비자용 시스템의 PCIe 대역폭은 그보다 훨씬 낮다. 즉, 계산은 빠른데 서로 대화하는 길이 좁다.

통신 오버헤드: 계산보다 대화가 느려지는 순간

텐서 병렬은 한 레이어 안의 큰 행렬 계산을 여러 GPU가 나눠서 처리한다. 이 방식은 모든 GPU가 동시에 일할 수 있어 좋아 보인다. 하지만 각 레이어 계산 후에는 "내가 계산한 조각"을 서로 합쳐야 한다. 이 동기화가 반복된다. 레이어가 80개인 모델이라면 이런 통신이 수십 번, 수백 번 발생한다.

NVLink가 있는 데이터센터 GPU에서는 이 비용이 비교적 작다. 그러나 PCIe만 있는 소비자용 GPU에서는 통신 시간이 무시하기 어렵다. 그래서 PCIe 환경에서 텐서 병렬을 무리하게 쓰면 GPU 사용률은 높아 보이는데 실제 토큰 생성 속도는 기대만큼 나오지 않는 일이 생긴다. 일부 자료는 PCIe 기반 텐서 병렬에서 통신이 추론 시간의 큰 비중을 차지할 수 있다고 지적한다.⁴

비유하자면 두 명의 요리사가 하나의 요리를 나눠 만드는 상황과 비슷하다. 각자 칼질은 빠르지만, 매 단계마다 "이제 네 재료 줘", "간은 맞췄어?", "다음 순서로 넘어가도 돼?"라고 확인해야 한다면 혼자 조용히 만드는 것보다 늦어질 수 있다.

파이프라인 버블: 기다리는 GPU가 생긴다

파이프라인 병렬은 모델의 레이어를 순서대로 나눠 배치한다. 예를 들어 GPU 0이 앞쪽 레이어를 처리하고, GPU 1이 뒤쪽 레이어를 처리한다. 이 방식은 통신량이 텐서 병렬보다 적어서 PCIe 환경에 잘 맞는다. 하지만 다른 문제가 있다. 바로 파이프라인 버블이다.

하나의 요청만 처리한다고 생각해보자. 먼저 GPU 0이 일한다. 이때 GPU 1은 기다린다. GPU 0이 끝내고 결과를 넘기면 GPU 1이 일한다. 이제 GPU 0은 기다린다. 마치 컨베이어 벨트에 물건이 하나밖에 없는 공장처럼, 어느 한쪽은 계속 쉬게 된다.

동시 요청이 많으면 이 빈 시간을 어느 정도 메울 수 있다. GPU 1이 첫 번째 요청의 뒤쪽 레이어를 처리하는 동안 GPU 0이 두 번째 요청의 앞쪽 레이어를 처리할 수 있기 때문이다. 하지만 개인용 로컬 추론처럼 한 번에 하나의 대화만 주고받는 상황에서는 파이프라인 병렬이 단일 GPU보다 느려질 수 있다.

이것이 "모델이 한 장에 들어가면 그냥 한 장에서 돌려라"라는 조언의 이유다. 멀티 GPU는 용량 문제를 해결하기 위해 쓰는 경우가 많지, 작은 모델을 무조건 빠르게 만들기 위한 도구가 아니다. 실제 커뮤니티 벤치마크에서도 한 장에 들어가는 8B 모델을 여러 GPU로 나누면 오히려 토큰 속도가 떨어지는 사례가 보고된다.⁸

두 종류의 멀티 GPU를 구분하자

멀티 GPU라고 해서 모두 같은 방식은 아니다. 특히 추론에서는 두 가지 목적을 분명히 나눠야 한다. 하나는 모델이 안 들어가서 나누는 멀티 GPU이고, 다른 하나는 처리량을 늘리기 위한 복제형 멀티 GPU다.

모델이 안 들어가서 쓰는 멀티 GPU

첫 번째는 우리가 지금까지 주로 이야기한 방식이다. 한 장의 GPU에 모델이 들어가지 않으니 모델 자체를 여러 GPU에 나눠 싣는다. 텐서 병렬, 파이프라인 병렬, 레이어 분할, 샤딩 같은 말들이 이 범주에 들어간다.

이 방식의 목표는 "하나의 거대한 모델을 실행 가능하게 만드는 것"이다. 예를 들어 45GB가 필요한 70B Q4 모델을 24GB GPU 두 장에 나눠 올리는 식이다. 사용자는 하나의 모델과 대화하지만, 내부에서는 여러 GPU가 각자 맡은 조각을 계산한다.

장점은 명확하다. 단일 GPU로 불가능했던 모델을 실행할 수 있다. 더 높은 양자화 품질을 선택할 수도 있다. 예를 들어 32B 모델을 Q4가 아니라 Q8로 올리고 싶을 때 여러 GPU가 도움이 될 수 있다.

단점도 분명하다. GPU 사이 통신이 필요하고, 설정이 복잡하며, 어느 한 GPU가 느리거나 VRAM이 부족하면 전체가 영향을 받는다. 또한 모든 프레임워크가 모든 병렬 방식을 똑같이 지원하지 않는다. vLLM은 텐서 병렬과 파이프라인 병렬을 제공하고, llama.cpp는 소비자 환경에서 레이어 분할 방식으로 자주 쓰이며, 도구마다 설정 방식과 성능 특성이 다르다.⁹

처리량을 늘리기 위한 복제형 멀티 GPU

두 번째는 모델을 나누지 않고 복제하는 방식이다. 예를 들어 8B 모델이 12GB VRAM에 충분히 들어간다고 하자. 24GB GPU가 네 장 있다면, 하나의 8B 모델을 네 조각으로 쪼갤 필요가 없다. 각 GPU에 모델을 한 벌씩 올리고, 들어오는 요청을 네 GPU에 나눠 보내면 된다.

이것은 데이터 병렬 또는 복제형 서빙에 가깝다. GPU 0은 사용자 A를 처리하고, GPU 1은 사용자 B를 처리하고, GPU 2는 사용자 C를 처리한다. 각 요청은 한 장의 GPU 안에서 끝나므로 GPU 간 통신이 거의 없다. 대신 전체 서비스의 처리량이 늘어난다.

이 방식은 특히 프로덕션 서비스에서 중요하다. 모델이 단일 GPU에 잘 들어가고, 문제는 "한 명에게 빠르게 답하는 것"이 아니라 "동시에 많은 사람에게 답하는 것"이라면 복제형 멀티 GPU가 더 단순하고 효율적이다. 로드밸런서가 요청을 분산하고, 각 GPU 프로세스가 독립적으로 모델을 서빙하면 된다.

두 방식을 혼동하면 설계가 꼬인다. 모델이 한 장에 들어가는데 굳이 쪼개서 통신 오버헤드를 만들 필요가 없다. 반대로 모델이 한 장에 들어가지 않는데 복제형으로 여러 벌을 띄울 수도 없다. 먼저 목적을 정해야 한다.

판단을 위한 간단한 체크리스트

멀티 GPU를 구매하거나 설정하기 전에, 다음 질문에 답해보자.

• 목표 모델의 가중치 크기와 실제 실행 VRAM을 계산했는가

• KV 캐시를 포함해 목표 컨텍스트와 동시 요청 수를 반영했는가

• Q4, Q5, Q8, FP16 중 어떤 정밀도가 실제 품질 요구사항에 맞는가

• 더 작은 모델이나 도메인 특화 모델로 같은 품질을 낼 수 있는가

• 최대 컨텍스트를 줄여도 서비스 요구사항을 만족하는가

• KV 캐시 dtype 변경이나 PagedAttention 같은 추론 엔진 최적화를 검토했는가

• 모델을 나누려는 것인지, 요청 처리량을 늘리려는 것인지 구분했는가

• GPU 사이 연결이 NVLink인지 PCIe인지, PCIe라면 x16/x8/x4 구성을 확인했는가

• 전력 공급, 발열, 케이스 공간, 메인보드 PCIe 레인 수를 확인했는가

• 단일 고용량 GPU가 멀티 GPU보다 더 단순하고 저렴한 총비용을 제공하지 않는가

이 질문들에 답하지 못한 상태에서 GPU를 추가하면, 높은 확률로 예상보다 느리고 뜨겁고 불안정한 시스템을 만나게 된다.

모델 크기별 실전 판단표

아래 표는 추론용 로컬 또는 소규모 서버 구축을 가정한 대략적인 판단 기준이다. 실제 필요한 VRAM은 모델 구조, 양자화 방식, 컨텍스트 길이, 배치 크기, 추론 엔진에 따라 달라진다.

이 표에서 가장 중요한 줄은 70B INT4다. 이 구간은 개인과 소규모 팀이 멀티 GPU를 현실적으로 고민하는 경계선이다. 35B 이하는 대부분 단일 GPU 최적화를 먼저 해야 하고, 70B FP16 이상은 이미 데이터센터급 설계로 넘어간다. 70B INT4는 그 중간에 있다. 그래서 유혹도 크고, 실수도 많다.

멀티 GPU로 가야 한다면, 이유를 한 문장으로 적어라

좋은 인프라 설계에는 명확한 이유가 있다. 멀티 GPU를 도입하기로 했다면, 그 이유를 한 문장으로 쓸 수 있어야 한다.

"70B Q4 모델이 단일 24GB GPU에 들어가지 않아 두 장으로 나눈다."

"70B FP16 평가를 위해 최소 4장의 80GB GPU가 필요하다."

"8B 모델은 한 장에 들어가지만 동시 사용자 200명을 처리해야 하므로 GPU별 복제 서버를 여러 개 띄운다."

이렇게 쓰면 설계 방향이 분명해진다. 첫 번째는 모델 분할이 필요하다. 두 번째는 데이터센터급 텐서 병렬과 충분한 KV 캐시 예산이 필요하다. 세 번째는 모델 분할이 아니라 복제형 서빙과 로드밸런싱이 필요하다.

반대로 "그냥 더 빠를 것 같아서", "GPU가 남아서", "큰 모델이 좋아 보여서" 같은 이유라면 잠시 멈추는 편이 좋다. 멀티 GPU는 멋진 장난감이지만, 운영 환경에서는 장난감이 아니다. 케이블 하나, 드라이버 버전 하나, PCIe 슬롯 배치 하나가 성능과 안정성을 흔든다.

이제 우리는 멀티 GPU가 필요한 상황과 그렇지 않은 상황을 구분할 수 있게 되었다. 다음 단계는 하드웨어의 현실을 보는 일이다. GPU는 단순히 VRAM 숫자로만 고르는 부품이 아니다. 메모리 대역폭, PCIe 레인, NVLink, 전력, 발열, 케이스 공간이 모두 추론 성능을 좌우한다. 다음 장에서는 바로 그 현실적인 하드웨어 세계로 들어간다.

참고

¹GPU Memory Requirements for LLMs: VRAM Calculator

²Best VRAM Cheat Sheet for Local LLMs: Every Model, Every Quant

³Multi-GPU Setup Guide for Running Large Local LLMs in 2026

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

⁵KV Cache Memory: Calculating GPU Requirements for LLM Inference

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

⁷Optimizing Inference for Long Context and Large Batch Sizes with NVFP4 KV Cache

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

⁹Multi-GPU LLM Inference Guide — NVLink vs PCIe, Tensor Parallelism (2026)