FP8, FlashAttention 3, Continuous Batching, Speculative Decoding을 조합해 5-8배 비용 효율을 달성하는 실전 배포 파이프라인과 모니터링 전략을 다룹니다.
이 시리즈에서 다룬 기법들을 개별적으로 적용해도 효과가 있지만, 조합했을 때 누적 효과는 더욱 극적입니다.
기준선: FP16, 정적 배칭, 사전 할당 KV 캐시
처리량: 1x (기준)
+ FP8 양자화 (7장):
메모리 50% 절감 → 배치 크기 증가 가능
처리량: ~1.6x
+ PagedAttention (3장):
KV 캐시 낭비 96% 감소 → 동시 요청 수 증가
처리량: ~3.2x (1.6 x 2)
+ Continuous Batching (4장):
GPU 유휴 시간 제거 → 활용률 극대화
처리량: ~4.5x (3.2 x 1.4)
+ Prefix Caching (6장):
반복 Prefill 제거 → TTFT 감소, 처리량 증가
처리량: ~5.4x (4.5 x 1.2)
+ Speculative Decoding (5장, 저배치 시나리오):
지연시간 2x 감소 → 요청 회전율 증가
처리량: ~6.5x (5.4 x 1.2)
+ FlashAttention 3:
Attention 연산 최적화, HBM 접근 감소
처리량: ~7.2x (6.5 x 1.1)
최종: FP16 기준 대비 약 5-8x 비용 효율 개선위 수치는 워크로드에 따라 크게 달라집니다. 짧은 입력 + 긴 출력의 대화형 워크로드에서는 Speculative Decoding의 기여가 크고, 긴 입력 + 짧은 출력의 분류/추출 워크로드에서는 Prefix Caching의 기여가 큽니다.
FlashAttention은 Attention 연산을 타일링(Tiling)과 재계산(Recomputation)으로 최적화해, HBM 접근을 줄이고 SRAM(on-chip memory)을 최대한 활용하는 기법입니다.
FlashAttention 3은 H100/H200의 비동기 하드웨어 기능을 활용해 이전 버전 대비 추가적인 속도 향상을 달성합니다.
FlashAttention 1: 타일링 기반 Attention, HBM 접근 감소
FlashAttention 2: 병렬화 개선, 더 나은 작업 분할
FlashAttention 3: H100 비동기 실행, FP8 Attention 지원FlashAttention은 별도 설정 없이 vLLM, SGLang 등 주요 추론 엔진에 기본 통합되어 있습니다.
vLLM은 가장 넓은 모델 지원과 활발한 커뮤니티를 기반으로 프로덕션 환경에서 가장 많이 사용됩니다.
# vLLM 프로덕션 서버 시작 (Llama 3 70B, H100 x 2)
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3-70B-Instruct \
--tensor-parallel-size 2 \
--dtype float16 \
--quantization fp8 \
--kv-cache-dtype fp8 \
--enable-prefix-caching \
--max-num-seqs 128 \
--max-model-len 8192 \
--gpu-memory-utilization 0.92 \
--enable-chunked-prefill \
--speculative-model meta-llama/Llama-3-8B-Instruct \
--num-speculative-tokens 5 \
--port 8000주요 파라미터 설명은 다음과 같습니다.
--tensor-parallel-size 2: 2-GPU 텐서 병렬화--quantization fp8: 모델 가중치 FP8 양자화--kv-cache-dtype fp8: KV 캐시 FP8 저장--enable-prefix-caching: Prefix Caching 활성화--max-num-seqs 128: 최대 동시 요청 128개--gpu-memory-utilization 0.92: GPU 메모리 92% 사용--enable-chunked-prefill: 긴 Prefill을 분할해 Decode 지연 방지--speculative-model: Speculative Decoding용 드래프트 모델SGLang은 RadixAttention 기반의 강력한 Prefix Caching과 프로그래밍 인터페이스가 강점입니다.
# SGLang 프로덕션 서버 시작
python -m sglang.launch_server \
--model-path meta-llama/Llama-3-70B-Instruct \
--tp 2 \
--quantization fp8 \
--mem-fraction-static 0.88 \
--max-running-requests 128 \
--chunked-prefill-size 4096 \
--port 8000SGLang은 RadixAttention이 기본 활성화되어 있어 별도의 Prefix Caching 설정이 필요 없습니다. 복잡한 프롬프트 구조(트리형 생성, 반복 패턴)에서 vLLM보다 높은 캐시 히트율을 보이는 경우가 있습니다.
NVIDIA의 TensorRT-LLM은 하드웨어 최적화의 깊이에서 강점을 가집니다. 특히 NVIDIA GPU에서의 절대적인 성능이 중요한 경우에 선택합니다.
1. 모델 변환: HuggingFace → TensorRT-LLM 엔진
trtllm-build --model_dir ./llama-70b \
--output_dir ./engine \
--tp_size 2 \
--use_fp8 \
--max_batch_size 128
2. Triton Inference Server로 서빙
tritonserver --model-repository ./model_repo| 기준 | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
| 모델 지원 폭 | 가장 넓음 | 넓음 | NVIDIA 최적화 모델 |
| 배포 편의성 | 매우 높음 | 높음 | 중간 (빌드 필요) |
| Prefix Caching | APC | RadixAttention (더 강력) | 기본 수준 |
| 절대 성능 | 높음 | 높음 | 가장 높음 (NVIDIA GPU) |
| 커뮤니티 | 가장 활발 | 성장 중 | NVIDIA 지원 |
| Speculative Decoding | 다양한 변형 지원 | Eagle 지원 | Medusa 지원 |
대부분의 프로덕션 환경에서는 vLLM으로 시작하는 것을 권장합니다. 배포가 간편하고, OpenAI 호환 API를 제공하며, 커뮤니티 지원이 풍부합니다. 성능이 부족한 경우에 SGLang이나 TensorRT-LLM으로 전환을 검토합니다.
여러 GPU 레플리카로 서빙할 때, 로드밸런싱 전략이 전체 시스템의 효율을 좌우합니다.
6장에서 다룬 캐시 인식 라우팅은 프로덕션에서 핵심적인 최적화입니다.
단순 라운드 로빈 대신, 각 레플리카의 현재 부하(대기 중인 요청 수, KV 캐시 사용률)를 고려해 라우팅합니다.
라우팅 점수 = w1 * (1 - GPU 활용률)
+ w2 * (1 - KV 캐시 사용률)
+ w3 * 접두사 캐시 히트 보너스
+ w4 * (1 / (대기 큐 길이 + 1))
가장 높은 점수의 레플리카로 요청 라우팅트래픽 변동에 대응하기 위한 오토스케일링 전략을 정리합니다.
GPU 기반 추론의 오토스케일링에서 전통적인 CPU/메모리 사용률은 적합하지 않습니다. LLM 추론에 특화된 지표를 사용해야 합니다.
스케일 아웃 트리거:
- 평균 TTFT P95 > SLO 임계값 (예: 500ms)
- 평균 TPOT P95 > SLO 임계값 (예: 100ms)
- 대기 큐 길이 > 임계값 (예: 50개)
- KV 캐시 사용률 > 90%
스케일 인 트리거:
- 평균 GPU 활용률 < 30% (10분 이상)
- 대기 큐 길이 = 0 (5분 이상)LLM 서빙의 오토스케일링에서 가장 큰 과제는 콜드 스타트 시간입니다. 70B 모델을 새 GPU에 로드하는 데 수 분이 걸릴 수 있으므로, 예측 기반(Predictive) 스케일링이 중요합니다.
1. 예측 스케일링: 과거 트래픽 패턴으로 미래 부하 예측
2. Warm Pool: 모델이 이미 로드된 대기 인스턴스 유지
3. 모델 캐싱: S3/GCS에서 모델 가중치를 빠르게 다운로드
4. 최소 레플리카: 항상 최소 N개의 레플리카 유지오토스케일링의 스케일 인(축소)은 신중해야 합니다. 진행 중인 요청이 있는 레플리카를 갑자기 종료하면 사용자 요청이 실패합니다. 새 요청을 받지 않도록 설정(Drain)하고, 진행 중인 요청이 모두 완료된 후 종료하는 Graceful Shutdown 절차가 필수입니다.
프로덕션 LLM 서빙의 모니터링은 크게 세 가지 계층으로 구성됩니다.
- TTFT (P50, P95, P99)
- TPOT (P50, P95, P99)
- TPS (초당 생성 토큰)
- 요청당 입력/출력 토큰 수 분포
- 오류율 (타임아웃, OOM, 모델 오류)
- Speculative Decoding Acceptance Rate- GPU 활용률 (SM Active, Memory Bandwidth 활용률)
- GPU 메모리 사용량 (모델 + KV 캐시 + 기타)
- KV 캐시 사용률 및 블록 할당 현황
- Prefix Cache 히트율
- 배치 크기 분포
- 대기 큐 길이와 대기 시간- 시간당 처리 요청 수
- tokens/$ (비용 효율)
- SLO 달성률 (목표: 99%+)
- GPU 시간당 비용vLLM과 SGLang 모두 Prometheus 형식의 메트릭을 내장 지원합니다.
Critical:
- TTFT P95 > SLO x 1.5 (5분 연속)
- 오류율 > 1% (3분 연속)
- GPU 메모리 > 95%
Warning:
- TTFT P95 > SLO (10분 연속)
- Acceptance Rate < 0.5 (Speculative Decoding 비효율)
- Prefix Cache 히트율 < 30% (캐싱 전략 재검토 필요)전체 배포 파이프라인을 단계별로 정리합니다.
1단계: 모델 준비
2단계: 추론 엔진 설정
3단계: 벤치마크
4단계: 배포
5단계: 운영
10장에 걸쳐 LLM 추론 최적화의 핵심 기법들을 하나씩 살펴보았습니다. 마지막으로 전체 시리즈의 핵심 메시지를 정리합니다.
LLM 추론 최적화는 매우 빠르게 발전하는 분야입니다. 이 시리즈에서 다룬 기법들은 2026년 현재의 스냅샷이며, 새로운 하드웨어(B200, 커스텀 ASIC), 새로운 알고리즘(더 효율적인 Attention, 새로운 캐싱 전략), 새로운 아키텍처(SSM 하이브리드, Diffusion 기반 생성)가 지속적으로 등장하고 있습니다.
기법의 세부 사항은 변할 수 있지만, 이 시리즈에서 다룬 원칙들 -- 메모리 효율, 연산 병렬화, 중복 제거, 비용 최적화 -- 은 앞으로도 유효할 것입니다.
LLM 추론 최적화의 궁극적인 목표는 "더 많은 사람이, 더 적은 비용으로, 더 빠르게 AI의 혜택을 받을 수 있게 하는 것"입니다. 이 시리즈가 그 여정에 도움이 되기를 바랍니다.
이 장에서는 프로덕션 추론 최적화의 실전 전략을 종합했습니다.
이 시리즈 전체에서 다룬 기법들이 LLM 추론의 비용과 지연시간을 줄이는 데 실질적인 가이드가 되기를 바랍니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
GPU 선택, 클라우드 vs 온프레미스, 배칭 전략이 비용과 지연시간에 미치는 영향을 분석하고, SLO 기반 최적화와 비용 모델링 방법을 다룹니다.
텐서 병렬화, 파이프라인 병렬화, 시퀀스 병렬화, Expert 병렬화의 원리를 분석하고, 멀티 GPU 추론 전략과 클러스터 수준 최적화를 다룹니다.
양자화의 기초 개념부터 FP8의 부상, W8A8/W4A16 전략, GPTQ/AWQ/SmoothQuant 기법, KV 캐시 양자화까지 정확도와 성능의 트레이드오프를 분석합니다.