speculative decoding이란? LLM 추론 가속 원리와 적용 조건

개발자에게 중요한 것은 실제 워크로드에서 답변이 더 빠르게 스트리밍되는지입니다. 서빙 운영자는 동시 요청과 메모리 압박 속에서도 그 효과가 유지되는지 확인해야 합니다. 호스팅 API를 이용하는 팀이라면 제공업체가 이 최적화를 설정으로 제공하거나 문서에 명시하는지부터 살펴봐야 합니다.

문서 확인일: 2026년 10월 30일. 확인 대상은 vLLM, SGLang, NVIDIA TensorRT-LLM입니다. 아래 명령어는 각 프로젝트의 현행 문서를 따른 설정 예시이며, 이 글에서 직접 측정한 벤치마크 결과가 아닙니다.

speculative decoding은 어떻게 작동하나요?

계산 비용이 낮은 제안기가 다음 토큰을 예측하면, 타깃 모델이 답변에 반영할 토큰을 결정합니다. 토큰은 모델이 처리하는 텍스트 단위로, 단어의 일부인 경우가 많습니다. 타깃은 원래의 동작을 유지하려는 모델을 뜻합니다.

꼼꼼한 편집자를 위해 보조 작성자가 문장 초안을 준비한다고 생각하면 이해하기 쉽습니다. 보조 작성자는 앞서 나가며 초안을 쓸 수 있지만, 편집자의 확인을 거쳐야 독자에게 전달됩니다. 핵심은 타깃이 새 토큰마다 별도의 생성 단계를 기다리는 대신, 제안된 뒷부분을 한꺼번에 평가할 수 있다는 점입니다. NVIDIA는 이를 초안 생성 과정에 이어 타깃 검증을 수행하는 방식으로 설명합니다. TensorRT-LLM 문서

그림의 문자는 토큰 ID를 나타냅니다. 초안 생성기가 A B C를 제안했다고 가정합니다. 다음 토큰으로 확률이 가장 높은 것을 고르는 그리디 디코딩에서, 타깃이 A B에는 동의하지만 그다음으로는 X를 원할 수 있습니다. 그러면 확정된 답변은 A B X가 됩니다. 거부된 C 뒤에 미리 생성한 초안도 잘못된 접두부를 바탕으로 했으므로 함께 버립니다.

샘플링으로 출력을 생성할 때는 두 모델이 같은 단어를 골랐는지만으로 채택 여부를 결정하지 않습니다. 표준 추측 샘플링은 타깃과 제안기의 확률을 사용하며, 제안이 거부되면 보정 분포를 적용합니다. 타깃의 확률 분포를 보존하는 것은 바로 이 보정 과정입니다. 원래 알고리즘에서는 초안 전체가 채택될 경우 타깃이 토큰을 하나 더 생성할 수도 있습니다. Leviathan, Kalman, Matias의 원 논문

따라서 작은 모델의 역할은 후보를 제안하는 것이지, 타깃 대신 답하는 것이 아닙니다. 엄밀한 검증기를 사용한다면 성능이 좋지 않은 초안 생성기는 속도를 떨어뜨릴 수는 있어도, 모르는 사이에 답변을 대신 결정해서는 안 됩니다.

‘성능이 낮은 모델에 맡기지 않는다’는 의미

요구해야 할 보장은 타깃 분포의 보존입니다. 매 실행에서 무작위 응답이 똑같이 나온다는 뜻도, 타깃의 오류가 사라지거나 추론 능력이 좋아진다는 뜻도 아닙니다. vLLM은 알고리즘이 무손실이어도 수치 연산과 배칭의 영향으로 차이가 생길 수 있다고 명시합니다. vLLM의 무손실 보장

추측 디코딩을 평가할 때는 타깃 가중치, 양자화, 샘플링 설정을 고정해야 합니다. 여러 조건을 동시에 바꾸면 품질 차이가 어느 변경에서 비롯됐는지 구분할 수 없습니다.

주요 방식과 엔진별 설정 문서

사용할 타깃 모델과 서빙 엔진 버전이 지원하는 제안기를 선택해야 합니다. 초안을 생성하고 검증한다는 기본 원리는 같지만, 초안을 만드는 주체가 달라집니다.

별도의 초안 모델 사용

