Chapter 13

메모리 시스템 설계

지금까지 셀 하나의 물리에서 출발해 DRAM 어레이, 인터페이스, HBM 적층, NAND와 SSD, 신뢰성까지 부품 단위로 메모리를 배웠다. 실제 제품을 만드는 사람에게 던져지는 질문은 하나다. “이 칩에는 어떤 메모리를, 몇 개, 어떻게 붙일 것인가?” 이 장은 그 질문에 답하는 도구를 모은 플레이그라운드다. 루프라인으로 병목을 진단하고, LLM 추론에 필요한 메모리를 계산하고, 기술을 골라 직접 메모리 시스템을 설계해 본다.

워크로드의 요구를 대역폭·용량·지연·전력·비용 다섯 축으로 정리하고 메모리 기술과 짝지을 수 있다.
산술 강도와 루프라인 모델로 커널이 메모리 한계인지 연산 한계인지 판정할 수 있다.
LLM의 가중치·KV 캐시 용량과 디코드 토큰/초 상한을 식으로 계산할 수 있다.
DDR5·LPDDR5X·GDDR7·HBM3E/HBM4·CXL 메모리의 대역폭, 용량, pJ/bit, 비용, 폼팩터 차이를 설명할 수 있다.
메모리 전력 = pJ/bit × 비트율로 전력 예산을 세우고, 기기별 실제 메모리 구성이 왜 그렇게 되었는지 설명할 수 있다.

설계 문제: 워크로드에 맞는 메모리 고르기

메모리 시스템 설계는 결국 요구사항을 숫자로 적는 일에서 시작한다. 프로세서가 초당 몇 바이트를 먹는지(대역폭(bandwidth)), 한 번에 얼마를 들고 있어야 하는지(용량(capacity)), 첫 바이트가 얼마나 빨리 와야 하는지(지연(latency)), 그리고 이것을 얼마의 전력과 비용, 보드 면적 안에서 해내야 하는지다. 1장에서 본 메모리 계층의 트레이드오프가 여기서는 “어느 DRAM을 고를까”라는 구체적인 선택지로 바뀐다.

그림 13-1. 워크로드마다 다섯 요구사항의 무게가 다르다(원 크기 = 상대적 중요도). 폰은 전력과 비용, GPU와 AI 가속기는 대역폭, 서버는 용량·비용·지연, 차량은 실시간성(최악 지연)과 신뢰성이 결정적이다. 그 결과 선택되는 메모리 기술이 갈린다.

설계 절차는 대략 다음 네 단계로 정리된다. 이 장의 시뮬레이터는 이 순서를 그대로 따른다.

병목 진단커널의 산술 강도를 구해 루프라인에 올린다. 메모리 한계인가, 연산 한계인가?

요구량 산정필요한 대역폭(바이트/초)과 용량(바이트)을 워크로드 식으로 계산한다. LLM이면 가중치+KV 캐시.

기술 선택DDR5·LPDDR5X·GDDR7·HBM·CXL 가운데 대역폭/용량/pJ/bit/비용이 맞는 것을 고르고 개수를 정한다.

예산 검증전력(pJ/bit × 비트율), 비용, 면적, 신뢰성(ECC) 예산 안에 드는지 확인하고 반복한다.

대역폭과 지연은 다른 문제다

HBM은 대역폭이 DDR5의 20배를 넘지만 지연은 거의 같다(둘 다 DRAM 셀이고, tRCD·CL 같은 코어 타이밍이 비슷하다 — 5장). CPU의 load-to-use 지연은 로컬 DRAM에서 약 80~120 ns, CXL로 붙인 메모리는 여기에 약 70~100 ns가 더해진다. 포인터를 따라가는 DB·그래프 워크로드는 대역폭보다 지연에 민감하고, 행렬 연산은 반대다. 이 장의 시뮬레이터는 주로 대역폭·용량·전력·비용을 다루며, 지연은 표와 콜아웃으로 보충한다.

루프라인 모델: 메모리 한계인가, 연산 한계인가

어떤 계산 커널이 빠른지 느린지는 두 숫자로 거의 결정된다. 프로세서의 피크 연산 성능 $\pi$ (FLOP/s)와 메모리 대역폭 $\beta$ (Byte/s). 그리고 커널 쪽의 숫자 하나, 산술 강도(arithmetic intensity, operational intensity) $I$다. 산술 강도는 DRAM에서 가져온 바이트 하나당 몇 번의 연산을 하는지를 뜻한다.

