smithLLM을 직접 서빙하는데 답이 한 글자씩 느리게 흘러나와서, vLLM 설정에 speculative_config를 넣어 볼지 고민하고 계신가요? 결론부터 말하면 동시 요청이 적고 지연이 중요하면 켜는 게 거의 항상 이득이고, 동시 요청이 많아 GPU가 이미 바쁘면 실제 부하로 재 본 뒤에 정해야 해요. 방식은 모델에 내장 MTP 층이 있으면 MTP, 공개 EAGLE-3 드래프터가 있으면 EAGLE-3, 둘 다 없으면 학습이 필요 없는 n-gram부터 시작하는 순서가 무난해요.
원리(작은 모델이 몇 토큰을 미리 쓰고 큰 모델이 한 번에 채점하는 구조)는 이미 알고 있다고 보고, 이 글은 고르는 데 필요한 숫자만 다뤄요. 논문이 공개한 실측값으로 토큰당 GPU 비용을 직접 계산하고, 초안 길이 γ를 늘릴 때 연산량이 얼마나 불어나는지, 배치가 커지면 이득이 어떻게 줄어드는지 보여 드려요.
투기적 디코딩, 어떤 방식이 얼마나 빠른가
방식마다 논문이 쓴 모델·하드웨어가 달라서, 각자 발표한 숫자를 나란히 놓으면 비교가 안 돼요. 다행히 EAGLE-3 논문(Li 외, 2025)의 표 1이 같은 타깃 모델과 같은 벤치마크 다섯 개(MT-bench, HumanEval, GSM8K, Alpaca, CNN/DM)로 여러 방식을 한꺼번에 쟀어요. 그중 Vicuna 13B, temperature 0의 평균값이에요.
이 표에서 읽을 점은 세 가지예요.
- 학습이 필요 없는 방식은 1.6~1.9배 근처예요. PLD(프롬프트에서 같은 구절을 찾아 복사)와 작은 초안 모델은 바로 켤 수 있지만 이득이 작아요. 단, PLD는 CNN/DM 요약에서만 2.42배로 다른 작업(1.16~1.85배)보다 확연히 높았어요. 입력을 베끼는 작업이면 학습 없이도 꽤 빨라져요.
- 타깃 모델의 은닉 상태를 쓰는 방식이 확실히 빨라요. Medusa → Hydra → EAGLE → EAGLE-3 순으로 올라가요. 대신 타깃 모델마다 드래프터를 학습해야 해요.
- 작업에 따라 크게 달라요. 같은 EAGLE-3도 HumanEval(코드) 6.47배, CNN/DM 5.01배였어요. 정해진 틀이 많은 출력일수록 초안이 잘 맞아요.
temperature 1에서는 숫자가 내려가요. Llama 3.1 8B 기준 EAGLE-3 평균이 0에서 4.44배, 1에서 3.45배였어요. 이 표에 Medusa는 temperature 1 줄이 아예 없는데, 논문은 Medusa 같은 방식이 샘플링 설정에서 수락 조건을 느슨하게 해 무손실이 보장되지 않아 비교에서 뺐다고 적었어요.
토큰당 GPU 비용으로 바꿔 계산하기
속도 배수는 그대로 돈으로 바뀌어요. 같은 GPU에서 초당 토큰 수가 늘면 토큰 하나에 드는 GPU 시간이 줄기 때문이에요. EAGLE-3 논문 표 4에는 SGLang 팀이 H100 한 장, 배치 1, Llama 3.1 8B로 잰 처리량이 있어요. 여기에 Lambda GPU 클라우드 가격표의 H100 SXM 80GB 1장 인스턴스 요금(시간당 4.29달러, 2026-10-25 확인, 세금 별도)을 곱했어요.
계산식은 100만 토큰 비용 = 시간당 요금 × 1,000,000 ÷ (3,600 × 초당 토큰 수) 예요.
| 설정 (H100 1장, 배치 1) | 초당 토큰 | 출력 100만 토큰 비용 | 500토큰 답 하나 생성 시간 |
|---|---|---|---|
| 투기적 디코딩 없음 | 158.34 | 약 7.53달러 | 약 3.16초 |
| EAGLE-2 | 244.10 | 약 4.88달러 | 약 2.05초 |
| EAGLE-3 | 373.25 | 약 3.19달러 | 약 1.34초 |
여기서 조심할 점이 있어요. 배치 1은 비용 면에서 가장 비싼 운영 방식이라, 실제 서비스는 여러 요청을 묶어 단가를 낮춰요. 그러면 투기적 디코딩이 쓰던 "남는 연산"이 줄어들어 절감 폭도 줄어요. 다음 절의 배치별 숫자가 이 부분이에요.
다른 GPU나 요금이면 위 식에서 시간당 요금만 바꾸면 돼요. 비율은 그대로라서, 배치 1에서 EAGLE-3는 어느 단가에서든 토큰당 비용을 약 58% 줄여요(158.34 ÷ 373.25 = 0.42).
배치가 커지면 이득이 줄어드는 이유와 실제 숫자
투기적 디코딩은 메모리 대역폭을 기다리느라 놀던 연산기를 검증에 쓰는 기법이에요. 동시 요청이 많아 연산기가 이미 바쁘면, 버려지는 초안 토큰의 검증 계산이 고스란히 비용이 돼요. EAGLE-3 논문 표 3은 SGLang v0.4.4, H100 한 장, Llama 3.1 8B, MT-bench로 배치 크기별 처리량 향상을 쟀어요.
1배 아래는 끄는 편이 빠르다는 뜻이에요. 이 실험은 트리 없이 체인 길이 3으로 쟀어요.
표로 보기
| 구분 | EAGLE-3 | EAGLE |
|---|---|---|
| 2 | 1.8 | 1.4 |
| 4 | 1.8 | 1.4 |
| 8 | 1.6 | 1.2 |
| 16 | 1.5 | 1 |
| 24 | 1.4 | 0.93 |
| 32 | 1.3 | 0.94 |
| 48 | 1.4 | 0.88 |
| 56 | 1.3 | 0.99 |
| 64 | 1.4 | 0.99 |
토큰당 비용은 처리량 향상의 역수예요. EAGLE-3는 배치 64에서도 1 ÷ 1.38 = 약 72%로 비용을 28% 줄였지만, 구형 EAGLE은 배치 48에서 1 ÷ 0.88 = 약 1.14, 즉 켜서 비용이 14% 늘었어요. 같은 논문의 vLLM 실험(Llama 3.1 8B, MT-bench, 체인 길이 2)에서도 EAGLE은 배치 32부터 1배 아래(0.93배)로 떨어졌고, EAGLE-3는 배치 56에서 1.01배로 이득이 거의 사라졌어요.
vLLM 공식 문서의 Speculative Decoding 안내도 같은 그림을 그려요. 이 기능의 목표를 "중간~낮은 QPS에서 토큰 간 지연 단축"으로 적고, 방식별 이득을 저QPS·고QPS로 나눠 매겨 둬요.
방식 (vLLM method) | 저QPS(지연 중심) | 고QPS(처리량 중심) | 문서의 메모 |
|---|---|---|---|
EAGLE (eagle3) | 높음 | 중간~높음 | 범용 모델 기반 방식 |
MTP (mtp) | 높음 | 중간~높음 | 타깃 모델이 MTP를 내장했을 때 최적 |
초안 모델 (draft_model) | 높음 | 중간 | 별도 초안 모델 필요 |
n-gram (ngram) | 낮음~중간 | 중간 | 가볍고 켜기 쉬움 |
접미사 디코딩 (suffix) | 낮음~중간 | 중간 | 초안 모델 없음, 추측 깊이 자동 조절 |
초안 길이 γ를 늘릴수록 연산 비용이 붙는다
num_speculative_tokens(γ)는 크게 잡고 싶어지는 값이에요. Leviathan 외(2022) 논문의 두 식으로 계산해 보면 왜 아닌지 보여요. 정리 3.8은 속도 향상을, 정리 3.11은 전체 연산량이 몇 배로 느는지를 줘요.
- 속도 향상 = (1 − α^(γ+1)) ÷ ((1 − α)(γc + 1))
- 연산량 증가 = (1 − α)(γĉ + γ + 1) ÷ (1 − α^(γ+1))
α는 초안 토큰 하나가 수락될 확률, c는 초안 모델 한 번 실행 시간 ÷ 타깃 모델 한 번 실행 시간, ĉ는 같은 비율을 연산량으로 잰 값이에요. 아래는 c와 ĉ를 같다고 두고 직접 계산한 값이에요.
| α | c | γ | 한 번에 확정되는 토큰(기댓값) | 속도 향상 | 연산량 |
|---|---|---|---|---|---|
| 0.2 (바이그램 수준) | 0 | 3 | 1.25 | 1.25배 | 3.21배 |
| 0.6 | 0.05 | 2 | 1.96 | 1.78배 | 1.58배 |
| 0.6 | 0.05 | 4 | 2.31 | 1.92배 | 2.26배 |
| 0.8 | 0.05 | 3 | 2.95 | 2.57배 | 1.41배 |
| 0.8 | 0.05 | 5 | 3.69 | 2.95배 | 1.69배 |
| 0.8 | 0.05 | 8 | 4.33 | 3.09배 | 2.17배 |
α 0.8에서 γ를 5에서 8로 늘리면 속도는 2.95배 → 3.09배로 5% 오르는데 연산량은 1.69배 → 2.17배로 28% 늘어요. GPU가 한가할 때는 이 연산이 공짜에 가깝지만, 공유 서버에서는 다른 요청이 쓸 연산을 빼앗아요. 첫 줄도 눈여겨보세요. 수락률이 낮은 n-gram은 지연은 25%밖에 안 줄면서 연산은 3배 넘게 써요. 수락이 잘 안 되는 작업에 n-gram을 켜 두면 배치 처리량이 떨어지기 쉬운 이유예요.
이 식은 "타깃 모델이 γ+1개 위치를 한 번에 보는 데 추가 시간이 없다"고 가정한 이론값이라 실측은 이보다 낮게 나와요. 원 논문의 T5-XXL 실험도 초안이 클수록 α는 올랐지만(0.75 → 0.82) 속도는 떨어졌어요(3.4배 → 1.7배). c가 커졌기 때문이에요.
품질과 메모리 — 숫자 밖의 비용
품질. 표준 검증 규칙(확률 min(1, p/q)로 수락, 거절하면 남은 분포에서 다시 뽑기)을 쓰면 출력 분포는 타깃 모델 단독과 같아요. vLLM 문서는 이를 "하드웨어 수치 정밀도 한계 안에서 이론적으로 무손실"이라고 적고, 로그 확률(logprobs)이 안정적이라고 보장하지는 않는다고 덧붙여요. 그래서 테스트에서 출력 문자열을 비트 단위로 비교하는 대신, 평가 지표로 비교하는 편이 안전해요.
일부러 품질을 내주고 속도를 사는 옵션도 있어요.
- vLLM의 FLy 검증: 문서에 "분포를 보존하지 않는다"고 명시돼 있어요.
- Hugging Face transformers의 Assisted decoding 문서에 있는
assistant_ensemble_weight(정적 앙상블 검증): 타깃과 초안 분포의 혼합을 따르게 돼요. - 샘플링 설정의 Medusa typical acceptance: EAGLE-3 논문이 무손실이 보장되지 않는다고 짚은 부분이에요.
이런 옵션을 켰다면 속도만 재지 말고 기존 품질 평가 세트를 다시 돌려야 해요.
메모리. 별도 초안 모델은 가중치와 KV 캐시를 한 벌 더 올려요. bf16이면 파라미터 1개에 2바이트라서 1B 초안은 가중치만 약 2GB, 135M 초안은 약 0.27GB예요. 그 메모리만큼 타깃 모델의 KV 캐시가 줄어 동시에 처리할 수 있는 요청 수가 줄어요. MTP는 체크포인트에 이미 들어 있는 층을 쓰고, n-gram·접미사 방식은 모델이 없어서 이 부담이 거의 없어요.
지원 범위. transformers의 generate()는 초안 모델·MTP 방식에서 배치 입력을 지원하지 않는다고 문서에 적혀 있어요. 여러 요청을 묶어 처리하려면 vLLM 같은 서빙 엔진을 써야 해요. vLLM도 vllm<=0.15.0에서는 파이프라인 병렬과 함께 쓸 수 없다고 적어 두었으니 버전을 확인하세요.
상황별 추천 — 무엇을 켤까
| 상황 | 추천 | 이유 |
|---|---|---|
| 사내 코딩 도우미, 동시 사용자 몇 명 | eagle3 (드래프터 있으면) | 코드 작업에서 수락 길이가 가장 길고 배치가 작아요 |
| DeepSeek-V3·GLM-4.5 계열 서빙 | mtp | 체크포인트에 초안 층이 들어 있어 추가 모델이 없어요 |
| RAG 답변·문서 요약·코드 수정 | ngram 또는 suffix부터 | 출력이 입력을 많이 베껴 학습 없이도 수락이 잘 돼요 |
| 같은 계열 소형 모델이 있고 메모리 여유 | draft_model | 학습이 필요 없고 저QPS 이득이 커요 |
| 피크 때 배치 수십 이상, 처리량이 목표 | 실제 부하로 켠 것과 끈 것 비교 | 배치 24~64에서 1배 아래가 나온 실측이 있어요 |
| 창작·높은 temperature 위주 | γ를 2~3으로 작게 | 수락률이 낮아 긴 초안은 연산만 버려요 |
vLLM에서 n-gram은 이렇게 켜요. 공식 문서 예시와 같은 값이에요.
vllm serve <target-model> \
--speculative-config '{
"method": "ngram",
"num_speculative_tokens": 4,
"prompt_lookup_min": 2,
"prompt_lookup_max": 5
}'--speculative-config는 셸 문자열 안에 든 JSON이라 따옴표나 쉼표 하나만 틀려도 서버가 뜨지 않아요. 긴 설정은 먼저 JSON Validator에 붙여 문법을 확인하면 오류 줄을 바로 찾을 수 있어요. 자주 나는 문법 오류는 JSON 파싱 에러 원인 6가지에 정리해 두었어요. 그리고 temperature·top_p는 이 설정의 키가 아니라 요청마다 주는 샘플링 파라미터라는 점도 문서가 따로 짚어요.
도입 체크리스트
- 목표를 하나로 정해요. 사용자가 느끼는 지연(토큰 간 지연)인지, 같은 GPU로 받는 요청 수(처리량)인지에 따라 결론이 달라져요.
- 기준선을 먼저 재요. 끈 상태에서 실제 프롬프트 분포로 TTFT·TPOT의 p50·p99와 tokens/s를 기록해요. 벤치마크용 짧은 프롬프트만 쓰면 수락률이 실제와 달라져요.
- 평균 수락 길이를 봐요. 검증 한 번에 확정되는 토큰 수예요. vLLM은 요청별 수락 지표를 따로 볼 수 있게 해 두었어요. 2에 못 미치면 γ를 줄이거나 방식을 바꿔요.
- 피크 부하로 다시 재요. 배치 1에서 3배 빨라도 피크 때 1배 아래일 수 있어요. 위 SGLang 표가 그 예예요.
- 무손실 검증인지 확인해요. 느슨한 검증 옵션을 켰다면 품질 평가를 다시 돌려요.
- 트래픽이 바뀌면 다시 맞춰요. 코드 질문 비중이 줄고 잡담이 늘면 수락률이 떨어져 같은 γ가 손해가 될 수 있어요.
자주 묻는 질문
투기적 디코딩을 켜면 답변 품질이 떨어지나요?
표준 검증 규칙을 쓰면 출력 분포는 타깃 모델 단독과 같아서 품질은 그대로예요. 다만 부동소수점 계산 순서가 바뀌어 같은 입력에서도 드물게 다른 토큰이 나올 수 있어요. vLLM의 FLy, transformers의 assistant_ensemble_weight처럼 검증을 느슨하게 하는 옵션은 출력 분포가 달라지니 품질을 다시 평가해야 해요.
num_speculative_tokens는 몇으로 시작하면 되나요?
vLLM 문서 예시는 n-gram 4, 초안 모델 5예요. 수락률 0.8 기준으로 계산하면 γ 3에서 5로는 속도가 2.57배에서 2.95배로 오르지만, 8로 늘려도 3.09배에 그치고 연산량만 늘어요. 3~5로 시작하고 평균 수락 길이를 보며 조정하세요.
동시 사용자가 많은 API 서버에도 효과가 있나요?
줄어들어요. EAGLE-3 논문의 SGLang 측정에서 배치 2에서는 1.81배였지만 배치 64에서는 1.38배였고, 구형 EAGLE은 배치 24부터 1배 아래였어요. 피크 부하로 켠 것과 끈 것을 직접 비교해서 정하세요.
초안 모델은 아무 작은 모델이나 써도 되나요?
기본 방식은 두 모델의 토크나이저·어휘가 같아야 해요. 토큰 번호 단위로 확률을 비교하기 때문이에요. transformers는 토크나이저가 다른 모델을 쓰는 UAD 경로를 따로 두고 있어요. 크기는 타깃보다 두 자릿수 작은 정도가 원 논문에서 가장 좋았어요.
OpenAI나 Claude 같은 API를 쓰는데 이 설정을 할 수 있나요?
아니요. 투기적 디코딩은 모델을 돌리는 서버 쪽 설정이라, 이 글의 선택은 모델을 직접 띄워 서빙할 때 해당돼요. API를 쓴다면 출력 토큰 수를 줄이거나 스트리밍으로 체감 지연을 줄이는 쪽이 할 수 있는 일이에요.
정리
- 같은 조건 비교에서 학습 없는 방식(PLD·작은 초안 모델)은 1.7~1.9배, EAGLE-3는 5.5배 수준이었어요. 모델에 MTP가 있으면 MTP, 드래프터가 있으면 EAGLE-3, 없으면 n-gram부터 시작해요.
- 배치 1에서는 토큰당 GPU 비용이 크게 줄지만(H100·Llama 3.1 8B 계산에서 7.53달러 → 3.19달러), 배치가 커질수록 이득이 줄고 방식에 따라 손해가 나요. 피크 부하로 재서 정하세요.
- γ는 3~5로 시작해요. 늘릴수록 속도는 포화되고 연산량은 계속 늘어요.
- 설정 JSON은 JSON Validator로 먼저 확인하면 서버 기동 실패를 줄일 수 있어요.