더 작은 언어 모델이 자체 가중치로 후보 토큰을 생성합니다. 가장 직관적인 구성이지만, 모델을 하나 더 로드하고 운영해야 합니다. 호환성과 타깃과의 일치도가 중요합니다. 작다고 해서 반드시 쓸모 있는 것은 아닙니다. vLLM은 일반적으로 같은 어휘 집합을 전제로 하며, 서로 다른 어휘 집합을 사용하는 제한적 옵션도 문서화하고 있습니다. vLLM 초안 모델

이미 메모리 한계에 가까운 서비스라면 모델부터 하나 더 올리는 것은 적절한 출발점이 아닐 수 있습니다. 반면 지연 시간에 민감한 서비스에 여유 자원이 있고 타깃과 잘 맞는 초안 생성기가 있다면, 조건을 통제한 실험으로 시도해 볼 만합니다.

EAGLE speculative decoding의 작동 방식

EAGLE은 Extrapolation Algorithm for Greater Language-model Efficiency의 약자로, 타깃에 맞춰 학습한 보조 초안 생성기를 사용합니다. 이 생성기는 타깃의 내부 표현을 활용해 뒤에 이어질 내용을 제안합니다. 흔히 헤드라고 부르는 이러한 학습 구성요소에는 호환되는 체크포인트가 필요합니다. vLLM은 eagle과 eagle3 설정을 구분합니다. vLLM EAGLE 문서

타깃과 EAGLE 체크포인트는 서로 호환되는 한 쌍으로 다뤄야 합니다. 이름에 같은 모델 계열이 들어 있다는 이유만으로 체크포인트를 고르면 안 됩니다. 정확한 모델 계열, 모델 리비전, 서빙 구현을 모두 배포 기록에 남겨야 합니다.

MTP 기반 추측 디코딩

다중 토큰 예측, 즉 MTP는 모델에 내장된 미래 토큰 제안 기능을 활용합니다. vLLM은 지원 모델 계열에서 사용할 수 있는 옵션으로 이를 설명하며, 별도의 초안 모델 식별자가 필요 없는 실행 예시를 제공합니다. 해당 기능이 없는 모델에 method를 mtp로 설정한다고 해서 기능이 생기는 것은 아닙니다. vLLM MTP 문서

지원되는 MTP 체크포인트를 이미 서빙하고 있다면, 관련 없는 독립 초안 모델을 추가하기 전에 문서에 제시된 MTP 방식부터 시도하는 것이 좋습니다. 호환성을 검토해야 할 선택지가 줄어듭니다. 물론 성능은 여전히 직접 측정해야 합니다.

아래 표는 각 엔진의 공식 문서로 바로 연결됩니다. 설정을 시작할 위치를 안내하는 표이며, 모든 모델이 표의 모든 조합에서 작동한다는 뜻은 아닙니다.

알고리즘 이름과 실행 구조는 서로 다른 개념입니다. TensorRT-LLM의 현행 릴리스 노트에서는 별도 초안 엔진을 사용하는 실행 경로를 제거하고, 초안 생성기를 모델 내부의 하위 모듈로 배치하는 구현을 유지한다고 설명합니다. 초안/타깃 방식 자체가 사라졌다는 뜻은 아닙니다. 예전 배포 안내가 현재 설치된 릴리스에는 없는 실행 경로를 설명할 수 있다는 뜻입니다. TensorRT-LLM 릴리스 노트

속도가 빨라지는 조건과 그렇지 않은 조건

추가 작업을 모두 포함하고도 유효한 출력이 더 빨리 나와야 추측 디코딩의 이득이 있습니다. 채택률은 중요하지만, 전체 계산의 일부에 불과합니다.

초안 생성 비용을 상쇄할 만큼 채택되어야 합니다

채택률은 제안한 초안 토큰 중 채택된 토큰의 비율입니다. 이 수치만으로는 후보를 만드는 데 얼마나 많은 비용이 들었는지 알 수 없습니다. 느린 초안 생성기는 타깃과 더 자주 일치하면서도 서비스 전체는 더 느리게 만들 수 있습니다.

판단 기준으로는 다음 식이 유용합니다.

(초안 생성 시간 + 검증 시간 + 조정 시간) ÷ 확정된 출력 토큰 수 < 기준 구성의 토큰당 디코딩 시간

