같은 GPU에서 LLM 서빙 처리량을 2~4배 향상시키는 다섯 가지 추론 최적화 기법 — 양자화부터 Speculative Decoding까지

처음으로 GPT-4급 모델을 프로덕션에 올렸을 때, 응답 하나 받는 데 3초가 넘게 걸리는 걸 보고 멘붕했던 기억이 납니다. 모델은 분명히 똑똑한데, 너무 느려서 실제 서비스에 쓰기가 겁났거든요. 비용 문제도 심각했고요. 그런데 지금은 같은 GPU에서 처리량이 몇 배씩 올라가고, 추론 비용은 GPT-4급 기준 약 50배 하락했습니다(GPT-4 출시 초기 $20/백만 토큰 → 2025년 기준 $0.40/백만 토큰 수준, DigitalOcean LLM Inference Trilemma 기준).

이 변화의 배경에는 LLM 추론 최적화 기술의 눈부신 발전이 있습니다. 단순히 더 빠른 GPU를 쓰는 게 아니라, 모델이 토큰을 생성하는 방식 자체를 바꾸는 기법들이 등장했습니다. 이 글에서는 양자화, PagedAttention, Speculative Decoding 등 실무에서 바로 적용 가능한 핵심 기법 다섯 가지와, 워크로드별로 어떤 조합을 선택해야 하는지를 살펴봅니다. 이 글을 다 읽고 나면, vLLM 서버를 최적화 설정으로 띄우는 데 필요한 코드와 판단 기준을 바로 손에 넣을 수 있습니다.

LLM을 서비스에 직접 올리든, API 비용을 줄이고 싶든, 아니면 그냥 이 분야가 궁금하든 — 지금부터 꽤 실용적인 이야기를 풀어드릴게요.

핵심 개념

LLM 추론의 두 단계와 세 가지 병목

LLM이 토큰을 생성할 때는 크게 두 단계를 거칩니다.

• 프리필(Prefill): 입력 프롬프트 전체를 한 번에 처리해서 초기 KV 캐시를 생성하는 단계. KV 캐시란 모델이 이전 토큰들의 계산 결과(Key와 Value 행렬)를 저장해두는 메모리 공간입니다.
• 디코딩(Decoding): 토큰을 하나씩 자기회귀적으로 생성하는 단계

프리필은 병렬 처리가 가능해서 비교적 빠르지만, 디코딩은 이전 토큰이 결정되어야 다음 토큰을 생성할 수 있는 구조적 직렬성 때문에 느립니다. 여기서 세 가지 주요 병목이 발생합니다.

이 세 병목을 각각, 혹은 조합으로 공략하는 기법들이 현재 LLM 서빙 최적화의 핵심입니다.

추론 트릴레마(Inference Trilemma): 처리량(Throughput), 레이턴시(Latency), 비용(Cost) 세 가지를 동시에 최대화하는 것은 불가능합니다. 워크로드 특성에 따라 무엇을 우선시할지 먼저 결정하는 것이 최적화의 출발점이고, 아래 기법들은 각각 이 트릴레마의 어느 꼭짓점을 공략하느냐에 따라 선택이 달라집니다.

워크로드별로 어떤 기법을 조합하면 좋을지, 먼저 한눈에 보여드립니다.

기법 1: 양자화 — VRAM을 절반 이하로 줄이는 방법

양자화(Quantization)는 모델의 가중치를 더 낮은 비트 수로 표현해서 VRAM 사용량과 메모리 대역폭 부하를 동시에 줄이는 기법입니다.

저도 처음에는 "정밀도를 낮추면 모델이 멍청해지는 거 아닌가?" 싶었는데, 실제로 써보면 생각보다 잘 버팁니다. 다만 태스크에 따라 차이가 있어서 주의가 필요합니다.

# vLLM >= 0.6.x 기준
from vllm import LLM, SamplingParams
 
llm = LLM(
    model="Qwen/Qwen2.5-7B-Instruct-AWQ",
    quantization="awq",
    dtype="auto",
    gpu_memory_utilization=0.90,
)
 
sampling_params = SamplingParams(temperature=0.7, max_tokens=512)
outputs = llm.generate(["LLM 추론 최적화를 설명해주세요."], sampling_params)
print(outputs[0].outputs[0].text)

현재 주류 양자화 방식을 비교하면 이렇습니다.

