LLM 추론 최적화: KV 캐시, 양자화, 투기적 디코딩의 원리와 운영

LLM 추론은 왜 이렇게 비싼가

LLM은 훈련보다 추론 단계에서 더 많은 컴퓨팅 자원을 소비하는 경우가 많다. 70B 파라미터 모델을 최적화 없이 A100 GPU에 배포하면 시간당 $100 이상이다. 최적화 적용 시 동일 처리량을 $15~20에 낼 수 있다. 이 챕터는 그 차이를 만드는 핵심 기술 세 가지—KV 캐시, 양자화, 투기적 디코딩—를 원리부터 운영까지 다룬다.

LLM 추론의 병목: 메모리 대역폭

LLM 추론은 메모리 대역폭 바운드(memory-bandwidth bound) 다. GPU 연산 유닛은 대부분 기다리고 있고, 병목은 모델 가중치와 KV 캐시를 VRAM에서 연산 유닛으로 전송하는 속도다.

두 단계 비교:
  Prefill (Prompt 처리)    — 계산 집약(compute-bound): 입력 토큰 전체를 한 번에 처리
  Decode  (토큰 생성)      — 메모리 집약(memory-bound): 토큰을 한 번에 하나씩 생성
                              매 스텝마다 전체 모델 가중치 + KV 캐시를 메모리에서 읽음

이 구조 때문에 디코딩 처리량(tokens/s)은 GPU 연산 성능이 아니라 VRAM 대역폭에 제약된다. 최적화 전략도 이 병목을 중심으로 설계된다.

LLM 추론 아키텍처와 병목 지점

KV 캐시 최적화

KV 캐시는 어텐션 레이어의 Key·Value 텐서를 재사용하기 위해 저장하는 구조다. 재계산 없이 이전 토큰 컨텍스트를 유지하므로 디코딩에 필수적이지만, 긴 시퀀스·큰 배치에서 VRAM을 빠르게 채운다.

Paged Attention (vLLM)

기존 시스템은 시퀀스 최대 길이만큼 연속 메모리를 사전 할당해 단편화가 심했다. Paged Attention은 OS 페이지 테이블에서 영감을 얻어 KV 캐시를 고정 크기 블록(page) 단위로 관리한다.

기존 방식:                          Paged Attention:
[시퀀스A: 2048토큰 사전 예약]        블록 크기: 16 토큰
[시퀀스B: 2048토큰 사전 예약]  →    [A블록1][B블록1][A블록2][C블록1][B블록2]...
→ 실제 사용: 300토큰이어도           실제 사용 크기만큼만 블록 할당
  2048토큰 분량 VRAM 점유             → 메모리 낭비 없음, 더 많은 배치 처리 가능

KV 캐시 공유 (Prefix Caching / Radix Attention): 동일한 시스템 프롬프트를 공유하는 요청들의 KV 캐시를 재사용. RAG 시스템·챗봇에서 공통 컨텍스트 비용을 크게 줄인다.

Grouped Query Attention (GQA)

MHA(Multi-Head Attention)에서 모든 쿼리 헤드가 별도의 KV를 갖는 대신, 여러 쿼리 헤드가 하나의 KV 헤드를 공유한다.

MHA: Q 헤드 32개, K 헤드 32개, V 헤드 32개 → KV 캐시 크기 32 기준
GQA: Q 헤드 32개, K 헤드 8개, V 헤드 8개  → KV 캐시 크기 8 기준 (4× 절감)
MQA: Q 헤드 32개, K 헤드 1개, V 헤드 1개  → KV 캐시 최소 (품질 저하 가능)

Llama 3, Mistral, Gemma 등 최신 모델은 GQA를 기본 채택. 동일 VRAM으로 더 긴 컨텍스트나 더 큰 배치를 처리할 수 있다.

KV 캐시 양자화

KV 텐서를 FP16 대신 INT8·FP8로 저장.