$$I = \frac{\text{연산 수 (FLOP)}}{\text{DRAM 트래픽 (Byte)}},\qquad P_{\text{attainable}} = \min\!\left(\pi,\ \beta \cdot I\right),\qquad I_{\text{ridge}} = \frac{\pi}{\beta}$$

$P$: 도달 가능한 성능 상한. $I_{\text{ridge}}$(릿지 포인트): 두 지붕이 만나는 산술 강도. 커널의 $I$가 이보다 작으면 메모리 한계(memory-bound), 크면 연산 한계(compute-bound)다. Williams·Waterman·Patterson(2009)이 제안했다.

그림 13-2. 루프라인. 로그-로그 축에서 메모리 지붕은 기울기 1의 직선($P=\beta I$)이고 연산 지붕은 수평선($P=\pi$)이다. 릿지 포인트 왼쪽의 커널은 메모리 대역폭을 늘려야(경사 지붕을 위로) 빨라지고, 오른쪽 커널은 연산기를 늘려야 빨라진다. 알고리즘 쪽에서는 데이터 재사용(타일링, 배치)으로 커널을 오른쪽으로 옮길 수 있다.

대표 커널의 산술 강도

산술 강도는 커널의 데이터 재사용 정도를 말해 준다. 몇 가지는 손으로 쉽게 계산된다.

STREAM Triad $a_i = b_i + s\,c_i$ (FP64): 원소당 2 FLOP, 읽기 16 B + 쓰기 8 B → $I = 2/24 \approx 0.083$. 재사용이 전혀 없다.
GEMV $y = Ax$ ($n\times n$, FP16): $2n^2$ FLOP, 행렬 $2n^2$ B → $I \approx 1$. LLM의 배치 1 디코드가 바로 이 형태다.
GEMM $C = AB$ ($n\times n$, FP16, 캐시가 충분하다고 가정): $2n^3$ FLOP, $3\cdot 2n^2$ B → $I \approx n/3$. $n=4096$이면 약 1365.
3×3 합성곱(CNN 중간층): 출력 하나에 필터 가중치와 입력 창을 반복 재사용하므로 수십~수백. 깊이별(depthwise) 합성곱은 채널 간 재사용이 없어 한 자릿수로 떨어진다.

릿지 포인트는 최근 가속기일수록 커지고 있다. 연산기는 공정·아키텍처(텐서 코어, 낮은 정밀도)로 빠르게 늘지만 DRAM 대역폭은 그만큼 늘지 못하기 때문이다. 이것이 1장에서 말한 메모리 월의 현대판이며, HBM(7장)과 PIM(12장)이 등장한 이유다.

SIMULATOR

루프라인 플레이그라운드

프로세서

피크 연산 π 메모리 대역폭 β LLM 디코드 배치 B 온칩 캐시 지붕 표시 (DRAM의 ~5배 가정)

릿지 포인트—

선택한 커널—

산술 강도 I—

도달 가능 성능—

병목 판정—

피크 대비—

연산 한계가 되려면 β ≥—

해볼 것: 점을 클릭해 선택하고 좌우로 드래그하면 산술 강도가 바뀐다. ① H100급에서 “LLM 디코드” 점(배치 1)은 피크의 0.3 %만 쓴다. 배치 B 슬라이더를 올려 릿지(≈ 300)를 넘는 배치를 찾아보자. ② 프리셋을 “폰 NPU”로 바꾸면 릿지가 600을 넘는다. 폰에서 LLM이 왜 대역폭에 목마른지 보인다. ③ “서버 CPU”는 릿지가 약 20이라 3×3 합성곱도 연산 한계가 된다. ④ 대역폭만 2배로 올리면 메모리 한계 커널은 정확히 2배 빨라지지만 GEMM은 그대로다.

루프라인을 읽는 요령

루프라인은 상한이다. 실제 커널은 지붕 아래에 찍힌다. 지붕과의 간격이 크면 캐시 미스, 뱅크 충돌, 불충분한 병렬성, 명령어 오버헤드 같은 구현 문제를 의심한다. 또 “DRAM 트래픽”을 어떻게 세느냐가 중요하다. 같은 GEMM이라도 타일이 캐시에 들어가지 않으면 같은 데이터를 여러 번 DRAM에서 다시 읽게 되고, 실효 산술 강도가 뚝 떨어진다. 캐시 계층마다 지붕을 따로 그리는 계층적 루프라인이 이런 분석에 쓰인다.

