Speculative Decoding 적용 방법: Draft Model, Medusa, EAGLE, 모델별 특징 정리

Speculative Decoding 적용 방법: Draft Model, Medusa, EAGLE, 모델별 특징 정리

1편에서는 speculative decoding의 핵심 원리를 정리했다. 작은 예측자가 여러 토큰 후보를 먼저 만들고, 큰 target model이 그 후보를 한 번에 검증해서, 최종 출력 분포를 유지하면서 decoding step 수를 줄이는 방식이다.

2편에서는 이 원리를 실제 시스템에 어떻게 적용하는지 정리한다. 중심 질문은 하나다.

Speculative decoding은 어떤 방식으로 후보 토큰을 만들고, 어떤 모델에서 잘 동작하며, 실무에서는 무엇을 측정해야 하는가.

이 글은 적용 방법을 기능 목록처럼 나열하지 않는다. 연구자들이 어떤 문제를 마주했고, 그 문제를 풀기 위해 어떤 구조가 등장했는지 순서대로 정리한다. speculative decoding은 단순한 추론 옵션이 아니라, autoregressive generation의 병목을 줄이기 위한 여러 연구 흐름이 모인 결과로 보는 편이 정확하다.

그림 1. speculative decoding 적용 방식은 후보 토큰을 어디서 만드는지에 따라 나뉜다.

1. 적용 방법을 나누는 기준

Speculative decoding의 적용 방식은 후보 토큰을 누가, 어떤 정보로, 어떤 비용에 만드는지에 따라 나뉜다.

가장 기본적인 방식은 작은 draft model을 따로 두는 것이다. draft model은 target model보다 작고 빠르며, target model이 생성할 가능성이 높은 토큰 후보를 여러 개 만든다. target model은 그 후보들을 한 번의 forward pass로 검증한다.

다른 방식은 별도의 작은 모델을 두지 않는다. prompt 안에서 반복되는 토큰 패턴을 재사용하거나, target model 내부에 여러 토큰을 예측하는 head를 붙이거나, hidden state 같은 중간 feature를 이용해 다음 후보를 만든다.

적용 방식은 크게 네 가지로 정리할 수 있다.

• 작은 draft model을 붙이는 방식
• n-gram 또는 prompt lookup 방식
• Medusa 계열의 multi-token prediction head 방식
• EAGLE 계열의 feature-level drafting 방식

이 네 방식은 같은 문제를 겨냥한다. target model을 매 토큰마다 깊게 실행하는 비용을 줄이는 것이다. 다만 후보를 만드는 위치와 비용이 다르기 때문에 장단점도 달라진다.

2. 연구 흐름: 작은 모델에서 내부 예측자로 이동했다

Speculative decoding의 초기 형태는 작은 모델과 큰 모델을 함께 쓰는 구조에서 출발했다. Fast Inference from Transformers via Speculative Decoding은 approximation model이 여러 토큰을 제안하고, target model이 이를 검증하는 방식으로 동일한 분포의 출력을 유지하면서 추론을 가속할 수 있음을 보였다.

비슷한 시기에 Accelerating Large Language Model Decoding with Speculative Sampling은 speculative sampling을 통해 target model의 분포를 보존하면서 여러 후보 토큰을 처리하는 절차를 정리했다. 이 흐름에서 중요한 지점은 속도를 위해 작은 모델의 출력을 그대로 믿지 않는다는 점이다. 최종 출력은 target model의 검증 절차를 통과해야 한다.

이후 연구는 두 방향으로 확장됐다. 하나는 draft model을 어떻게 더 싸고 잘 맞게 만들 것인가이다. 다른 하나는 별도 draft model 없이 target model 내부에서 여러 토큰 후보를 만들 수 있는가이다.

Medusa는 target model 위에 여러 decoding head를 붙여 다음 여러 위치의 토큰을 예측하는 방향을 제안했다. 별도 draft model을 운영하지 않고, target model 내부 표현을 이용해 후보를 만든다는 점이 중요하다.

EAGLE은 토큰 자체보다 feature 수준에서 다음 상태를 예측하는 방식으로 접근한다. 토큰 불확실성보다 feature 불확실성을 다루는 쪽이 speculative sampling에 더 유리하다는 문제의식에서 출발한다.