GGUF의 Q 숫자는 가중치당 비트 수를 뜻합니다. Q8_0은 8비트, Q4_K_M은 4비트, Q2_K는 2비트로 저장하므로, 숫자가 작을수록 파일이 작아지고 속도가 빨라지는 대신 정확도도 낮아집니다.

FP8의 부상: 2025년 기준 NVIDIA Hopper(H100/H200) GPU는 FP8을 하드웨어 레벨에서 지원합니다. BF16 대비 2배 처리량을 내면서 정확도 손실은 거의 없어서, 데이터센터 서빙의 기본 정밀도로 자리잡고 있습니다.

이 기법이 효과적인 워크로드: 레이턴시와 비용 모두 줄이고 싶을 때, 특히 엣지 배포나 VRAM 제약 환경. 단, 수학 추론·코드 생성 태스크는 INT4 전환 전 반드시 벤치마크를 돌려보는 것을 권장합니다.

기법 2: PagedAttention + Continuous Batching — GPU를 쉬지 않게

기존 LLM 서빙 시스템의 가장 큰 낭비 중 하나는 KV 캐시를 시퀀스 최대 길이만큼 미리 예약해두는 방식이었습니다. 1024 토큰짜리 공간을 잡아뒀는데 실제로는 200 토큰만 쓰면? 나머지 824 토큰 분량의 VRAM이 그냥 낭비됩니다.

PagedAttention은 OS의 가상 메모리 페이징 아이디어를 KV 캐시에 적용해서, 실제로 사용하는 만큼만 블록 단위로 동적 할당합니다. 이걸 Continuous Batching과 결합하면, 한 요청이 완료되는 즉시 다음 요청을 배치에 밀어넣어 GPU를 거의 쉬지 않게 만들 수 있습니다. (Runpod — vLLM PagedAttention 가이드)

# vLLM >= 0.6.x 기준
# PagedAttention과 Continuous Batching은 기본 활성화
# --enable-prefix-caching: 공통 시스템 프롬프트의 KV 캐시를 재사용
# --max-num-seqs: 동시에 처리할 최대 시퀀스 수
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 256

실제로 vLLM 등장 이전과 이후를 비교하면, 동일한 GPU에서 동시 처리 가능한 요청 수가 2~4배 증가하는 경우가 많습니다.

이 기법이 효과적인 워크로드: 동시 사용자가 많은 서비스(챗봇, API 게이트웨이). 처리량이 최우선인 거의 모든 환경에 기본 적용되는 기법입니다.

기법 3: Speculative Decoding — 미리 찍고 한 번에 검증

솔직히 이 기법을 처음 접했을 때 "이게 말이 되나?" 싶었습니다. 아이디어가 너무 단순해 보이거든요.

작은 드래프트 모델(또는 보조 헤드)이 토큰 여러 개를 미리 추측합니다. 그 다음, 큰 본 모델이 단 한 번의 포워드 패스로 이 추측들을 일괄 검증합니다. 맞은 토큰은 그대로 수락하고, 틀린 부분부터 다시 생성합니다.

핵심 보장: 수락된 토큰은 본 모델이 직접 생성한 것과 수학적으로 동일한 분포를 따릅니다. 즉, 출력 품질 변화 없이 속도만 올라가는 구조입니다. (NVIDIA Developer — Speculative Decoding 소개)

현재 가장 널리 채택된 방식은 **EAGLE(Extrapolation Algorithm for Greater Language-model Efficiency)**로, 별도 드래프트 모델 없이 본 모델의 피처를 활용해 다음 토큰을 예측합니다. EAGLE-3는 약 80% 채택률(acceptance rate)로 2.5~2.8배 속도 향상을 제공하며, vLLM, SGLang, TensorRT-LLM 모두 네이티브 지원을 포함했습니다. (EAGLE-3 GitHub)

# vLLM >= 0.6.x 기준
# speculative_model="[ngram]": 추가 모델 없이 N-gram 패턴으로 드래프트 생성
from vllm import LLM, SamplingParams
 
llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    speculative_model="[ngram]",
    num_speculative_tokens=5,
    use_v2_block_manager=True,
)

ngram vs EAGLE 선택 기준: ngram은 추가 모델이 필요 없고 메모리 오버헤드가 없어서 바로 켜볼 수 있습니다. 반복 패턴이 많은 태스크(템플릿 기반 출력, 코드 주석)에서 잘 동작합니다. EAGLE은 별도 드래프트 헤드를 사용하는 만큼 준비가 필요하지만, 일반 대화·요약 태스크에서 채택률이 훨씬 높습니다.

