제4부 데이터센터와 스케일
4.9 Grace II — GB200 NVL72 랙스케일
4.9.1 이 장에서 배우는 것 / 선수 지식
지금까지의 조각을 랙 하나로 합친다. 4.4(Blackwell)·4.5(5세대 NVLink·NVL72)·4.8(Grace·C2C)가 만나는 곳이 GB200 NVL72 — Grace+Blackwell 슈퍼칩(GB200) 다수를 5세대 NVLink로 묶어 랙 하나를 하나의 거대 컴퓨터로 만든 시스템이다. 핵심은 두 종류의 고대역 결합이 한 랙에서 겹친다는 것: C2C(CPU↔GPU 일관) + NVLink(GPU↔GPU 전결합 72-도메인). 이 장은 그 통합 자원 풀과 전력·냉각·운영 현실, 그리고 "언제 랙 하나가 필요한가"를 다룬다. 발표 기준·변동 가능 표기를 유지한다.
배우는 것:
- GB200 슈퍼칩(Grace+Blackwell)과 그것을 모은 NVL72 랙의 구조 — C2C와 NVLink가 한 랙에서 겹치는 그림.
- 랙의 집계 자원(72-GPU NVLink 도메인 + Grace LPDDR + HBM 일관 풀)이 거대 모델에 주는 의미.
- 전력·냉각(액냉)·네트워킹·운영 현실 — "랙이 새 연산 단위"가 되며 따라오는 인프라 요건.
- 언제 랙 하나가 필요하고 언제 과투자인지 판단.
선수 지식: 4.4(Blackwell·듀얼다이·FP4), 4.5(NVLink 도메인·NVSwitch·NVL72), 4.8(Grace·C2C·일관 메모리), 4.7(토폴로지·bisection), 4.11(노드/랙 간 IB — 랙 너머), 4.14(병렬화 매핑). 환경은 0.3. 이 장의 GPU/CPU 수·메모리·전력·구성은 전부 발표 기준이며 변동 가능 — 정확한 사양은 그 시점 공식 자료로 확인. 데모와 양산 가용성 구분.
4.9.2 GB200 슈퍼칩 — Grace + Blackwell
GB200(발표 기준): Grace CPU와 Blackwell GPU를 NVLink-C2C(4.8)로 결합한 슈퍼칩 모듈. 한 모듈 안에서 CPU 메모리(LPDDR)와 GPU 메모리(HBM)가 일관 결합된다(구성·GPU 개수는 확인 필요 — 보통 1 Grace + 다수 Blackwell).
모듈 안에서 CPU-GPU 일관 메모리(HBM + LPDDR)가 형성된다. GB200 = 1 Grace + 2 Blackwell (→ 랙 36 Grace · 72 GPU).
이것이 4.8의 GH200(Grace+Hopper)의 다음 세대 — GPU가 Blackwell(FP4·듀얼다이)로, 그리고 여러 슈퍼칩을 NVLink로 묶는 NVL72의 구성 단위가 된다.
4.9.3 NVL72 — 두 결합이 겹치는 랙
GB200 NVL72(발표 기준): GB200 슈퍼칩 다수를 컴퓨트 트레이로 랙에 넣고, 5세대 NVLink·NVSwitch(랙 백플레인) 로 72개 Blackwell GPU를 하나의 NVLink 도메인(4.5)으로 묶는다. 동시에 각 GPU는 짝 Grace와 C2C 일관 결합(4.8).
각 트레이 안에서는 C2C(CPU↔GPU 일관)가, 트레이↔트레이는 5세대 NVLink가 동작한다. 즉 한 랙에서 두 결합이 겹친다 — C2C: 각 GPU ↔ 자기 Grace(CPU 메모리 일관 확장, 4.8), NVLink: 72 GPU 전결합(GPU 간 고대역 도메인, 4.5).
핵심: 한 랙 안에서 "GPU↔GPU 전결합(NVLink 72-도메인)"과 "CPU↔GPU 일관(C2C)"이 동시에 작동한다. 거대 모델이 ① GPU 간 통신은 72-GPU NVLink 고대역으로, ② HBM을 넘는 메모리는 Grace LPDDR로 일관 확장 — 두 병목(통신·용량)을 한 랙에서 함께 푼다.
4.9.4 집계 자원 — 랙이 새 연산 단위
NVL72 한 랙의 자원을 "하나의 컴퓨터"로 보면(수치는 발표 기준·확인 필요, 여기선 구조):
| 자원 | 집계 내용 |
|---|---|
| 연산 | 72 × Blackwell GPU의 텐서코어 (FP4/FP8, 4.4) 집계 |
| GPU 메모리 | 72 × HBM (단일 NVLink 도메인에서 집계 풀, 4.5) |
| CPU 메모리 | 36(또는 구성별) × Grace LPDDR (C2C 일관 확장, 4.8) |
| 통신 | 72-GPU 전결합 NVLink (큰 bisection, 4.7) + 랙 간 IB (4.11) |
= HBM(빠름) + LPDDR(큼) 일관 풀 + 72-GPU 고대역 도메인을 한 랙에.
왜 "랙이 새 단위"인가: 과거엔 GPU 한 장 또는 8-GPU 노드가 사고의 단위였다(4.1). 거대 모델(조 단위 파라미터·큰 MoE·거대 추론)이 노드를 넘어서자, 랙 전체를 하나의 자원 풀로 보고 그 위에 모델을 펼치는 것이 자연스러워졌다 — "the datacenter is the computer". NVL72는 그 단위를 하드웨어로 구현한 것.
사고 단위의 진화 — 각 단계마다 '하나처럼 보이는' 경계가 커진다 (다이→노드→랙→클러스터).
4.9.5 전력·냉각·운영 현실
랙스케일은 인프라 요건이 따라온다 — 칩 사양만 보면 안 되는 이유.
전력. 72 GPU + 36 Grace + NVSwitch의 랙 전력은 수십 kW급(정확한 값 발표 기준·확인 필요). 일반 데이터센터 랙(수 kW)을 한참 초과 → 고전력 배전·전원 설비가 필요.
냉각 — 액냉. 이 전력 밀도는 공랭으로 못 식힌다 → 액체 냉각(liquid cooling). 콜드플레이트·매니폴드·CDU(냉각 분배 장치)가 랙에 통합. 데이터센터가 액냉을 지원해야 도입 가능 — 시설 개조가 전제일 수 있다.
도입 전제: 데이터센터의 전력 용량·액냉 인프라·바닥 하중·배관. '칩을 산다'가 아니라 '데이터센터를 (재)설계한다'에 가깝다.
네트워킹. 랙 안은 NVLink, 랙 간은 여전히 InfiniBand(4.11). 여러 NVL72를 SuperPOD으로 묶으면 랙 간 IB 패브릭이 다음 병목·설계 지점.
운영·서비스. 고밀도·액냉·일체형이라 유지보수·교체·모니터링(7.3 DCGM) 이 노드 단위와 다르다. RAS(신뢰성·가용성·서비스성)가 중요 — 한 컴포넌트 장애가 큰 도메인에 영향.
정직: 대부분의 조직은 NVL72를 직접 소유·운영하지 않는다 — 전력·액냉·자본·운영 부담이 크다. 클라우드로 임대하거나, 초대형 학습이 필요한 소수가 코로케이션·전용 시설로 운영한다. 도입은 칩이 아니라 시설·전력·냉각·운영 역량 문제다.
4.9.6 워크스루 — 언제 랙 하나가 필요한가
의사결정 워크스루.
예 — 조 단위 MoE 학습: Q1 아니오(노드 초과), Q2 예(전문가 all-to-all이 막대 → 큰 도메인 필요), Q3 예(거대 상태) → NVL72 적합. 단 Q4(시설)로 보통 클라우드 임대.
예 — 7B 모델 다수 추론 서빙: Q1 예(한 GPU/노드에 들어감) → 노드·추론 갈래로 충분, NVL72 과투자(4.1).
집계 메모리 산수(개념). 거대 모델 추론에서 가중치 + KV가 단일 GPU HBM을 크게 초과하면, 72-GPU NVLink 도메인에 가중치를 텐서 병렬로 펼치고(통신은 NVLink 고대역) KV를 HBM+LPDDR 일관 풀에 두는 식으로 한 랙에 담는다 — 노드 8-GPU로는 통신·용량 둘 다 한계에 부딪히던 규모를 랙이 흡수. (정확한 용량·성능은 발표 기준·실측.)
4.9.7 중간 점검 (체크포인트)
- [ ] GB200(Grace+Blackwell)과 NVL72(72-GPU NVLink 도메인)의 관계, C2C와 NVLink가 한 랙에서 겹침을 그린다.
- [ ] 랙의 집계 자원(72-GPU 도메인 + HBM/LPDDR 일관 풀)이 거대 모델의 통신·용량 병목을 함께 푸는 방식을 설명한다.
- [ ] 랙스케일의 전력·액냉·랙 간 IB·운영 요건을 알고, "칩이 아니라 시설 문제"임을 안다.
- [ ] 워크로드가 노드를 넘어 큰 NVLink 도메인·거대 메모리를 요구할 때만 랙이 정당함을 판단한다.
증상→의심: 거대 모델이 다노드에서 통신 병목·확장 실패 → 통신 집약 병렬화가 NVLink 도메인(8) 초과, 큰 도메인(NVL72) 필요(4.14). NVL72인데 활용률 낮음 → 워크로드가 작아 과투자(노드면 충분). 랙 도입 검토가 이해 곤란 → 전력·액냉 시설 미비(클라우드 임대 고려). 랙 간 확장이 안 됨 → 랙 간은 IB(4.11), NVLink 아님.
4.9.8 트레이드오프
| 단위 | 적합 워크로드 | 비고 |
|---|---|---|
| 1 GPU / MIG | 작은 추론·실험 | 4.1·4.10 |
| 8-GPU 노드 | 대부분의 학습·추론 | NVLink 도메인 8, IB로 스케일아웃 |
| NVL72 랙 | 조 단위 모델·큰 MoE·거대 추론 | 72-도메인 + Grace 메모리. 시설 전제 |
| SuperPOD(랙 다수) | 초대형 학습 | 랙 간 IB 패브릭(4.11) |
견해: NVL72는 "노드로는 통신·용량이 둘 다 한계에 부딪히는 거대 모델" 의 도구다. 그 규모가 아니면 8-GPU 노드 + IB 스케일아웃이 비용·유연성에서 낫다. 소유는 전력·액냉·자본·운영 부담이 커, 대부분 클라우드 임대가 합리적. "최대 시스템을 사는" 게 아니라 워크로드가 랙 단위를 요구하는지 먼저 증명하고, 요구해도 임대로 시작.
비NVIDIA 정직: "랙·데이터센터를 하나의 컴퓨터로"는 업계 공통 방향이다 — 다른 가속기 벤더·하이퍼스케일러도 랙스케일 통합·액냉·전용 패브릭을 추진(TPU Pod, 자체 슈퍼컴 등). NVL72의 차별점은 NVLink 72-도메인 + Grace 일관 결합 + CUDA·NCCL 통합의 성숙도. 평가는 칩이 아니라 시스템·소프트웨어·운영 전체로, 사양은 발표 기준이니 실측·TCO로.
4.9.9 흔한 함정
- 칩 사양만 보고 도입 결정. NVL72는 수십 kW·액냉·시설 개조가 전제. 전력·냉각·바닥하중·배관을 빼고 "칩이 빠르다"만 보면 도입이 차단된다.
- 랙 = 단일 디바이스 오해. 72-GPU NVLink 도메인은 고대역 peer·집합연산을 주지만 자동으로 한 CUDA 디바이스가 되진 않는다 — 여전히 멀티-GPU 병렬화(NCCL, 4.13~4.14). (4.4 듀얼다이의 단일 디바이스 추상과 다른 층.)
- 과투자. 노드로 충분한 워크로드에 랙을 사면 활용률·TCO가 나쁘다. 워크로드가 노드를 넘는지 먼저 증명.
- 랙 간을 NVLink로 가정. 랙 안은 NVLink, 랙 간은 IB(4.11). 여러 랙 학습은 IB 패브릭 설계가 별도 병목·과제.
- 발표 수치 단정. GPU/CPU 수·메모리·전력·가용성은 발표 기준·변동. 데모와 양산을 구분, 실측·데이터시트로.
- 운영 역량 과소평가. 액냉·고밀도·RAS·모니터링(7.3)은 노드 운영과 다르다. 소유하려면 운영 역량이 전제 — 없으면 클라우드.
4.9.10 연습문제
연습 1 (두 결합). NVL72 한 랙에서 동시에 작동하는 두 종류의 고대역 결합(C2C·NVLink)을 구분하고, 거대 모델 학습에서 각각이 어떤 병목을 푸는지.
정답
① NVLink-C2C(CPU↔GPU 일관, 4.8): 각 Blackwell GPU가 짝 Grace의 LPDDR을 일관·고대역으로 접근 → HBM 용량 벽을 LPDDR로 확장(거대 임베딩·KV·옵티마이저 상태를 HBM 너머에). ② 5세대 NVLink(GPU↔GPU 전결합, 4.5): 72 GPU가 단일 NVLink 도메인으로 전결합 → GPU 간 통신 병목(텐서 병렬 all-reduce·MoE all-to-all)을 NVLink 고대역·큰 bisection 안에서 해결. 한 랙이 통신(②)과 용량(①) 병목을 함께 푼다.
연습 2 (단위 판단). 다음 각각에 적합한 단위(1 GPU/MIG · 8-GPU 노드 · NVL72 랙)를 고르고 근거: (a) 1.8T MoE 사전학습, (b) 70B 모델 LoRA 파인튜닝, (c) 다수 소형 모델 추론, (d) 2T 모델 저지연 추론 서비스.
정답
(a) NVL72 랙 — 노드 초과·MoE all-to-all 막대·거대 상태 → 큰 NVLink 도메인 + Grace 메모리. (b) 8-GPU 노드(또는 그 이하) — 70B LoRA는 보통 한 노드 NVLink 도메인에 들어가고 통신이 풀학습보다 적음. (c) 1 GPU/MIG — 소형 모델 다수는 분할·수평 확장(4.10), 큰 도메인 불필요. (d) NVL72 랙 — 2T 모델은 가중치·KV가 노드를 크게 초과, 텐서 병렬 통신을 72-도메인 NVLink로 + 메모리를 HBM/LPDDR 풀로. 핵심: 통신·용량이 노드를 넘느냐.
연습 3 (인프라). 한 팀이 NVL72를 온프렘 소유하려 한다. 칩 성능 외에 반드시 확인해야 할 인프라 요건 4가지와, 이것들이 "대부분 클라우드 임대"로 이어지는 이유.
정답
요건: ① 전력 — 랙당 수십 kW 배전·전원 용량, ② 냉각 — 액냉 인프라(CDU·매니폴드·콜드플레이트)와 데이터센터 액냉 지원, ③ 물리 시설 — 바닥 하중·배관·공간·랙 규격, ④ 운영 역량 — 고밀도·RAS·모니터링(7.3)·유지보수 절차. 클라우드 임대로 이어지는 이유: 이 요건들이 막대한 자본·시설 개조·전문 운영을 요구해, 초대형·고사용률이 아닌 한 소유의 TCO·리스크가 크다. 클라우드는 이 인프라를 이미 갖춰 임대로 즉시 쓸 수 있어 대부분에 합리적.
4.9.11 요약 · 다음 장
- GB200 NVL72는 Grace+Blackwell 슈퍼칩(GB200)을 5세대 NVLink로 묶어 랙 하나를 하나의 컴퓨터로 만든 시스템 — 한 랙에서 C2C(CPU↔GPU 일관) 와 NVLink(72-GPU 전결합 도메인) 가 겹친다.
- 랙의 집계 자원(72-GPU NVLink 도메인 + HBM/LPDDR 일관 풀)이 거대 모델의 통신·용량 병목을 함께 푼다 — "랙이 새 연산 단위".
- 대가는 인프라: 수십 kW·액냉·랙 간 IB·고급 운영. 도입은 "칩"이 아니라 시설·전력·냉각·운영 역량 문제 → 대부분 클라우드 임대.
- 랙은 노드로는 통신·용량이 둘 다 한계에 부딪히는 거대 모델 전용 도구다. 그 규모가 아니면 노드 + IB가 낫다. 수치는 발표 기준·실측·TCO로.
다음 장: 4.10 MIG와 GPU 공유. 지금까지 "여러 GPU를 하나처럼 키우는" 방향(스케일업)이었다면, 이제 반대로 한 GPU를 여러 개로 나누는 방향이다. MIG(Multi-Instance GPU)로 하드웨어 분할·멀티테넌시를 구현하는 법과, MPS·타임슬라이싱과의 차이(7.4~7.5 예고)를 본다.