정리하자면 연구 흐름은 작은 보조 모델을 붙이는 구조에서, target model 내부 정보와 중간 feature를 더 적극적으로 재사용하는 구조로 이동했다. 이유는 단순하다. draft가 싸야 하고, target과 잘 맞아야 하며, 운영 복잡도도 낮아야 하기 때문이다.

3. 방식 1: 작은 draft model을 붙이는 방식

가장 표준적인 구조는 target model과 draft model을 따로 두는 방식이다.

예를 들어 target model이 70B 모델이라면 draft model은 같은 계열의 7B, 3B, 1B 모델이 될 수 있다. draft model은 빠르게 여러 토큰을 제안하고, target model은 이 후보 토큰을 검증한다.

흐름은 다음과 같다.

1. 현재까지의 prefix가 있다.
2. draft model이 앞으로 올 토큰 후보를 k개 만든다.
3. target model이 prefix와 draft 후보 전체를 입력으로 받아 각 위치의 확률을 계산한다.
4. target model의 분포 기준으로 후보를 accept 또는 reject한다.
5. reject가 발생하면 target model 분포에서 보정 토큰을 샘플링한다.
6. 확정된 토큰을 prefix에 붙이고 다음 라운드로 넘어간다.

그림 2. 작은 draft model 방식은 후보 생성과 target 검증을 분리한다.

이 방식의 장점은 개념이 명확하다는 점이다. 작은 모델이 초안을 쓰고, 큰 모델이 검토한다. 초보자에게 가장 설명하기 쉬운 구조도 이 방식이다.

단점은 운영 비용이다. 모델이 두 개 필요하다. draft model도 GPU 메모리를 사용하고, 배포 파이프라인도 추가된다. target model과 tokenizer가 맞아야 하고, 모델 계열이 다르면 후보 품질이 떨어질 수 있다.

가장 중요한 지표는 accept rate다. draft model이 target model과 비슷한 예측을 자주 하면 accept rate가 올라간다. accept rate가 높을수록 target model 한 번의 검증으로 더 많은 토큰을 확정할 수 있다.

반대로 draft model이 target model과 자주 어긋나면 이점이 줄어든다. draft model을 실행하는 비용은 계속 발생하는데, target model이 후보를 많이 거절하면 실제로 확정되는 토큰 수가 적어진다.

작은 draft model 방식은 다음 조건에서 유리하다.

• target model이 충분히 크고 한 토큰 생성 비용이 높다.
• draft model이 target model과 같은 계열이거나 분포가 잘 맞는다.
• 출력이 비교적 예측 가능해 accept rate가 높다.
• GPU 메모리에 draft model을 함께 올릴 여유가 있다.
• serving stack이 두 모델 실행을 안정적으로 다룰 수 있다.

이 방식은 다음 조건에서 불리하다.

• target model이 이미 작아서 한 토큰 비용이 낮다.
• draft model의 품질이 낮아 reject가 자주 발생한다.
• 메모리 여유가 부족해 draft model을 올리는 것 자체가 병목이다.
• 요청 길이와 batch 패턴이 불규칙해 스케줄링 비용이 커진다.

4. 방식 2: n-gram 또는 prompt lookup 방식

n-gram 또는 prompt lookup 방식은 별도 모델을 두지 않는다. 이미 입력 prompt나 이전 출력에 등장한 토큰 조각을 후보로 재사용한다.

아이디어는 단순하다. 문서 요약, 코드 편집, 긴 컨텍스트 질의응답에서는 입력에 있는 표현이 출력에 다시 나타나는 경우가 많다. 이때 작은 신경망 모델을 새로 실행하지 않고, prompt 안에서 이어질 법한 토큰 시퀀스를 찾아 draft 후보로 쓴다.

예를 들어 입력 문서에 “speculative decoding은 draft model과 target model을 사용한다”라는 문장이 있고, 출력이 같은 표현을 반복할 가능성이 높다면 prompt lookup은 그 뒤에 올 토큰을 후보로 제안할 수 있다.

이 방식의 장점은 비용이 매우 낮다는 점이다. 별도 draft model이 필요 없다. GPU 메모리도 거의 추가로 쓰지 않는다. 구현도 상대적으로 가볍다.

단점은 적용 범위가 좁다는 점이다. prompt 안에 재사용할 만한 패턴이 없으면 좋은 후보를 만들기 어렵다. 창의적인 생성, 일반 대화, 추론형 답변에서는 accept rate가 낮아질 수 있다.

