표준 Speculative Decoding은 구조가 단순하다. 작은 드래프트 모델이 여러 토큰을 제안하고, 큰 타겟 모델이 한 번의 forward pass로 몰아서 검증한다. 검증 비용이 드래프트 길이에 관계없이 거의 일정하기 때문에, 수락률만 충분히 높으면 throughput이 준선형으로 오른다.
문제는 "드래프트 모델을 어떻게 두느냐"에 있다. 별도 모델을 올리면 메모리가 추가로 필요하고, 그 모델이 타겟 모델과 다른 내부 표현 공간에서 살기 때문에 수락률이 기대보다 낮게 나온다. Medusa·EAGLE·Lookahead는 이 삼각관계—드래프트 모델 메모리, 추론 오버헤드, 수락률—의 서로 다른 항을 공략한다. Medusa는 추론 오버헤드를, EAGLE은 context mismatch를, Lookahead는 드래프트 모델 메모리 자체를 제거한다. 공략 항이 다르기 때문에 어느 환경에서 무엇을 선택해야 하는지도 갈린다.
Medusa: 헤드를 여럿 달아 드래프트 오버헤드를 없앤다
Medusa의 구조는 직관적이다. 타겟 모델의 LM Head 위에 추가 헤드를 k개 붙이고, 각 헤드가 독립적으로 k번째 다음 토큰을 예측한다. Forward pass 한 번에 최대 k+1개의 토큰 후보가 나오고, 드래프트를 위한 별도 모델 forward가 없으니 추론 오버헤드는 사실상 0이다. 추가 파라미터도 헤드뿐이어서 A100 80GB 기준으로 약 0.2-0.5GB 수준에 그친다.
검증은 Tree Attention으로 한다. 헤드들이 만들어낸 토큰 조합을 트리로 구성하고, 타겟 모델이 트리 전체를 병렬로 검증해 가장 긴 수락 체인을 선택한다. Medusa 논문은 백본을 frozen한 Medusa-1이 2.2x 이상, 공동 파인튜닝하는 Medusa-2가 2.3x-3.6x 속도 향상을 보인다고 보고한다.
배치가 커지면 이야기가 달라진다. 각 헤드는 현재 토큰의 hidden state만 보고 독립적으로 예측한다. 배치 안의 시퀀스마다 컨텍스트가 다르면 헤드별 수락률이 시퀀스마다 달라진다. 배치 크기가 1일 때는 트리 구조가 유리하게 작동하지만, 배치가 커지면 수락률이 낮은 시퀀스들이 전체 트리의 검증 병목이 된다. 헤드 수를 늘릴수록 트리가 넓어지고, 수락률이 불균일한 배치에서는 오히려 overhead가 증가하는 구간이 온다. Medusa 논문의 벤치마크가 단일 요청(batch=1) 시나리오에 집중한 이유도 이 때문이다.
자체 파인튜닝 모델에 붙이기는 가장 쉽다. 드래프트 모델 학습 파이프라인 없이 헤드만 추가하면 된다. 단, 수락률이 모델과 도메인에 따라 편차가 크고, 배치 서빙 환경에서는 예상보다 이득이 작게 나올 수 있다.
EAGLE: 타겟 모델의 hidden state를 드래프트 입력으로 재사용한다
표준 Speculative Decoding이 수락률을 낮추는 근본 이유는 context mismatch다. 드래프트 모델이 타겟 모델과 다른 표현 공간에서 예측하기 때문에, 방향이 맞더라도 타겟 모델이 거부한다.
EAGLE은 이 gap을 줄이기 위해 타겟 모델의 마지막 레이어 hidden state를 드래프트 모델의 입력으로 직접 공급한다. 드래프트 모델이 타겟 모델이 "무엇을 보고 있는지"를 입력으로 받으니, 예측이 타겟 모델의 분포에 훨씬 가깝게 붙는다. LLaMA2-Chat 기준으로 acceptance rate α가 0.75-0.77이고, 한 번의 검증 pass에서 평균 3.62-3.90개 토큰이 수락된다. 이 수락률 덕분에 EAGLE이 Medusa보다 1.47x-1.60x, Lookahead보다 1.7x-2.1x 빠른 결과가 나온다.
EAGLE-2는 draft length를 고정값이 아니라 컨텍스트에 따라 동적으로 조정하는 adaptive draft tree를 추가했다. EAGLE-1은 드래프트 step 수를 고정하기 때문에, 수락률이 낮은 구간에서도 같은 길이의 드래프트를 만들어 낭비가 생겼다. EAGLE-2는 이 구간을 감지해 드래프트를 짧게 끊는다. 결과적으로 EAGLE-1 대비 20%-40% 추가 가속을 달성한다. LLaMA3-Instruct 70B에서 3.29x, Vicuna 13B에서 4.26x가 나왔고, 사이클당 수락 토큰 수(τ)가 EAGLE-1의 3.94에서 4.98로 올랐다.
EAGLE-3는 EAGLE-2에서 한 발 더 나아가 드래프트 헤드를 마지막 레이어뿐 아니라 여러 중간 레이어의 hidden state 혼합에 대해 학습시킨다. 채팅 도메인에서 EAGLE-2 대비 수락률이 8-14% 향상된다. vLLM 0.8+ 기준으로 EAGLE-3가 현재 권장 방법이다.
이 구조에는 메모리 비용이 붙는다. Hidden state를 공유하더라도 드래프트 모델 자체의 KV 캐시는 타겟 모델과 분리된다. 70B 타겟 기준으로 드래프트 모델이 A100 80GB에서 약 1.5-3GB를 추가로 점유한다. 공개된 EAGLE/EAGLE-2/EAGLE-3 체크포인트가 있는 모델이라면 바로 쓸 수 있지만, 자체 파인튜닝 모델에 붙이려면 4×A100 (40G)에서 1-2일의 별도 학습이 필요하다.
Lookahead Decoding: Draft Model 메모리를 0으로 만든다
Lookahead Decoding은 드래프트 모델 자체를 없앤다. Jacobi 반복 기반으로 여러 위치의 토큰을 동시에 예측하면서, 그 과정에서 생성되는 n-gram 패턴을 풀에 쌓는다. 이후 디코딩 단계에서 현재 컨텍스트와 일치하는 n-gram을 풀에서 꺼내 드래프트 체인으로 사용한다. 추가 모델이 없으니 메모리 오버헤드는 n-gram 버퍼뿐이다.
핵심 파라미터는 N(Jacobi 반복 윈도우 크기)과 W(n-gram 크기)다. N과 W가 클수록 더 긴 드래프트 체인을 구성할 수 있지만, Jacobi 반복 자체의 연산이 늘어나 TTFT가 올라간다. 단일 GPU에서 두 파라미터 간 최적점을 찾는 실험이 배포 전에 필요하다.
수락률이 텍스트의 n-gram 반복성에 강하게 종속된다. MT-bench 같은 자유로운 대화 생성에서는 최대 1.8x 수준이지만, 코드 완성이나 문서 요약처럼 반복 패턴이 많은 도메인에서는 멀티-GPU 환경에서 4x까지 나온다. 반복성 없는 텍스트에서는 n-gram 풀이 비어 수락률이 바닥을 친다.
메모리 여유가 없는 단일 GPU 환경에서는 사실상 유일한 선택지다.
세 변종의 수락률·메모리·배치 민감도 비교
아래 표는 각 논문의 보고 수치와 A100 80GB 기준 추정치를 정리한 것이다. 동일 조건에서 방법별로 직접 맞대어 측정한 수치가 아니므로 배치 조건의 상대 비교는 방향성 가이드로 읽는다.
| 방법 | 단일 요청 속도향상 | 수락 토큰 수 (τ) | 추가 메모리 | 배치 민감도 |
|---|---|---|---|---|
| Medusa-2 | 2.3x - 3.6x | 중간 | ~0.2-0.5 GB | 높음 (배치↑ → 이득↓) |
| EAGLE-1 | 2.78x - 3.52x | ~3.62-3.90 | ~1.5-3 GB | 중간 |
| EAGLE-2/3 | 3.29x - 4.26x | ~4.98 | ~1.5-3 GB | 중간-낮음 |
| Lookahead | 1.8x (chat) / 4x (code) | 도메인 의존 | ~0 GB | 낮음 |
EAGLE이 Medusa보다 배치 민감도가 낮은 이유는 드래프트 품질 자체에 있다. 수락률이 높으면 배치 내 시퀀스 간 수락 체인 길이의 편차가 줄어든다. Medusa는 헤드별 독립 예측이라 시퀀스마다 편차가 크고, 이 편차가 배치를 키울수록 누적돼 throughput 이득을 갉아먹는다.
언제 무엇을 선택해야 하는가
세 시나리오로 나눠 본다.
단일 요청 저지연 서빙(chatbot)이 목표라면 EAGLE-2 또는 EAGLE-3이 현재 가장 나은 선택이다. 수락률이 안정적이고, batch=1 환경에서는 추가 메모리 비용 대비 속도 이득이 명확하다. 공개 체크포인트가 있는 모델이어야 한다는 전제가 붙는다.
높은 배치 throughput(batch API, 비동기 처리)이 목표라면 판단이 달라진다. Medusa는 batch=1에서 빛나지만 배치가 올라갈수록 이득이 빠르게 줄어든다. EAGLE은 배치 전반에서 더 안정적이나, 큰 배치에서는 speculative decoding 자체의 이득이 줄어드는 한계가 어느 방법이든 공통으로 존재한다. 높은 배치 환경에서는 어느 변종을 쓰든 먼저 수락률을 실측해야 한다.
단일 GPU, 메모리 여유가 없는 환경이라면 Lookahead가 유일한 현실적 선택이다. 단, 서빙 도메인이 코드나 문서 요약처럼 n-gram 반복성이 높아야 실질 이득이 나온다.
수락률을 사전에 측정하기 어려운 상황이라면 EAGLE이 가장 안전한 하한을 제공한다. Medusa는 도메인이 맞으면 올라가지만 맞지 않으면 급격히 떨어지고, Lookahead는 반복성 없는 텍스트에서 baseline과 거의 차이가 없어진다.
| 시나리오 | 권장 방법 | 핵심 이유 |
|---|---|---|
| 단일 요청, 저지연 (chatbot) | EAGLE-2/3 | 높은 τ, 안정적 수락률 |
| 높은 배치 throughput | EAGLE-2/3 또는 Draft Model | 배치 민감도 낮은 편 |
| 단일 GPU, 메모리 여유 없음 | Lookahead | 추가 모델 메모리 0 |
| 코드·문서 요약 등 고반복 도메인 | Lookahead | n-gram 재사용 이득 최대 |
| 자체 파인튜닝 모델, 빠른 적용 | Medusa-1 | 드래프트 모델 학습 없이 헤드만 추가 |
vLLM·SGLang에서 활성화하기
vLLM 0.8 이후 speculative decoding API는 --speculative-config로 통합됐다. EAGLE-3와 n-gram 방식은 아래처럼 활성화한다.
# EAGLE-3 (vLLM 0.8+, 권장)
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-config '{
"method": "eagle3",
"model": "yuhuili/EAGLE3-LLaMA3.1-Instruct-70B",
"num_speculative_tokens": 5
}'
# N-gram / Lookahead (추가 모델 불필요)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
--speculative-config '{
"method": "ngram",
"num_speculative_tokens": 5
}'
# 표준 Draft Model
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-config '{
"method": "draft_model",
"model": "meta-llama/Llama-3.1-8B-Instruct",
"num_speculative_tokens": 5
}'
Python API에서는 동일한 딕셔너리를 LLM(..., speculative_config={...})로 넘기면 된다. 드래프트 모델의 텐서 병렬 크기를 타겟과 맞출 때는 draft_tensor_parallel_size를 명시해야 한다.
현재 vLLM에서 Medusa는 독립 named method로 노출되지 않는다. SGLang은 Medusa를 별도 지원한다. num_speculative_tokens는 드래프트 체인 길이의 상한으로, adaptive draft length가 있는 EAGLE-2/3에서는 실제 길이를 동적으로 줄이니 고정 step보다 낭비가 없다. 처음에는 5 정도에서 시작해 수락률을 실측한 뒤 조정하는 방식이 낫다.
남은 질문은 MTP(Multi-Token Prediction)의 부상이다. DeepSeek-V3처럼 학습 시점부터 MTP를 내재화한 모델이 늘어나면, 별도 드래프트 체크포인트 없이 타겟 모델 자체에서 드래프트가 나온다. 이 구조가 EAGLE의 포지션을 어디까지 대체할지는 아직 열려 있다.