TP/DP 멀티 GPU 서빙 실측 기록: Runpod A100 4장으로 3가지 구성 비교

GPU를 4장 쌓은 단일 노드에서, vLLM 서빙을 TP=4, TP=2 × DP=2, DP=4의 3가지 구성으로 구동하고 속도를 비교한 기록이다. 처음에는 TP=8까지 비교할 예정이었다. 하지만 Runpod에서는 8장의 재고를 찾기 어려웠고 가격도 저렴하지 않았다. 현재는 4장이 한계이므로, 같은 4장 안에서 TP와 DP의 비중만 바꾸어 조합하는 형태로 재구성했다.

먼저 결과를 적겠다. GPU 1장에 들어가는 모델(Qwen3-8B/14B)에서는 DP=4가 가장 빨랐으며, Qwen3-8B의 경우 처리량(throughput)이 TP=4 대비 약 1.3배였고 평균 TTFT는 약 27% 짧았다. GPU 1장에 들어가지 않는 Qwen2.5-72B에서는 반대로 TP=4가 처리량에서 우위를 보였다.

TP의 비중이 높을수록(왼쪽) GPU 간 통신 경로가 늘어난다. DP의 비중이 높을수록(오른쪽) 통신은 줄고, 각 GPU는 완전히 독립된 레플리카(모델 복제)가 된다.

멀티 GPU 병렬화의 4가지 방식

멀티 GPU/멀티 노드 추론에 사용되는 병렬화 방식은 크게 4가지가 있다.

• 데이터 병렬화(DP): 처리량(throughput)을 늘리기 위해, GPU와 노드 전체에 모델 인스턴스를 통째로 복제하는 방식. -
• 텐서 병렬화(TP): 대규모 모델에 적합하다. 레이어를 분할하여 큰 행렬 연산을 분담시켜 지연 시간(latency)을 낮춘다. -
• 파이프라인 병렬화(PP): 이 역시 대규모 모델용이며, 여러 GPU나 노드에 걸쳐 레이어를 단계별로 분할한다. -
• 전문가 병렬화(EP): Mixture-of-Experts(MoE) 모델용으로, 전문가를 여러 GPU에 분산 배치하는 방식.

본 기사에서 다루는 것은 DP와 TP만이다. 측정한 모델(Qwen3-8B/14B, Qwen2.5-72B)은 모두 MoE가 아닌 dense 모델이며, 단일 노드의 GPU 4장에 들어간다. 여러 노드에 걸치는 PP는 필요하지 않고, EP도 해당되지 않는다. 남은 선택지는 '레이어를 분할할지(TP)', '모델을 통째로 복제할지(DP)'의 두 가지 중 하나이므로, 그 비중을 4장의 GPU 안에서 바꾸면서 비교한다.

1. Runpod Pod 준비

• Template:
  vLLM Verified - Compute 필터:
  GPU Type = A100 SXM(PCIe가 아닌 NVLink 확보), GPU Count = 4 - Storage: 모델 크기를 고려하여 컨테이너 디스크에 여유를 둔다(7B~14B급이라면 50GB 이상+)

8장을 확보했다면, 3절의 커맨드에 --tensor-parallel-size 8 구성을 추가하면 된다.

등록하고 충전한 후, Pods에서 선택하여 GPU를 고른다.

GPU로 A100 SXM을 선택하고, GPU count를 4로 하여 Deploy Pod를 클릭한다.

배포가 완료되면, Compute type이 A100 SXM x4로 되어 있다. 요금은 시간당 $6.36이다.

다음으로 vLLM의 API 키를 위한 시크릿(Secret)을 만든다. Secrets → Create secret을 열고, 아래 커맨드로 생성한 임의 값을 등록한다.

openssl rand -hex 32

생성된 환경 변수의 참조값을 복사한다. 나중에 Pod의 컨테이너에 환경 변수로 주입할 것이다.

Pods에서 Edit Pod를 클릭하고, 환경 변수 VLLM_API_KEY의 VALUE에 방금 복사한 참조값을 넣는다.

2. 연결 후 확인

nvidia-smi -L # 먼저 GPU가 4장 인식되었는지 확인
nvidia-smi topo -m # GPU 사이에 NV#이 나오면 NVLink 정상, PHB/PXB는 PCIe 연결만

GPU0부터 GPU3까지 NVLink로 연결되어 있음을 확인한다.

3. 서빙 실행

Pods에서 배포한 컨테이너의 오른쪽 끝 오버플로우 메뉴를 클릭하고, Edit pod를 클릭한다.

3-1. TP=4

Runpod Edit Pod의 Container Start Command에 아래 인수를 그대로 붙여넣는다. vLLM Verified 템플릿에는 ENTRYPOINT에 vllm serve가 이미 포함되어 있으므로, 필드에는 모델명부터 시작하는 인수만 작성하면 된다.

Qwen/Qwen3-8B --tensor-parallel-size 4 --host 0.0.0.0 --port 8000 --dtype auto --enforce-eager --gpu-memory-utilization 0.95 --max-model-len 8128

3-2. TP=2 × DP=2

