vLLM 멀티 GPU 서빙 완전정리 — Tensor·Pipeline·Data Parallel 선택 기준

vLLM으로 7B 모델을 잘 운영하다가 32B·70B급 모델을 올리려는 순간 벽에 부딪히는 경우가 많습니다. 가중치가 GPU 한 장에 들어가지 않거나, 들어가더라도 KV Cache 여유가 없어 동시 요청을 거의 받지 못하는 상황입니다. 이때 GPU를 늘리는 것 자체는 어렵지 않지만, Tensor Parallel·Pipeline Parallel·Data Parallel 중 무엇을 어떻게 조합하느냐에 따라 같은 GPU 수에서도 처리량과 지연시간이 크게 달라집니다.

결론부터 말하면 모델이 GPU 한 장에 들어가면 복제(Data Parallel)로 처리량을 늘리고, 한 장에 들어가지 않으면 노드 안에서는 Tensor Parallel, 노드를 넘어야 하면 Pipeline Parallel을 조합하는 것이 기본 원칙입니다. 이 글에서는 각 병렬화 방식의 동작 원리와 선택 기준, 실행 옵션, 검증 방법을 순서대로 정리합니다.

GPU 메모리 부족 오류를 이미 겪고 있다면 vLLM CUDA OOM 해결 가이드를, 멀티 GPU 전에 모델 자체를 줄이는 선택지가 궁금하다면 LLM 양자화 완전정리를 먼저 참고하세요.

핵심 요약

• 멀티 GPU의 목적은 용량 확장(큰 모델을 올림)과 처리량 확장(같은 모델을 더 많이 처리) 두 가지이며, 해법이 서로 다릅니다.
• Tensor Parallel(TP)은 레이어 내부 행렬을 쪼개므로 통신이 매우 빈번합니다. NVLink가 있는 단일 노드 안에서 사용하는 것이 기본입니다.
• Pipeline Parallel(PP)은 레이어를 구간별로 나눠 통신량이 적은 대신 파이프라인 버블이 생깁니다. 노드 간 확장이나 PCIe 환경에서 검토합니다.
• 모델이 한 장에 들어가는데 TP를 거는 것은 낭비인 경우가 많습니다. 이때는 Data Parallel(복제)이 처리량 면에서 유리합니다.
• TP 크기는 모델의 Attention Head 수(정확히는 KV Head 수)로 나누어떨어져야 합니다.
• MoE 모델은 --enable-expert-parallel로 Expert를 GPU에 분산하는 Expert Parallel(EP)을 함께 검토합니다.

1. 멀티 GPU가 필요한 두 가지 이유부터 구분하기

“GPU를 늘려야 한다”는 판단 전에, 지금 부족한 것이 메모리(용량)인지 연산(처리량)인지부터 구분해야 합니다. 목적에 따라 정답이 반대가 되기 때문입니다.

상황	부족한 것	기본 해법
모델 가중치가 GPU 한 장에 안 들어감	메모리	TP(노드 내) 또는 TP+PP(노드 간)
모델은 들어가는데 KV Cache 여유가 없음	메모리	TP로 가중치를 나눠 캐시 공간 확보, 또는 양자화
모델은 잘 도는데 동시 요청이 밀림	연산·처리량	인스턴스 복제(DP) + 로드밸런싱
TTFT(첫 토큰 지연)가 너무 김	연산	TP가 도움되는 경우도 있으나 원인 분석 먼저

같은 “느리다”는 증상이라도 KV Cache 사용률이 100%에 붙어 있는 것과 GPU 연산이 포화된 것은 다른 문제입니다. 지표 확인 방법은 vLLM 속도 튜닝 가이드에서 정리한 TTFT·ITL·처리량 기준을 그대로 사용하면 됩니다.

2. 몇 장이 필요한지 빠르게 계산하기

가중치 메모리는 대략 파라미터 수 × 데이터형 바이트로 계산합니다. FP16·BF16은 파라미터당 2바이트입니다.

모델 크기	FP16·BF16	INT8	INT4
7B~8B	약 14~16GB	약 7~8GB	약 4~5GB
32B	약 64GB	약 32GB	약 17~19GB
70B~72B	약 140~144GB	약 70~72GB	약 36~40GB

