추측 디코딩은 왜 작은 모델 하나로 끝나지 않을까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: LLM 응답이 느릴 때 speculative decoding을 켜면 항상 빨라질까, 아니면 먼저 확인해야 할 조건이 있을까?
• 핵심 출처:
  • Speculative Decoding - vLLM - 게시일 미표기, 2026-06-16 확인
  • Speculative Sampling — TensorRT-LLM - 게시일 미표기, 2026-06-16 확인
  • Speculative Decoding - SGLang - 게시일 미표기, 2026-06-16 확인
  • Fast Inference from Transformers via Speculative Decoding - 2022-11-30 초판, 2026-06-16 확인

1. 왜 지금 봐야 하나

LLM 서비스를 운영하다 보면 “모델을 더 작게 바꿀까?”, “GPU를 더 붙일까?”, “스트리밍이면 괜찮지 않을까?” 같은 질문이 반복된다. 그런데 사용자가 실제로 체감하는 불편은 대부분 토큰이 한 글자씩 너무 천천히 나오는 구간에서 생긴다. 첫 토큰이 늦는 문제는 prefill, 큐 대기, 캐시 미스와 관련이 크지만, 이미 생성이 시작된 뒤의 속도는 decode 단계의 순차성이 크게 좌우한다.

Speculative decoding, 한국어로는 보통 추측 디코딩 또는 추론적 디코딩이라고 부르는 기법은 이 순차성을 줄이려는 방법이다. vLLM 문서는 이 기능을 “medium-to-low QPS, memory-bound workload에서 inter-token latency를 줄이는 방법”으로 설명한다. TensorRT-LLM 문서는 작은 배치에서 GPU가 덜 활용될 때 한 번의 forward pass로 여러 토큰을 진전시키는 기술군이라고 설명한다. SGLang도 EAGLE, MTP, standalone draft model, NGRAM 등 여러 방법을 지원하며 serving throughput을 높이는 고급 기능으로 다룬다.

중요한 점은 이것이 “작은 모델로 대충 먼저 답하게 하자”가 아니라는 것이다. 핵심은 빠른 제안자(draft/proposer)가 여러 토큰을 미리 내고, 원래 목표 모델(target)이 한 번에 검증해서 맞는 토큰만 받아들이는 구조다. 그래서 제품에 적용할 때는 “켜면 빨라진다”보다 “어떤 요청에서 draft가 잘 맞고, 검증 비용이 이득보다 작을까?”를 먼저 봐야 한다.

2. 핵심 개념

일반적인 autoregressive LLM은 다음 토큰을 하나 만들고, 그 토큰을 다시 입력에 붙여 다음 토큰을 만든다. 100개의 출력 토큰이 필요하면 원칙적으로 100번의 순차적인 decode step이 필요하다. GPU는 병렬 계산에 강하지만, 토큰 생성 의존성 때문에 매 step을 완전히 한 번에 처리하기 어렵다.

Speculative decoding은 이 문제를 두 단계로 나눈다.

1. 제안(propose): 작은 draft model, EAGLE/MTP head, NGRAM, suffix matcher 같은 빠른 방법이 앞으로 나올 법한 토큰 여러 개를 만든다.
2. 검증(verify): target model이 그 토큰 묶음을 한 번에 평가하고, target이 받아들일 수 있는 접두부만 확정한다.

비유하면 코드 자동완성에서 보조 개발자가 “아마 다음 5줄은 이럴 것 같습니다”라고 초안을 쓰고, 시니어 개발자가 한 번에 리뷰해서 앞부분 3줄은 승인하고 나머지는 버리는 식이다. 승인된 3줄만큼은 target model을 3번 순차 실행한 효과를 1번 검증에 가깝게 얻는다.

원 논문인 Fast Inference from Transformers via Speculative Decoding은 이 기법의 목표를 “출력 분포를 바꾸지 않고 여러 토큰을 병렬로 계산해 빠르게 샘플링하는 것”으로 설명한다. 따라서 올바르게 구현된 추측 디코딩은 단순 근사 생성이 아니다. target model이 최종 분포를 보존하도록 받아들이고 거절하는 절차가 핵심이다.

3. 최신 이슈와 연결

최근 서빙 엔진들이 speculative decoding을 단일 알고리즘이 아니라 방법 선택 문제로 문서화하는 흐름이 눈에 띈다.

vLLM은 draft model, EAGLE, MTP, PARD, MLP speculator 같은 모델 기반 방법과 N-gram, suffix decoding 같은 가벼운 방법을 나눠 설명한다. 문서상 모델 기반 방법은 보통 latency reduction이 크지만 별도 draft model이나 speculator가 필요하고, N-gram·suffix 계열은 이득이 작아도 peak traffic에서 부담이 덜하다고 정리한다.

TensorRT-LLM은 speculative sampling을 draft-target model, Medusa, ReDrafter, EAGLE, NGram, Lookahead Decoding 같은 기술군으로 설명한다. 특히 draft-target 방식은 draft와 target이 같은 vocabulary를 가져야 하며, draft가 만든 최대 K개 토큰을 target이 검증하고 최대 K+1개 토큰을 반환할 수 있다고 설명한다.

SGLang은 EAGLE-3를 “best speed/quality” 선택지로 안내하면서도, MTP head가 있는 모델, 작은 draft LLM이 있는 경우, 별도 모델이 없는 NGRAM, 실험적인 overlap scheduler 등 시나리오별 선택지를 분리한다. 즉 실전에서는 “speculative decoding 지원 여부”보다 “내 모델·요청·GPU·트래픽에서 어떤 proposer가 acceptance rate와 비용의 균형을 맞추는가”가 더 중요해졌다.

