스펙ulative 디코딩: 20~50% 더 빠른 LLM 추론

70B 모델은 포워드 패스당 1개의 토큰을 생성하며, 각 패스에서는 VRAM에서 가중치를 다시 로드하고, 컨텍스트에 대한 어텐션을 계산하며, 메모리를 동기화합니다. 토큰 사이에는 GPU가 순차적인 의존성이 해결되기를 기다리며 유휴 상태(idle)에 있게 됩니다.

H100에서 70B 모델은 30-50ms마다 1개의 토큰을 생성합니다. GPU에는 여러 토큰을 병렬로 처리할 수 있는 컴퓨트 용량이 충분하지만, 순차적인 의존성이 이를 방해합니다 — 각 토큰은 이전 토큰에 의존하므로 파이프라인이 멈추게 됩니다.

Speculative decoding(투기적 디코딩)은 출력 분포를 변경하지 않으면서, 원래 1개의 토큰을 생성하는 데 걸리는 시간 동안 여러 개의 토큰을 생성함으로써 이 병목을 해결합니다. 얻을 수 있는 토큰은 표준 자기회귀(autoregressive) 디코딩을 통해 얻을 수 있는 결과와 통계적으로 동일하며, 유일한 차이는 그들을 얼마나 빠르게 얻을 수 있는가 하는 점입니다.

이 가이드에서는 메커니즘, 2026년에 사용 가능한 변형, 수용률(acceptance rate)의 트레이드오프, 그리고 llama.cpp, vLLM, SGLang, TensorRT-LLM에서의 실제 설정을 다룹니다.

자기회귀 디코딩 작동 방식 (그리고 느린 이유)

투기적 디코딩을 이해하려면, 이 기술이 우회하는 자기회귀적 제약 조건을 먼저 이해해야 합니다. 표준 자기회귀 생성은 토큰을 순차적으로 처리합니다:

1. 현재 컨텍스트로 모델을 통해 포워드 패스를 실행합니다.
2. 출력 분포에서 다음 토큰을 샘플링합니다.
3. 해당 토큰을 컨텍스트에 추가합니다.
4. 반복합니다.

각 단계에는 완전한 포워드 패스가 필요합니다 — VRAM에서 가중치를 로드하고, 전체 컨텍스트에 대한 어텐션을 계산하여 단일 토큰을 생성하는 과정입니다. 70B 매개변수를 가진 모델의 경우, H100에서 토큰당 대략 30-50ms가 소요됩니다. GPU에는 여유로운 컴퓨트 용량이 있지만 — 병렬로 더 많은 작업을 처리할 수 있지만 — 순차적인 의존성이 이를 막습니다.

컴퓨트-VRAM 갭

모던 GPU는 단일 토큰 생성에 필요한 것보다 더 많은 FLOPS를 가지고 있으므로, 실제 병목은 메모리 대역폭입니다 — 각 포워드 패스마다 가중치를 VRAM에서 컴퓨트 유닛으로 스트리밍해야 하기 때문입니다. 한 번에 하나의 토큰만 생성할 때, GPU는 유용한 컴퓨트를 하는 대신 메모리 전송을 기다리는 데 대부분의 시간을 씁니다.

투기적 디코딩은 메모리 전송당 GPU가 처리하는 작업량을 늘려서 이 문제를 해결합니다. 포워드 패스당 1개의 토큰 대신 K개의 토큰을 생성하여, 메모리 비용을 여러 출력에 걸쳐 분배(amortize)합니다.

Draft-Verify 메커니즘

투기적 디코딩은 반복되는 Draft(초안)-Verify(검증) 사이클로 작동합니다. 빠른 Draft 메커니즘은 K개의 후보 토큰을 제안합니다 — 작은 Draft 모델, n-gram 조회, 또는 대상(target) 모델에 부착된 예측 헤드(prediction head)를 통해 — 그리고 대상 모델은 단일 포워드 패스에서 이 K개를 모두 검증합니다. Draft 단계는 저렴하며, 일반적으로 대상 모델 포워드 패스 시간의 5-20%를 차지합니다. 반면, 검증 단계에서는 각 Draft된 토큰을 대상 모델이 생성했을 결과와 비교하여, 가장 긴 일치하는 접두사(prefix)를 수락하고 첫 번째 거부(rejection) 지점부터 다시 샘플링합니다.