Hugging Face Transformers의 generation 전략 문서는 prompt lookup decoding을 입력에서 겹치는 n-gram을 찾아 후보 토큰으로 사용하는 방식으로 설명한다. 이 방식은 특히 입력과 출력 사이의 복사 또는 부분 반복이 많은 작업에서 의미가 있다.

prompt lookup 방식은 다음 조건에서 유리하다.

• 요약처럼 입력 문서의 표현이 출력에 많이 재사용된다.
• 코드 생성이나 코드 수정처럼 기존 코드 조각이 반복된다.
• 별도 draft model을 올릴 메모리 여유가 없다.
• 낮은 운영 복잡도가 중요하다.

이 방식은 다음 조건에서 불리하다.

• prompt와 출력의 어휘나 문장 구조가 크게 다르다.
• 대화형 답변처럼 새 문장을 계속 구성해야 한다.
• 입력이 짧아 lookup 후보가 거의 없다.
• 반복 후보가 많지만 실제 target 분포와 잘 맞지 않는다.

n-gram 계열은 speculative decoding의 가장 단순한 적용으로 볼 수 있다. 성능 상한은 낮을 수 있지만, 비용이 작고 실패해도 시스템 복잡도를 크게 늘리지 않는다.

5. 방식 3: Medusa 계열의 multi-token prediction head

Medusa 계열은 별도 draft model을 두는 대신 target model 위에 여러 개의 예측 head를 붙인다. 각 head는 다음 한 토큰만 보는 것이 아니라, 앞으로 몇 번째 위치의 토큰을 예측한다.

기본 언어 모델 head가 다음 토큰을 예측한다면, Medusa head는 다음과 같은 식으로 동작한다.

• head 1: 다음 1번째 토큰 후보를 예측한다.
• head 2: 다음 2번째 토큰 후보를 예측한다.
• head 3: 다음 3번째 토큰 후보를 예측한다.
• head 4: 다음 4번째 토큰 후보를 예측한다.

이렇게 얻은 후보들은 tree 형태로 조합될 수 있다. target model은 이 후보 tree를 검증하면서 여러 토큰을 한 번에 확정하려고 한다.

Medusa의 핵심은 draft model을 외부에 하나 더 두지 않는다는 점이다. target model의 hidden state를 공유하고, 그 위에 붙은 head가 여러 위치의 후보를 만든다. 따라서 별도 모델을 서빙하는 부담이 줄어든다.

다만 이 방식은 추가 학습이 필요하다. 여러 head가 미래 토큰을 잘 예측하도록 학습해야 한다. target model에 head를 붙이고 학습하는 과정이 필요하므로, 단순히 설정값만 켜는 방식과는 다르다.

Medusa 방식은 다음 조건에서 유리하다.

• target model을 수정하거나 추가 학습할 수 있다.
• 별도 draft model 운영을 피하고 싶다.
• 같은 모델 내부 표현을 써서 후보를 만들고 싶다.
• 특정 모델을 장기간 안정적으로 서빙한다.

이 방식은 다음 조건에서 불리하다.

• 폐쇄형 모델처럼 내부 구조를 수정할 수 없다.
• 모델별로 head 학습과 검증을 반복하기 어렵다.
• 다양한 모델을 빠르게 교체해야 하는 운영 환경이다.
• 추가 학습 데이터와 평가 파이프라인이 부족하다.

Medusa는 speculative decoding을 단순히 “작은 모델을 붙이는 기법”에서 “모델 내부에 빠른 후보 생성기를 넣는 기법”으로 확장한 사례다.

6. 방식 4: EAGLE 계열의 feature-level drafting

EAGLE 계열은 토큰 후보를 바로 예측하는 대신 feature 수준의 다음 상태를 예측한다. 여기서 feature는 모델 내부 hidden state에 가까운 표현으로 이해하면 된다.

토큰은 이산적이다. 특정 위치에서 가능한 토큰은 vocabulary 전체에 걸쳐 분포한다. 이 분포는 불확실성이 크다. 반면 hidden feature는 다음 상태에 대한 더 연속적인 정보를 담고 있으므로, 미래를 예측하는 다른 경로가 가능하다.

EAGLE의 문제의식은 여기서 출발한다. speculative sampling에서 어려운 부분은 draft가 target과 잘 맞는 후보를 만드는 것이다. EAGLE은 토큰 자체를 바로 맞히는 대신, 다음 feature를 예측하고 그 feature로부터 후보 토큰을 구성하는 방향을 사용한다.