정밀도	메모리 절감	Perplexity 영향
FP16 (기본)	기준	없음
INT8	50%	거의 없음 (0.1~0.3% 이하)
FP8	50%	거의 없음
INT4	75%	소폭 (주의 필요)

양자화 (Quantization)

양자화는 모델 가중치를 낮은 정밀도로 표현해 VRAM 사용량과 메모리 대역폭을 동시에 줄인다.

양자화 방식 비교

방식	설명	품질	속도	권장 상황
FP8 (W8A8)	가중치·활성화 모두 FP8	≈ FP16	++++	NVIDIA Hopper (H100) 이상, 프로덕션 기본
AWQ (W4A16)	중요 가중치(1%) 보호 후 4비트 양자화	≈ FP16	+++	2026 신규 배포 기본값
GPTQ (W4A16)	2차 최적화 기반 4비트	FP16 대비 소폭 낮음	+++	빠른 캘리브레이션 필요 시
GGUF (llama.cpp)	CPU·소형 GPU 대상 혼합 정밀도	설정 따라 다름	CPU에서 활용 가능	엣지·로컬 추론

AWQ vs GPTQ: AWQ는 출력에 불균형하게 영향을 미치는 "중요 가중치" 1%를 보호하고 나머지를 양자화한다. 이 보호 덕분에 4비트임에도 FP16에 가까운 품질을 유지한다. 2026년 기준 신규 배포 기본값.

FP8: NVIDIA Hopper GPU의 Transformer Engine이 FP8 연산을 하드웨어 레벨에서 지원한다. FP16 대비 처리량 33% 향상, 메모리 50% 절감.

투기적 디코딩 (Speculative Decoding)

LLM 디코딩은 한 번에 토큰 하나를 생성하므로 병렬성이 없다. 투기적 디코딩은 이 제약을 우회한다.

동작 원리

1. 소형 드래프트 모델(Draft Model, 1~7B)이 토큰 K개를 빠르게 자동회귀 생성
   예: K=5 → ["The", "quick", "brown", "fox", "jumps"]

2. 타깃 대형 모델이 K+1 토큰을 한 번의 포워드 패스로 동시 검증
   (이 비용 ≈ 토큰 1개 생성 비용)

3. 일치하는 토큰까지 수락, 불일치하면 거기서 중단하고 타깃 모델 결과 사용

이점: 수락된 토큰 수만큼 속도 향상. 평균 3~4개 토큰 수락 시 처리량 3~4× 향상. 출력 품질은 타깃 모델과 수학적으로 동일하게 보장된다.

드래프트 모델 선택: 타깃 모델과 같은 패밀리의 소형 모델이 수락률 최대화. Llama 3 70B ↔ Llama 3 8B, Gemma 27B ↔ Gemma 2B.

투기적 디코딩 동작 흐름

연속 배칭 (Continuous Batching)

전통적인 정적 배칭은 배치의 모든 시퀀스가 끝날 때까지 새 요청을 받지 못했다. 짧은 시퀀스가 끝나도 긴 시퀀스를 기다려야 하므로 GPU 활용률이 낮아진다.

연속 배칭(In-flight Batching): 디코딩 스텝마다 완료된 시퀀스를 제거하고 새 요청을 삽입한다.

정적 배칭:
  스텝 1~10: [A(10tok)] [B(8tok)] [C(6tok)] [D(6tok)]
  스텝 7: C·D 완료 → GPU의 2슬롯 idle, A·B 완료 대기

연속 배칭:
  스텝 7: C·D 완료 → 즉시 E·F 삽입
  → GPU 항상 풀 활용

처리량 기준으로 정적 배칭 대비 2~4× 개선이 일반적이다. vLLM, TGI, TensorRT-LLM 모두 기본 채택.

Flash Attention

표준 어텐션은 Q×K^T 행렬(시퀀스 길이²)을 HBM(고대역폭 메모리)에 저장한다. 4,096 토큰이면 약 4,096² = 16M 원소 행렬이다. Flash Attention은 이 행렬을 HBM에 쓰지 않고 온칩 SRAM에서 블록 단위로 처리한다.