K개의 토큰을 검증하는 비용은 자기회귀적으로 하나의 토큰을 생성하는 비용과 거의 동일하므로, Draft가 정확할 경우 1회 검증 단계의 비용으로 K개의 토큰을 얻을 수 있습니다.

구체적 예시

Draft 모델이 5개의 토큰을 제안했다고 가정해 보겠습니다: ["I", " like", " cooking", " and", " traveling"]. 대상 모델은 단일 포워드 패스로 이를 검증합니다:

대상 모델은 토큰 1과 2를 수락하고, 토큰 3에 대해서는 " playing"을 생성하여, 세 번의 별도 포워드 패스 대신 한 사이클에서 세 개의 토큰을 생성합니다. 만약 Draft가 토큰 5까지 정확했다면, 1회 검증의 비용으로 5개의 토큰을 얻게 되며, 그 사이클에서만 5배의 가속 효과를 얻게 됩니다.

검증의 병목

실제로, 실행 시간의 대부분(메서드와 모델 크기에 따라 42-95%)을 검증이 차지합니다. 대상 모델의 포워드 패스가 병목이며, 거부된 토큰은 낭비된 컴퓨트를 의미합니다.

이것이 수용률이如此 중요한 이유입니다. 첫 번째 이후의 모든 거부된 토큰은 낭비된 검증 작업입니다. 가장 좋은 투기적 디코딩 메서드는 단순히 원시 수용률만 최대화하는 것이 아니라, 사이클당 기대되는 수락 토큰 수를 최대화합니다.

수학적 보장

투기적 디코딩의 가장 중요한 특성 중 하나는 대상 모델에 대한 표준 자기회귀 샘플링과 동일한 분포에서 토큰을 생성한다는 것입니다. 검증 단계는 거부 샘플링(rejection sampling)을 사용합니다 — Draft가 토큰 x를 제안할 때, 대상 모델은 자신의 확률 p(x)를 계산하고 Draft는 p_draft(x)를 계산합니다. 수용 확률은 다음과 같습니다:

min(1, p(x) / p_draft(x))

대상이 동의할 때 (p(x) ≥ p_draft(x)), 토큰은 항상 수락됩니다. 대상이不同意할 때, 토큰은 비율에 비례하는 확률로 수락되고, 거부된 토큰은 잔여 분포(residual distribution)에서 다시 샘플링됩니다:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

이 절차는 출력 시퀀스가 대상 모델의 분포를 정확히 따르도록 보장하며, 이것이 투기적 디코딩이 손실 없이(lossless) 작동하는 이유입니다. Draft 모델은 품질이 아닌 속도에 영향을 미칩니다 — 얻는 토큰은 표준 디코딩과 통계적으로 구별할 수 없으며, 동일한 퍼플렉시티(perplexity)와 분포를 가집니다. 유일한 차이는 지연 시간(latency)입니다.

Draft 모델 전략

Draft 메커니즘은 가장 중요한 변수입니다. 다른 접근 방식들은 설정 복잡도, 수용률, 가속 효과 사이의 트레이드오프가 다릅니다.

독립 Draft 모델

가장 단순한 접근 방식은 대상 모델과 함께 더 작은 모델을 로드하는 것입니다 — 일반적으로 1B-3B 모델이 7B-70B 대상 모델의 Draft를 만드는 경우입니다.

장점:

• 개념적으로 직관적이고 단순함
• 어떤 대상 모델과도 작동함
• 대상 모델의 분포에 맞춰 Draft 모델을 튜닝 가능

단점:

• VRAM에 두 번째 모델을 로드해야 함 (크기에 따라 1-4 GB)
• Draft 모델의 품질이 수용률을 직접 결정함
• 크로스 패밀리 Draft (예: Llama를 위한 Qwen Draft)는 일반적으로 성능이 낮음

실용적 규칙: 같은 패밀리의 모델을 사용하십시오. Gemma 2 2B는 Gemma 2 27B의 Draft로 잘 작동합니다. Llama 3.2 1B는 Llama 3.1 70B의 Draft로 잘 작동합니다. 크로스 패밀리 Draft는 토큰 분포가 달라지는 경향이 있어 낮은 수용률을 보입니다.

호환 가능한 Draft 모델 찾기

주어진 대상 모델에 대해 모든 작은 모델이 Draft 모델로 작동하지는 않습니다. 결정적인 요인은 분포 정렬(distribution alignment)입니다 — Draft 모델의 출력 확률이 대상 모델과 얼마나 밀접하게 일치하는지입니다.