LLM 추론의 메모리

대규모 언어 모델(LLM) 추론은 현대 메모리 설계를 이끄는 가장 강력한 워크로드다. 추론은 두 단계로 나뉜다. 프롬프트 전체를 한꺼번에 처리하는 프리필(prefill)과, 토큰을 하나씩 생성하는 디코드(decode)다. 두 단계의 메모리 성격은 정반대다.

그림 13-3. (a) 프리필은 가중치 행렬을 한 번 읽어 N개 토큰에 재사용하므로 산술 강도가 높다. (b) 디코드는 토큰 하나를 만들 때마다 모든 가중치와 지금까지 쌓인 KV 캐시를 DRAM에서 다시 읽는다. 배치와 문맥이 커지면 KV 캐시가 가중치보다 커지는 일이 흔하다(아래 바는 Llama-3-8B 구조로 계산한 예).

① 가중치 메모리

$$M_{W} = N_{\text{param}} \times b_{W}$$

$b_W$: 파라미터당 바이트. FP16/BF16 = 2, FP8 = 1, INT4 = 0.5 (양자화 스케일 같은 메타데이터는 무시). 예: 70B 모델은 FP16 140 GB, FP8 70 GB, INT4 35 GB.

② KV 캐시

어텐션은 이전 모든 토큰의 키(K)와 값(V) 벡터를 다시 쓴다. 매번 재계산하지 않도록 레이어마다 저장해 두는 것이 KV 캐시다.

$$M_{KV} = 2 \cdot L \cdot n_{kv} \cdot d_{head} \cdot \text{seq} \cdot \text{batch} \cdot b_{KV}$$

2: K와 V, $L$: 레이어 수, $n_{kv}$: KV 헤드 수, $d_{head}$: 헤드 차원, seq: 문맥 길이(토큰), $b_{KV}$: KV 원소당 바이트. 모든 쿼리 헤드가 자기 KV를 갖는 MHA는 $n_{kv}=n_{head}$, 여러 쿼리 헤드가 KV를 공유하는 GQA는 $n_{kv}$가 8 정도로 작아 KV 캐시가 수 배 줄어든다.

예를 들어 Llama-3-70B($L=80,\ n_{kv}=8,\ d_{head}=128$)는 토큰당 KV가 $2\cdot80\cdot8\cdot128\cdot2\,\text{B} = 320\ \text{KiB}$다. 문맥 128k 토큰 하나면 약 42 GB, 배치 8이면 300 GB를 넘는다. 긴 문맥 서비스에서 메모리를 먹는 주범은 가중치가 아니라 KV 캐시다.

③ 디코드 속도의 상한

배치 $B$의 디코드 한 스텝은 가중치 전체와 $B$개 시퀀스의 KV 캐시를 한 번씩 읽는다. 연산은 파라미터당 약 2 FLOP(곱셈+덧셈)이다. 따라서 루프라인을 그대로 적용하면 다음과 같다.

$$t_{\text{step}} \ge \max\!\left(\frac{M_W + M_{KV}}{\beta_{\text{total}}},\ \frac{2\,N_{\text{param}}\,B}{\pi_{\text{total}}}\right),\qquad \text{tokens/s (사용자당)} \le \frac{1}{t_{\text{step}}} \approx \frac{\beta}{M_W}$$

배치가 작고 문맥이 짧으면 두 번째 근사가 성립한다. 예: 8B 모델 FP16(16 GB)을 H100(3.35 TB/s)에서 돌리면 사용자당 최대 약 210 토큰/초. 디코드 산술 강도는 $I \approx 2B/b_W$이므로 배치를 키우면 루프라인에서 오른쪽으로 이동한다.

SIMULATOR

LLM 메모리 계산기

모델

가중치 정밀도

KV 캐시 정밀도

레이어 수 L KV 헤드 n_kv 문맥 길이 배치

GPU

가중치—

KV 캐시—

토큰당 KV—

합계 (+10 % 여유)—

필요 GPU 수—

HBM 스택 환산 (36 GB)—

디코드 상한 (사용자당)—