이는 비용과 이득을 따지는 기준이지, 벤치마크 예측식이 아닙니다. 실제 하드웨어에서 전체 과정을 측정해야 합니다. ‘확정된 출력 토큰’에는 채택된 초안 후보뿐 아니라 타깃이 제공한 보정 토큰이나 추가 토큰도 포함됩니다.

코드 편집 어시스턴트는 주변 코드의 반복 구조 덕분에 초안 제안이 유용할 수 있습니다. 고객 지원 어시스턴트에서는 정중한 연결 표현은 타깃과 잘 맞더라도 제품별 답변에서는 일치도가 떨어질 수 있습니다. 평균 채택률만으로 배포 여부를 결정하기 전에 두 워크로드를 따로 측정해야 합니다.

초안이 길어지면 버려질 수 있는 작업도 늘어납니다. 추가로 확정되는 출력이 초안 생성, 검증, 메모리 오버헤드를 상쇄하는 범위에서만 초안 깊이를 늘려야 합니다. Fireworks의 튜닝 안내도 같은 점을 강조합니다. 채택률만으로 속도 개선을 입증할 수는 없습니다. Fireworks 벤치마크 안내

배치 크기에 따라 활용할 여지가 달라집니다

디코딩이 병목인 대화형 워크로드부터 시작하고, 이후 최대 동시 요청 조건에서 검증해야 합니다. vLLM은 요청 빈도가 중간 이하인 메모리 대역폭 병목 워크로드를 추측 디코딩의 대상으로 명시합니다. 메모리가 병목인 단계에서는 가용 연산 능력보다 모델 데이터를 이동하는 속도가 처리 속도를 더 크게 제한합니다. vLLM 워크로드 안내

병렬 검증을 추가하면 충분히 쓰이지 않던 연산 자원을 활용할 수 있습니다. 하지만 바쁜 서버는 이미 그 자원을 다른 요청에 사용하고 있을 수 있습니다. 따라서 채팅 요청 하나의 지연 시간이 줄었다고 해서, 요청이 몰리는 엔드포인트의 전체 처리량까지 늘었다고 볼 수는 없습니다.

연속 배칭은 각 생성 단계에 함께 참여하는 요청 구성을 바꿉니다. 실제 서비스의 요청 유입 패턴을 포함해 해당 스케줄러 아래에서 추측 디코딩을 평가해야 합니다. 한산한 개발용 엔드포인트와 대기열이 쌓이는 프로덕션 엔드포인트는 서로 다른 실험 조건입니다.

모든 환경에 통하는 배치 크기 기준을 정해서는 안 됩니다. 이득이 발생하는 경계는 모델, 하드웨어, 초안 생성 방식, 스케줄러에 따라 달라집니다. 응답이 얼마나 빠르게 스트리밍되는지와, 지연 시간 목표를 지키면서 서비스가 얼마나 많은 트래픽을 감당하는지를 함께 봐야 합니다.

메모리 비용이 속도 이득을 없앨 수 있습니다

초안 생성기도 한정된 GPU 메모리를 나눠 씁니다. 별도 가중치, 초안 상태, 검증 작업 공간이 원래 요청 처리에 쓸 수 있던 메모리를 차지할 수 있습니다. 기존 토큰의 어텐션 상태를 저장하는 KV 캐시도 이 메모리 예산에 포함됩니다.

짧은 프롬프트에는 빠르게 답하지만 긴 문서에서는 메모리 한계에 가까워지는 문서 어시스턴트를 예로 들어 보겠습니다. 짧은 프롬프트 실험에 성공했어도, 프로덕션 캐시와 함께 초안을 담을 공간이 있는지는 별도로 확인해야 합니다. 지원하려는 가장 긴 컨텍스트를 현실적인 동시 요청 조건에서 테스트해야 합니다.

SGLang의 메모리 부족 대응 안내에는 메모리 예약량, 그래프 캡처 크기, 초안 트리 크기, 동시 요청 수를 줄이는 방법이 명시되어 있습니다. 추측 디코딩을 수용하려고 동시 요청 수를 낮춰야 한다면, 그 대가까지 측정해야 합니다. 비용 없이 얻는 최적화가 아닙니다. SGLang 메모리 문제 해결

사용자가 실제로 기다리는 구간을 줄여야 합니다