황금 규칙: Draft 모델의 수용률이 50% 이하로 떨어지면, 투기적 디코딩이 실제로는 속도를 늦출 수 있습니다. 대부분의 제안이 거부될 때, Draft 모델 실행과 검증의 오버헤드는 이점을 상쇄합니다.

EAGLE과 EAGLE-3: 예측 헤드

EAGLE (Efficient Architecture Guided Language Model Estimation)는 별도의 Draft 모델이 필요 없도록 합니다. 대신, 대상 모델의 내부 레이어에 가벼운 자기회귀 예측 헤드를 부착합니다.

EAGLE 작동 방식

EAGLE은 예측 헤드를 훈련시켜 대상 모델의 중간 레이어에서 오는 히든 스테이트(hidden states)를 받아 미래 토큰을 예측하게 합니다. 추론(inference) 도중:

1. 대상 모델은 자신의 레이어를 통해 포워드 패스를 실행합니다.
2. 각 레이어에서 EAGLE 헤드는 히든 스테이트를 읽고 미래 위치의 토큰을 제안합니다.
3. 복수의 헤드가 병렬로 작동하며, 각각 다른 미래 타임스텝을 예측합니다.
4. 대상 모델은 단일 패스로 모든 제안을 검증합니다.

장점: EAGLE 헤드는 대상 모델의 분포에 맞춰 특별히 훈련됩니다. 대상의 내부 표현을 직접 보기 때문에, 독립적인 Draft 모델보다 훨씬 더 나은 정렬을 제공합니다.

EAGLE-3 개선 사항

EAGLE-3 (2025)는 세 가지 주요 변경으로 접근 방식을 정교하게 했습니다:

1. 레이어 선택: 모든 레이어에 헤드를 부착하는 대신, EAGLE-3는 베이지안 최적화를 사용하여 최적의 exit layer를 선택하여 오버헤드를 줄입니다.
2. 멀티-토큰 예측: 각 헤드가 동시에 여러 토큰을 예측하여, 계산 비용에 비례하지 않고 Draft 깊이를 증가시킵니다.
3. 훈련 효율성: EAGLE-3는 대상 모델 자신의 생성 데이터로 훈련하여, 분포 내(in-distribution) 워크로드에서 수용률을 높입니다.

수용률: EAGLE-3는 분포 내 워크로드에서 일반적으로 60-80%의 수용률을 달성하며, 독립적인 Draft 모델의 40-60%에 비해 높습니다. 높은 반복성이 있는 코드 생성 워크로드에서, 수용률은 85%를 초과할 수 있습니다.

설정: EAGLE-3는 대상 모델에 대해 사전 훈련된 헤드가 필요합니다. NVIDIA는 TensorRT-LLM과 HuggingFace의 Speculative Decoding Modules 컬렉션을 통해 몇 가지 인기 있는 모델에 대한 EAGLE-3 헤드를 제공합니다. vLLM과 SGLang에 대한 서드파티 구현도 존재합니다.

P-EAGLE: 병렬 Drafting (2026년 3월)

EAGLE-3의 주요 한계는 자기회귀적 Drafting입니다 — 각 Draft 토큰은 이전 토큰에 의존하므로, K개의 Draft 토큰을 생성하려면 Draft 헤드를 통해 K개의 순차적인 포워드 패스가 필요하며, Draft 오버헤드는 K에 비례하여 선형으로 증가합니다. P-EAGLE는 10개 토큰까지 병렬로 예측하도록 훈련된 가벼운 4층 drafter를 통해 단일 포워드 패스에서 모든 K개의 Draft 토큰을 생성하여 이 상한선을 제거합니다.

결과: P-EAGLE은 NVIDIA B200의 실제 워크로드에서 vanilla EAGLE-3에 비해 최대 1.69배의 가속을 달성합니다. K 값이 높을수록 이 이점은 커집니다 — EAGLE-3의 순차적 Drafting이 병목이 되는 곳에서, P-EAGLE의 병렬 Drafting은 추가 비용이 발생하지 않습니다.