총 처리량 상한—

스텝 병목—

해볼 것: ① 8B에서 문맥을 128k로 늘리면 KV 캐시가 가중치의 몇 배가 되는가? ② “7B (MHA)”와 “8B (GQA)”를 번갈아 보며 n_kv = 32 vs 8이 KV 캐시를 4배 바꾸는 것을 확인하자. ③ 70B를 FP16 → FP8 → INT4로 바꾸면 GPU 수와 토큰/초가 함께 좋아진다. 메모리 한계 영역에서는 “바이트를 줄이는 것 = 속도”다. ④ 아래 그래프에서 배치를 늘리면 사용자당 속도는 조금씩 떨어지지만 총 처리량은 거의 비례해 늘다가, KV 캐시가 GPU 메모리를 넘는 지점(OOM)에서 끝난다. 모델은 계산을 단순화한 상한 추정이다(텐서 병렬 통신, 커널 효율, 어텐션 연산은 무시).

심화: KV 캐시를 줄이는 기법들

KV 캐시는 메모리 설계자와 모델 설계자가 가장 치열하게 줄이는 대상이다. GQA/MQA(KV 헤드 공유), KV 양자화(FP8·INT4), 페이지드 어텐션(KV를 고정 크기 블록으로 관리해 단편화를 없애는 기법, vLLM), 오래된 토큰을 버리거나 압축하는 슬라이딩 윈도·토큰 축출, KV를 잠재 벡터로 압축하는 MLA(DeepSeek-V2) 등이 있다. 하드웨어 쪽에서는 KV를 CPU 메모리나 CXL 메모리, SSD(10장)로 내리는 KV 오프로딩이 연구되고 있다. 대역폭은 떨어지지만 GB당 비용이 훨씬 싸기 때문이다.

메모리 기술 비교

같은 DRAM 셀(4장)이라도 어떤 인터페이스와 패키지로 내보내느냐에 따라 전혀 다른 제품이 된다. 6장에서 본 것처럼 대역폭은 핀 속도 × 버스 폭이고, 이 둘을 어떻게 얻느냐가 기술별 성격을 가른다. DDR·LPDDR·GDDR은 좁은 버스를 빠르게 돌리고, HBM은 느린 핀 1024~2048개를 실리콘 인터포저 위에 깔아 넓게 간다.

$$BW_{\text{unit}} = \frac{\text{핀 속도 (Gb/s)} \times \text{버스 폭 (bit)}}{8},\qquad BW_{\text{system}} = N_{\text{unit}} \times BW_{\text{unit}}$$

예: HBM3E 9.6 Gb/s × 1024 bit ÷ 8 ≈ 1.23 TB/s/스택, GDDR7 32 Gb/s × 32 bit ÷ 8 = 128 GB/s/칩, DDR5-6400 × 64 bit ÷ 8 = 51.2 GB/s/채널.

기술	단위 · 버스 폭	핀 속도	단위당 대역폭	단위당 용량	에너지	GB당 상대 비용	폼팩터 · 특징
DDR5 RDIMM	DIMM, 64 bit (+ECC 16)	4.8~6.4 Gb/s (MRDIMM ~8.8)	38~51 GB/s (MRDIMM ~70)	32~128 GB (3DS 256 GB)	~10~15 pJ/bit	1× (기준)	소켓형 모듈, 교체·증설 가능, RCD·PMIC 탑재, 온다이 ECC + 사이드밴드 ECC
LPDDR5X	패키지, x64 (16 bit × 4)	7.5~10.7 Gb/s	60~85 GB/s	8~32 GB	~4~6 pJ/bit	~1.2~1.5×	BGA 납땜·PoP·온패키지, LPCAMM2 모듈, 저전압(VDDQ 0.5 V), 딥 슬립
GDDR7	칩, x32	28~32 Gb/s (PAM3)	112~128 GB/s	2~3 GB	~6~8 pJ/bit	~2×	GPU 주변 PCB에 납땜, 짧고 정밀한 배선, 용량이 작음
HBM3E	스택, 1024 bit	8~9.8 Gb/s	~1.0~1.25 TB/s	24~36 GB (8~12단)	~3~4 pJ/bit	~4~5×	실리콘 인터포저 위 2.5D 실장(CoWoS 등), TSV 적층, 가장 높은 대역폭 밀도
HBM4 (2026~)	스택, 2048 bit	~8~11 Gb/s	~2~2.8 TB/s	36~48 GB (12~16단)	~2.5~3 pJ/bit (약)	더 높음	로직 공정 베이스 다이, 채널 수 2배, 커스텀 베이스 다이 논의
CXL 메모리	PCIe 5.0 x8/x16 링크	32 GT/s	~32 / 64 GB/s (방향당)	128~512 GB/모듈	DDR5 + 컨트롤러·SerDes	~1× + 컨트롤러	E3.S·애드인 카드, 지연 +~70~100 ns, 메모리 풀링·티어링

