168편 · 약 16분

LLM 추론의 메모리 산술: Arithmetic Intensity, Roofline Model, 그리고 배치 크기의 물리학

요약

현대 GPU가 LLM 추론에서 최대 성능의 0.3%도 쓰지 못하는 이유가 있다. Arithmetic Intensity(AI)가 낮기 때문이다. 디코드 단계에서 배치 크기 1로 실행되는 모델의 AI는 약 1–2 FLOP/byte인 반면, H100 SXM5의 ridge point는 약 591 FLOP/byte다. 이 격차가 "메모리 벽(memory wall)"이고, LLM 서빙 최적화의 대부분은 이 벽을 극복하려는 시도다. Roofline Model이라는 분석 도구를 사용하면 모든 최적화 기법—배칭, 프리필-디코드 분리, 투기적 디코딩, KV 캐시 압축—이 왜 존재하는지 하나의 일관된 틀로 이해할 수 있다.

1. Roofline Model: GPU 성능의 상한선

Roofline Model은 연산 가속기의 달성 가능한 처리량을 두 가지 자원 제약으로 모델링한다.

Arithmetic Intensity (AI)는 연산의 핵심 비율이다:

AI = FLOP 수 / 데이터 이동량(bytes)

특정 연산의 AI가 계산되면, Roofline에 따라 두 천장 중 낮은 쪽이 달성 가능한 처리량이다:

메모리 천장: Peak Bandwidth × AI (단위: TFLOP/s)
컴퓨트 천장: Peak FLOP/s (단위: TFLOP/s)

두 천장이 만나는 지점을 ridge point라고 하며, 이를 기준으로 연산이 메모리 제한(AI < ridge point)인지 컴퓨트 제한(AI > ridge point)인지 결정된다.

성능 (TFLOP/s)

          컴퓨트 상한 (H100: 1,979 TFLOP/s FP8)
          
          메모리 상한 (BW × AI)
          
          Ridge point (~591 FLOP/byte)
          
          ← 메모리 제한 영역
          컴퓨트 제한 영역 →
          
          디코드 B=1 (~1.5 FLOP/byte)
          
          프리필 4K tokens
          
          → Arithmetic Intensity (FLOP/byte)

H100 SXM5 FP8 기준 Roofline: Peak 1,979 TFLOP/s, BW 3.35 TB/s, Ridge ≈ 591 FLOP/byte

Roofline Model: 두 천장과 ridge point

주요 GPU의 Roofline 수치

GPU	Peak FLOP/s (FP8/FP16)	HBM BW	Ridge Point
H100 SXM5	~1,979 / 989 TFLOP/s	3.35 TB/s	~591 FLOP/byte
A100 SXM4	~312 TFLOP/s (BF16)	2.0 TB/s	~156 FLOP/byte
H200 SXM5	~1,979 TFLOP/s (FP8)	4.8 TB/s	~413 FLOP/byte
RTX 4090	~330 TFLOP/s (FP8)	1.0 TB/s	~330 FLOP/byte

2. LLM 추론의 두 단계: 완전히 다른 물리

같은 모델이라도 프리필(prefill)과 디코드(decode) 단계는 전혀 다른 Arithmetic Intensity를 갖는다.

프리필: 컴퓨트 제한

프리필은 입력 프롬프트의 모든 토큰을 한 번에 처리한다. 시퀀스 길이를 S, 모델 hidden dimension을 d라 하면:

어텐션 연산 FLOP: 4 × S² × d (QKV + Softmax + Output)
가중치 로드: O(d²) (레이어당 한 번)
S가 크면 AI가 급격히 상승 → 컴퓨트 제한 영역 진입

4K 토큰 프리필에서 AI는 수백 FLOP/byte 수준으로, H100의 ridge point를 넘어 컴퓨트 제한이 된다. GPU Tensor Core 활용률이 70-90%에 달할 수 있다.

디코드: 메모리 제한

디코드는 매 스텝마다 토큰 한 개를 생성한다:

가중치 행렬 크기: 4 × d² × num_layers bytes (70B 모델 ≈ 140 GB in BF16)
한 토큰 생성에 필요한 FLOP: 2 × d² × num_layers (가중치 전체와 행렬-벡터 곱)
AI ≈ 2 / bytes_per_param = 배치 크기 1에서 ~1.5 FLOP/byte

이는 H100 ridge point(591)의 0.25% 수준이다. GPU는 대부분의 시간을 메모리에서 가중치를 읽는 데 쓰고, Tensor Core는 놀고 있다.

3. 배치가 AI를 바꾸는 방식

배치 크기 B개의 요청이 가중치를 공유할 때 AI는 다음과 같이 스케일된다:

AI(B) ≈ (2 / bytes_per_param) × B

70B BF16 모델(bytes_per_param ≈ 2)에서:

배치 크기 B	AI (FLOP/byte)	H100 대비 활용률
1	~1.5	< 0.3%
8	~12	~2%
32	~48	~8%
128	~192	~33%
512	~768	~컴퓨트 제한 진입

B = 1

AI ≈ 1.5 FLOP/byte
GPU 활용 < 1%
BW: ~2.25 TB/s 실효

→

B = 64

AI ≈ 96 FLOP/byte
GPU 활용 ~16%
BW 포화 접근

→

B ≥ 512

AI ≥ 768 FLOP/byte
컴퓨트 제한 진입
BW 병목 해소

배치 크기와 Arithmetic Intensity의 관계 (70B BF16 모델, H100)

왜 배치를 무한정 키울 수 없나

배치를 키우면 AI가 높아지지만, 두 가지 병목이 생긴다:

KV 캐시 메모리: 배치 내 각 요청의 KV 캐시가 HBM을 차지한다. 70B 모델에서 배치 1개당 KV 캐시는 시퀀스 길이 4K 기준 약 8-16 GB(모델 설정에 따라 다름). HBM 80 GB를 가중치와 KV 캐시가 나눠 쓰면, 실제 사용 가능한 배치 크기는 수십 개 수준이다.

지연 시간 SLO: 배치가 커지면 토큰당 지연 시간(TTFT + inter-token latency)이 늘어 SLO를 위반한다. 프로덕션 환경에서는 지연 시간 요구사항이 배치 크기의 실질적 상한이 된다.

4. Continuous Batching: 미완성 요청의 빈자리 채우기

전통적인 정적 배칭(static batching)은 배치 내 모든 요청이 같은 길이의 응답을 생성할 때까지 기다린다. 짧게 끝난 요청이 있어도 가장 긴 요청이 끝날 때까지 GPU 자원이 낭비된다.

Continuous Batching(= Iteration-Level Scheduling)은 각 디코딩 스텝마다 완료된 요청을 제거하고 새 요청을 삽입한다. 같은 배치 크기에서 GPU 활용률이 크게 오른다.

ORCA(OSDI 2022)가 처음 제안
vLLM, SGLang, TGI가 모두 구현

5. 프리필-디코드 분리(P/D Disaggregation)가 필요한 이유

프리필은 컴퓨트 제한, 디코드는 메모리 제한이라는 사실은 하나의 GPU가 두 역할을 동시에 하는 것이 비효율적임을 의미한다.

프리필이 긴 요청이 들어오면 디코드 중인 다른 요청의 KV 캐시가 밀려난다 (preemption).
디코드에 최적화된 설정(배치 크기 극대화)은 프리필 처리량을 낮춘다.

P/D 분리 아키텍처는 프리필 전용 GPU와 디코드 전용 GPU를 분리한다:

프리필 노드: 높은 컴퓨트 집약도 → GPU 코어 활용 최대화
디코드 노드: 낮은 AI, 높은 배치 크기 → HBM 대역폭 활용
KV 캐시를 RDMA/NVLink로 전송 (NVLink 900 GB/s, InfiniBand 400 Gb/s)

vLLM 0.23+, SGLang, NVIDIA Dynamo가 모두 P/D 분리를 지원한다.

6. 투기적 디코딩이 AI를 개선하는 방법

투기적 디코딩(speculative decoding)은 AI를 올리는 또 다른 방법이다. 작은 드래프터 모델이 여러 토큰을 빠르게 생성하고, 큰 타깃 모델이 한 번에 검증한다.

검증 단계에서 타깃 모델이 N개의 드래프트 토큰을 동시에 처리하므로 AI가 올라간다:

AI(speculative) ≈ AI(decode) × avg_accepted_tokens

평균 수락률이 70-80%이고 드래프트 길이가 4-6토큰이면, 실효 배치 크기가 3-5배 상승하는 효과가 있다.

7. 운영자를 위한 체크리스트

상황	진단 지표	조치
처리량이 낮고 GPU 활용률이 1% 미만	배치 크기 1, 디코드 지배	Continuous batching / 배치 크기 ↑
TTFT(첫 토큰 지연)가 높음	프리필 병목	P/D 분리, 프리필 청킹(chunked prefill)
KV 캐시 메모리 부족	OOM 또는 preemption 빈발	KV 캐시 양자화(INT8/FP8), sliding window 어텐션
SLO 달성이 어려움	배치 크기와 latency 트레이드오프	투기적 디코딩으로 throughput/latency 동시 개선
하드웨어 선택	Ridge point vs 실제 AI 비교	BW가 높은 H200/B200은 메모리 제한 완화

8. Open Questions

H100의 ridge point(~591 FLOP/byte)에 실제로 도달하는 LLM 워크로드가 있는가? 현재는 P/D 분리 + 대형 배치에서도 300-400 수준에 머무는 경우가 많다.
B200 Blackwell(HBM3e 8 TB/s 목표)에서 ridge point가 낮아지면 현재의 최적화 기법이 일부 불필요해질 수 있다.