LLM 응답 속도를 높이려고 양자화와 KV Cache를 조정했는데도 토큰이 한 글자씩 나오는 속도, 즉 TPOT(Time Per Output Token)가 기대만큼 줄지 않는 경우가 있습니다. 이때 검토할 기능이 Speculative Decoding입니다. 작은 초안 모델이나 규칙 기반 추측기가 여러 토큰을 먼저 제안하고, 본 모델이 한 번에 검증해 채택하는 방식입니다.
핵심은 “작은 모델의 답을 그대로 쓰는 것”이 아닙니다. 초안 토큰을 대상 모델이 검증하므로 알고리즘 관점에서는 대상 모델의 분포를 보존합니다. 다만 실제 환경에서는 부동소수점 연산, 배치 구성, 샘플링 설정 때문에 결과가 비트 단위로 항상 같다고 단정할 수는 없습니다.
먼저 메모리를 줄여야 한다면 LLM 양자화 완전정리와 vLLM KV Cache 완전정리를 함께 확인하세요.
핵심 요약
- Speculative Decoding은 여러 후보 토큰을 제안하고 대상 모델이 병렬 검증해 Decode 단계를 줄입니다.
- 낮은 QPS의 메모리 대역폭 병목 환경에서 효과가 크고, 이미 GPU가 포화된 높은 QPS에서는 이득이 작거나 역효과가 날 수 있습니다.
- N-gram은 코드·문서처럼 입력에 반복 구문이 많을 때 가볍게 시도하기 좋습니다.
- Draft Model은 별도 모델 메모리와 호환성 검증이 필요하고, EAGLE 계열은 지원되는 전용 Speculator가 있어야 합니다.
- 평균 지연시간만 보지 말고 P95 TPOT, 처리량, 수락률, GPU 메모리를 함께 비교해야 합니다.
1. 한 토큰씩 생성하는 비용을 줄이는 원리
일반 Decode는 대상 모델이 매 단계 다음 토큰 하나를 계산합니다. 반면 Speculative Decoding은 초안 단계에서 k개 후보를 만든 다음, 대상 모델이 후보 전체를 한 번에 확인합니다. 앞에서부터 채택 조건을 만족한 토큰은 사용하고 거절된 지점부터 다시 진행합니다.
일반: Target → 1토큰 → Target → 1토큰 → Target → 1토큰
추측: Draft → 후보 4토큰 → Target이 병렬 검증 → 여러 토큰 채택
가속 폭은 후보 수락률과 초안 생성 비용의 균형으로 결정됩니다. 초안이 빠르지만 계속 틀리면 검증 호출과 부가 연산만 늘어납니다. 반대로 대상 모델과 지나치게 비슷한 큰 Draft Model은 잘 맞히더라도 초안 계산이 무거워집니다.
2. 방식별 선택 기준
방식잘 맞는 상황주의점
| N-gram | 입력 문서 인용, 코드 완성, 반복 문구 | 창의적 생성에서는 적중률이 낮을 수 있음 |
| Draft Model | 호환되는 작은 모델이 있고 범용 대화가 많음 | 추가 VRAM, 토크나이저·어휘 호환성 |
| EAGLE 계열 | 지원 대상 모델과 전용 Speculator가 준비됨 | 모델 조합과 vLLM 버전 확인 필요 |
| MLP Speculator | 검증된 전용 헤드를 사용할 수 있음 | 일반 모델에 임의 적용할 수 없음 |
첫 실험은 추가 가중치가 필요 없는 N-gram 방식이 단순합니다. 입력과 출력 사이에 복사가 자주 일어나는 요약·코드·문서 QA라면 좋은 기준선이 됩니다. 이후 범용 요청에서 수락률이 낮다면 지원되는 Draft Model이나 EAGLE 계열을 비교합니다.
3. 후보 토큰 수를 크게 잡으면 항상 빠를까
후보 수를 늘리면 한 번의 검증으로 더 많은 토큰을 채택할 기회가 생깁니다. 그러나 뒤쪽 후보일수록 앞 토큰이 맞아야 유효하고, 잘못된 후보를 검증하는 계산도 커집니다. 따라서 2·4·6처럼 작은 범위부터 측정하는 편이 안전합니다.
실험 조합 예시
baseline: speculative decoding 미사용
case A: 후보 2개
case B: 후보 4개
case C: 후보 6개
공통 조건: 같은 프롬프트, 출력 길이, temperature, 동시성, GPU
CLI 인자는 vLLM 릴리스에 따라 구조와 이름이 달라질 수 있습니다. 운영 버전의 공식 문서와 vllm serve --help에서 speculative_config 관련 옵션을 확인한 뒤 고정하세요.
4. 어떤 지표로 비교해야 하나
- TTFT: 첫 토큰까지 걸린 시간. Speculative Decoding은 주로 Decode를 줄이므로 TTFT 개선이 작을 수 있습니다.
- TPOT 또는 ITL: 출력 토큰 사이 지연시간. 사용자 체감과 직접 연결됩니다.
- 요청 지연시간 P50·P95: 평균만으로 가려지는 긴 꼬리를 확인합니다.
- Output tokens/s: 동시 요청 전체 처리량을 봅니다.
- Acceptance rate: 제안 토큰 중 실제 채택 비율입니다.
- GPU 메모리와 사용률: Draft Model의 추가 비용과 포화 여부를 확인합니다.
낮은 동시성에서 TPOT가 줄어도 높은 동시성에서 처리량이 떨어질 수 있습니다. 실제 서비스의 입력·출력 길이 분포와 QPS를 재현해야 하는 이유입니다.
5. 실패하기 쉬운 패턴
- 벤치마크 프롬프트가 너무 단순함: 반복 문장이 많은 합성 데이터는 수락률을 과대평가할 수 있습니다.
- 대상 모델과 초안 모델의 호환성을 생략함: 토크나이저와 어휘가 다르면 사용할 수 없거나 품질 검증이 복잡해집니다.
- GPU가 이미 포화됨: 높은 QPS에서는 초안 계산이 배치 효율을 해칠 수 있습니다.
- 평균만 비교함: P95 지연시간과 긴 출력 요청을 별도로 확인해야 합니다.
- 버전별 제한을 무시함: Pipeline Parallel 등 기능 조합의 지원 여부가 바뀔 수 있습니다.
6. 적용 체크리스트
- 현재 병목이 Prefill인지 Decode인지 분리합니다.
- 실제 트래픽 표본으로 Baseline을 고정합니다.
- 가장 단순한 N-gram 또는 공식 지원 Speculator 하나만 추가합니다.
- 후보 수를 바꾸며 수락률·P95 TPOT·처리량을 기록합니다.
- 낮은 QPS와 피크 QPS를 각각 부하 테스트합니다.
- 이득이 확인된 조합만 카나리 인스턴스에 배포합니다.
공식 자료
정리: Speculative Decoding은 체크박스 하나로 모든 서버를 가속하는 기능이 아닙니다. Decode 병목, 낮은 QPS, 높은 후보 수락률이 겹칠 때 강력합니다. 가장 중요한 작업은 기능을 켜는 것이 아니라 실제 트래픽으로 수락률과 P95 지연시간을 측정하는 것입니다.
'AI·LLM 엔지니어링' 카테고리의 다른 글
| RAG Reranker 완전정리 — Bi-Encoder·Cross-Encoder 2단계 검색 설계 (0) | 2026.07.26 |
|---|---|
| RAG Hybrid Search 실전 가이드 — Dense·BM25·RRF로 검색 정확도 높이기 (0) | 2026.07.26 |
| vLLM Structured Outputs 완전정리 — JSON Schema·Regex·Grammar로 출력 고정하기 (0) | 2026.07.26 |
| 임베딩 모델 선택과 평가 — Cosine·Recall@k·MRR·nDCG 실전 기준 (0) | 2026.07.26 |
| vLLM KV Cache 완전정리 — 메모리 계산·Prefix Caching·FP8 튜닝법 (2) | 2026.07.26 |