vLLM 설정: HuggingFace에서 사전 훈련된 P-EAGLE 헤드를 다운로드하고, vLLM 설정에서 "parallel_drafting": true로 설정한 뒤, 동일한 --speculative-model 플래그를 사용하십시오 — vLLM이 나머지를 처리합니다. P-EAGLE은 현재 EAGLE 기반 투기적 디코딩의 최첨단(state-of-the-art) 기술이며, 2026년에 EAGLE을 배포한다면 P-EAGLE 변형을 사용해야 합니다.

n-gram Speculative Decoding

n-gram 투기적 디코딩은 신경망 기반 Draft 대신 프롬프트 히스토리에 대한 패턴 매칭을 사용합니다. 알고리즘은 컨텍스트에서 반복되는 n-gram 시퀀스를 찾아, 현재 토큰 시퀀스가 이전에 보았던 패턴과 일치하면 그 패턴 뒤를 이어갔던 토큰을 제안합니다. 예를 들어, 모델이 이미 def calculate_total(items):를 생성했고 def calculate_total(를 다시 만나면, 이전 발생 사례를 기반으로 다음 토큰이 items):일 가능성이 높다는 것을 알 수 있습니다.

n-gram 맵 변형(ngram-map-k, ngram-map-k4v)은 선형 스캔 대신 더 빠른 조회를 위해 해시 테이블을 사용하며, 해시 키는 크기가 N인 현재 n-gram이고, 값은 그 뒤에 이은 토큰 시퀀스입니다.

장점:

• VRAM 오버헤드 제로 — 로드할 추가 모델 없음 (해시 테이블은 약 16 MB)
• 반복적인 워크로드에 매우 빠름 (코드 편집, 리팩토링, 템플릿 생성)
• 자기 유사성이 높은 워크로드에서 수용률이 90%+에 달할 수 있음

단점:

• 새로운 생성에 무용지물 — 패턴이 이전에 나온 적이 없다면, n-gram은 제안할 것이 없음
• 창의적이거나 다양한 워크로드에서 수용률이 거의 제로로 떨어짐
• 제한된 Draft 깊이 (일반적으로 매칭당 2-4개 토큰)

최적 사용처: 코드 리팩토링, 템플릿 채우기, 반복적인 문서화, 그리고 모델이 유사한 패턴을 다시 방문하는 모든 워크로드. 최악의 사용처: 창의적 글쓰기, 오픈-엔드 챗, 추론 작업.

파라미터 튜닝

n-gram 파라미터는 예상보다 더 중요합니다. 기본값은 코드를 위해 작동하지만, 텍스트 워크로드는 조정이 필요합니다:

텍스트 워크로드의 경우, size-n을 8-10으로 줄이고 min-hits을 2로 늘리십시오. 이는 매칭 빈도를 희생하여 매칭당 수용률을 높이는 것입니다.

Self-Speculative Decoding

Self-speculative decoding (LayerSkip 또는 self-speculation이라고도 함)은 별도의 모델이 필요 없도록 모델 자신의 부분 계산(partial computation)을 Draft로 사용합니다.

작동 방식

토큰마다 전체 모델을 실행하는 대신, self-speculative decoding은 일부 Transformer 레이어를 건너뛰어 짧은 버전(truncated version)을 실행하여 저렴하게 Draft 토큰을 생성하고, 전체 모델이 제안을 검증합니다.

예를 들어, 32개 레이어의 모델은 Draft를 위해 레이어 16개만 실행할 수 있고, 전체 32개 레이어로 검증합니다. 잘린 포워드 패스는 더 적은 레이어를 처리하기 때문에 더 빠르며, Draft 토큰은 대상 모델과 동일한 초기 레이어를 보기 때문에 혜택을 받습니다.

장점:

• 로드할 추가 모델 가중치 없음
• 대상 분포와 자연스러운 정렬 (동일한 아키텍처, 부분 레이어)
• 깊은 레이어에 상당한 중복성이 있는 모델에 잘 작동

단점:

• 부분 포워드 패스를 지원하도록 추론 엔진을 수정해야 함
• KV 캐시 복잡성 — Draft는 부분 KV 캐시를 사용하며, 이는 전체 모델의 캐시와 조정되어야 함
• 수용률이 일반적으로 EAGLE나 잘 튜닝된 Draft 모델보다 낮음

llama.cpp 구현: PR #18471은 컨텍스트 히스토리를 Draft로 사용하여 self-speculative decoding을 도입했습니다. 모델은 자신의 생성 히스토리에서 토큰을 재사용하여 연속 생성을 제안하며, 특히 같은 컨텍스트 윈도우 내에서 패턴이 반복되는 코딩 워크로드에서 효과적입니다.