이 접근은 더 복잡하지만 장점도 있다. target model의 내부 표현을 활용하므로, 작은 독립 draft model보다 target model과 더 잘 맞는 후보를 만들 가능성이 있다. 또한 draft 단계에서 token-level uncertainty를 직접 다루는 부담을 줄일 수 있다.

EAGLE 방식은 다음 조건에서 유리하다.

• 모델 내부 feature를 활용할 수 있다.
• 높은 accept rate가 중요하다.
• 별도 draft model보다 target model과 밀접한 후보 생성기를 원한다.
• 연구 또는 고급 서빙 환경에서 모델별 최적화를 수행할 수 있다.

이 방식은 다음 조건에서 불리하다.

• 구현 난도가 낮아야 한다.
• 모델 내부 접근이 제한된다.
• 빠르게 여러 모델에 공통 적용해야 한다.
• feature 예측기의 학습과 검증을 운영하기 어렵다.

EAGLE은 speculative decoding의 방향이 점점 세밀해졌다는 점을 보여준다. 처음에는 작은 모델이 토큰을 대신 써 주는 구조였다. 이후에는 target model 내부 표현을 이용해, 더 잘 맞는 draft를 더 싸게 만드는 방향으로 연구가 이동했다.

7. 모델별 특징 1: Decoder-only LLM

GPT 계열, LLaMA 계열, Mistral 계열처럼 일반적인 chat LLM 대부분은 decoder-only 구조다. speculative decoding 연구와 구현도 주로 이 구조를 중심으로 발전했다.

decoder-only LLM에서는 prefix 뒤에 다음 토큰을 계속 붙인다. target model은 prefix와 draft 후보를 한 번에 입력받아 각 위치의 logits를 계산할 수 있다. 이 구조가 speculative verification과 잘 맞는다.

decoder-only 모델에서 중요한 변수는 KV cache다. LLM serving에서는 이미 생성된 토큰의 key-value를 cache로 저장해 다음 토큰 계산을 줄인다. speculative decoding은 한 번에 여러 후보 토큰을 검증하므로, KV cache 관리와 rollback 처리가 중요해진다.

accept된 토큰의 KV cache는 유지할 수 있다. reject된 후보 이후의 cache는 버리거나 다시 구성해야 한다. 이 과정이 비효율적이면 speculative decoding의 이점이 줄어든다.

decoder-only 모델은 speculative decoding 적용이 가장 자연스러운 대상이다. 다만 모델 크기, batch size, draft 품질, cache 관리에 따라 실제 성능 차이가 크게 난다.

8. 모델별 특징 2: Code LLM

Code LLM에서는 speculative decoding이 특히 유리할 수 있다. 코드는 자연어보다 반복 구조가 많고, 문법적 제약이 강하며, indentation, 괄호, import, 함수명, 변수명 같은 패턴이 자주 반복된다.

예를 들어 Python 코드를 작성할 때 다음 줄의 들여쓰기, 닫는 괄호, 반복되는 변수명은 비교적 예측 가능하다. draft model이나 prompt lookup 방식이 target model과 같은 후보를 낼 가능성이 높아진다.

코드 작업에서는 입력 컨텍스트의 일부를 출력에서 그대로 재사용하는 경우도 많다. 코드 수정, 리팩터링, 테스트 생성에서는 기존 코드의 함수명과 타입, 문자열이 반복된다. 이 때문에 prompt lookup 방식도 좋은 후보가 될 수 있다.

다만 code LLM에서 항상 좋은 결과가 나오는 것은 아니다. 작은 차이가 오류로 이어질 수 있기 때문이다. accept/reject 절차가 target model 분포를 보존하더라도, 서빙 시스템 관점에서는 stop sequence, indentation, streaming chunk 경계, tool call 포맷을 세밀하게 관리해야 한다.

Code LLM에서 봐야 할 지표는 단순 tokens per second만이 아니다. 다음 항목을 함께 봐야 한다.

• accept rate
• end-to-end latency
• first token latency
• 코드 블록 완성률
• syntax error 비율
• stop sequence 처리 안정성
• 긴 파일 컨텍스트에서의 cache 효율

코드 생성은 speculative decoding의 좋은 적용 대상이지만, 품질 평가는 문자열 유사도보다 실행 가능성과 포맷 안정성까지 포함해야 한다.