Qwen/Qwen3-8B --tensor-parallel-size 2 --data-parallel-size 2 --host 0.0.0.0 --port 8000 --dtype auto --enforce-eager --gpu-memory-utilization 0.95 --max-model-len 8128

3-3. DP=4

Qwen/Qwen3-8B --tensor-parallel-size 1 --data-parallel-size 4 --host 0.0.0.0 --port 8000 --dtype auto --enforce-eager --gpu-memory-utilization 0.95 --max-model-len 8128

편집 후에는 Pod를 재시작(Stop → Start, 또는 Edit 저장 시 자동 재시작)하지 않으면 새로운 명령어가 반영되지 않습니다. 모델을 변경할 경우에는 attention head의 수가 TP 크기로 나누어지는지 사전에 확인해야 합니다. 나누어지지 않으면 "must be divisible" 오류가 발생합니다.

4. 속도 측정

vllm bench serve \
--backend vllm \
--model Qwen/Qwen3-8B \
...

세 가지 구성(TP=4, TP=2×DP=2, DP=4) 각각에 대해, 병렬도 1(지연 시간 중시)과 고병렬도(처리량 중시) 두 가지 조건을 모두 실행하여 비교합니다. 결과를 공정하게 비교하기 위해 모델・프롬프트 세트・--num-prompts는 고정하고 서버 설정만 변경합니다.

측정 지표

TTFT(Time To First Token): prefill 성능의 지표 -
TPOT / ITL(Time Per Output Token / Inter-Token Latency): decode 성능의 지표 -
Throughput: 1초당 요청 수, 1초당 생성 토큰 수

사전 가설

TP에서는 레이어별로 각 GPU의 부분 결과를 더하여 모든 GPU에서 공유하는 통신(all-reduce)이 발생합니다. 이 통신량을 기준으로 측정하기 전에는 다음과 같이 예상했습니다.

TP=4: 4-way all-reduce이므로 통신은 가장 많지만, 모델이 가장 세밀하게 분할되므로 요청 1건당 TTFT는 가장 짧아질 것입니다 -
TP=2 × DP=2: 통신 오버헤드가 절반(2-way all-reduce)으로 줄어들고, 두 개의 레플리카가 요청을 분담하여 처리량이 유리해질 것입니다 -
DP=4: 추론 시의 DP는 레플리카 간 통신이 전혀 없기(0 byte) 개별 요청의 지연 시간은 TP=1과 같지만 동시 처리의 처리량은 가장 높아질 것입니다

즉, "TP의 비중을 낮추고 DP의 비중을 높일수록, 지연 시간은 손해를 보고 처리량은 이득을 보는" 트레이드오프 곡선을 4장의 GPU만으로 확인해 볼 생각이었습니다.

5. 실측 결과

처음에 확보한 Pod는 4x L40S(PCIe, NVLink 없음)였습니다. 이 호스트에서는 NCCL(NVIDIA의 GPU 간 통신 라이브러리)의 P2P 핸드셰이크가 멈추는 문제가 있어, NCCL_P2P_DISABLE=1을 추가하여 회피했습니다. 다음에 확보한 Pod가 4x A100 SXM입니다. nvidia-smi topo -m으로 모든 쌍이 NV12(12개로 묶은 NVLink)로 연결되어 있음을 확인하고, NCCL_P2P_DISABLE을 제거하고 다시 측정했습니다.

측정에는 4절의 명령어를 사용했습니다. 성공하면 먼저 아래와 같은 결과가 나옵니다.

결과 일람 비교

요청 50건, 병렬도는 최대(--request-rate inf)

))) 총 입력 토큰 51,200 / 총 생성 토큰 6,400은 모든 구성에서 동일하다. 같은 프롬프트 세트를 사용했기 때문이다. 모든 구성에서 성공(Successful) 50 / 실패(Failed) 0.

Qwen3-8B

6. 고찰: 모델이 GPU 1장에 들어가는지에 따라 TP/DP의 비중이 결정됨

아래는 위의 실측값만으로 읽어낼 수 있는 범위의 고찰이다.

6-1. PCIe → NVLink로 변경 시 TTFT가 약 2.5배 단축 (GPU 차이 포함)

같은 TP=4 구성에서 L40S(PCIe)를 A100 SXM(NVLink)으로 바꾸자 Mean TTFT가 2,053ms → 832ms로 약 2.5배 단축되었다. TP=4는 레이어마다 4-way all-reduce가 필요하므로 인터커넥트의 차이가 두드러지게 나타난다. 다만 두 GPU는 스펙 자체도 다르기 때문에, 이 차이가 모두 인터커넥트에 의한 것이라고 단정하기는 어렵다.

6-2. Qwen3-8B에서는 TP=2×DP=2가 TP=4보다 우수함

예상과 달리, 같은 A100 SXM 환경에서 TP=2×DP=2가 TP=4보다 TTFT(706ms vs 832ms)와 처리량(throughput)(12.46 vs 11.53 req/s) 모두 높았다. 이는 통신량이 절반으로 줄어드는 이점과, 2개의 레플리카가 요청을 분담하는 이점이 결합된 결과로 보인다. 제4절의