MTP (Multi-Token Prediction)

MTP는 특정 모델 체크포인트에 직접 내장된 투기적 디코딩의 전문화된 형태입니다. Qwen 3.6은 표준 및 MTP 활성화 GGUF 변형 두 가지를 제공합니다.

차이점: MTP 헤드는 훈련 중에 모델 아키텍처에 녹아들어 있습니다. 모델은 단일 포워드 패스에서 여러 미래 토큰을 제안하는 추가 예측 헤드를 가지고 있습니다. 별도의 Draft 모델이 없으며 — MTP 헤드는 대상 모델 자체의 일부입니다.

트레이드오프:

• 관리할 Draft 모델이 없음 — --spec-type draft-mtp --spec-draft-n-max N로 MTP 활성화
• MTP 헤드는 약 1-2 GB의 VRAM 오버헤드를 추가
• 희소 라우팅이 MTP 헤드를 저렴하게 유지하는 MoE 아키텍처 (Qwen 3.6 35B-A3B)에서 가장 잘 작동

Qwen 3.6 27B와 35B의 MTP vs 표준 디코딩에 대한 상세 벤치마크는 Qwen 3.6 MTP vs 16GB GPU에서 Standard를 참조하십시오.

수용률: 실제에서의 의미

수용률 (α)은 투기적 디코딩 성능에 있어 단일 가장 중요한 지표입니다. 이것이 가속을 얻는 것인지 오버헤드를 지불하는지를 결정합니다.

가속 공식

검증 패스당 기대 수락 토큰 수:

E[accepted] = α × K

여기서 K는 사이클당 제안되는 Draft 토큰 수입니다. α = 0.7이고 K = 5라면, 패스당 3.5개의 토큰을 수락하게 됩니다 — 표준 디코딩(패스당 1개 토큰 생성)보다 3.5배 빠른 것입니다.

메서드별 수용률

수용률이 떨어질 때

수용률은 생성 전체에 걸쳐 일정하지 않습니다. 다음에 따라 변합니다:

• 토큰 위치: 초기 토큰은 일반적으로 더 높은 수용률을 가짐 (컨텍스트가 많고 불확실성이 적음). 모델이 더 다양한 연속 생성을 탐색함에 따라 후기 토큰은 떨어짐.
• 워크로드 유형: 반복적인 패턴이 있는 코드 편집은 α > 80%를 보입니다. 오픈-엔드 창의적 글쓰기는 α < 40%를 보입니다.
• Temperature: 더 높은 Temperature는 Draft와 대상 사이의 분산을 증가시켜 수용률을 낮춥니다. 투기적 디코딩은 낮은 Temperature (0.0-0.7)에서 가장 잘 작동합니다.

임계값: 유효 수용률 (α × K)이 1.0 이하로 떨어지면, 투기적 디코딩은 표준 디코딩보다 느립니다. Draft 오버헤드와 검증 시간이 단일 자기회귀 단계의 비용을 초과하기 때문입니다.

생산 환경에서의 Speculative Decoding: 실제로 발생하는 일

연구 논문들은 2-4배의 가속을 보고하지만, 생산 벤치마크는 더 미세한 이야기를 들려줍니다 — 가속은 배치 크기가 커질수록 줄어 들고, 검증이 사이클 시간을 지배하며, 어떤 단일 메서드도 모든 워크로드에서 우승하지 못합니다.

SpecDecode-Bench 발견 사항 (2026)

vLLM에서 4가지 모델과 6가지 워크로드에 대한 5가지 SD 변형(n-gram, EAGLE, EAGLE-3, Draft-Model, MTP)의 체계적인 평가는 다음을 보여줬습니다:

1. SD는 작동하지만, 배치 크기가 커지면 가속이 줄어듭니다. 배치 크기 1에서, EAGLE은 Llama-3-70B에서 최대 1.96배를 달성합니다. 배치 크기 128로 갈 때, 이는 1.21배로 떨어집니다. 높은 동시성에서 시스템은 컴퓨트 바운드(compute-bound)가 되며, GPU는 추측에 쓸 유휴 용량이 적어집니다.

2. 검증이 실행 시간의 대부분(42-95%)을 차지합니다. 대상 모델의 포워드 패스가 병목입니다. 거부된 토큰에 대한 낭비된 검증을 줄이는 것이 가장 유망한 개선 방향입니다.