이 기법이 효과적인 워크로드: 레이턴시가 최우선인 실시간 챗봇. 창의적 생성이나 코드처럼 예측 불가한 출력이 많은 태스크에서는 채택률이 낮아 오히려 오버헤드가 생길 수 있으므로 주의가 필요합니다.

기법 4: Prefix Caching / RadixAttention — 반복 컨텍스트를 캐싱

시스템 프롬프트가 긴 챗봇이나 RAG 파이프라인을 운영해봤다면, 매 요청마다 같은 문서나 지시문을 프리필하느라 시간과 비용을 낭비하는 걸 경험해보셨을 겁니다.

저도 prefix caching을 처음 켰을 때 캐시 히트율이 기대보다 훨씬 낮아서 이상하다 싶었는데, 알고 보니 시스템 프롬프트 끝에 타임스탬프가 들어가 매 요청마다 미묘하게 달랐습니다. 접두사가 1바이트라도 다르면 캐시 미스가 납니다. 프롬프트 구조를 정비하는 것이 먼저입니다.

Prefix Caching은 공통 접두사 토큰의 KV 캐시를 저장해뒀다가 후속 요청에서 재사용합니다. vLLM에서는 --enable-prefix-caching 옵션 하나로 활성화됩니다.

SGLang의 RadixAttention은 여기서 한 단계 더 나아가, 공유 접두사를 Radix Tree 구조로 관리해서 부분 일치도 재사용할 수 있게 합니다. RAG 파이프라인이나 에이전트처럼 시스템 프롬프트 + 문서 청크가 반복되는 워크로드에서 2배 이상 처리량 향상을 기대할 수 있습니다. (Introl Blog — KV Cache Optimization)

이 기법이 효과적인 워크로드: 동일한 시스템 프롬프트나 문서 청크를 여러 요청이 공유하는 챗봇, RAG, 에이전트. 매 요청마다 컨텍스트가 완전히 달라지는 배치 처리에서는 효과가 거의 없습니다.

기법 5: MLA — DeepSeek이 KV 캐시를 90% 줄인 방법

Multi-Head Latent Attention(MLA)은 DeepSeek-V2에서 소개된 아키텍처 혁신입니다. 처음 논문을 봤을 때는 "그냥 KV 캐시 압축 아닌가?" 싶었는데, 실제로 서빙해보면 체감이 다릅니다.

실용적 요약: DeepSeek-V3, Kimi K2처럼 MLA 기반 모델을 서빙하면, 같은 VRAM에서 컨텍스트 길이를 훨씬 늘리거나 더 많은 요청을 동시에 처리할 수 있습니다. KV 캐시가 최대 90% 줄어드는 덕분입니다.

아키텍처 배경: 기존 MHA(Multi-Head Attention)가 Key와 Value 행렬을 모두 캐시하는 대신, MLA는 하나의 압축된 잠재(latent) 벡터로 양쪽을 표현합니다. 기존 MHA 모델에 MLA를 소급 적용하려면 파인튜닝이 필요하므로, 실질적으로는 신규 모델을 선택할 때 고려하는 요소입니다.

FlashMLA는 MLA 전용 FlashAttention 커널로, NVIDIA H800에서 BF16 기준 660 TFlops를 달성했습니다. H800의 BF16 이론치가 약 1,979 TFlops인 점을 감안하면 약 33% 효율로 들릴 수 있는데, KV 캐시 접근이 집중되는 디코딩 단계의 메모리 바운드 특성을 고려하면 실질적으로 높은 수치입니다. (DeepSeek FlashMLA GitHub)

이 기법이 효과적인 워크로드: DeepSeek-V3, Kimi K2처럼 MLA 아키텍처를 채택한 모델을 서빙할 때. 기존 MHA 모델에는 직접 적용이 어렵습니다.

실전 적용

예시 1: 대화형 챗봇 — TTFT 100ms 이하를 목표로

실시간 챗봇에서 사용자가 가장 체감하는 지표는 첫 번째 토큰이 나오기까지의 시간, 즉 **TTFT(Time-to-First-Token)**입니다. TTFT가 200ms를 넘으면 사용자는 "느리다"고 느끼기 시작합니다. 트릴레마에서 레이턴시 최소화를 선택하는 시나리오입니다.

