제1부 GPU 아키텍처

1.9 HBM과 대역폭 산수

1.9.1 이 장에서 배우는 것 / 선수 지식

1.7~1.8에서 온칩 메모리를 봤다. 이 장은 그 바깥 — 글로벌 메모리(GPU의 DRAM, 오늘날 대부분 HBM) 의 물리 구조와 대역폭·용량이라는 자원을 다룬다. "대역폭 = 폭 × 레이트"의 산수와, LLM 추론에서 용량(GB) 이 배치·KV 캐시·동시 사용자를 어떻게 제약하는지를 본다. 이 대역폭을 성능 천장으로 바꾸는 루프라인 분석은 1.10으로 잇는다.

배우고 나면 할 수 있어야 하는 것:

GDDR과 HBM 스택의 구조 차이를 도해로 설명하고, 대역폭·용량·전력의 트레이드오프를 말한다.
"대역폭 = 버스 폭 × 데이터레이트 ÷ 8"의 산수를 안다.
LLM 추론에서 HBM 용량이 모델 가중치·KV 캐시·활성화로 나뉘고, KV 캐시가 배치·길이에 선형임을 계산한다(5.7 연결).

선수 지식: 1.2(처리량 컴퓨팅), 1.7~1.8(온칩 메모리·병합). 정밀도 포맷은 1.13에서 깊이 다루지만 여기선 "원소 1개가 몇 바이트인가"만 알면 된다(FP32=4B, FP16/BF16=2B, FP8/INT8=1B).

정직성: HBM 스택당 GB/s·패키지 총 GB·TB/s는 세대·제품·시점 의존이라 반드시 해당 시점 공식 사양으로 확인. 본문 수치는 산수 시범용.

1.9.2 왜 대역폭이 천장인가

GPU가 일을 끝내려면 (1) 산술 연산 능력(FLOP/s)과 (2) 그 연산에 먹일 데이터를 가져오는 능력(byte/s, HBM)이 둘 다 필요하다. 어떤 커널이든 실행 시간은 둘 중 느린 쪽이 정한다.

실행 시간 $\approx \max($총 FLOP / 피크 FLOP/s, 총 byte / 피크 byte/s$)$

연산이 데이터보다 오래 걸리면 연산 바운드(코어가 바쁨), 반대면 메모리 바운드(코어가 데이터를 기다림). AI 워크로드의 핵심 사실: 딥러닝의 많은 연산이 메모리 바운드다(재사용 적은 element-wise·정규화·어텐션 softmax·LLM 디코딩). 이 둘을 정량 비교하는 도구(산술 강도·루프라인)는 1.10이며, 이 장은 그 한쪽 천장(대역폭·용량)의 물리적 정체를 세운다.

1.9.3 GDDR vs HBM — 물리 구조

글로벌 메모리는 GPU 패키지 바깥(소비자 GPU의 GDDR) 또는 같은 패키지 안(데이터센터 GPU의 HBM)의 DRAM이다. 근본 차이는 인터페이스 폭과 배치다.

GDDR(GDDR6·6X·7 등) — PCB 위에 메모리 칩을 평면 배치하고 칩마다 32비트 폭 채널을 긴 PCB 트레이스로 연결. 폭이 좁은(채널당 32b) 대신 신호 클럭을 매우 높여 대역폭을 낸다.

HBM(High Bandwidth Memory; HBM2e·3·3e·4 등) — DRAM 다이를 여러 장(4~16 hi) 수직 적층(TSV로 관통 연결)하고, 그 스택을 GPU 다이와 함께 실리콘 인터포저 위에 나란히 놓아 수천 비트(스택당 1024b급) 의 초광폭 버스로 잇는다. 폭이 압도적으로 넓은 대신 클럭은 GDDR보다 낮다.

대역폭의 정체는 단순하다: 대역폭 = 버스 폭(비트) × 유효 데이터레이트(비트/초/핀) ÷ 8. HBM은 폭으로, GDDR은 클럭으로 같은 곱을 향해 간다.

1.9.3.1 트레이드오프 — 대역폭·용량·전력·비용

축	GDDR	HBM
버스 폭	협폭(칩당 32b), 다수 칩	초광폭(스택당 ~1024b)
핀당 클럭	매우 높음	상대적으로 낮음
총 대역폭	높음(소비자급)	매우 높음(데이터센터급, GDDR 대비 수 배)
용량	다이당 제약, 보드 면적 의존	적층(hi)으로 패키지당 고용량
전력 효율(pJ/bit)	낮음(고클럭·긴 트레이스)	높음(짧은 TSV·저전압 광폭)
비용·제조	표준 PCB, 저렴	인터포저·TSV·적층, 비쌈·수율 난도
주 용도	게이밍·워크스테이션	데이터센터 AI·HPC