수치는 2024~2026년 제품과 JEDEC 규격의 전형적 범위이며, 에너지는 DRAM 코어와 I/O를 포함한 시스템 수준 대략값, 비용은 경향을 보여 주는 상대값이다(시장 가격은 수급에 따라 크게 변한다).

그림 13-4. 폼팩터가 대역폭 밀도를 정한다. (a) DIMM은 교체·증설이 쉽지만 커넥터와 긴 배선 때문에 핀 속도와 채널 수에 한계가 있다. (b) LPDDR은 SoC에 바짝 붙여 배선을 짧게 하고 전압을 낮춘다. (c) GDDR은 PCB 위에서 최고 핀 속도를 뽑는다. (d) HBM은 실리콘 인터포저의 미세 배선으로만 가능한 1024~2048 bit 버스를 쓴다(7장).

전력 예산: 데이터 이동이 비싸다

메모리 전력의 대부분은 비트를 옮기는 데서 나온다. 셀을 활성화하고(ACT), 로컬·글로벌 배선을 거쳐 I/O 드라이버가 채널을 구동하는 모든 과정에 에너지가 든다. 그래서 메모리 전력은 비트당 에너지와 비트율의 곱으로 1차 근사할 수 있다.

$$P_{\text{mem}} \approx E_{\text{bit}} \times BW \times 8 \;+\; P_{\text{background}}$$

$E_{\text{bit}}$: pJ/bit, $BW$: Byte/s. $P_{\text{background}}$: 리프레시(5장), 주변 회로, 대기 전력. 예: HBM3E 한 스택 1.2 TB/s × 8 × 3.5 pJ ≈ 34 W, 폰 LPDDR5X 68 GB/s × 8 × 5 pJ ≈ 2.7 W, 서버 DDR5 12채널 614 GB/s × 8 × 12 pJ ≈ 59 W.

그림 13-5. M. Horowitz(ISSCC 2014)가 정리한 45 nm 기준 에너지. DRAM에서 64 bit를 가져오는 에너지는 부동소수 곱셈의 수백 배다. 공정이 미세해지면 연산 에너지는 크게 줄지만 칩 밖으로 나가는 배선 에너지는 그만큼 줄지 않아 격차가 더 벌어진다. 데이터를 가까이 두는 것(캐시, HBM, PIM)이 곧 전력 설계다.

이 관점에서 기술별 pJ/bit 차이가 설명된다. HBM이 GDDR보다 비트당 에너지가 낮은 이유는 배선이 수 mm로 짧고 핀 속도가 낮아(9.6 vs 32 Gb/s) I/O 드라이버와 이퀄라이저가 단순하기 때문이다. LPDDR은 전압을 낮추고 종단(ODT)을 줄여 에너지를 아낀다. DIMM은 커넥터와 긴 트레이스, 버퍼(RCD)를 거치므로 비트당 에너지가 가장 크다. 대신 용량을 싸게 늘릴 수 있다.

전력 예산의 함정: 피크 vs 평균

위 식은 대역폭을 100 % 쓸 때의 피크 전력이다. 실제 평균 전력은 활용률에 비례하는 부분과, 놀고 있어도 드는 백그라운드(리프레시·주변 회로)로 나뉜다. 폰은 대부분의 시간을 딥 슬립·셀프 리프레시로 보내므로 백그라운드 전력이 배터리 수명을 좌우하고, AI 가속기는 거의 항상 대역폭을 가득 쓰므로 동적 전력이 열 설계(TDP)를 좌우한다. 또 고온에서는 리프레시 주기가 절반(32 ms)으로 줄어 백그라운드 전력이 늘어난다(11장).

메모리 시스템 설계 플레이그라운드