답변이 느리다는 것은 출력이 시작되기까지 오래 걸린다는 뜻일 수도, 출력 이후 스트리밍이 느리다는 뜻일 수도, 모델 외부에서 지연된다는 뜻일 수도 있습니다. 추측 디코딩이 겨냥하는 것은 생성 과정입니다. 애플리케이션이 대부분의 시간을 문서 검색이나 툴 호출 대기에 쓴다면, 디코딩 루프가 빨라져도 체감은 거의 달라지지 않을 수 있습니다.

측정할 때는 대기열, 프리필, 디코딩 시간을 분리해야 합니다. 프리필은 프롬프트를 처리하는 단계이고, 디코딩은 그 뒤에 이어질 내용을 생성하는 단계입니다. LLM 추론 가이드에서 각 단계를 설명하며, 초당 토큰 수 가이드에서는 출력 속도와 전체 요청 처리량을 구분합니다.

추측 디코딩을 활성화하는 방법

서빙 프로세스에서 추측 디코딩을 켜고, 같은 타깃에서 기능을 끈 기준 구성과 비교합니다. 아래 예시는 엔진이 이미 설치되어 있고, 하드웨어에 선택한 모델을 올릴 공간이 있으며, 해당 가중치에 접근할 수 있다는 전제하에 작성했습니다. 배포할 릴리스에 맞는 문서를 사용해야 합니다. 현행 latest 페이지가 오래된 컨테이너와의 호환성을 보장하지는 않습니다.

vLLM speculative decoding 설정

vLLM은 --speculative-config로 JSON 객체를 전달받습니다. 다음 별도 초안 모델 예시는 온라인 서빙 문서에 나온 타깃, 초안 생성기, 초안 길이를 그대로 사용합니다.

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

5는 이 예시에서 제안하는 토큰 수일 뿐, 권장 최적값이 아닙니다. 문서에서는 기존의 개별 플래그인 --speculative-model과 --num-speculative-tokens를 더 이상 사용하지 않도록 안내합니다. vLLM 실행 예시

내장 MTP 기능의 예로, 문서에 제시된 Xiaomi MiMo 베이스 체크포인트는 다음과 같이 실행합니다.

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

이는 다른 모델을 사용하는 예시입니다. 위 Qwen 타깃에 그대로 끼워 넣을 수 있는 초안 생성기가 아닙니다. 관건은 체크포인트 지원 여부입니다. 모델에 MTP 기능이 있어야 하고, 엔진도 이를 지원해야 합니다. vLLM MTP 실행 예시

SGLang 추측 디코딩 설정

SGLang의 현행 오버랩 스케줄러 예시는 독립 초안 모델을 사용하는 Qwen 타깃/초안 생성기 쌍을 제시합니다.

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

현재 오버랩 실행 경로에는 --speculative-eagle-topk 1이 필요합니다. 다른 예시에서 폭이 더 넓은 트리 설정을 가져오면 이 경로와 호환되지 않습니다. 문서에 나온 스케줄러 설정과 초안 생성 설정을 한 묶음으로 유지해야 합니다. SGLang 오버랩 스케줄러 예시

워크로드가 달라지는 상황을 위해 SGLang은 지원되는 EAGLE 구성에서 적응형 추측 디코딩을 사용하는 방법도 별도로 안내합니다. 초안 깊이가 자동으로 조정될 것이라고 기대하기 전에 해당 기능의 요건부터 확인해야 합니다. SGLang 적응형 추측 디코딩

TensorRT-LLM 설정

TensorRT-LLM은 YAML 구성 파일로 추측 디코딩 설정을 받습니다. 다음 내용을 speculative.yaml로 저장합니다.

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

초안 길이와 체크포인트는 NVIDIA의 추측 디코딩 설정 예시를 따릅니다. 문서의 서빙 CLI로 호환되는 타깃을 실행합니다.

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

설정 이름뿐 아니라 체크포인트 세대도 확인해야 합니다. NVIDIA는 Eagle을 Eagle3의 호환용 별칭으로 명시하지만, 이전 세대의 EAGLE 체크포인트는 이 경로와 호환되지 않습니다. TensorRT-LLM 체크포인트 제약