HBM 읽기·쓰기 횟수를 O(N²) → O(N)으로 줄임
메모리 절감: 긴 시퀀스에서 특히 효과적
수치 결과는 표준 어텐션과 동일

Flash Attention 2·3은 추가로 병렬화와 GPU 점유율 개선. PyTorch 2.0+ 기본 탑재, HuggingFace Transformers 자동 사용.

서빙 프레임워크 비교

프레임워크	주요 특징	최적 사용 상황
vLLM	Paged Attention, 연속 배칭, 빠른 업데이트 주기	오픈소스 모델 범용 서빙
TGI (HuggingFace)	HuggingFace 모델 최우선 지원, Flash Attention 기본	HuggingFace 생태계
TensorRT-LLM (NVIDIA)	NVIDIA GPU 최적화, FP8 지원, 최고 처리량	NVIDIA 인프라 최대 성능
llama.cpp	CPU·Apple Silicon 지원, GGUF 포맷	엣지·로컬 추론
Ollama	로컬 개발 편의성, llama.cpp 기반	개발·프로토타이핑

프로덕션 운영 체크리스트

배포 설정

✅ GPU VRAM 용량 검토: 모델 가중치 + KV 캐시 + 배치 여유분 합산

✅ 양자화 방식 선택: Hopper GPU → FP8, 범용 → AWQ(W4A16)

✅ KV 캐시 최대 길이(max_model_len) 실측 후 설정 — VRAM OOM 방지

✅ GQA 지원 모델 우선 선택 — KV 캐시 크기 4× 절감

성능 측정

✅ TTFT(Time To First Token): Prefill 지연 — 체감 응답성의 핵심 지표

✅ TPOT(Time Per Output Token): Decode 지연 — 스트리밍 속도

✅ GPU 활용률: nvidia-smi, nvitop — 70% 이하면 배칭·병렬화 재검토

✅ KV 캐시 사용률 모니터링 — 95% 이상 시 max_model_len 또는 배치 크기 조정

비용 최적화

✅ Prefix caching 활성화: 공통 시스템 프롬프트가 있는 서비스에서 30~60% 비용 절감

✅ 투기적 디코딩: 예측 가능한 출력(코드·번역) 서비스에서 2~4× 처리량 향상

✅ 모델 라우팅: 단순 질의는 소형 모델, 복잡 질의만 대형 모델 — 비용 30~50% 절감

✅ 요청별 토큰 비용 추적: input_tokens × 입력 단가 + output_tokens × 출력 단가

장애 대응

✅ OOM(Out of Memory) 알림: KV 캐시 90% 도달 시 알림, 100% 시 자동 배치 크기 축소

✅ 양자화 후 품질 회귀: Perplexity 측정 및 Golden Set 정기 평가

✅ 투기적 디코딩 수락률 모니터링: 수락률 60% 이하면 드래프트 모델 재검토

✅ 버전 관리: 양자화 설정·서빙 프레임워크 버전 고정, 업그레이드 시 처리량·품질 동시 검증

LLM 추론 서버 운영 체크리스트

흔한 실수

실수	결과	대응
KV 캐시 크기 계산 없이 배포	첫 트래픽에서 OOM	배포 전 max_tokens × 배치 크기 × 레이어별 크기 계산
양자화 후 품질 검증 안 함	무결한 서비스 제공 실패	양자화 전후 perplexity + task 정확도 비교
정적 배칭만 사용	GPU 낭비, 불필요한 지연	연속 배칭(vLLM, TGI) 기본 사용
투기적 디코딩을 창의적 생성에 적용	수락률 낮아 드래프트 모델 오버헤드만 발생	수락률 측정 후 적합 워크로드만 적용
처리량(QPS)만 측정, TTFT 미측정	스트리밍 서비스에서 사용자 체감 저하	TTFT·TPOT 분리 측정 및 SLO 설정