3. 모든 곳에서 우승하는 단일 메서드는 없습니다. EAGLE-3는 가장 좋은 올라운더 선택입니다. Draft-model 메서드는 대상 모델이 크고 (70B+) 있을 때 두드러집니다. n-gram은 코드 편집과 높은 오버랩 작업에 최적입니다.

4. 오라클 분석은 갭을 드러냅니다. 조합된 n-gram + EAGLE 전략의 이론적 상한선은 코드 편집 워크로드에서 약 4.9배에 도달하지만, 현재 구현들은 2-3배를 달성합니다. 최적화를 위한 여지가 있습니다.

실질적인 가속 기대치

배치 크기 효과는 중요합니다. 작은 배치에서, GPU는 추측에 쓸 유휴 컴퓨트가 있습니다. 큰 배치에서, 시스템은 이미 포화 상태이므로 투기적 디코딩은 비례하는 이득 없이 오버헤드만 추가합니다.

생산 환경 모니터링

생산 환경에서 수용률을 추적해야 합니다. 감소하는 수용률은 Draft 모델이 대상에서 벗어나고 있음을 알립니다 — 워크로드가 변경되었거나, Draft 모델이 재훈련을 필요로 하기 때문입니다.

모니터링할 주요 지표:

• 요청별 수용률 (베이스라인 주변에서 안정적이어야 함)
• 투기적 디코딩 유/무 시 초당 토큰 수 (실제 가속)
• 사이클 시간 대비 검증 시간 비율 (42-95%여야 함)
• Draft 모델 포워드 패스 시간 (대상 모델 시간의 20% 미만이어야 함)

수용률이 40% 이하로 떨어지면, 해당 요청에 대해 투기적 디코딩을 비활성화하십시오. 오버헤드는 가치가 없습니다.

실제 설정

엔진 선택은 Draft 전략만큼 중요합니다 — 각 런타임이 배치 처리, API 호환성, 처리량을 어떻게 처리하는지 확인하려면 Ollama vs vLLM vs LM Studio and other local runtimes를 참고하십시오. 투기적 디코딩 경로를 선택하기 전에.

llama.cpp

일반 서버 설정과 GGUF 로딩을 위해, llama.cpp quickstart로 시작하십시오. 아래 플래그들은 여기에 투기적 디코딩을 추가합니다.

llama.cpp는 --spec-type 플래그를 통해 여러 투기적 디코딩 메서드를 지원합니다:

# Draft model (standalone)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Mandatory: --parallel 1 for speculative decoding

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (text workload tuning)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Self-speculative (coding workloads)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

주요 플래그:

• --parallel 1 — llama.cpp의 투기적 디코딩은 단일 배치 모드가 필요합니다. 이것은 현재 제한 사항입니다.
• --spec-draft-n-max — 사이클당 Draft 토큰 수. 3-5로 시작하십시오. 더 높은 값은 VRAM 압력을 증가시킵니다.
• --spec-ngram-simple-size-n — 조회 n-gram 길이. 기본값 12는 코드에 잘 작동하며, 텍스트의 경우 8로 줄이십시오.

흔한 함정:

• --parallel 1 잊음 — 서버가 투기적 디코딩을 조용히 무시합니다.
• 크로스 패밀리 Draft 모델 사용 — 수용률이 붕괴되어 가속 효과가 사라집니다.
• --spec-draft-n-max 과도하게 설정 — 각 추가 Draft 토큰은 Draft 버퍼를 위해 VRAM을 소모합니다. 5-8 근처에서 감수적 수익(diminishing returns)이 시작됩니다.

vLLM

vLLM quickstart는 기본 배포를 다룹니다. 아래 플래그들은 기존 vLLM 서버에서 투기적 디코딩을 활성화합니다.

vLLM은 --speculative-model과 --speculative-num-steps 플래그를 통해 투기적 디코딩을 지원합니다:

# Draft model
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (parallel drafting)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

vLLM의 투기적 디코딩은 연속 배치 처리(continuous batching)와 통합되어 있어, 동시 워크로드에서도 작동합니다. 스케줄러는 단일 포워드 패스 내에서 여러 토큰 슬롯을 처리하고, 메모리 매니저는 Draft 및 대상 모델 모두의 KV 캐시를 처리합니다.

