추론용 추측 실행
개요
Draft-Verify 파이프라인, 서빙 프레임워크 통합, 메모리/compute 트레이드오프, 레이턴시 vs 쓰루풋 최적화
추론용 추측 실행(Speculative Execution for Inference)은 autoregressive LLM의 토큰 생성 지연 시간을 줄이기 위해, 작은 draft 모델이 여러 토큰을 먼저 제안하고 큰 target 모델이 이를 한 번에 검증하는 시스템 기법입니다. 이 문서는 Speculative Decoding Analysis에서 다룬 알고리즘 메커니즘을 넘어, 실제 서빙 환경에서의 시스템 통합, 메모리 관리, 하드웨어 활용, 그리고 주요 프레임워크 구현 사례를 분석합니다.
추측 실행의 핵심은 "더 적은 target step으로 동일한 출력을 얻는 것"입니다. 그러나 실제로는 draft 모델의 추가 메모리 비용, verification 파이프라인의 오버헤드, 배치 스케줄링과의 상호작용 등 시스템 레벨의 복잡한 트레이드오프가 존재합니다. 따라서 이 기법을 서빙에 적용할 때는 단순히 알고리즘을 붙이는 것이 아니라, 전체 추론 스택 관점에서 최적화가 필요합니다.
추측 실행은 decode 구간의 step 수를 줄여 같은 출력 분포를 더 적은 target 호출로 얻으려는 접근입니다. 그래서 단일 알고리즘 최적화가 아니라 continuous batching, KV cache 관리, verification 커널, fallback 경로까지 포함한 서빙 시스템 설계 문제로 다뤄야 합니다.
1. 추론 병목과 추측 실행의 출발점
LLM 추론은 두 단계로 나뉩니다:
- Prefill 단계: 입력 프롬프트를 한 번에 처리하며, GPU compute를 충분히 활용합니다.
- Decode 단계: 토큰을 하나씩 생성하며, memory bandwidth에 의해 병목이 발생합니다.
Decode 단계에서는 매 스텝마다 전체 모델 파라미터를 읽어야 하지만, 계산량은 상대적으로 적습니다. 이것이 흔히 말하는 "memory-bound" 특성입니다. 추측 실행은 이 병목을 공략합니다. 작은 draft 모델이 저렴하게 여러 토큰을 미리 생성하고, target 모델이 이를 병렬 검증함으로써 decode step 수를 줄입니다.
| 특성 | Prefill | Decode (기본) | Decode (추측 실행) |
|---|---|---|---|
| 병목 | Compute | Memory BW | Memory BW (단, step 감소) |
| GPU 활용률 | 높음 | 낮음 | 중간~높음 (verification 시) |
| 배치 효과 | 높음 | 낮음 | 중간 (draft+verify 배치) |
| 출력 보장 | — | 확률 보존 | 동일 분포 보존 |
2. 핵심 개념
- Draft Model: target 모델보다 작은 보조 모델로, 빠르게 k개 후보 토큰을 생성합니다. 파라미터 수는 target의 5%~25% 수준이 일반적입니다.
- Target Model: 최종 출력을 결정하는 검증자 역할의 큰 모델입니다.
- Speculative Window (k): 한 번에 제안하는 후보 토큰 수입니다. k가 클수록 step 감소 효과가 크지만, reject 확률도 증가합니다.
- Acceptance Rate (α): draft 제안 중 target이 채택하는 비율입니다. α가 높을수록 speedup이 커집니다.
- Expected Speedup: 이론적으로
1 / (1 - α + α/(k+1))수준입니다. α=0.7, k=5일 때 약 2.3x speedup을 기대할 수 있습니다. - Verification Cost: target 모델이 k개 후보를 검증하는 비용입니다. KV cache 증가와 attention 계산이 포함됩니다.
- Rollback: mismatch 지점 이후 모든 후보를 폐기하고 target 모델의 fallback decode로 복귀하는 동작입니다.
3. 비교/분석
3.1 추측 실행 변형 비교
| 변형 | Draft 소스 | 학습 필요 | 메모리 오버헤드 | Speedup 범위 | 특징 |
|---|---|---|---|---|---|
| 독립 Draft Model | 별도 소형 모델 | 없음 (보통) | 높음 (모델 2개) | 2x~3x | 가장 직관적, 배포 부담 |
| Self-Speculation | 같은 모델 얕은 층 | 구조 조정 | 중간 (Early Exit) | 1.5x~2.5x | 배포 간소화, 품질 제어 필요 |
| Medusa | Multi-head (backbone 위) | Fine-tuning | 낮음 (head만 추가) | 2.2x~3.6x | Tree attention, 별도 draft 불필요 |
| EAGLE | Feature-level predictor | Fine-tuning | 낮음 (feature head) | 2.7x~3.5x | Feature 불확실성 해결, 안정적 |
| Lookahead | 자체 N-gram 추출 | 없음 | 없음 | 1.2x~1.8x | 추가 모델 불필요, exact decoding |
3.2 서빙 프레임워크별 지원 현황
| 프레임워크 | 추측 실행 지원 | 통합 방식 | 비고 |
|---|---|---|---|
| vLLM | EAGLE, Medusa | Draft-verify 파이프라인 내장 | Continuous batching 연동 |
| TensorRT-LLM | 자체 draft, EAGLE | 커스텀 커널 | NVIDIA 하드웨어 최적화 |
| SGLang | EAGLE, Lookahead | RadixAttention 기반 | Prefix caching과 시너지 |
| llama.cpp | 독립 draft, Self-spec | CPU/GPU 하이브리드 | 엣지 디바이스 특화 |
| DeepSpeed-FastGen | Draft model | SplitFuse | Prefill-decode 혼합 배치 |
4. 동작 원리 — 시스템 레벨 파이프라인
4.1 전체 흐름
추측 실행의 시스템 흐름은 다음과 같습니다:
- Draft Phase: draft 모델이 현재 prefix를 기반으로 k개 후보 토큰을 순차 생성합니다.
- Batch Assembly: draft 결과와 기존 KV cache를 결합해 verification 배치를 구성합니다.
- Verification Phase: target 모델이 k개 후보를 한 번의 forward pass로 병렬 검증합니다.
- Accept/Reject Decision: 각 위치에서 draft 분포와 target 분포를 비교해 채택 여부를 결정합니다.
- Rollback & Retry: mismatch 이후 토큰을 폐기하고, 다음 토큰을 fallback decode합니다.
4.2 KV Cache 관리
추측 실행에서 KV cache 관리는 특히 중요합니다:
- Draft KV Cache: draft 모델의 별도 KV cache가 필요합니다. 크기는 draft 모델의 크기에 비례합니다.
- Shared Prefix: 채택된 prefix의 KV cache는 재사용됩니다.
- Rollback 시점: rejected suffix의 KV cache를 정확히 폐기해야 합니다.
- Memory Budget: draft + target의 KV cache가 GPU 메모리에 동시에 맞아야 합니다.
4.3 검증 커널 최적화
target 모델의 verification은 여러 토큰을 한 번에 처리하므로, attention 커널이 배치 차원에서 효율적이어야 합니다:
- Tree Attention: Medusa에서 사용하는 트리 구조의 attention으로, 여러 경로를 동시에 검증합니다.
- Batch GEMM: k개 후보의 projection을 한 번에 배치 처리합니다.
- KV Gather: 필요한 KV entry만 선택적으로 수집하는 커널이 필요합니다.
5. 메모리 및 Compute 트레이드오프
5.1 메모리 비용 분석
추측 실행은 메모리를 추가로 사용합니다:
- Draft Model 파라미터: target 모델의 5%~25% 크기
- Draft Model KV Cache: draft 길이에 비례
- Verification 버퍼: k개 후보의 logits와 attention score
| 구성 요소 | 크기 (7B target 기준) | 비고 |
|---|---|---|
| Target 파라미터 | ~14GB (FP16) | 고정 |
| Target KV Cache | 배치별 가변 | 기존과 동일 |
| Draft 파라미터 | ~0.7~3.5GB | 추가 비용 |
| Draft KV Cache | ~수백 MB | k에 비례 |
| Verification 버퍼 | ~수백 MB | k에 비례 |
5.2 Compute 비용 분석
- Draft 비용: 매 step마다 draft 모델의 k회 sequential forward
- Verification 비용: target 모델의 1회 forward (k+1개 토큰 처리)
- Net 이득: draft 비용 + verification 비용 < 기본 decode 비용 × step 수
draft가 충분히 작고 acceptance rate가 높을 때만 실제 이득이 발생합니다. 특히 짧은 응답에서는 draft 비용이 상대적으로 커서 이득이 제한될 수 있습니다.
6. 장단점
| 장점 | 단점 |
|---|---|
| Output distribution이 완전히 보존됨 (lossless) | Draft 모델 추가 메모리/계산 비용 |
| 기존 모델 재학습 없이 적용 가능 (대부분) | Acceptance rate가 낮으면 오히려 손해 |
| 긴 응답 생성에서 누적 speedup이 큼 | KV cache 관리 복잡도 증가 |
| Tree attention으로 여러 경로 동시 검증 가능 | 배치 스케줄링과의 상호작용 고려 필요 |
| 서빙 프레임워크 내장 지원이 보편화 | Short-context/short-response에서 이득 제한 |
추측 실행의 본질은 "target model의 step 수를 줄이는 것"입니다. 그러나 실제로는 draft 비용, verification 비용, 메모리 오버헤드, KV cache 관리가 모두 맞물려야 의미 있는 speedup이 나옵니다. 따라서 어떤 환경에서 어떤 변형을 사용할지는 시스템 전체 관점에서 판단해야 합니다.
7. 관련 기술
- Speculative Decoding Analysis: 알고리즘 메커니즘과 accept/reject 상세 분석
- Continuous Batching Analysis: 배치 스케줄링과의 통합
- PagedAttention Analysis: KV cache 블록 관리
- KV Cache Offloading Analysis: 메모리 제약 하에서의 KV 관리
- LLM Inference Scheduler Analysis: 서빙 스케줄러와의 통합
| 자료 | 핵심 |
|---|---|
Fast Inference from Transformers via Speculative Decoding (Leviathan et al., ICML 2023) |
추측 실행 원 논문, T5-XXL에서 2x~3x 가속 |
Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads |
Multi-head decoding, tree attention, 2.2x~3.6x |
EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty (Li et al., 2024) |
Feature-level autoregression, 2.7x~3.5x |
Break the Sequential Dependency of LLM Inference Using Lookahead Decoding (Fu et al., 2024) |
추가 모델 없이 N-gram 기반 추측, 1.2x~1.8x |
SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills (Agrawal et al., 2023) |
Prefill-decode 혼합 배치, decode throughput 4x~10x |
8. 핵심 정리
추론용 추측 실행은 autoregressive decoding의 sequential bottleneck을 공격하는 시스템 기법입니다. draft 모델의 추가 비용과 verification의 이득이 상쇄되어야 하므로, 어떤 draft 구조를 선택하고, 어떤 verification 커널을 사용하며, 어떤 KV cache 관리 전략을 적용할지가 실제 성능을 결정합니다.
서빙 프레임워크들은 이제 추측 실행을 기본 기능으로 제공하는 방향으로 진화하고 있습니다. vLLM, TensorRT-LLM, SGLang 등이 각자의 continuous batching, PagedAttention, RadixAttention 등과 추측 실행을 통합하고 있으며, 이는 더 이상 실험적 기법이 아니라 실용적 서빙 최적화의 일부가 되었음을 의미합니다.
결국 추측 실행의 효과는 draft quality, acceptance rate, 시스템 통합 품질의 세 축에 의해 결정됩니다. 이 세 요소가 함께 최적화될 때, 추측 실행은 LLM 추론의 레이턴시와 쓰루풋 모두를 개선하는 강력한 도구가 됩니다.