여기서 끝이 아닙니다. 실제로는 가중치 + KV Cache + 활성값·CUDA Graph 여유분이 모두 들어가야 합니다. 예를 들어 80GB GPU 2장에 70B FP16 모델(약 140GB)을 TP=2로 올리면 GPU당 가중치만 약 70GB를 차지해 KV Cache 공간이 거의 남지 않습니다. 이 경우 TP=4로 가중치를 GPU당 35GB 수준으로 낮춰 캐시 공간을 확보하는 편이 동시성 면에서 훨씬 안정적입니다. KV Cache가 얼마나 필요한지는 vLLM KV Cache 완전정리의 계산식을 참고하세요.

3. Tensor Parallel — 레이어 안쪽을 쪼갠다

Tensor Parallel(TP)은 각 레이어의 행렬 연산 자체를 여러 GPU에 나눕니다. Attention Head와 MLP의 행렬이 GPU 수만큼 분할되고, 매 레이어마다 all-reduce 통신으로 결과를 합칩니다.

vllm serve YOUR_MODEL \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.90

레이어마다 통신이 발생하므로 GPU 간 대역폭이 성능을 좌우합니다. 그래서 TP는 NVLink로 연결된 단일 노드 내 GPU에서 쓰는 것이 기본이고, PCIe만으로 연결된 GPU에서 TP를 크게 잡으면 통신이 병목이 되어 기대만큼 빨라지지 않을 수 있습니다.

TP 크기의 제약

• TP 크기는 모델의 Attention Head 수로 나누어떨어져야 합니다. GQA 모델은 KV Head 수와의 관계도 확인해야 하며, 조건이 맞지 않으면 vLLM이 시작 단계에서 오류를 냅니다.
• TP는 2의 거듭제곱(2·4·8)으로 잡는 것이 일반적입니다.
• GPU 연결 상태는 nvidia-smi topo -m으로 확인할 수 있습니다. NV#(NVLink)인지 PIX·PHB(PCIe)인지에 따라 기대치를 다르게 잡아야 합니다.

4. Pipeline Parallel — 레이어를 구간으로 나눈다

Pipeline Parallel(PP)은 모델의 레이어를 앞부분·뒷부분처럼 구간(Stage)으로 나눠 GPU에 배치합니다. 통신은 스테이지 경계에서 활성값을 전달할 때만 발생하므로 TP보다 통신량이 훨씬 적습니다.

vllm serve YOUR_MODEL \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2

위 예시는 총 8장의 GPU를 사용합니다(4×2). 일반적인 조합 원칙은 노드 안에서는 TP, 노드 사이는 PP입니다. 노드 간 네트워크는 NVLink보다 훨씬 느리기 때문에 통신이 잦은 TP를 노드 경계에 걸치면 성능이 급격히 떨어집니다.

PP의 대가는 파이프라인 버블입니다. 앞 스테이지가 일하는 동안 뒤 스테이지가 노는 구간이 생기고, 요청 하나의 지연시간(특히 TTFT)이 늘어날 수 있습니다. 동시 요청이 충분히 많아 파이프라인이 계속 채워질 때 효율이 살아나는 구조입니다.

5. TP vs PP — 상황별 선택 기준

환경·목표	권장 구성	이유
단일 노드, NVLink 연결	TP	고대역폭에서 TP 통신 비용 흡수 가능
단일 노드, PCIe만 연결	작은 TP 또는 PP 비교 측정	PCIe에서 큰 TP는 통신 병목
여러 노드에 걸친 초대형 모델	노드 내 TP × 노드 간 PP	느린 노드 간 링크에 통신 적은 PP 배치
지연시간(TTFT) 최우선	가능하면 TP 단독	PP는 버블로 지연 증가 가능
처리량 최우선, 요청 많음	TP+PP 또는 DP 복제	파이프라인이 채워지면 효율 회복

6. Data Parallel — 나누지 말고 복제하라

모델이 GPU 한 장에 여유 있게 들어간다면, TP로 쪼개는 것보다 같은 모델을 GPU마다 복제해 요청을 나눠 받는 것이 처리량 면에서 유리한 경우가 많습니다. TP는 통신 오버헤드를 항상 수반하지만 복제는 오버헤드가 없기 때문입니다.