추측 디코딩 방식과 함께 서빙 엔진도 선택하는 단계라면, 더 넓은 범위를 다루는 vLLM과 SGLang 비교를 참고하면 됩니다. 아무리 좋은 초안 생성기라도 엔진에 애플리케이션 필수 기능이 빠져 있다면 이를 보완할 수 없습니다.

호스팅 API를 쓰는 팀도 효과를 볼 수 있나요?

제공업체가 해당 기능을 문서화하고 활성화한 경우에는 가능합니다. 직접 제어할 수 있는 범위는 서비스마다 다릅니다. 제공업체의 서빙 최적화로 이득을 얻기 위해 GPU를 직접 보유할 필요는 없습니다.

호스팅 추론 서비스인 Fireworks AI는 전용 배포에서 지원되는 대부분의 모델에 기본 초안 생성기를 제공한다고 설명합니다. 기본 초안 생성기가 없는 모델은 별도 설정이 없으면 모델 기반 추측 디코딩 없이 실행됩니다. 서버리스 서빙 설정은 Fireworks가 관리하므로, 전용 배포용 플래그가 있다는 이유만으로 모든 서버리스 엔드포인트가 추측 디코딩을 사용한다고 볼 수는 없습니다. Fireworks 배포 문서

파일을 조금 수정한 뒤 다시 생성하는 API 호출을 위해 Fireworks는 Predicted Outputs도 안내합니다. 요청의 prediction 필드에 예상 텍스트를 전달하는 방식입니다. 이미 알고 있는 텍스트가 후보를 제안하는 또 다른 원천이 되며, 모델 기반 추측 디코딩과 함께 사용할 수 있습니다. 답의 범위가 열려 있는 질문보다는, 답변의 상당 부분을 미리 알고 있을 때 유용합니다. Fireworks Predicted Outputs

다른 호스팅 엔드포인트에서도 이 이점을 주장하거나 설정을 추가하려면, 먼저 해당 제공업체의 문서로 확인해야 합니다. API 호환성만으로는 엔드포인트 뒤에서 어떤 초안 모델이 실행되는지, 초안 모델이 있기는 한지조차 알 수 없습니다.

추측 디코딩을 둘러싼 과장

추측 디코딩은 조건이 맞을 때 서빙 성능을 개선하는 기법이며, 어디서나 일정한 배수로 속도를 높여 주는 기능은 아닙니다. 이 글에서 구체적인 가속 배수를 약속하지 않는 이유도 여기에 있습니다. 타깃, 초안 생성기, GPU, 트래픽 구성이 다른 환경의 결과는 현재 서비스의 성능을 설명하지 못합니다.

‘채택되는 토큰이 많을수록 애플리케이션이 빨라진다’는 말은 초안 생성 비용, 대기열, 생성 전후에 애플리케이션이 수행하는 작업을 빠뜨립니다. ‘초안은 길수록 좋다’는 주장은 거부 이후 버려지는 작업을 무시합니다. ‘무손실이면 출력 문자열이 동일하다’는 말은 샘플링 분포와 특정한 무작위 결과를 혼동한 것입니다.

가장 큰 비용을 초래하는 실수는 한산한 엔드포인트의 결과를 프로덕션 처리 용량의 근거로 삼는 일입니다. 개발자 한 명에게는 코딩 어시스턴트가 빨라 보이는데, 공유 엔드포인트가 감당하는 동시 세션 수는 줄어들 수 있습니다. 응답 지연 시간, 지속 처리량, 또는 둘 모두 중 무엇을 최적화할지 정하고 배포 확대 기준에 명시해야 합니다.

다음 주에 실행할 도입 절차

개발자는 디코딩이 병목일 때 호환되는 제안기를 시험합니다. 운영자는 프로덕션 부하에서도 이득이 나는지 확인해야 합니다. 호스팅 API 팀은 제공업체가 실제로 문서화한 설정부터 검토합니다.

대기 시간 대부분이 생성 전에 발생한다면 그 병목부터 해결해야 합니다. 초안을 올릴 메모리가 부족하거나 호환되는 체크포인트가 없다면 타깃을 기존 방식으로 운영하면 됩니다. 기능이 존재한다는 사실만으로 현재 배포 환경에 그 기능이 필요하다고 판단할 수는 없습니다.

개발자가 자주 묻는 질문

AI 시스템 구축과 운영에 관한 실용적인 가이드는 뉴스레터를 구독하면 받아볼 수 있습니다.