핵심 관점 셋:

전력당 비트(pJ/bit). 고클럭 협폭(GDDR)은 신호를 빠르게 토글하느라 전력을 더 소모한다. 광폭 저전압(HBM)은 같은 대역폭을 더 적은 전력으로 — 데이터센터에서 와트가 곧 돈이자 열이므로 HBM이 유리.
대역폭 vs 용량은 별개 축이다. 적층 수·다이 밀도가 용량을, 폭×클럭이 대역폭을 정한다. LLM 추론은 용량(모델·KV가 들어가야)과 대역폭(토큰마다 가중치를 읽어야) 둘 다에 병목이 된다(1.9.5).
세대 진화는 거의 다 이 곱을 키우는 일. HBM2e→3→3e→4는 핀당 레이트·(일부)폭·적층을 키워 스택당 대역폭·용량을 끌어올린다. GPU 세대별 HBM 실장은 4.1(라인업)·4.2(Hopper)·4.4(Blackwell).

1.9.4 워크스루 — 대역폭 산수

대역폭(B/s) $=$ 버스 폭(bit) $\times$ 유효 데이터레이트(transfers/s/pin) $\div 8$
예(산수 시범용 가정): 스택당 폭 1024b, 스택 6개 → 총 폭 6144b
유효 레이트 6.4 Gbps/pin
대역폭 $= 6144 \times 6.4\mathrm{e}9 \div 8 \approx 4.9\mathrm{e}12\,\mathrm{B/s} \approx 4.9\,\mathrm{TB/s}$ (가정값)

실측 대역폭은 이 이론값의 일부(컨트롤러 효율·리프레시·접근 패턴)다. 한 커널이 실제로 보는 대역폭은 병합 여부(1.8)에도 좌우된다 — 비병합이면 가져온 바이트의 일부만 쓰여 유효 대역폭이 급락한다.

1.9.5 메모리 용량이 LLM 배치·KV 캐시를 좌우 (5.7 연결)

대역폭이 "얼마나 빨리"라면 용량(GB)은 "애초에 들어가는가"다. LLM 추론에서 HBM 용량은 세 부분으로 나뉜다:

HBM 총 용량(GB) $=$ 모델 가중치(고정, $P \cdot b$) + KV 캐시(배치·길이에 비례, 변동) + 활성화·작업버퍼(상대적으로 작음)

실사용 가능 용량은 데이터시트 용량보다 조금 작다. 데이터센터 GPU의 HBM은 보통 ECC(오류 정정) 가 켜져 있고, ECC는 오류 정정 코드를 저장할 용량을 예약해 실사용 가능 용량을 정가 용량보다 줄인다(정확한 손실률·구현 방식은 세대·설정 의존 → 확인 필요). "80GB GPU"처럼 표기된 값이 배치·KV 용량 계산의 정확한 상한이 아닐 수 있으니, 타이트하게 채우는 배치·KV 캐시 산정에는 약간의 여유(margin) 를 두거나 nvidia-smi로 실제 가용 용량을 확인한다.

KV 캐시 산수. 트랜스포머는 디코딩 시 과거 토큰의 Key·Value를 저장해 재계산을 피한다. 대략적 크기:

KV 바이트 $\approx 2$(K·V) $\times L$(층 수) $\times H_{\mathrm{kv}}$(KV 헤드수) $\times d_{\mathrm{head}} \times b_{\mathrm{kv}} \times S$(시퀀스) $\times B$(배치)

여기서 b_kv는 KV 캐시 정밀도(FP16=2B, FP8=1B). 핵심 관찰:

KV 캐시는 배치 B·시퀀스 길이 S에 선형으로 커진다. 가중치는 고정이지만 KV는 동시 사용자·문맥 길이에 따라 폭증 → 긴 문맥·다중 사용자 서빙에서 용량 병목은 가중치가 아니라 KV 캐시가 되기 쉽다.
그래서 "배치를 키워 대역폭 효율을 높인다"(1.10)와 "용량이 KV 캐시로 초과된다"가 정면충돌한다. 서빙 배치 크기는 이 둘의 균형점이다.
완화책: GQA·MQA(KV 헤드 수↓), KV 캐시 양자화(b_kv↓), PagedAttention류 블록 관리(단편화 제거로 실효 용량↑), 오프로드(CPU·NVMe로 일부 내림 — 대역폭 페널티). 구현은 5.7(TensorRT-LLM: KV 캐시·인플라이트 배칭)·3.6(어텐션).