9. 모델별 특징 3: Chat 및 instruction model

Chat model에서는 draft와 target의 정렬이 중요하다. 같은 base model 계열이라도 instruction tuning, RLHF, system prompt 처리 방식이 다르면 다음 토큰 분포가 달라질 수 있다.

예를 들어 target model은 정중한 문체와 안전 정책을 강하게 따르도록 학습되어 있는데, draft model은 base model에 가깝다면 후보가 자주 어긋날 수 있다. 이 경우 accept rate가 낮아지고 속도 이점이 줄어든다.

Chat model에서는 출력 형식도 중요하다. 일반 답변뿐 아니라 JSON, tool call, function call, XML-like tag, markdown table 같은 구조화 출력이 많다. draft가 형식을 잘 맞히면 이점이 커지지만, 형식이 조금만 어긋나도 reject가 자주 발생할 수 있다.

또한 sampling 설정의 영향을 크게 받는다. temperature가 높고 top-p가 넓으면 가능한 다음 토큰의 다양성이 커진다. draft model이 target model의 선택을 맞히기 어려워질 수 있다. 반대로 낮은 temperature나 deterministic한 설정에서는 accept rate가 높아질 가능성이 있다.

Chat model에서 적용할 때는 다음 항목을 분리해서 측정해야 한다.

• 일반 질의응답
• 긴 문서 기반 답변
• JSON 또는 tool call 생성
• 코딩 질문
• 다국어 대화
• 안전 정책이 개입되는 요청

하나의 평균 accept rate만 보면 위험하다. 실제 서비스 트래픽은 요청 유형별로 분포가 다르고, speculative decoding은 요청 유형에 따라 효과가 크게 달라질 수 있다.

10. 모델별 특징 4: Multilingual model

Multilingual model에서는 언어별 accept rate가 달라질 수 있다. 이유는 토큰화, 학습 데이터 분포, 문장 구조가 언어마다 다르기 때문이다.

영어는 많은 tokenizer에서 상대적으로 효율적으로 토큰화된다. 한국어, 일본어, 중국어, 아랍어 같은 언어는 tokenizer 구성에 따라 한 문장을 표현하는 토큰 수와 subword 경계가 달라진다. 같은 의미의 문장이라도 언어별 토큰 길이와 예측 난도가 다를 수 있다.

draft model이 영어 중심으로 잘 맞춰져 있다면 영어 요청에서는 accept rate가 높고, 다른 언어에서는 낮을 수 있다. 반대로 multilingual instruction tuning이 잘 된 draft model이라면 언어별 차이가 줄어들 수 있다.

한국어 같은 언어에서는 조사, 어미, 띄어쓰기, 한자어, 외래어 표기가 후보 예측에 영향을 줄 수 있다. target model이 선호하는 문체와 draft model이 선호하는 문체가 다르면 표면적으로는 비슷한 의미라도 토큰 단위 accept가 낮아질 수 있다.

Multilingual model에서 필요한 평가는 다음과 같다.

• 언어별 accept rate
• 언어별 tokens per second
• 언어별 평균 출력 길이
• tokenizer 기준 토큰 수 대비 문자 수
• 번역, 요약, 대화, 코드 혼합 요청의 분리 평가
• 한국어와 영어가 섞인 요청에서의 안정성

다국어 모델에서는 전체 평균보다 언어별 분포를 보는 것이 더 중요하다. 특정 언어에서만 속도가 빨라지고 다른 언어에서는 효과가 거의 없을 수 있다.

11. 모델별 특징 5: Encoder-decoder model

T5, BART 같은 encoder-decoder 모델은 입력을 encoder가 먼저 처리하고, decoder가 출력 토큰을 생성한다. speculative decoding은 decoder 쪽 autoregressive generation에 적용할 수 있다.

encoder-decoder 구조에서는 encoder output이 고정된 조건으로 작동한다. decoder는 이전 출력 토큰과 encoder output을 함께 참조해 다음 토큰을 만든다. 따라서 draft와 target이 encoder output을 어떻게 활용하는지가 중요하다.

작은 draft model을 붙이는 경우, draft model도 같은 입력 조건을 반영해야 한다. 입력 문서의 세부 내용을 draft가 제대로 반영하지 못하면 요약이나 번역에서 후보가 target과 어긋날 수 있다.

