H100 8장, 640GB GPU 메모리의 진짜 의미
80GB H100이 여덟 장인 NVIDIA DGX H100의 공식 사양에는 총 GPU 메모리 640GB라고 적혀 있습니다. AMD도 MI300X 192GB 여덟 장을 묶은 플랫폼을 총 1.5TB HBM3로 소개합니다. 사양표만 보면 이 메모리를 한 덩어리처럼 쓸 수 있을 듯합니다.
실제 하드웨어에는 80GB HBM을 가진 GPU 여덟 개가 들어 있습니다. 가중치 파일이 500GB인 모델을 실행하려면 서빙 엔진이 가중치와 연산을 여러 GPU에 나눠야 합니다. 반대로 같은 모델을 GPU마다 한 벌씩 올리면 서로 다른 요청을 처리하는 모델 복제본 여덟 개가 됩니다.
따라서 “GPU 8장이면 메모리가 8배인가?”라는 질문에는 먼저 한 가지 조건을 붙여야 합니다. 한 모델에 GPU 몇 장을 묶을 것인가? 이 선택에 따라 실행할 수 있는 모델의 크기와 전체 처리량, 응답시간이 달라집니다.
640GB는 여덟 개의 80GB다
CUDA Programming Guide는 멀티 GPU 시스템에서도 각 GPU가 직접 연결된 별도의 메모리를 갖는다고 설명합니다. GPU 0에 할당한 데이터는 GPU 0의 HBM에 놓입니다. GPU 1이 그 데이터를 읽으려면 NVLink나 PCIe를 거쳐 접근하거나 자신의 메모리로 옮겨야 합니다.
NVLink와 NVSwitch는 이 이동을 빠르게 만들지만 HBM의 물리적인 위치까지 없애지는 않습니다. 어느 GPU가 어떤 데이터를 보관하고, 어느 시점에 다른 GPU와 결과를 주고받을지는 소프트웨어가 정합니다.
CUDA Unified Memory를 사용하면 CPU와 GPU가 같은 메모리 영역에 접근할 수 있고, CUDA가 필요한 데이터를 옮겨 줍니다. 그래도 데이터가 실제로 놓인 위치와 이동 비용은 남습니다. NVIDIA도 성능을 높이려면 데이터 이동을 줄이고 연산하는 프로세서에 직접 연결된 메모리를 이용하라고 안내합니다.
사양표의 총 GPU 메모리는 서버에 설치된 HBM의 합계입니다. 한 모델이 그 용량을 얼마나 활용할지는 병렬화 방식과 GPU 간 연결 구조가 결정합니다.
같은 여덟 장을 네 가지로 쓸 수 있다
LLM 서빙에서는 같은 GPU 여덟 장도 다음처럼 배치할 수 있습니다.
구성 | 한 모델이 쓰는 GPU | 모델 복제본 | 주된 목적 |
|---|---|---|---|
Data Parallel 8 | 1장 | 8개 | 한 GPU에 들어가는 모델의 전체 처리량 확대 |
Tensor Parallel 8 | 8장 | 1개 | GPU 한 장 메모리보다 큰 모델을 나눠서 배치 |
Pipeline Parallel 8 | 8장 | 1개 | 모델의 레이어를 나눠 배치하거나 여러 노드로 확장 |
Tensor Parallel 4 × Data Parallel 2 | 4장 | 2개 | 모델 크기와 동시 처리량의 균형 |
Data Parallel(DP)은 같은 모델을 여러 GPU에 복제합니다. GPU마다 서로 다른 요청 묶음을 처리하므로 전체 처리량을 늘리기 좋습니다. 모델 한 벌은 여전히 GPU 한 장에 들어가야 합니다. 80GB GPU 여덟 장을 DP 8로 구성해도 한 복제본이 쓸 수 있는 메모리의 상한은 80GB입니다.
Tensor Parallel(TP)은 한 레이어의 큰 행렬을 여러 GPU에 나눕니다. 각 GPU가 부분 계산을 맡고 NCCL로 결과를 합칩니다. 가중치가 분산되므로 한 GPU보다 큰 모델을 실행할 수 있고, GPU마다 KV cache를 위한 공간도 더 남길 수 있습니다.
Pipeline Parallel(PP)은 모델의 레이어를 여러 GPU에 순서대로 나눠 배치합니다. 앞쪽 GPU의 출력은 다음 GPU의 입력으로 넘어갑니다. TP로 모델을 고르게 나누기 어렵거나 빠른 GPU 간 연결이 없는 환경에서는 PP를 검토할 수 있습니다. 한 요청이 여러 GPU를 차례로 거치므로 단계 사이의 대기와 지연을 관리해야 합니다.
실제 서비스에서는 세 방식을 섞습니다. 예를 들어 TP 4와 DP 2를 조합하면 GPU 네 장에 모델 하나를 나눠 올리고, 같은 구성을 두 벌 운용합니다. 모델 한 벌은 네 장의 메모리를 활용하며 두 복제본이 서로 다른 요청을 처리합니다. vLLM 설정으로 표현하면 tensor_parallel_size=4, data_parallel_size=2인 구성입니다.
MoE 모델에서는 Expert Parallel(EP)도 사용합니다. 여러 expert를 GPU에 나눠 배치하고, 각 토큰을 선택된 expert로 보내는 방식입니다. 이 과정에서 all-to-all 통신이 발생합니다. 이 글에서는 Dense 모델의 기본 구성을 중심으로 보겠습니다.
70B 모델로 계산해 보면
70B Dense 모델의 가중치를 BF16으로 저장하면 단순 계산으로 약 140GB가 필요합니다. 파라미터 하나에 2바이트를 쓰기 때문입니다. 가중치가 균등하게 분할된다고 가정하면 GPU 한 장이 맡는 양은 다음과 같습니다.
병렬화 | GPU당 BF16 가중치 | 80GB HBM에서 가중치를 제외한 공간의 상한 |
|---|---|---|
TP 2 | 약 70GB | 약 10GB |
TP 4 | 약 35GB | 약 45GB |
TP 8 | 약 17.5GB | 약 62.5GB |
TP 2는 80GB 두 장의 합계가 160GB이므로 가중치만 보면 모델이 들어갑니다. 그러나 GPU마다 70GB 가까이 가중치가 차지합니다. 서빙 엔진의 실행 버퍼와 CUDA Graph, 메모리 할당에 필요한 여유 공간을 빼고 나면 KV cache에 쓸 수 있는 공간이 많지 않습니다. 입력과 출력이 길거나 동시 요청이 늘면 이 공간이 먼저 부족해집니다.
TP 4와 TP 8은 GPU당 가중치가 줄어 KV cache에 더 많은 메모리를 배정할 수 있습니다. 대신 참여하는 GPU가 늘면서 동기화도 많아집니다. vLLM도 TP 크기를 키우면 GPU당 메모리 부담은 줄지만 과도한 동기화 비용이 생길 수 있다고 안내합니다.
4비트로 양자화한 70B 모델의 가중치는 이론적으로 약 35GB입니다. 실제 체크포인트에는 스케일과 메타데이터가 붙고 일부 레이어를 더 높은 정밀도로 유지할 수 있어 실행할 때는 그보다 많은 메모리가 필요합니다. 그래도 모델과 충분한 KV cache가 한 장에 들어간다면, GPU 여덟 장에 모델을 한 벌씩 올리는 구성이 TP 8보다 전체 처리량에 유리할 수 있습니다. 각 요청이 GPU 한 장 안에서 끝나므로, TP처럼 레이어마다 GPU 사이에서 결과를 동기화하지 않아도 됩니다.
필요한 메모리를 확보하는 범위에서 TP 그룹을 작게 잡으면 동기화 부담을 줄일 수 있습니다. 가중치와 KV cache가 들어가면서 목표 응답시간을 만족하는 가장 작은 TP 그룹을 먼저 찾고, 더 많은 요청을 받아야 할 때 복제본을 늘리는 편이 일반적입니다.
메모리를 나누면 통신이 따라온다
Tensor Parallel에서는 각 GPU가 행렬의 일부만 계산합니다. 다음 연산으로 넘어가기 전에 부분 결과를 합쳐야 하므로 레이어를 지날 때마다 GPU 간 통신이 반복됩니다. Hugging Face의 Tensor Parallel 설명도 가중치 행렬을 나눈 뒤 all-reduce로 결과를 합치는 구조를 보여 줍니다.
이때는 NVLink의 유무뿐 아니라 GPU가 NVSwitch 또는 PCIe 스위치를 통해 어떻게 연결되는지도 봐야 합니다. H100의 4세대 NVLink는 GPU당 최대 900GB/s의 총 대역폭을 제공합니다. H100의 PCIe Gen5 x16 인터페이스는 양방향 합계 128GB/s입니다. 둘 다 이론적인 최고 사양이며 실제 집합 통신 처리량은 GPU 배치와 메시지 크기, NCCL이 선택한 경로에 따라 달라집니다.
PCIe GPU 여덟 장이 꽂힌 서버라도 모든 GPU 쌍이 같은 거리로 연결되지는 않습니다. 같은 PCIe 스위치 아래에 있는 GPU와 CPU 소켓을 건너야 하는 GPU의 경로가 다를 수 있습니다. GPU가 많을수록 사양표에서 다음 항목을 함께 확인해야 하는 이유입니다.
GPU 사이에 NVLink나 Infinity Fabric이 연결되는 범위
NVSwitch 또는 PCIe 스위치의 연결 구조와 업스트림 대역폭
GPU 간 P2P 지원 여부와 NUMA 배치
여러 노드를 사용할 때 NIC 대역폭과 GPUDirect RDMA 지원
vLLM의 분산 서빙 지침은 한 노드 안에서 모델을 나눌 때 Tensor Parallel을 우선 제시합니다. 여러 노드로 넘어가면 노드 안에서는 TP를 쓰고 노드 사이에는 PP를 조합하는 구성을 안내합니다. NVLink가 없는 GPU에서는 PP가 TP보다 통신 부담을 줄일 수 있다는 설명도 덧붙입니다. 반대로 TP가 노드 경계를 넘으면 GPU 간 통신이 네트워크를 거쳐야 하므로 병목이 생기기 쉽습니다.
AMD 플랫폼도 원리는 같습니다. MI300X 플랫폼은 192GB HBM3를 가진 GPU 여덟 개를 Infinity Fabric으로 연결해 총 1.5TB를 제공합니다. 빠른 인터커넥트가 여러 GPU의 메모리와 연산을 함께 쓰기 쉽게 만들지만, 모델을 어떻게 분할할지는 여전히 프레임워크와 서빙 엔진이 정합니다.
학습에서는 DDP와 FSDP를 구분한다
학습에서 널리 쓰는 PyTorch DistributedDataParallel(DDP)은 GPU마다 모델 복제본을 둡니다. 각 GPU가 다른 미니배치를 계산한 뒤 그래디언트를 동기화합니다. 학습 속도와 전체 배치 크기는 늘릴 수 있지만, 파라미터가 한 GPU에 들어가지 않는 문제는 DDP만으로 풀리지 않습니다.
FullyShardedDataParallel(FSDP)은 파라미터와 그래디언트, 옵티마이저 상태를 여러 학습 프로세스에 나눠 보관합니다. 계산할 레이어의 파라미터를 모아 사용하고 다시 나누기 때문에 여러 GPU의 메모리를 큰 모델 학습에 활용할 수 있습니다. 그 대신 통신과 순간적인 메모리 사용량을 함께 계산해야 합니다. 활성값도 배치와 시퀀스 길이에 따라 별도의 공간을 차지합니다.
따라서 “GPU 8장의 메모리로 얼마나 큰 모델을 학습할 수 있는가”는 가중치 용량만으로 답하기 어렵습니다. 정밀도, 옵티마이저, 활성값, 시퀀스 길이와 FSDP·TP·PP 조합을 함께 봐야 합니다.
GPU 개수보다 먼저 정할 것
멀티 GPU LLM 서빙은 다음 순서로 정리하면 선택지가 빠르게 좁혀집니다.
질문 | 우선 검토할 구성 |
|---|---|
모델과 필요한 KV cache가 GPU 한 장에 들어가는가? | 한 장에 모델 한 벌을 올리고, 처리량이 필요하면 Data Parallel로 복제 |
한 장에는 부족하지만 한 노드의 메모리에는 들어가는가? | 빠른 GPU 간 연결을 이용한 Tensor Parallel |
레이어가 GPU 수에 고르게 나뉘지 않거나 NVLink가 없는가? | Pipeline Parallel 또는 TP와 PP의 조합 |
여러 노드가 필요한가? | 노드 안은 TP, 노드 사이는 PP를 기본안으로 검토 |
MoE 모델인가? | Expert Parallel 지원과 all-to-all 통신 경로 확인 |
GPU 수를 정하기 전에 모델과 체크포인트 정밀도, 실제 입력·출력 길이, 동시 요청 수와 목표 응답시간을 먼저 적는 편이 좋습니다. 이 값이 있어야 가중치와 KV cache를 계산하고, 한 모델에 몇 장을 묶을지 정할 수 있습니다.
모델을 어떻게 나눌지에 따라 필요한 GPU 수와 연결 방식도 달라집니다. TP처럼 GPU 사이의 통신이 잦다면 NVLink와 NVSwitch가 유리합니다. 복제본이 독립적으로 요청을 처리하는 DP는 PCIe 기반 서버에서도 구성할 수 있습니다.
80GB GPU 여덟 장은 여덟 개의 독립적인 80GB 실행 환경이 될 수도 있고, 모델 하나를 나눠 담는 8-GPU 그룹이 될 수도 있습니다. 네 장씩 묶은 복제본 두 개로도 쓸 수 있습니다.
총 640GB라는 숫자만으로는 실행할 수 있는 모델의 크기나 속도를 알 수 없습니다.
매니코어소프트는 모델과 트래픽에 맞춰 GPU, 인터커넥트, 서버와 냉각을 하나의 AI 인프라로 설계합니다. 모델명과 정밀도, 예상 컨텍스트 길이, 동시 사용자 수를 알려 주시면 멀티 GPU AI 인프라 구성 상담에서 적합한 GPU 수와 연결 방식을 함께 검토하겠습니다.
주요 참고 자료
NVIDIA, DGX H100/H200 User Guide
NVIDIA, Hopper Architecture In-Depth
NVIDIA, NVLink and NVSwitch Supercharge Large Language Model Inference
vLLM, Optimization and Tuning
vLLM, Parallelism and Scaling
Hugging Face, Tensor Parallelism
PyTorch, FullyShardedDataParallel