이제 직접 설계해 보자. 위쪽 프리셋은 요구사항(목표 대역폭·용량과 전력·비용·면적 예산)을 불러올 뿐, 설계는 여러분이 한다. 기술을 고르고, 유닛(DIMM 채널, 패키지, 칩, 스택) 수와 핀 속도, 유닛당 용량을 정하면 대역폭·용량·전력·비용·면적이 계산되고 오른쪽 레이더 차트가 요구 대비 충족 여부를 보여 준다. 왼쪽 그림은 선택한 구성을 (대략적인) 실제 크기로 배치한 것이다.

$$\begin{gathered}BW = N\cdot \frac{r\cdot w}{8},\quad C = N\cdot C_{\text{unit}},\quad P = E_{\text{bit}}\cdot 8BW + N\cdot P_{\text{bg}}\\[4pt] \text{비용} = C\cdot k_{\text{GB}} + N\cdot k_{\text{unit}},\quad A = N\cdot A_{\text{unit}}\end{gathered}$$

$r$: 핀 속도, $w$: 버스 폭. 전력은 대역폭을 가득 쓸 때의 피크 값. 비용은 DDR5 1 GB = 1로 둔 상대 지수, $k_{\text{unit}}$은 RDIMM의 버퍼·PCB, HBM의 인터포저·패키징 몫. 면적은 배선 여유를 포함한 보드/패키지 점유 면적. 모든 계수는 교육용 가정이다.

SIMULATOR

메모리 시스템 설계 플레이그라운드

요구사항

배치 (근사 축척)

요구 대비 충족

설계

메모리 기술

유닛 수 핀 속도 유닛당 용량

요구사항 · 예산

목표 대역폭 ≥ 목표 용량 ≥ 전력 예산 ≤ 비용 예산 ≤ 면적 예산 ≤

총 버스 폭—

대역폭—

용량—

피크 전력—

상대 비용—

점유 면적—

용량 ÷ 대역폭 (전체 1회 읽기)—

8B INT4 (4 GB) 디코드 상한—

해볼 것: ① “스마트폰” 요구사항에서 DDR5를 고르면 면적과 전력이, HBM3E를 고르면 비용이 터진다. ② “게이밍 GPU”는 GDDR7 칩 몇 개로 충족되는가? HBM3E 1스택과 비교하자. ③ “서버 CPU”는 대역폭보다 용량이 문제다. HBM으로는 768 GB를 싸게 만들 수 없다. ④ “AI 가속기”는 HBM3E 스택 수와 핀 속도를 올리면 대역폭은 맞지만 전력 예산이 빠듯해진다. 레이더의 점선 오각형이 요구선이고, 모든 축이 그 밖으로 나가면 합격이다(대역폭·용량은 클수록, 전력·비용·면적은 작을수록 바깥).

기기별 메모리 구성 사례

실제 제품의 메모리 구성은 앞의 요구사항 분석이 시장에서 어떻게 결론 났는지를 보여 준다. 아래 표는 2024~2026년 대표적인 구성이다.

기기	메모리 · 버스	대역폭	용량	왜 이렇게?
플래그십 스마트폰	LPDDR5X-8533~9600, 64 bit	68~77 GB/s	12~16 GB (최대 24)	전력·두께가 최우선. SoC 위 PoP 또는 바로 옆에 실장, 저장소는 UFS 4.x
얇은 노트북	LPDDR5X-8533, 128 bit (고성능형 256~512 bit)	~136 GB/s (512 bit: ~546 GB/s)	16~32 GB (최대 128)	배터리와 통합 GPU 대역폭의 균형. 온패키지·납땜형 또는 LPCAMM2 모듈
데스크톱 PC	DDR5-5600~6400 UDIMM, 2채널(128 bit)	90~102 GB/s	32~64 GB (최대 192)	싸고 증설 가능한 용량. 그래픽은 별도 GPU의 GDDR이 담당
게이밍 GPU	GDDR7 28 Gb/s, 512 bit (16칩)	~1.8 TB/s	32 GB	대역폭 대비 비용이 가장 싼 방법. 용량은 칩 수에 묶임 (2025 최상위급 기준)
서버 CPU (1소켓)	DDR5-6400 RDIMM, 12채널 (MRDIMM 8800)	~614 GB/s (MRDIMM ~845)	768 GB~3 TB	용량·비용·ECC·증설성. CXL로 TB급 추가 확장
AI 가속기	HBM3E 8스택, 8192 bit	~8 TB/s (HBM4 세대 약 22 TB/s)	192 GB (2026년 HBM4 세대 288 GB)	LLM 디코드는 메모리 한계. 전력·비용보다 대역폭이 가치를 결정
자율주행 SoC	LPDDR5(X) 차량용, 256 bit	~200 GB/s 이상	32~64 GB	AEC-Q100 등급, −40~105 °C 이상, ISO 26262 기능 안전, 인라인 ECC(11장)