SGLang

SGLang은 --speculative-algorithm 플래그를 통해 투기적 디코딩을 지원합니다:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

SGLang의 RadixAttention 아키텍처는 프리픽스 캐싱이 검증 비용을 줄이기 때문에 투기적 디코딩과 잘 어울립니다 — 대상 모델은 공유된 프리픽스에 대해 캐시된 어텐션을 재사용하여, 각 검증 패스가 콜드 포워드 패스보다 저렴해집니다.

TensorRT-LLM

TensorRT-LLM은 Triton Inference Server를 갖춘 생산 등급의 투기적 디코딩을 제공합니다. 설정은 더 복잡하지만 NVIDIA 하드웨어에서 최고의 성능을 제공합니다:

1. 대상 및 Draft 모델 모두에 대해 TensorRT 엔진을 빌드하십시오.
2. model.yaml에서 투기적 디코딩 구성을 지정하여 모델 저장소를 설정하십시오.
3. LLM API / PyTorch 백엔드로 Triton을 시작하십시오.

TensorRT-LLM은 Draft-model과 EAGLE-3 변형 모두를 지원합니다. 코드 생성 워크로드에서, n-gram 투기적 디코딩을 사용하는 TensorRT-LLM은 생산 배포에서 2-3배의 지연 시간 감소가 입증되었습니다.

언제 Speculative Decoding을 사용해야 하는가

사용할 때

• 큰 대상 모델 (7B+): Draft 메커니즘의 오버헤드는 대상의 컴퓨트에 걸쳐 분배됩니다. 대상 모델이 느릴 때 투기적 디코딩이 빛을 발합니다 — 대상이 클수록 가속의 가치가 더 큽니다.
• 낮은 Temperature 워크로드: 대상 모델의 분포가 집중되고 Draft가 일치할 가능성이 더 높기 때문에 Temperature 0.0-0.7에서 투기적 디코딩이 가장 잘 작동합니다.
• 대화형 애플리케이션: 지연 시간 민감형 워크로드 (챗, 코드 완성, 에이전트 도구 호출)가 가장 혜택을 봅니다. 이미 GPU를 포화 상태에 놓고 있는 배치 처리는 더 적은 혜택을 봅니다.
• 코드 생성 및 편집: 코드 패턴의 높은 반복성은 n-gram과 self-speculative decoding을 특히 효과적으로 만듭니다.

건너뛸 때

• 작은 대상 모델 (< 3B): Draft 모델의 오버헤드가 대상의 포워드 패스 시간에 접근합니다. 가속은 미미하거나 마이너스입니다.
• 높은 Temperature 샘플링: Temperature > 0.7에서, 대상 모델의 분포가 너무 넓어 Draft가 신뢰할 수 있게 일치시킬 수 없습니다.
• 창의적 글쓰기 및 오픈-엔드 생성: 새로운 콘텐츠에서 낮은 수용률은 오버헤드가 가치가 없게 만듭니다.
• 큰 배치 크기 (> 32): 시스템이 컴퓨트 바운드가 되고, 투기적 디코딩은 비례하는 이득 없이 오버헤드만 추가합니다. SpecDecode-Bench는 배치 크기가 1에서 128으로 갈 때 가속이 1.96x에서 1.21x로 떨어지는 것을 보여줍니다.

메서드 조합

고급 설정은 여러 투기적 디코딩 전략을 조합합니다. SpecDecode-Bench의 오라클 분석은 적응적으로 n-gram과 EAGLE를 조합하면 코드 편집 워크로드에서 가속을 4.9x까지 높일 수 있음을 보여주었습니다.

그 아이디어는 이전에 나온 패턴에 대해 수용률이 높고 오버헤드가 거의 0인 n-gram을 사용하고, 새로운 토큰에 대해 EAGLE로 폴백하는 것입니다. 실제로는 여러 메서드 추측을 지원하도록 엔진 지원이 필요하며 — vLLM과 TensorRT-LLM은 실험적 지원을 가지고 있지만, 생산 등급 구현은 여전히 성숙해지고 있습니다.

현재로서는 가장 실질적인 조합은 llama.cpp의 MTP + n-gram입니다. MTP는 신경망 기반 추측을 처리하고, n-gram은 MTP가 놓치는 반복적인 패턴을 잡아냅니다. Qwen 3 27B에서, 이 조합은 표준의 67 tokens/sec에 비해 120 tokens/sec를 달성하여 1.8배의 가속을 보입니다.