encoder-decoder 모델은 문서 요약, 번역, 변환 작업에 많이 쓰인다. 이런 작업에서는 입력 표현이 출력에 반영되는 정도가 높기 때문에 prompt lookup류의 단순 방식과 결합할 여지도 있다. 다만 decoder-only LLM serving stack에 비해 구현 경로가 다를 수 있다.

encoder-decoder 모델에서는 다음 항목을 봐야 한다.

• encoder output 재사용 비용
• decoder speculative verification 구현 방식
• 번역 언어쌍별 accept rate
• 요약 길이별 속도 변화
• 입력 길이가 길 때 encoder 비용이 전체 latency에서 차지하는 비중

입력이 매우 길고 출력이 짧은 작업에서는 decoder 가속의 체감 효과가 제한될 수 있다. speculative decoding은 주로 출력 토큰을 많이 생성할수록 유리하기 때문이다.

12. 모델별 특징 6: MoE 모델

MoE 모델은 토큰마다 일부 expert만 활성화하는 구조를 사용한다. Mixtral 같은 sparse MoE 모델은 모든 파라미터를 매번 쓰지 않기 때문에 dense model과 다른 추론 특성을 가진다.

MoE에서 speculative decoding을 적용할 때는 routing이 변수가 된다. draft 후보가 target model에서 어떤 expert 경로를 타는지, accept와 reject에 따라 cache와 expert 실행이 어떻게 관리되는지가 중요하다.

MoE target model에 작은 dense draft model을 붙일 수도 있다. 이 경우 draft는 빠르게 후보를 만들지만, target의 expert routing과 분포를 충분히 잘 맞혀야 한다. target이 특정 토큰에서 선택하는 expert와 logits 분포가 draft와 잘 맞지 않으면 accept rate가 낮아질 수 있다.

MoE 모델에서는 GPU 간 통신도 중요하다. expert parallelism을 쓰는 경우 expert가 여러 장비에 나뉘어 있을 수 있다. speculative decoding이 target forward 횟수를 줄이더라도, 후보 검증 과정에서 통신 패턴이 복잡해지면 이점이 줄어들 수 있다.

MoE 모델에서 봐야 할 지표는 다음과 같다.

• accept rate
• expert load balance
• GPU 간 communication overhead
• batch size별 throughput
• cache memory 사용량
• reject 이후 rollback 비용

MoE에서 speculative decoding은 가능하지만, dense decoder-only 모델보다 시스템 관점의 변수가 더 많다.

그림 3. 모델 종류에 따라 accept rate와 운영 변수의 의미가 달라진다.

13. vLLM에서 적용할 때 보는 관점

vLLM의 speculative decoding 문서는 draft model, n-gram proposer 등 여러 speculative decoding 관련 옵션을 다룬다. vLLM 관점에서 중요한 점은 단순히 옵션을 켜는 것이 아니라 serving scheduler, KV cache, batch 처리와 함께 봐야 한다는 것이다.

vLLM 같은 serving engine에서는 여러 요청을 동시에 처리한다. speculative decoding은 한 요청 안에서 여러 후보 토큰을 만들고 검증하므로, batch 구성과 스케줄링에 영향을 준다.

단일 요청 benchmark에서는 속도가 빨라졌는데 실제 서비스에서는 이점이 줄어드는 경우가 있다. 이유는 여러 요청이 섞이면 GPU utilization, memory bandwidth, cache allocation, request length 분포가 함께 영향을 받기 때문이다.

vLLM에서 확인해야 할 항목은 다음과 같다.

• draft model을 GPU에 함께 올릴 수 있는가
• target model과 draft model의 tokenizer가 호환되는가
• n-gram proposer로 충분한 효과가 나는 작업인가
• batch size가 커질 때 speculative overhead가 어떻게 변하는가
• streaming 응답에서 first token latency가 나빠지지 않는가
• 긴 컨텍스트에서 KV cache memory가 부족해지지 않는가

실무에서는 “speculative decoding을 켰다”가 끝이 아니다. 요청 분포별 benchmark를 만들어야 한다. 짧은 대화, 긴 문서 요약, 코드 생성, JSON 출력처럼 서로 다른 케이스를 분리해야 한다.

14. Hugging Face Transformers에서 적용할 때 보는 관점