그림 13-6. 기기별 메모리 구성. 폰은 한 패키지(x64)를 SoC 위에 쌓고, PC는 CPU용 DDR5와 GPU용 GDDR을 따로 둔다. 서버는 채널 수로 용량과 대역폭을 늘리고 CXL로 더 확장한다. AI 가속기는 인터포저 위 HBM 스택으로 대역폭을 극대화하고, 차량은 여러 LPDDR 패키지에 ECC와 안전 기능을 더한다.

SIMULATOR

기기별 대역폭–용량 지도

전체 1회 읽기 시간 등고선 플레이그라운드 설계 표시 (★)

강조

기기—

메모리—

대역폭—

용량—

용량 ÷ 대역폭—

해볼 것: 점을 클릭하면 세부 정보가 나온다. 대각선은 “메모리 전체를 한 번 읽는 시간”(용량 ÷ 대역폭)이 같은 선이다. AI 가속기는 수십 ms에 전체를 훑을 수 있어(모델 가중치를 토큰마다 읽는 워크로드에 맞춤) 왼쪽 위에, 서버는 1초 이상 걸리는 대신 용량이 큰 오른쪽 아래에 있다. 플레이그라운드에서 만든 설계를 ★로 겹쳐 보자.

“용량 ÷ 대역폭” 한 숫자로 보는 설계 철학

용량을 대역폭으로 나눈 값은 메모리 전체를 한 번 훑는 데 걸리는 시간이다. LLM 디코드는 토큰마다 가중치 전체를 읽으므로 이 값이 곧 토큰 하나의 최소 시간이다. 이 값이 수십 ms인 HBM 가속기는 “자주, 전부 읽는” 워크로드에, 1~10 s인 DDR5 서버는 “많이 담아 두고 일부만 읽는” 워크로드에 맞춰진 설계다. CXL 메모리는 이 값을 더 키우는 방향(더 큰 용량, 추가 대역폭은 적음)의 확장이다.

도전 과제

이제 배운 것을 모두 써 볼 차례다. 각 과제의 목표 스펙을 시뮬레이터로 충족해 보자. 조건은 시뮬레이터 값이 바뀔 때마다 실시간으로 채점되며, 모든 조건을 만족하면 카드에 체크가 켜진다. “목표 불러오기” 버튼은 요구사항만 채워 주고 설계는 맡긴다.

도전 1 · 플레이그라운드진행 중

온디바이스 AI 태블릿

8B 모델을 INT4로 돌려 초당 30 토큰 이상을 내고 싶다. 배터리와 얇은 두께가 중요하다.

도전 2 · LLM 계산기진행 중

70B 모델, 긴 문맥 서비스

H100 80 GB로 70B 모델을 문맥 32k, 동시 사용자 16명에게 서비스한다. GPU는 2장뿐이다.

도전 3 · 플레이그라운드진행 중

차세대 AI 가속기

10 TB/s와 256 GB를 한 패키지에. 그런데 메모리 전력은 300 W를 넘으면 안 된다.

힌트

도전 1: 패키지 하나로는 대역폭이 모자라다. 버스를 넓혀라. 도전 2: 메모리 한계 영역에서는 바이트를 줄이는 것이 답이다. 가중치와 KV 캐시 정밀도를 모두 살펴보자. 도전 3: HBM3E로 대역폭을 맞추면 전력이 넘친다. pJ/bit가 더 낮은 기술로, 핀 속도는 너무 올리지 말고.

핵심 정리