• 가장 단순한 방법은 GPU별로 vLLM 인스턴스를 하나씩 띄우고 앞단에 Nginx 같은 로드밸런서를 두는 것입니다.
• 최근 vLLM은 --data-parallel-size 옵션으로 엔진 차원의 Data Parallel 실행도 지원합니다. 설치한 버전에서 지원 여부와 동작 방식을 vllm serve --help로 확인하세요.
• MoE 모델은 Attention은 DP로, Expert 층은 EP로 섞는 구성이 쓰이기도 합니다.

7B~14B급 모델을 GPU 4장에 서빙한다면 “TP=4 한 대”보다 “복제 4대 + 로드밸런싱”이 총 처리량에서 앞서는 경우가 많습니다. 단, 인스턴스가 나뉘면 Prefix Cache도 인스턴스별로 나뉘므로, 같은 사용자의 요청을 같은 인스턴스로 보내는 세션 고정이 도움이 될 수 있습니다.

7. Expert Parallel — MoE 모델이라면

Mixture of Experts(MoE) 모델은 전체 파라미터는 크지만 토큰마다 일부 Expert만 활성화됩니다. Expert Parallel(EP)은 이 Expert들을 GPU에 분산 배치하는 방식입니다.

vllm serve YOUR_MOE_MODEL \
  --tensor-parallel-size 4 \
  --enable-expert-parallel

MoE 모델에서 TP만 쓰면 모든 GPU가 모든 Expert 조각을 들고 있어야 하지만, EP를 켜면 Expert 단위로 나뉘어 메모리 효율이 좋아질 수 있습니다. 모델·버전별 지원 범위 차이가 크므로 공식 문서의 지원 모델 목록을 먼저 확인하는 것이 안전합니다.

8. 멀티 노드 실행 — Ray 클러스터

단일 머신을 넘어서는 경우 vLLM은 Ray 런타임으로 여러 노드를 묶습니다.

# 헤드 노드
ray start --head --port=6379

# 워커 노드
ray start --address='HEAD_NODE_IP:6379'

# 헤드 노드에서 서버 실행 (예: 2노드 × 8GPU = 16장)
vllm serve YOUR_MODEL \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2

멀티 노드에서 자주 확인해야 하는 항목은 다음과 같습니다.

• 모든 노드에 같은 버전의 vLLM·CUDA·드라이버가 설치되어 있는지
• 모델 경로가 모든 노드에서 접근 가능한지(공유 스토리지 또는 동일 캐시)
• NCCL이 올바른 네트워크 인터페이스를 쓰는지 — 필요 시 NCCL_SOCKET_IFNAME, InfiniBand 환경이면 NCCL_IB_HCA 등을 지정
• 통신 문제 디버깅 시 NCCL_DEBUG=INFO로 초기화 로그 확인

9. 구성이 잘 됐는지 검증하는 방법

서버가 뜨는 것과 GPU를 제대로 쓰는 것은 다릅니다. 구성 후에는 반드시 같은 부하로 전후를 비교합니다.

• 스케일링 효율: GPU 1장 대비 N장의 처리량이 몇 배인지 측정합니다. TP는 통신 비용 때문에 N배에 도달하지 못하는 것이 정상이며, 2장에서 1.6~1.9배 수준이면 나쁘지 않은 편입니다.
• GPU 사용률 균형: nvidia-smi에서 특정 GPU만 놀고 있다면 PP 스테이지 배분이나 로드밸런싱이 틀어진 신호입니다.
• KV Cache 사용률: TP를 늘렸다면 vllm:kv_cache_usage_perc가 실제로 낮아졌는지 확인합니다.
• TTFT·ITL 분포: 평균이 아니라 p95·p99로 비교합니다.

10. 흔한 실수

실수 1. PCIe로 연결된 소비자용 GPU 4장에 TP=4를 걸고 4배를 기대한다

TP는 레이어마다 통신합니다. PCIe 대역폭에서는 통신 대기가 연산 이득을 상당 부분 상쇄할 수 있습니다. 이 환경이라면 복제(DP)나 더 작은 모델·양자화를 먼저 검토하세요.