# vLLM >= 0.6.x 기준
from vllm import AsyncEngineArgs
from vllm.engine.async_llm_engine import AsyncLLMEngine
 
engine_args = AsyncEngineArgs(
    model="Qwen/Qwen2.5-14B-Instruct-AWQ",
    quantization="awq",
    enable_prefix_caching=True,
    max_num_seqs=128,
    gpu_memory_utilization=0.85,
    speculative_model="[ngram]",
    num_speculative_tokens=4,
)
 
engine = AsyncLLMEngine.from_engine_args(engine_args)

예시 2: RAG 파이프라인 — 문서 KV를 재사용해서 처리량 올리기

RAG(Retrieval-Augmented Generation) 파이프라인은 대부분 [시스템 프롬프트 + 검색된 문서 청크 + 사용자 질문] 구조를 반복합니다. 문서 청크가 여러 요청에 걸쳐 반복된다면, KV 캐시 재사용 효과가 극대화됩니다. 트릴레마에서 처리량과 비용 절감 모두를 노리는 시나리오입니다.

# SGLang — RadixAttention이 기본 활성화
# --chunked-prefill-size: 긴 문서 프리필을 여러 청크로 나눠서 처리
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --port 30000 \
  --mem-fraction-static 0.85 \
  --chunked-prefill-size 512

# vLLM >= 0.6.x 기준
# LMCache + vLLM 결합으로 멀티턴 QA KV 영속화
# pip install lmcache vllm
 
import lmcache.integration.vllm  # noqa: F401
# 이 import는 vLLM 내부 클래스들을 LMCache 통합 버전으로 패치합니다.
# 코드 변경 없이 side-effect만으로 KV 캐시 영속화 기능이 활성화되는 구조입니다.
from vllm import LLM
 
llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    kv_cache_dtype="auto",
    enable_prefix_caching=True,
)
# 동일 문서를 참조하는 후속 요청은 KV 재계산 없이 처리됩니다

LMCache를 vLLM과 결합하면 멀티턴 QA, 문서 분석 워크로드에서 최대 15배 처리량 향상이 보고되었습니다.

예시 3: 엣지/온디바이스 배포 — VRAM 없이 동작시키기

트릴레마에서 **비용(VRAM 제약)**을 최우선으로 두는 시나리오입니다. 서버 GPU 없이 MacBook이나 소형 디바이스에서 LLM을 돌려야 한다면, llama.cpp가 사실상 표준입니다.

# Ollama 설치 후
# Q4_K_M: K-quants 방식 4비트 양자화의 Medium 크기 변형 — 속도·정확도 균형점
ollama pull qwen2.5:7b-instruct-q4_K_M
 
# 또는 llama.cpp 직접 사용
# --n-gpu-layers: Apple Silicon이라면 최대값으로 설정해 Neural Engine 활용
./llama-cli \
  -m ./models/qwen2.5-7b-instruct-Q4_K_M.gguf \
  -n 512 \
  --n-gpu-layers 35 \
  -p "LLM 추론 최적화를 설명해줘"

예시 4: 배치 처리 — 처리량을 극대화하는 구성

실시간성이 필요 없는 대규모 배치 작업이라면, 트릴레마에서 처리량 최대화를 선택합니다. 레이턴시보다 시간당 처리 토큰 수가 우선입니다.

# vLLM >= 0.6.x 기준
from vllm import LLM, SamplingParams
 
llm = LLM(
    model="Qwen/Qwen2.5-72B-Instruct-AWQ",
    quantization="awq",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.95,
    max_num_seqs=512,
)
 
# 수천 건을 한 번에 넘기면 내부적으로 최적 배치를 구성합니다
prompts = [f"문서 {i}를 요약해주세요: ..." for i in range(5000)]
outputs = llm.generate(prompts, SamplingParams(max_tokens=256))

Intelligent Model Routing: 간단한 작업은 소형 모델(7B 이하)로, 복잡한 작업만 대형 모델로 라우팅하면 비용을 30~60% 추가로 절감할 수 있습니다. LiteLLM이나 커스텀 라우터로 구현 가능합니다.

장단점 분석

장점

단점 및 주의사항

