부록2. GPU 인프라: 학습 클러스터와 추론 서빙의 실체
대규모 LLM 학습 클러스터의 실체. 데이터센터 전력/냉각, GPU 간 네트워크(IB/RoCE), GPU 서버 구성, 체크포인트 스토리지. 학습과 추론 인프라의 설계 차이.
- 11. LLM은 텍스트를 어떻게 처리하는가
- 22. 입력 처리: 텍스트가 숫자가 되기까지
- 33. 어텐션: 새 토큰이 문맥을 얻는 과정
- 44. FFN: 지식이 저장된 곳
- 55. 조립: 토큰이 쌓이고 레이어가 깊어지는 과정
- 66. 추론: Prefill, Decode, KV 캐시
- 77. 출력 제어: 확률에서 토큰을 고르는 방법
- 88. 학습: 30억 개의 숫자가 조정되는 과정
- 99. 하드웨어: GPU, 메모리, 속도의 관계
- 1010. 모델 파일: 포맷, 양자화, 서빙 구조
- 1111. 실전 적용: 모델 선택부터 파이프라인까지
- 12부록1. 왜 트랜스포머인가: RNN에서 Mamba까지
- 13부록2. GPU 인프라: 학습 클러스터와 추론 서빙의 실체
부록 1에서 트랜스포머가 왜 승리했는지를 다뤘다. 이 부록에서는 그 트랜스포머를 실제로 학습하고 서빙하는 물리적 인프라를 다룬다. 데이터센터, 네트워크, 서버, 스토리지. 시스템 엔지니어에게 가장 익숙한 영역이면서, AI 시대에 가장 극적으로 변하고 있는 영역이기도 하다.
대규모 학습 클러스터 — 어떤 규모인가
Meta가 Llama 3.1 405B를 학습할 때 사용한 클러스터는 H100 GPU 16,000장이었다. 이후 24,576장 클러스터 2개를 구축했고, 2025년에는 H100 129,000장을 하나의 클러스터로 묶기 위해 가동 중인 데이터센터 5개를 비우고 재구성하는 작업까지 했다.
대규모 학습 클러스터 규모 (공개 사례):
Meta Llama 3.1 405B H100 x 16,000장 2024
Meta 24K 클러스터 H100 x 24,576장 2024 (2개 구축)
Meta 129K 클러스터 H100 x 129,000장 2025 (DC 5개 통합)
Google TPU v5p Pod TPU x 8,960장 2024
xAI Colossus H100 x 100,000장 2024
Meta 전체 보유: H100 기준 350,000장+ (2024 말)
목표: 600,000장 상당의 연산력 (2025)이 숫자를 체감하려면, H100 한 장이 700W를 소비한다는 걸 떠올리면 된다. 10,000장이면 7MW. 소도시 하나의 전력 소비량이다. 129,000장이면 90MW 이상. 여기에 냉각, 네트워크, 스토리지 전력까지 더하면 100MW를 훌쩍 넘긴다.
데이터센터(퍼실리티) — 전력과 냉각이 전부 바뀌었다
기존 데이터센터와 AI 학습용 데이터센터는 설계 자체가 다르다.
기존 데이터센터 AI 학습용 데이터센터
----------------- ------------------ ----------------------
랙당 전력 5~15 kW 80~140 kW
냉각 방식 공냉 (에어컨) 수냉 (리퀴드쿨링) 필수
PUE 1.3~1.5 1.05~1.15 (수냉 기준)
전력 밀도 낮음 10배 이상
건물 설계 범용 GPU 밀도에 최적화
건설 기간 1~2년 2~4년 (전력 확보가 병목)가장 큰 변화는 냉각이다. H100 8장이 들어간 서버 1대가 10~12kW를 소비한다. 이걸 랙에 8대 쌓으면 80~100kW다. 공냉으로는 물리적으로 감당이 안 된다. 공기의 열전달 효율로는 랙당 30kW 정도가 한계다.
그래서 수냉(리퀴드쿨링)이 필수가 되었다.
냉각 방식 비교:
공냉 (Air Cooling):
- 찬 공기를 서버에 불어넣고 뜨거운 공기를 빼는 방식
- 랙당 ~30kW까지 가능 (최적화 시)
- 기존 데이터센터 대부분이 이 방식
- AI 워크로드에는 부족
Direct-to-Chip 수냉:
- GPU/CPU 칩 위에 직접 냉각판(cold plate)을 올림
- 냉각수가 칩의 열을 직접 흡수
- 랙당 100kW 이상 가능
- NVIDIA GB200 NVL72 기준 랙당 ~140kW
- 현재 AI 데이터센터의 주류
침수 냉각 (Immersion Cooling):
- 서버 전체를 냉각액에 담그는 방식
- 열전달 효율 최대
- 아직 대규모 도입 초기 단계
에너지 절감:
수냉은 공냉 대비 냉각 에너지 소비를 ~40% 절감.
50MW 시설 기준 연간 $4M+ 절약.전력 확보가 병목이라는 것도 중요하다. 미국 북부 버지니아(세계 최대 DC 시장)에서는 새 대규모 전력 연결에 3~5년이 걸린다. GPU는 살 수 있지만 꽂을 곳이 없는 상황이다. Meta가 텐트에 GPU 클러스터를 배치하기 시작한 것도 전력 확보 속도를 당기기 위해서다.
네트워크 — GPU 간 통신이 전체 성능을 결정한다
학습 클러스터에서 네트워크는 두 종류로 나뉜다.
학습 클러스터의 네트워크 구조:
+-- 프론트엔드(FE) 네트워크 --+ +-- 백엔드(BE) 네트워크 --+
| | | |
| 데이터 수집 (학습 데이터) | | GPU 간 통신 (학습) |
| 체크포인트 저장 | | RDMA 기반 |
| 로깅/모니터링 | | 무손실(lossless) 전송 |
| 일반 이더넷 | | 400Gbps 엔드포인트 |
+----------------------------+ +------------------------+
FE: 스토리지 <-> GPU 노드. 학습 데이터를 GPU에 공급.
BE: GPU <-> GPU. 학습 중 gradient 동기화. 여기가 핵심.백엔드 네트워크가 학습 성능을 결정한다. 수만 장의 GPU가 gradient를 동기화해야 하니까, 하나라도 느리면 전체가 기다린다.
백엔드 네트워크 기술:
InfiniBand (IB):
- NVIDIA Quantum2 기반
- RDMA 네이티브, 초저지연
- 전통적인 HPC/AI 학습 표준
- 벤더 락인 (NVIDIA 종속)
RoCE v2 (RDMA over Converged Ethernet):
- 이더넷 기반 RDMA
- Meta가 Llama 3 학습에 사용 (24K 클러스터)
- 개방형 표준, 벤더 선택지 넓음
- Arista 7800 + Wedge400 + Minipack2 (OCP 기반)
Meta는 두 방식을 모두 구축해서 비교 평가:
- IB 클러스터 24,576장 + RoCE 클러스터 24,576장
- 결과: 둘 다 대규모 GenAI 학습에 네트워크 병목 없이 성공
- RoCE가 개방성/비용 면에서 유리, Meta는 RoCE 확대 방향
공통: 400Gbps 엔드포인트, 논블로킹 패브릭 구조노드 내부에서는 NVLink/NVSwitch가 GPU 간 통신을 담당한다. H100 기준 NVLink 대역폭은 GPU당 900GB/s로, 네트워크(400Gbps = 50GB/s)의 18배다. 그래서 가능한 한 노드 내부에서 통신을 완결하고, 노드 간 통신을 최소화하는 병렬화 전략이 중요하다.
서버 — GPU 서버는 일반 서버와 완전히 다르다
일반 서버 vs GPU 학습 서버:
일반 서버 GPU 학습 서버
----------------- ---------------- ----------------------
핵심 부품 CPU GPU 8장
전력 500W~1kW 10~12kW (H100 8장 기준)
메모리 256~512GB RAM 640GB HBM (GPU) + 2TB RAM
네트워크 25~100GbE x 1~2 400GbE x 8 (RDMA)
가격 $5K~$20K $200K~$400K
냉각 공냉 충분 수냉 필수
대표 플랫폼:
NVIDIA DGX H100:
- H100 x 8장, HBM3 80GB x 8 = 640GB
- NVSwitch로 GPU 간 900GB/s 연결
- 400GbE x 8 (InfiniBand or RoCE)
- 전력: ~10.2kW
- 가격: ~$300K
Meta Grand Teton (OCP 공개):
- Meta 자체 설계, OCP에 기여
- H100 x 8장 기반
- 커스텀 냉각/전원 설계
- 오픈 하드웨어GPU 서버 한 대 가격이 3~4억 원이다. 24,576장 클러스터면 서버만 3,072대. 서버 구매비만 1조 원에 가깝다. 여기에 네트워크, 스토리지, 데이터센터 비용까지 더하면 대규모 학습 클러스터가 왜 빅테크만 구축할 수 있는지 이해가 된다.
스토리지 — 체크포인트가 핵심 요구사항이다
학습 클러스터의 스토리지 요구사항은 일반적인 서버 인프라와 다르다. 가장 큰 차이는 체크포인트(checkpoint)다.
왜 체크포인트가 중요한가:
GPU 10,000장으로 수 주간 학습 중 -> 하드웨어 장애 발생
체크포인트 없으면: 수 주간의 학습 결과 전부 소실
체크포인트 있으면: 마지막 저장 지점에서 재개
비용으로 따지면:
GPU 10,000장 x $2/시간 = $20,000/시간
8시간 학습 소실 = $160,000 (약 2억 원) 손실
-> 체크포인트 주기를 짧게 할수록 손실 최소화
-> 하지만 체크포인트 저장 중에는 GPU가 유휴 상태
체크포인트 크기:
파라미터 당 ~10바이트 (파라미터 2B + 옵티마이저 상태 8B)
70B 모델: 70억 x 10 = ~700GB / 체크포인트
405B 모델: 4050억 x 10 = ~4TB / 체크포인트
하루 여러 번 저장 -> 하루 수십 TB 쓰기이 체크포인트를 빠르게 저장하고 복구하려면 고성능 병렬 파일시스템이 필요하다.
학습 클러스터 스토리지 구성:
+-- 학습 데이터 저장소 --+ +-- 체크포인트 저장소 --+
| | | |
| 학습 데이터 (수십 TB) | | 빈번한 대량 쓰기 |
| 순차 읽기 위주 | | 수천 GPU 동시 쓰기 |
| 오브젝트 스토리지 가능 | | 병렬 파일시스템 필수 |
+-----------------------+ +----------------------+
병렬 파일시스템 (체크포인트용):
Lustre: HPC 전통 강자. DDN EXAscaler 등.
GPFS: IBM Spectrum Scale. 엔터프라이즈 환경.
BeeGFS: 경량. 중소 클러스터에 적합.
WEKA: 플래시 최적화. AI 워크로드 특화.
VAST Data: 통합 아키텍처. CoreWeave, Lambda 등 채택.
핵심 요구사항:
- 수천 노드 동시 쓰기 (체크포인트)
- TB/s급 처리량
- GPU 유휴 시간 최소화 (비동기 체크포인트)
- 장애 시 빠른 복구
Meta 사례:
- 자체 분산 파일시스템 Tectonic 사용
- 수천 GPU가 동시에 체크포인트 저장/로드
- FE 네트워크를 통해 스토리지 접근
최신 기술:
- GPUDirect Storage: GPU에서 스토리지로 직접 전송 (CPU 우회)
- 비동기 체크포인트: 학습 진행 중 백그라운드로 저장
- 로컬 NVMe 버퍼 -> 병렬 파일시스템 순차 복제GPU가 $30,000 이상인데 스토리지가 느려서 유휴 상태가 되면, 초당 수만 달러가 날아간다. 스토리지 성능이 GPU 활용률을 직접 결정한다는 점에서, AI 인프라에서 스토리지의 위상이 완전히 달라졌다.
추론 인프라 — 학습과 완전히 다른 설계
학습은 "한 번 크게, 오래" 돌리는 배치 작업이다. 추론은 "수백만 사용자의 요청을 실시간으로" 처리하는 서비스다. 설계 철학이 다르다.
학습 vs 추론 인프라:
학습 추론
----------------- ------------------ ----------------------
목표 모델 파라미터 생성 사용자 요청 실시간 처리
GPU 활용 패턴 100% 연속 사용 요청에 따라 가변
지연 민감도 낮음 (수 주 작업) 높음 (수백 ms 이내)
GPU 간 통신 필수 (gradient 동기화) 최소 (독립 요청 처리)
네트워크 BE 400Gbps 필수 일반 이더넷 가능
배치 크기 고정, 대규모 동적, Continuous Batching
장애 영향 체크포인트로 복구 사용자 체감 장애
스케일링 GPU 수 = 학습 속도 GPU 수 = 동시 처리량추론 서버는 학습 서버만큼의 GPU 간 통신이 필요 없다. 사용자 요청은 대부분 독립적이니까. 대신 지연시간(latency)이 중요하다.
추론 인프라 구성:
로드밸런서 -> 추론 서버 풀 -> 모델 서빙 프레임워크
|
+-- vLLM / TGI / TensorRT-LLM
+-- Continuous Batching
+-- KV 캐시 관리
+-- 모델 병렬화 (큰 모델용)
추론 서버 선택지:
- NVIDIA L40S: 추론 특화, 학습 대비 저전력/저가
- NVIDIA H100: 학습/추론 범용
- NVIDIA T4: 경량 추론, 가성비
- Google TPU: 추론 최적화 버전 제공
- Meta MTIA: 자체 추론 전용 칩 개발
서빙 프레임워크:
- vLLM: PagedAttention으로 KV 캐시 효율화. 오픈소스.
- TGI (Text Generation Inference): HuggingFace. 프로덕션용.
- TensorRT-LLM: NVIDIA 최적화. 최대 성능.
- ollama: 로컬 단일 사용자용. llama.cpp 백엔드.대규모 추론은 사용자 수에 따라 GPU를 수평 확장한다. 학습처럼 GPU를 묶는 게 아니라, 독립적인 추론 서버를 늘리는 방식이다. 6편에서 다뤘던 Continuous Batching이 여기서 핵심이 된다.
추론 인프라에서 비용 최적화:
[1] 양자화 적용:
FP16 -> INT8/INT4 -> VRAM 절약 -> 서버당 처리량 증가
[2] KV 캐시 최적화:
PagedAttention: 메모리를 페이지 단위로 관리 (OS 가상메모리와 유사)
-> KV 캐시 메모리 낭비 최소화
[3] Speculative Decoding:
작은 모델로 후보 토큰을 빠르게 생성 -> 큰 모델로 검증
-> 전체 지연시간 감소
[4] 추론 전용 하드웨어:
학습용 H100($30K) 대신 추론 특화 L40S($7K) 사용
-> 같은 예산으로 4배 이상 서버 확보전체 인프라 스택 요약
대규모 AI 인프라 스택:
+-- 퍼실리티(데이터센터) -----------------------------------+
| 전력: 수십~수백 MW, UPS, 변전소 |
| 냉각: Direct-to-Chip 수냉, CDU, 냉각탑 |
| PUE: 1.05~1.15 목표 |
+----------------------------------------------------------+
|
+-- 네트워크 ---------------------------------------------+
| BE: InfiniBand 또는 RoCE v2, 400Gbps, 논블로킹 |
| FE: 이더넷, 스토리지 접근 |
| 노드 내: NVLink/NVSwitch (900GB/s) |
+----------------------------------------------------------+
|
+-- 서버(컴퓨팅) -----------------------------------------+
| 학습: DGX H100/B200, GPU 8장, 10kW+, 수냉 |
| 추론: L40S/H100/T4, 워크로드별 선택 |
+----------------------------------------------------------+
|
+-- 스토리지 ---------------------------------------------+
| 체크포인트: Lustre/GPFS/WEKA, TB/s급 병렬 쓰기 |
| 학습 데이터: 오브젝트 스토리지 또는 병렬 FS |
| GPUDirect Storage: CPU 우회 직접 전송 |
+----------------------------------------------------------+
|
+-- 소프트웨어 -------------------------------------------+
| 학습: PyTorch, FSDP, 분산 학습 프레임워크 |
| 추론: vLLM, TGI, TensorRT-LLM |
| 오케스트레이션: Kubernetes, Slurm |
+----------------------------------------------------------+이게 로컬 LLM과 무슨 상관인가
시리즈 본편에서 다룬 ollama + GTX 1060은 이 스택의 극단적 축소판이다.
Meta 129K 클러스터 ollama + GTX 1060
-------------- ------------------ ------------------
GPU H100 x 129,000장 GTX 1060 x 1장
VRAM 총합 ~10 PB 6 GB
네트워크 400Gbps RDMA x 수만개 필요 없음 (단일 노드)
스토리지 PB급 병렬 FS 로컬 SSD
전력 ~100 MW 120 W
비용 수조 원 20만 원
용도 405B 모델 학습 7B 모델 추론같은 원리가 다른 스케일에서 동작하는 거다. 어텐션의 행렬곱도, KV 캐시의 VRAM 소비도, Decode의 메모리 바운드도 동일하다. 스케일만 다르다. 원리를 알면 어느 스케일에서든 판단할 수 있다.
이 글이 어떠셨나요?
관련 포스트
1. LLM은 텍스트를 어떻게 처리하는가
LLM이 텍스트 한 줄을 받아서 다음 토큰을 예측하기까지의 전체 과정을 4단계로 따라간다. 토크나이저, 임베딩, 트랜스포머 레이어, 출력까지 "OOM killer가 nginx를" 한 문장이 모델 안에서 겪는 여행.
2026. 03. 03. PM 10:00DevOps부록1. 왜 트랜스포머인가: RNN에서 Mamba까지
트랜스포머 이전의 RNN이 왜 한계에 부딪혔는지. 병렬화 불가, 장거리 의존성, 고정 상태 벡터. 트랜스포머가 이걸 어떻게 해결했고, Mamba가 어디로 가고 있는지.
2026. 05. 19. PM 10:00DevOps11. 실전 적용: 모델 선택부터 파이프라인까지
LLM을 실무에 적용하는 전략. 프롬프트 설계, RAG vs 파인튜닝 선택 기준, 계층형 파이프라인, 컨텍스트 윈도우 관리.
2026. 05. 12. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.