실수 2. 한 장에 들어가는 모델에 습관적으로 TP를 건다

TP는 공짜가 아닙니다. 용량이 목적이 아니라면 복제가 처리량에서 유리한 경우가 많습니다.

실수 3. 노드 경계에 TP를 걸친다

노드 간 네트워크는 NVLink보다 수십 배 느릴 수 있습니다. 노드 안 TP, 노드 간 PP 원칙을 지키세요.

실수 4. TP 크기를 Head 수와 맞추지 않는다

Attention Head(및 KV Head) 수로 나누어떨어지지 않는 TP 크기는 시작 오류나 비효율의 원인이 됩니다. 모델 설정의 num_attention_heads, num_key_value_heads를 먼저 확인하세요.

실전 체크리스트

• 부족한 것이 메모리인지 처리량인지 지표로 구분했다.
• 가중치 + KV Cache 예상 크기를 계산해 필요한 GPU 수를 정했다.
• nvidia-smi topo -m으로 GPU 간 연결(NVLink/PCIe)을 확인했다.
• TP 크기가 모델 Head 수로 나누어떨어지는지 확인했다.
• 노드 안 TP, 노드 간 PP 원칙으로 조합을 정했다.
• 단일 GPU 대비 스케일링 효율을 같은 부하로 측정했다.
• 장애 대비로 인스턴스 복제·헬스체크 구성을 검토했다.

마치며

멀티 GPU 서빙은 옵션 하나로 끝나는 작업이 아니라, 무엇이 부족한지 진단하고 그에 맞는 병렬화를 고르는 설계 작업입니다. 모델이 한 장에 들어가면 복제, 안 들어가면 노드 안 TP, 노드를 넘으면 PP 조합이라는 기본 원칙에서 출발해, 반드시 같은 부하로 전후 성능을 비교하며 조정하세요.

GPU를 늘리기 전에 양자화로 모델을 줄이는 선택지, KV Cache 튜닝으로 동시성을 확보하는 선택지와 비용을 비교해 보는 것도 잊지 마시기 바랍니다. 같은 예산이라면 더 단순한 구성이 운영 부담 면에서 항상 유리합니다.

FAQ

Q1. TP=2로 하면 속도도 2배가 되나요?

아닙니다. TP의 1차 목적은 메모리 분산입니다. 통신 비용 때문에 처리량은 GPU 수에 정비례하지 않으며, 오히려 확보된 KV Cache 공간 덕분에 동시성이 좋아지는 효과가 더 클 때도 많습니다.

Q2. 서로 다른 GPU(예: A100 + RTX 4090)를 섞어 TP를 걸 수 있나요?

권장되지 않습니다. TP는 모든 GPU가 같은 속도로 움직인다고 가정하므로 가장 느린 GPU에 전체가 맞춰지고, 메모리 크기가 다르면 시작조차 실패할 수 있습니다.

Q3. 70B 모델을 24GB GPU 여러 장으로 서빙할 수 있나요?

이론적으로 INT4 양자화(약 36~40GB)에 TP를 조합하면 가능하지만, PCIe 환경이라면 통신 병목과 KV Cache 부족으로 실용성이 떨어질 수 있습니다. 부하 테스트로 목표 TTFT·처리량을 만족하는지 반드시 확인해야 합니다.

Q4. Ray 없이 멀티 노드를 구성할 수 있나요?

vLLM의 멀티 노드 표준 경로는 Ray입니다. 단일 노드에서는 별도 설정 없이 멀티프로세싱 백엔드로 동작하며, --distributed-executor-backend 옵션으로 백엔드를 명시할 수 있습니다.

참고 공식 문서

• vLLM Distributed Inference and Serving
• vLLM Engine Arguments
• NVIDIA NCCL User Guide

함께 읽으면 좋은 글

• vLLM KV Cache 완전정리 — 메모리 계산·Prefix Caching·FP8 튜닝법
• vLLM 속도 튜닝 가이드 (2026) — TTFT·ITL·처리량을 개선하는 실전 순서
• vLLM CUDA OOM 해결 가이드 (2026) — GPU 메모리 부족 원인별 튜닝 순서
• LLM 양자화 완전정리 — FP16·INT8·INT4, GGUF·AWQ·GPTQ 선택법