메모리 시스템 설계는 워크로드의 요구를 대역폭·용량·지연·전력·비용(+면적·신뢰성)으로 정량화하고 기술과 개수를 고르는 반복 과정이다.
루프라인: $P=\min(\pi,\ \beta I)$. 산술 강도 $I$가 릿지 포인트 $\pi/\beta$보다 작으면 메모리 한계다. 가속기의 릿지는 수백 FLOP/B로 커지고 있다(메모리 월).
GEMV($I\approx1$)와 스트림($I<0.1$)은 메모리 한계, 큰 GEMM($I\approx n/3$)은 연산 한계다. 배치·타일링은 데이터 재사용으로 $I$를 높인다.
LLM 메모리 = 가중치($N_{\text{param}}\times b_W$) + KV 캐시($2 L n_{kv} d_{head}\cdot\text{seq}\cdot\text{batch}\cdot b_{KV}$). 긴 문맥·큰 배치에서는 KV 캐시가 지배한다.
디코드는 토큰마다 가중치 전체를 읽으므로 사용자당 토큰/초 ≤ 대역폭 ÷ 모델 바이트. 양자화(FP8·INT4)는 용량과 속도를 함께 개선한다.
대역폭 = 핀 속도 × 버스 폭. DDR/LPDDR/GDDR은 좁고 빠른 버스, HBM은 인터포저 위 1024~2048 bit의 넓고 느린 버스다. CXL은 용량 확장용이다.
메모리 전력 ≈ pJ/bit × 비트율 + 백그라운드. 배선이 짧을수록(HBM, PoP) pJ/bit가 낮고, DRAM 접근은 연산보다 수백 배 비싸다.
폰은 LPDDR5X, PC는 DDR5+GDDR, 서버는 DDR5 RDIMM+CXL, AI 가속기는 HBM, 차량은 ECC가 강화된 차량용 LPDDR — 각자의 요구사항이 낳은 결론이다.

확인 퀴즈

1. 피크 1000 TFLOPS, 메모리 대역폭 4 TB/s인 가속기에서 산술 강도 50 FLOP/B인 커널의 도달 가능 성능 상한은?

$\beta I = 4\ \text{TB/s}\times 50 = 200$ TFLOPS로 피크보다 작다. 릿지 포인트가 1000/4 = 250 FLOP/B이므로 I = 50은 메모리 한계 영역이다.

2. 같은 가속기에서 대역폭을 2배(8 TB/s)로 늘리면 릿지 포인트는 어떻게 되는가?

$I_{\text{ridge}}=\pi/\beta = 1000/8 = 125$. 더 적은 데이터 재사용으로도 연산 한계에 도달할 수 있게 된다. 피크 연산 성능 자체는 변하지 않는다.

3. $L=32,\ n_{kv}=8,\ d_{head}=128$인 모델을 문맥 8192 토큰, 배치 1, FP16 KV로 돌릴 때 KV 캐시 크기는?

$2\cdot32\cdot8\cdot128\cdot8192\cdot2 = 1{,}073{,}741{,}824$ B = 1 GiB. 토큰당 128 KiB다. 배치 32면 32 GiB로 가중치(8B FP16 = 16 GB)보다 커진다.

4. 70B 모델을 INT4(가중치 35 GB)로 양자화해 대역폭 3.35 TB/s인 GPU 한 장에서 배치 1로 디코드할 때, 토큰/초의 상한에 가장 가까운 것은?

토큰마다 가중치 35 GB를 읽어야 하므로 $3350/35 \approx 96$ 토큰/s가 상한이다(KV 캐시 읽기와 커널 비효율 때문에 실제로는 더 낮다). FP16이면 140 GB라 한 장에 들어가지도 않는다.

5. HBM3E 스택 하나가 1.2 TB/s를 3.5 pJ/bit로 전송할 때 동적 전력은 대략 얼마인가?

$1.2\times10^{12}\ \text{B/s}\times 8 \times 3.5\times10^{-12}\ \text{J} \approx 33.6$ W. 바이트를 비트로 바꾸는 ×8을 빼먹지 말자. 8스택이면 메모리 동적 전력만 약 270 W다.

6. 범용 서버 CPU가 HBM 대신 DDR5 RDIMM을 주 메모리로 쓰는 가장 큰 이유는?

서버 워크로드(DB, 가상화)는 대역폭보다 용량과 비용이 결정적이다. HBM은 스택 수가 인터포저 면적에 묶여 수백 GB가 한계이고 GB당 비용이 몇 배 비싸다. 지연은 둘이 비슷하고, pJ/bit는 오히려 HBM이 낮다. HBM도 ECC를 지원한다.