비용 고려 사항

투기적 디코딩은 컴퓨트를 지연 시간과 교환합니다. 토큰당 총 컴퓨트는 대략 동일합니다 — 단순히 순차적으로 처리하는 대신 병렬로 더 많은 작업을 수행하는 것입니다.

GPU 비용 영향:

• 단일 요청 지연 시간은 20-50% 개선되며, 이는 대화형 애플리케이션에서 중요합니다.
• 처리량 (여러 요청에 걸친 초당 토큰 수)은 덜 개선됩니다 — GPU는 큰 배치 크기에 이미 포화 상태입니다.
• VRAM 사용량은 Draft 모델의_footprint(독립 Draft는 1-4 GB, n-gram/EAGLE는 최소)만큼 증가합니다.

클라우드 추론: H100당 $2-4/hr에서, 투기적 디코딩은 토큰당 비용을 증가시키지 않고 요청별 지연 시간을 줄입니다. 이미 GPU를 포화 상태에 놓은 배치 처리에서, 비용 이점은 최소입니다 — 어떤 경우에도 동일한 GPU 시간을 지불하기 때문입니다.

투기적 디코딩이 돈을 아껴주는 경우: 요청당 과금하며 첫 토큰까지의 시간(time-to-first-token)을 줄이고 싶은 대화형 애플리케이션. 2배의 가속은 사용자가 절반만큼 오래 기다리고, 동일한 하드웨어에서 초당 더 많은 요청을 처리할 수 있음을 의미합니다.

아껴주지 않는 경우: 이미 GPU 활용률을 최대화하고 있는 배치 처리. 투기적 디코딩으로 인한 추가 컴퓨트는 처리량을 증가시키지 않습니다 — 단순히 지연 시간 프로필을 변경할 뿐입니다.

다음으로 무엇이 있을 것인가

투기적 디코딩은 연구 단계의 신기함에서 생산 표준으로 성숙해지고 있습니다. 최첨단 영역은 현재 한계를 넘어 밀고 나가고 있습니다:

• 모델 레벨 병렬 생성: 투기적 디코딩은 출력 분포를 건드리지 않고 추론 레이어에서 포워드 패스당 여러 토큰을 밀어냅니다. 디퓨전 언어 모델은 구조적으로 다른 베팅을 하며, 모델 아키텍처의 일부로서 포워드 패스당 여러 토큰을 생성합니다. 이것이 위의 Draft-verify 접근법과 어떻게 비교되는지, 그리고 포스트-Transformer 경관의 다른 끝인 상태 공간 모델과 JEPA 월드 모델과 어떻게 다른지 보기 위해 LLM 이후에 무엇이 올 것인가를 참조하십시오.

• Speculative Speculative Decoding (SSD): Drafting과 검증 단계를 별도 하드웨어에 걸쳐 병렬화합니다. Draft 모델은 비동기식으로 실행되며, 여러 가능한 검증 결과에 대해 사전에 추측합니다. 초기 결과는 최적화된 투기적 디코딩보다 최대 2배, 자기회귀 디코딩보다 5배의 가속을 보여줍니다. 아직 생산 준비가 되어 있지 않지만, 방향은 명확합니다.

• SpecSA (Sparse Speculative Verification): 투기적 디코딩과 동적 희소 어텐션을 결합합니다. 희소 어텐션을 검증 지향적인 워크로드로 전환하여, 자기회귀 희소 디코딩에 비해 최대 3.49배의 엔드-투-엔드 처리량을 달성합니다. 희소 어텐션이 이미 사용 중인 롱 컨텍스트 모델에 관련이 있습니다.

• 적응적 투기 (Adaptive speculation): 워크로드 특성에 따라 n-gram, EAGLE, Draft-model 메서드 사이를 자동으로 전환합니다. 오라클 분석은 상당한 미활용 잠재력을 보여줍니다 — 현재 구현은 2-3x를 달성하지만, 이론적 상한선은 4.9x입니다.

• 멀티모달 투기적 디코딩: Draft-verify를 비전-언어 모델 및 비디오 생성으로 확장합니다. 초기 설문은 동일한 원칙이 적용됨을 보여주지만, 검증 전략은 텍스트가 아닌 모달리티에 대한 적응이 필요합니다.

의사결정 프레임워크