Hugging Face의 assisted generation 소개는 작은 assistant model이 후보 토큰을 만들고 큰 모델이 검증하는 흐름을 설명한다. Transformers에서는 assisted generation, prompt lookup decoding 같은 형태로 speculative decoding 계열 기능을 접할 수 있다.

Hugging Face 환경은 실험에 좋다. 여러 모델 조합을 빠르게 바꿔 보면서 accept rate와 latency를 측정할 수 있다. 다만 production serving과 같은 성능이 나온다고 바로 가정하면 안 된다.

로컬 실험에서 확인할 항목은 다음과 같다.

• target model과 assistant model의 tokenizer 호환성
• assistant model 크기에 따른 latency 변화
• draft token 수에 따른 accept rate 변화
• temperature, top-p 설정 변화
• prompt 길이와 출력 길이 변화
• GPU memory 사용량

Hugging Face에서 좋은 결과가 나온 조합이라도 vLLM, TensorRT-LLM, custom serving으로 옮기면 결과가 달라질 수 있다. serving engine마다 batching, cache, kernel, memory allocation 전략이 다르기 때문이다.

15. 설정값을 이해하는 방법

Speculative decoding에서 자주 조정하는 값은 draft token 수다. 한 번에 몇 개의 후보 토큰을 제안할지 정하는 값이다.

이 값을 크게 하면 target model 한 번의 검증으로 더 많은 토큰을 확정할 가능성이 생긴다. 하지만 draft가 틀릴 가능성도 함께 커진다. 앞쪽 후보에서 reject가 발생하면 뒤쪽 후보는 활용되지 못할 수 있다.

따라서 draft token 수는 크게 잡을수록 무조건 좋은 값이 아니다. accept rate가 높은 작업에서는 크게 잡는 것이 유리할 수 있지만, accept rate가 낮은 작업에서는 오히려 낭비가 커진다.

핵심 설정은 다음과 같이 이해하면 된다.

• draft token 수: 한 라운드에서 몇 개 후보를 만들지 정한다.
• draft model 크기: 후보 생성 비용과 후보 품질 사이의 균형을 정한다.
• temperature: 샘플링의 다양성을 바꾸며 accept rate에 영향을 준다.
• top-p, top-k: 후보 분포의 폭을 바꾸며 draft와 target의 일치 가능성에 영향을 준다.
• batch size: GPU 효율과 scheduling overhead를 함께 바꾼다.
• max sequence length: KV cache memory와 long-context 효율에 영향을 준다.

실무에서는 이 값을 하나씩만 바꿔야 한다. 여러 값을 동시에 바꾸면 어떤 요인이 속도와 품질에 영향을 줬는지 분리하기 어렵다.

16. 실무 평가 지표

Speculative decoding은 tokens per second 하나로 판단하면 안 된다. target model forward 횟수는 줄었지만 first token latency가 늘거나, tail latency가 나빠지거나, GPU memory가 부족해질 수 있다.

기본 지표는 다음과 같다.

• accept rate: draft 후보 중 target이 받아들인 비율
• accepted tokens per step: target 검증 한 번당 확정된 평균 토큰 수
• output tokens per second: 최종 출력 기준 처리량
• end-to-end latency: 요청 시작부터 응답 완료까지 걸린 시간
• time to first token: streaming에서 첫 토큰이 나오기까지 걸린 시간
• p50, p95, p99 latency: 평균이 가리는 tail latency
• GPU utilization: 연산 자원이 실제로 쓰인 정도
• memory usage: target, draft, KV cache가 차지하는 메모리
• quality metric: 작업별 품질 변화 여부

품질 평가는 작업에 따라 다르게 잡아야 한다. 요약은 factuality와 coverage를 봐야 하고, 코드는 실행 가능성을 봐야 하며, JSON 출력은 schema validity를 봐야 한다.

accept/reject 절차가 이론적으로 target distribution을 보존하더라도, 실제 시스템에서는 구현, sampling 설정, stop condition, tokenizer 처리, floating point 차이, serving scheduler가 결과에 영향을 줄 수 있다. 따라서 최종 평가는 실제 배포 환경에 가까운 조건에서 해야 한다.

그림 4. speculative decoding은 accept rate, latency, memory, 품질을 함께 봐야 한다.

17. 어떤 경우에 도입하면 좋은가

Speculative decoding은 다음 조건에서 도입 가치가 크다.