4. 개발자 관점 해석

개발자가 오해하기 쉬운 지점은 세 가지다.

첫째, 정확히 같은 품질을 공짜로 얻는 기능이 아니다. 검증 절차가 분포를 보존하더라도 실제 시스템에는 draft 모델 로딩, 추가 메모리, 스케줄링, KV cache 관리, 배치와의 상호작용이 붙는다. 이미 high QPS로 GPU가 꽉 찬 서비스라면 draft 작업이 오히려 경쟁 부하가 될 수 있다.

둘째, acceptance rate가 핵심 지표다. draft가 낸 토큰이 target에게 많이 받아들여질수록 순차 step을 절약한다. 반대로 draft가 자주 틀리면 target 검증을 해놓고도 한두 토큰만 진행하거나 바로 거절되어 이득이 사라진다. 코드, 반복적인 양식, 문서 QA처럼 다음 토큰 예측이 쉬운 작업은 유리할 수 있고, 창의적 글쓰기나 높은 temperature의 발산형 응답은 불리할 수 있다.

셋째, 작은 모델 선택은 tokenizer와 분포의 문제다. TensorRT-LLM 문서는 draft-target 방식에서 같은 vocabulary가 중요하다고 설명한다. NVIDIA TensorRT-LLM GitHub 문서도 draft와 target tokenizer가 다르면 acceptance rate가 극도로 낮아져 성능이 회귀할 수 있다고 경고한다. “작으면 빠르다”만 보고 draft를 고르면 검증에서 대부분 버려질 수 있다.

그래서 speculative decoding은 모델 선택 기능이라기보다 decode 병목을 acceptance rate로 바꾸는 서빙 최적화에 가깝다. 평균 latency 하나만 보지 말고 TPOT, output tokens/sec, acceptance rate, GPU utilization, batch size별 성능을 같이 봐야 한다.

5. 내 프로젝트에 적용할 체크포인트

• 현재 병목이 정말 decode 단계인가? TTFT가 아니라 TPOT 또는 inter-token latency가 문제인지 먼저 분리했는가?
• 트래픽이 low/medium QPS인지, high QPS로 GPU가 이미 포화되어 있는지 확인했는가?
• 출력 유형이 반복적·예측 가능한가? 코드 보완, 템플릿 작성, 문서 기반 답변, 요약처럼 draft가 맞히기 쉬운가?
• draft/proposer 후보가 target과 tokenizer 또는 vocabulary 조건을 만족하는가?
• 별도 draft model을 올릴 VRAM 여유가 있는가, 아니면 NGRAM/suffix 같은 모델 없는 방법이 더 안전한가?
• acceptance rate, accepted tokens per step, TPOT, GPU utilization을 실험 로그에 남기는가?
• batch size가 커질 때도 이득이 유지되는가, 아니면 작은 배치에서만 좋아지는가?
• sampling temperature, top-p, max tokens가 바뀌어도 acceptance rate가 급격히 무너지지 않는가?

6. 오늘 10분 액션

오늘은 코드부터 바꾸지 말고, 현재 LLM 기능 하나를 골라 아래 표를 채워보자.

항목	내 서비스 값
대표 요청 유형	예: 문서 QA, 코드 생성, 상담 요약
평균 입력 토큰
평균 출력 토큰
TTFT
TPOT 또는 tokens/sec
평균 batch size/QPS
GPU utilization
출력 반복성	낮음/중간/높음
speculative 후보	draft model / EAGLE·MTP / NGRAM·suffix / 보류

10분 안에 결론을 하나만 내리면 된다.

“우리 서비스는 speculative decoding 실험 후보인가, 아니면 먼저 prefill/queue/cache를 봐야 하는가?”

출력 토큰이 짧고 TTFT가 대부분이라면 오늘의 결론은 “아직 보류”가 맞다. 반대로 긴 답변을 스트리밍하고 TPOT가 느리며 QPS가 낮거나 중간이라면 작은 벤치마크를 만들 가치가 있다.

7. 더 볼 자료

• vLLM Speculative Decoding — vLLM에서 지원하는 draft model, EAGLE, MTP, N-gram, suffix 방식과 설정 키를 확인하기 좋다.
• TensorRT-LLM Speculative Sampling — draft/target 실행 흐름과 NGram, Medusa, EAGLE 같은 접근을 비교할 때 유용하다.
• SGLang Speculative Decoding — EAGLE-3, MTP, standalone, NGRAM 등 실제 서빙 엔진 관점의 선택지를 볼 수 있다.
• Fast Inference from Transformers via Speculative Decoding — “빠르지만 출력 분포는 바꾸지 않는다”는 원리를 이해하기 위한 원 논문이다.

중복 회피 메모

최근 ai_dev 글은 긴 컨텍스트 메모리, 에이전트 권한 계약, prefill/decode 분리, RAG 검색 품질, Tool Search, KV 캐시 양자화, 도구 선택 파인튜닝, LLM-as-judge 신뢰성을 다뤘다. 이번 글은 일반적인 prefill/decode 병목 분석이나 KV 캐시 메모리 절약을 반복하지 않고, decode 단계에서 여러 토큰을 제안·검증해 TPOT를 줄이는 speculative decoding의 적용 조건과 실패 모드에 집중한다.