두 천장이 동시에 작용한다. LLM 서빙 용량 계획은 (1) "모델+KV가 HBM에 들어가는가"(용량)와 (2) "토큰을 충분히 빨리 생성하는가"(대역폭) 둘을 함께 푼다. 용량이 모자라면 텐서 병렬로 여러 GPU에 모델을 분할해 배치하는데(4.6·5.9), 그러면 GPU 간 인터커넥트 대역폭이 새 변수로 들어온다. 대역폭 사고는 HBM에서 끝나지 않고 NVLink·네트워크로 이어진다(4.6·4.11).

1.9.6 중간 점검 (체크포인트)

[ ] GDDR과 HBM의 구조 차이("좁고 빠르게 vs 넓고 느리게")와 전력·용량·비용 트레이드오프를 제시한다.
[ ] "대역폭 = 폭 × 레이트 ÷ 8"을 쓰고 가정값으로 계산한다.
[ ] LLM 용량이 가중치+KV+활성화로 나뉘고 KV가 배치·길이에 선형임을 안다.
[ ] 대역폭과 용량이 별개 천장이며 서로 충돌(배치↑로 대역폭효율↑ ↔ KV로 용량↓)함을 설명한다.

증상: "모델이 안 올라간다" → 용량 문제(텐서 병렬·양자화·KV 관리). "올라가는데 토큰이 느리다" → 대역폭 문제(양자화·배칭, 1.10).

1.9.7 흔한 함정

용량과 대역폭을 하나로 취급. "들어가는가(용량)"와 "빠른가(대역폭)"는 별개 천장이고 충돌한다. 따로 계산.
이론 대역폭을 실측으로 인용. 컨트롤러 효율·리프레시·비병합으로 실측은 이론의 일부. 병합 여부가 유효 대역폭을 좌우(1.8).
KV 캐시를 잊고 가중치만으로 용량 계획. 긴 문맥·다중 사용자에선 KV가 가중치를 추월한다. GQA·KV 양자화·PagedAttention 고려.
HBM 절대 수치 단정. 스택당·패키지 총 대역폭·용량은 세대·제품 의존. 공식 사양으로 확인.

1.9.8 연습문제

연습 1 (대역폭 산수). 스택당 폭 1024b, 스택 8개, 유효 레이트 8 Gbps/pin인 패키지의 이론 대역폭(TB/s)을 구하라.

정답

총 폭 = 1024 × 8 = 8192b. 대역폭 = 8192 × 8e9 ÷ 8 = 8.19e12 B/s ≈ 8.2 TB/s(이론, 가정값). 실측은 이보다 낮고 접근 패턴에 좌우.

연습 2 (KV 캐시 용량). 7B 모델(FP16, 가중치 14 GB), 32층, KV 헤드 8, head_dim 128, KV FP16(2B). 시퀀스 2048, 배치 16의 KV 캐시(GB)를 구하고 80 GB GPU에 가중치와 함께 들어가는지 보라. 배치 64면?

정답

KV바이트 = 2×32×8×128×2×2048×B. 계수(B 제외) = 2·32·8·128·2·2048 ≈ 2.68e8 B/배치 ≈ 0.268 GB/배치. B=16 → ≈4.3 GB, 합 14+4.3≈18.3 GB → 여유. B=64 → KV≈17.2 GB, 합≈31.2 GB → 여전히 들어감. KV는 배치·길이에 선형이라 더 큰 모델·긴 문맥·큰 배치에선 가중치를 추월(1.9.5).

연습 3 (HBM vs GDDR 선택). (a) 큰 배치 LLM 학습, (b) 단일 GPU 중소 모델 추론(비용 민감). 각각 HBM/GDDR 중 무엇이 적합하고 왜인가?

정답

(a) HBM — 용량·대역폭·전력효율·멀티GPU 스케일이 중요. (b) GDDR(소비자/워크스테이션) — 모델이 GDDR 용량에 들어가고 처리량 요구가 중간이면 비용대비 합리적, 양자화로 대역폭·용량 압박 완화. 핵심 판별: 용량·대역폭 요구와 비용·전력 제약.

1.9.9 요약 · 다음 장

HBM은 GDDR 대비 광폭·저전압으로 대역폭·용량·전력효율을 동시에 얻는 대신 비용이 크다. "대역폭 = 폭 × 레이트 ÷ 8".
LLM 서빙은 대역폭(토큰 속도) 과 용량(모델+KV) 의 두 천장을 함께 풀어야 하며 둘은 충돌한다. KV 캐시는 배치·길이에 선형으로 커진다.
HBM 절대 수치는 세대·제품 의존 — 공식 사양으로 확인.

다음 장: 1.10 루프라인·메모리바운드 분석. 이 장의 대역폭을 성능 천장으로 바꾸는 도구 — 산술 강도와 루프라인으로 임의 커널이 메모리/연산 바운드인지 종이·연필로 판정하고, 메모리 바운드의 약(융합·재사용·정밀도)을 정한다.