• target model이 커서 한 토큰 생성 비용이 높다.
• 출력 길이가 길다.
• draft가 target과 잘 맞아 accept rate가 높다.
• 코드, 요약, 문서 기반 답변처럼 반복 패턴이 있다.
• GPU memory와 serving stack이 추가 복잡도를 감당할 수 있다.
• 요청 유형별 benchmark와 회귀 테스트가 있다.

특히 긴 출력을 많이 생성하는 서비스에서는 효과를 보기 쉽다. target model 호출 한 번으로 여러 토큰을 확정할 수 있기 때문이다.

반대로 다음 조건에서는 신중해야 한다.

• 출력이 매우 짧다.
• target model이 작다.
• draft model을 올릴 메모리가 부족하다.
• 요청이 다양하고 sampling temperature가 높다.
• tool call, JSON, safety policy 등 형식 제약이 강하지만 draft가 이를 잘 맞히지 못한다.
• 운영팀이 accept rate와 latency를 지속적으로 관찰할 수 없다.

Speculative decoding은 만능 가속 스위치가 아니다. 맞는 조건에서는 강력하지만, 맞지 않는 조건에서는 복잡도만 늘릴 수 있다.

18. 적용 순서

처음부터 Medusa나 EAGLE 같은 구조를 바로 적용할 필요는 없다. 실무에서는 단순한 순서로 접근하는 편이 안전하다.

첫 번째는 현재 serving baseline을 측정하는 것이다. speculative decoding을 켜기 전의 latency, throughput, GPU utilization, memory usage를 알아야 한다.

두 번째는 요청 유형을 나누는 것이다. 일반 대화, 긴 요약, 코드 생성, JSON 출력, 다국어 요청을 섞어서 평균을 내면 판단이 흐려진다.

세 번째는 가장 낮은 복잡도의 방법부터 실험하는 것이다. 입력 반복이 많은 작업이면 prompt lookup 또는 n-gram proposer를 먼저 본다. target model이 크고 호환되는 작은 모델이 있다면 draft model 방식을 실험한다.

네 번째는 accept rate를 중심 지표로 둔다. accept rate가 낮으면 speculative decoding의 구조적 이점이 작다. 이때는 draft model 크기, 계열, tokenizer, sampling 설정을 조정한다.

다섯 번째는 production-like benchmark를 돌린다. 단일 요청 실험에서 좋아 보여도, 실제 batch와 streaming 조건에서는 결과가 달라질 수 있다.

마지막으로 모델 내부 수정이 가능한 환경에서 Medusa나 EAGLE 계열을 검토한다. 이 단계는 단순 옵션 적용이 아니라 모델별 최적화에 가깝다.

19. 한 장으로 정리하는 선택 기준

적용 방식을 고르는 기준은 다음과 같다.

이 표에서 중요한 것은 절대적인 우열이 아니다. speculative decoding은 모델, 데이터, serving 환경이 맞아야 효과가 난다. 따라서 방식 선택은 성능 수치보다 조건 매칭의 문제에 가깝다.

20. 정리

Speculative decoding의 적용 방법은 “작은 모델을 붙인다” 하나로 끝나지 않는다. 연구는 draft를 더 싸게 만들고, target과 더 잘 맞게 만들고, 운영 복잡도를 줄이는 방향으로 발전해 왔다.

작은 draft model 방식은 가장 기본적인 구조다. n-gram과 prompt lookup은 별도 모델 없이 반복 패턴을 활용한다. Medusa는 target model 내부에 여러 token prediction head를 붙인다. EAGLE은 feature 수준에서 draft를 만들어 token-level uncertainty를 줄이려 한다.

모델별로도 차이가 크다. decoder-only LLM은 가장 자연스럽게 맞고, code LLM은 반복 구조 덕분에 유리할 수 있다. chat model은 instruction 정렬과 sampling 설정이 중요하다. multilingual model은 언어별 토큰화와 문체 차이를 따로 봐야 한다. encoder-decoder와 MoE 모델은 구조적 특성 때문에 추가 고려가 필요하다.

실무에서 핵심은 기능을 켜는 것이 아니다. accept rate, latency, throughput, memory, 품질을 요청 유형별로 측정하는 것이다. speculative decoding은 연구자들이 autoregressive generation의 병목을 줄이기 위해 쌓아 온 방법이고, 실제 시스템에서는 그 조건이 맞을 때 강력한 가속 기법이 된다.