GQA(Grouped-Query Attention): MHA와 MLA의 중간 형태로, 여러 쿼리 헤드가 하나의 Key-Value 헤드를 공유합니다. Llama 3 시리즈가 채택한 방식으로, 추가 훈련 없이 기존 아키텍처에서 KV 캐시를 줄이는 실용적인 선택지입니다.

실무에서 가장 흔한 실수

1. 워크로드 분석 없이 기법을 먼저 고르는 것: 레이턴시 중심인지 처리량 중심인지 먼저 명확히 하지 않으면, 아무리 좋은 기법도 엉뚱한 방향으로 작동할 수 있습니다. 챗봇에 배치 최적화를 적용하면 오히려 TTFT가 늘어나기도 합니다.
2. 양자화 후 벤치마크를 건너뛰는 것: "INT4는 보통 괜찮다"는 말이 맞긴 한데, 저도 특정 instruction-following 태스크에서 예상보다 훨씬 큰 성능 하락을 경험한 적이 있습니다. 특히 수학 추론과 코드 생성은 꼭 확인해보시는 걸 권장합니다.
3. Speculative Decoding의 채택률을 모니터링하지 않는 것: 저도 한 번 채택률 체크를 빠뜨렸다가 Speculative Decoding이 오히려 느려지는 걸 한참 후에야 알아챘습니다. 채택률이 낮으면 드래프트 생성 오버헤드가 그대로 비용이 됩니다. vLLM의 /metrics 엔드포인트에서 spec_decode_acceptance_rate를 주기적으로 확인해보시면 좋습니다.

마치며

LLM 서빙 최적화의 핵심은 "하나의 마법 기법"이 아니라, 워크로드 특성에 맞는 기법들의 조합을 찾는 것입니다. 그리고 그 조합을 찾으려면 먼저 숫자가 보여야 합니다. 모니터링 없이 최적화하는 건, 연료 게이지 없이 장거리 운전하는 것과 같습니다. 첫 번째 할 일은 서버를 띄우는 것이 아니라, 지금 무엇이 느린지를 측정하는 것입니다.

지금 바로 시작해볼 수 있는 3단계:

1. vLLM 설치 후 AWQ 모델로 서빙을 시작해볼 수 있습니다. pip install vllm 후 python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct-AWQ --quantization awq --enable-prefix-caching 한 줄로 PagedAttention + Continuous Batching + Prefix Caching이 모두 활성화된 서버가 올라옵니다.
2. 현재 워크로드가 레이턴시 중심인지 처리량 중심인지 판단한 뒤, 위 예시 1~4 중 가장 유사한 케이스의 설정을 참고해보시면 됩니다. --enable-chunked-prefill(RAG·긴 컨텍스트)이나 Speculative Decoding(--speculative-model "[ngram]")을 하나씩 추가하면서 지표 변화를 관찰할 수 있습니다.
3. 먼저 curl http://localhost:8000/metrics로 vLLM이 노출하는 숫자를 확인해보세요. GPU 활용률, 배치 크기, Speculative Decoding 채택률이 텍스트로 쏟아집니다. 이 숫자들이 보이기 시작하면, 다음 최적화가 어디로 가야 할지 스스로 보입니다. 여유가 생기면 Prometheus + Grafana로 연결해서 대시보드를 구성하면 됩니다.

참고 자료

양자화

• LLM 추론 최적화 공식 문서 | HuggingFace
• AWS Inferentia LLM 양자화 최적화 | AWS Tech Blog

PagedAttention / Continuous Batching

• vLLM: PagedAttention, Continuous Batching 가이드 | Runpod
• LLM Inference Performance Engineering Best Practices | Databricks

Speculative Decoding

• Speculative Decoding for AI Inference Latency | NVIDIA Developer
• Speculative Decoding 2025 가이드 | Introl Blog
• HyperCLOVA X Speculative Decoding 적용기 | CLOVA Tech Blog

Prefix Caching / KV 캐시 최적화

• KV Cache Optimization: Production LLMs | Introl Blog

MLA / 어텐션 최적화

• FlashMLA | DeepSeek GitHub
• TransMLA: Multi-Head Latent Attention Is All You Need | arXiv

종합 / 트레이드오프

• Mastering LLM Techniques: Inference Optimization | NVIDIA Developer
• vLLM vs TensorRT-LLM vs SGLang H100 벤치마크 | Spheron
• LLM Inference Trilemma: Throughput, Latency, Cost | DigitalOcean