추측 디코딩(Speculative Decoding)이란? LLM이 여러 토큰을 미리 검증하는 방법

TL;DR

추측 디코딩은 빠른 초안 방식이 여러 후보 토큰을 먼저 만들고, 큰 목표 모델이 후보를 한 번에 검증하는 LLM 추론 최적화 기술입니다. 후보가 많이 받아들여지면 큰 모델의 순차 실행 횟수가 줄어 응답이 빨라집니다. 다만 초안 비용, 후보 수락률, 배치 크기와 하드웨어 조건에 따라 이득이 달라지며, 올바른 검증 규칙을 쓸 때 목표 모델의 출력 분포를 유지합니다.

핵심 3줄 요약

• 핵심 1
  초안과 검증을 나눕니다. 가벼운 방식이 토큰 후보를 제안하고 목표 LLM이 채택 여부를 결정합니다.
• 핵심 2
  여러 토큰을 한 번에 확인합니다. 채택된 후보만큼 생성이 앞으로 진행돼 순차 실행 횟수가 줄어듭니다.
• 핵심 3
  항상 빨라지는 것은 아닙니다. 수락률, 초안 모델 비용, 메모리, 배치 크기와 구현 호환성을 함께 측정해야 합니다.

이 글에서 다룰 내용

추측 디코딩을 한 문장으로 정의하면 무엇인가요?

추측 디코딩(Speculative Decoding)은 빠른 초안 메커니즘이 다음 토큰 후보 여러 개를 제안하고, 목표 언어 모델이 그 후보들을 병렬로 검증해 순차 디코딩 단계 수를 줄이는 추론 가속 방법입니다.

일반적인 LLM은 앞에서 만든 토큰을 바탕으로 다음 토큰 하나를 고른 뒤 다시 모델을 실행합니다. 긴 답변을 만들수록 이 순서를 여러 번 반복해야 합니다. 추측 디코딩은 작은 보조 모델이나 더 가벼운 후보 생성 방식으로 몇 토큰을 먼저 예상한 다음, 큰 목표 모델이 한 번의 실행에서 후보들의 확률을 계산하도록 합니다.

여기서 초안은 최종 답이 아닙니다. 목표 모델이 받아들인 토큰만 출력에 들어가고, 맞지 않는 지점에서는 목표 모델의 결과로 수정합니다. 원 논문이 제시한 정확한 샘플링 절차는 목표 모델의 출력 분포를 바꾸지 않으면서 이 과정을 수행합니다.

한 줄 정리: 작은 쪽이 답을 대신 쓰는 것이 아니라, 큰 모델이 빠르게 검사할 후보를 미리 준비합니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 긴 안내문을 검수한다고 가정해 보겠습니다. 빠른 조수가 다음 문장에 들어갈 단어 다섯 개를 연필로 먼저 적고, 전문 편집자가 그 다섯 개를 한꺼번에 살펴봅니다. 앞의 네 단어가 알맞고 다섯째가 틀렸다면 네 단어는 그대로 채택하고 다섯째부터 다시 고칩니다.

LLM에서도 초안 방식이 후보 토큰을 몇 개 만듭니다. 목표 모델은 후보가 이어진 전체 구간을 한 번에 계산해 앞에서부터 어느 지점까지 받아들일지 정합니다. 세 토큰을 채택했다면 큰 모델을 토큰마다 세 번 따로 실행하는 대신 한 번의 검증으로 세 칸을 전진한 셈입니다.

조수가 자주 맞힐수록 편집자는 빠르게 넘어갑니다. 반대로 후보가 첫 토큰부터 자주 틀리면 초안을 만드는 시간만 더해져 이득이 줄어듭니다. 그래서 추측 디코딩의 성능은 초안 속도와 후보 수락률의 균형으로 판단해야 합니다.

쉬운 예시: 초안은 연필 메모이고 목표 모델의 검증이 최종 승인입니다. 승인되지 않은 후보는 그대로 공개되지 않습니다.

왜 LLM 추론에서 추측 디코딩이 중요한가요?

토큰 하나씩 기다리는 순차 구간을 줄입니다

자기회귀 언어 모델은 새 토큰이 앞선 토큰에 의존하므로 기본 디코딩이 순차적으로 진행됩니다. 모델의 한 번 실행이 빨라도 수십 개나 수백 개 토큰을 만들면 그 실행이 계속 이어집니다. 추측 디코딩은 한 번의 목표 모델 검증에서 여러 후보 위치를 계산해 이 순차 단계 수를 줄입니다.

큰 모델의 비싼 실행 횟수를 아낍니다

초안 모델이 목표 모델보다 충분히 가볍고 후보가 자주 채택되면, 큰 모델이 수행하는 비싼 순방향 실행 횟수가 감소합니다. Google Research의 원 논문은 기존 모델을 다시 학습하거나 구조를 바꾸지 않고도 정확한 디코딩을 가속할 수 있음을 보였고, T5-XXL 실험에서 당시 구현 대비 2배에서 3배의 속도 향상을 보고했습니다. 이 수치는 모든 모델과 작업에 그대로 적용되는 보장값은 아닙니다.

낮은 지연 시간이 중요한 서비스에 도움이 됩니다

대화형 챗봇, 코드 자동완성, 실시간 보조 도구는 첫 토큰 뒤의 연속 생성 속도도 사용자 경험에 큰 영향을 줍니다. NVIDIA TensorRT-LLM 문서는 추측 디코딩을 낮은 배치 크기에서 LLM 추론을 가속하는 기술로 설명합니다. 서버가 이미 큰 배치로 충분히 활용되고 있다면 추가 이득이 작아질 수 있습니다.

핵심 인사이트: 추측 디코딩은 모델의 지식을 늘리는 학습법이 아니라, 같은 목표 모델의 출력을 더 적은 순차 단계로 얻으려는 실행 기술입니다.

추측 디코딩은 어떤 순서로 작동하나요?

1. 초안 방식이 후보 토큰을 만듭니다

가장 익숙한 구성은 작은 보조 모델이 다음 토큰 여러 개를 빠르게 생성하는 방식입니다. 하지만 초안은 꼭 별도 모델일 필요가 없습니다. Hugging Face 문서는 프롬프트에서 반복되는 n-gram을 찾는 Prompt Lookup, 같은 모델의 중간 층을 활용하는 Self-speculative Decoding, 추가 예측 층을 쓰는 MTP 같은 방법도 소개합니다.

2. 목표 모델이 후보 구간을 한 번에 계산합니다

목표 모델은 초안 토큰이 붙은 구간을 입력으로 받아 각 위치의 다음 토큰 분포를 계산합니다. 하드웨어가 여러 위치의 계산을 병렬로 처리할 수 있어, 짧은 후보 구간 전체를 검사하는 시간이 목표 모델로 토큰 하나를 만드는 시간과 비슷해질 수 있다는 점을 이용합니다. 실제 비용은 모델, 장치와 구현에 따라 달라집니다.

3. 앞에서부터 후보를 채택하거나 거절합니다

검증 결과에 따라 후보의 앞부분을 채택합니다. 그리디 디코딩에서는 목표 모델이 고른 토큰과 후보가 일치하는 동안 이어서 받아들이는 방식이 이해하기 쉽습니다. 확률 샘플링에서는 수정된 거절 샘플링 규칙을 사용해 목표 모델의 분포를 보존하면서 채택 여부와 보정 토큰을 정합니다.

4. 채택된 위치 다음부터 과정을 반복합니다

후보 네 개 중 세 개가 채택됐다면 출력은 세 토큰만큼 전진합니다. 거절된 후보 뒤의 계산과 캐시는 구현 규칙에 따라 버리거나 되감고, 새 위치에서 다시 초안을 만듭니다. 이 반복에서 한 번의 목표 모델 실행당 평균 몇 토큰이 채택되는지가 중요한 운영 지표입니다.

한 줄 정리: 제안 → 일괄 검증 → 앞부분 채택 → 거절 지점 보정의 순환이 기본 구조입니다.

속도 향상은 무엇에 따라 달라지나요?

후보 토큰 수락률

목표 모델이 초안 후보를 자주 받아들일수록 한 번의 검증으로 더 멀리 갑니다. 코드 완성처럼 다음 표현이 비교적 예측하기 쉬운 작업과, 창의적 문장처럼 후보가 자주 갈리는 작업은 수락률이 다를 수 있습니다. 전체 평균뿐 아니라 작업 유형과 입력 길이별 수락률을 나눠 보는 편이 좋습니다.

초안 생성 비용

보조 모델이 목표 모델보다 작아도 후보를 너무 길게 만들거나 별도 장치 사이에서 데이터를 자주 옮기면 비용이 커집니다. 초안이 빠르고 가벼워야 목표 모델 실행을 줄인 이득이 남습니다. 후보 길이는 길수록 무조건 좋은 값이 아니라 수락률과 초안 비용을 함께 보고 조정하는 값입니다.

배치 크기와 하드웨어 활용률

추측 디코딩은 목표 모델이 토큰 하나를 생성할 때 남는 병렬 계산 여력을 후보 검증에 활용합니다. 낮은 배치에서는 이 여력이 클 수 있지만, 큰 배치로 GPU가 이미 바쁘면 여러 후보를 검증하는 비용이 더 뚜렷해집니다. 서비스의 실제 동시 요청 수로 측정해야 합니다.

토크나이저와 모델 호환성

고전적인 초안 모델 방식은 두 모델이 같은 토크나이저를 쓸 때 구현이 단순하고 후보 정렬도 쉽습니다. NVIDIA 문서는 토크나이저가 다르면 수락률이 매우 낮아져 성능이 나빠질 수 있다고 경고합니다. Hugging Face의 Universal Assisted Decoding처럼 서로 다른 토크나이저를 다시 인코딩해 맞추는 구현도 있지만 추가 처리 비용과 지원 조건을 확인해야 합니다.

추측 디코딩과 헷갈리는 용어는 무엇이 다른가요?

자기회귀 디코딩과 추측 디코딩의 차이

자기회귀 디코딩은 앞선 토큰을 보고 다음 토큰을 순서대로 만드는 기본 생성 방식입니다. 추측 디코딩도 최종적으로는 목표 자기회귀 모델의 판단을 따르지만, 여러 후보를 미리 만들고 함께 검증해 순차 실행 횟수를 줄입니다. 모델의 생성 원리를 없애는 것이 아니라 실행 일정을 바꾸는 최적화입니다.

KV 캐시와 추측 디코딩의 차이

KV 캐시는 앞선 토큰에서 계산한 어텐션의 Key와 Value를 저장해 같은 과거 구간을 다시 계산하지 않도록 합니다. 추측 디코딩은 미래 후보를 먼저 만들고 여러 위치를 함께 검증합니다. 둘은 해결하는 낭비가 달라 함께 사용할 수 있으며, 거절된 후보의 캐시를 안전하게 되감는 구현이 필요합니다.

빔 서치와 추측 디코딩의 차이

빔 서치는 점수가 높은 여러 문장 후보를 단계마다 유지해 최종 출력 후보를 고르는 탐색 방법입니다. 추측 디코딩의 후보는 최종 문장 여러 개를 경쟁시키려는 것이 아니라 목표 모델의 디코딩을 빨리 진행하려는 임시 초안입니다. 빔 폭과 초안 길이는 역할이 다른 설정입니다.

추측 샘플링과 추측 디코딩의 차이

두 표현은 실무에서 겹쳐 쓰입니다. 추측 디코딩은 초안과 검증을 이용한 가속 틀을 넓게 가리키고, 추측 샘플링은 확률적으로 토큰을 뽑을 때 목표 분포를 보존하는 채택·거절 절차를 강조합니다. 사용하는 라이브러리 문서가 어느 범위를 뜻하는지 확인하세요.

병렬 디코딩과 추측 디코딩의 차이

병렬 디코딩은 여러 토큰이나 후보를 동시에 계산하는 방법 전체를 가리키는 넓은 표현입니다. 추측 디코딩은 그중에서도 저렴한 초안과 목표 모델의 검증을 결합합니다. 모든 병렬 생성 기법이 정확한 추측 디코딩의 분포 보존 규칙을 따르는 것은 아닙니다.

비교 정리: KV 캐시는 과거 계산 재사용, 빔 서치는 후보 탐색, 추측 디코딩은 미래 초안의 일괄 검증에 초점이 있습니다.

실전에서는 어디에 쓰이나요?

대화형 LLM 응답

사용자 한 명의 요청을 낮은 배치로 빠르게 처리해야 하는 챗봇과 개인 비서에서 활용할 수 있습니다. 반복적으로 긴 답을 만드는 서비스라면 초당 출력 토큰 수와 토큰 간 지연 시간의 변화를 함께 측정합니다.

코드 자동완성과 코드 수정

코드는 반복되는 구문과 주변 문맥의 패턴이 많아 초안 후보가 잘 맞는 구간이 생길 수 있습니다. 작은 코드 모델이나 프롬프트의 기존 n-gram을 후보로 쓰는 방식을 검토할 수 있지만, 언어·저장소·작업 유형별 수락률을 따로 확인해야 합니다.

요약과 번역

요약과 번역은 입력 문장의 표현이 출력에 다시 나타나는 구간이 있어 Prompt Lookup 같은 후보 생성 방식이 맞을 수 있습니다. 원 논문도 번역과 요약에서 가속 효과를 실험했습니다. 사실성이나 번역 품질은 속도 지표와 별도로 평가해야 합니다.

자체 호스팅 LLM 서빙

TensorRT-LLM이나 Transformers처럼 추측 디코딩을 지원하는 추론 도구에서 초안 모델, 후보 길이와 관련 설정을 구성할 수 있습니다. 기능 지원 여부만 보고 켜기보다 현재 모델 조합, GPU 메모리, 동시 요청 수와 폴백 동작을 먼저 시험합니다.

실전 팁: 평균 속도 하나보다 p50·p95 지연, 초당 토큰 수, 수락률, 메모리 사용량을 같은 요청 묶음에서 비교하세요.

도입할 때 어떤 순서로 확인하나요?

1. 현재 디코딩 기준값을 기록합니다

추측 디코딩을 끈 상태에서 같은 모델, 프롬프트, 출력 길이와 샘플링 설정으로 지연 시간과 처리량을 측정합니다. 첫 토큰 지연과 이후 토큰 간 지연을 나누면 어느 구간이 달라졌는지 읽기 쉽습니다.

2. 지원되는 초안 방식을 고릅니다

별도 보조 모델, 프롬프트 조회, 자체 추측, MTP 중 현재 런타임과 체크포인트가 지원하는 방식을 확인합니다. 문서의 예시 모델 조합과 토크나이저 조건을 그대로 검토한 뒤 작은 테스트 요청으로 기능을 확인합니다.

3. 후보 길이와 수락률을 함께 봅니다

후보 길이를 몇 가지 값으로 바꾸고 목표 모델 실행당 채택 토큰 수를 기록합니다. 후보가 길어져도 뒤쪽이 자주 거절되면 계산과 캐시만 늘 수 있습니다. 작업 유형별로 이득이 다른지도 구분합니다.

4. 실제 배치와 동시성으로 부하 시험합니다

개발 환경의 단일 요청에서 빨랐더라도 운영 서버의 동시 요청에서는 결과가 바뀔 수 있습니다. 평소 배치 크기, 최대 입력 길이와 출력 길이를 반영해 p95 지연과 처리량을 다시 비교합니다.

5. 품질과 분포 보존 조건을 확인합니다

그리디 생성이라면 기준 출력과 토큰 단위로 비교하고, 샘플링이라면 구현이 정확한 분포 보존 절차를 지원하는지 문서에서 확인합니다. 완화된 채택 규칙이나 근사 모드는 더 빠를 수 있지만 표준 추측 디코딩과 같은 품질 보장을 자동으로 갖지 않습니다.

한 줄 정리: 기능을 켠 뒤 빨라 보이는지 보는 대신, 동일 조건 기준값과 품질 검사를 먼저 고정해야 합니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 속도 향상을 보장값으로 쓰지 않습니다. 논문이나 문서의 배수는 특정 모델, 하드웨어와 작업에서 나온 결과입니다. 자체 서비스의 입력 길이, 출력 길이, 배치 크기와 동시성으로 다시 측정하세요.

둘째, 초안 모델의 메모리 비용을 포함합니다. 작은 모델이라도 가중치와 KV 캐시가 추가됩니다. GPU 메모리가 부족해 오프로딩이나 장치 간 전송이 생기면 지연이 오히려 늘 수 있습니다.

셋째, 같은 토크나이저 조건을 확인합니다. 전통적인 보조 모델 구성에서는 토큰 ID와 어휘가 맞아야 후보를 곧바로 검증하기 쉽습니다. 서로 다른 토크나이저를 지원하는 구현은 재인코딩 방식과 제한을 따로 확인하세요.

넷째, 정확한 검증과 근사 모드를 구분합니다. 표준 알고리즘의 목표 분포 보존은 정해진 채택·보정 규칙을 제대로 구현했을 때 성립합니다. 수락률을 높이려고 검증을 완화한 옵션은 출력 분포를 바꿀 수 있습니다.

다섯째, 평균만 보지 않습니다. 초안이 잘 맞는 요청과 맞지 않는 요청의 차이가 클 수 있습니다. p95 지연, 최악 구간, 오류율과 폴백 결과까지 확인해야 운영 중 느린 요청을 놓치지 않습니다.

주의: 추측 디코딩은 모델의 사실 오류나 환각을 고치는 안전장치가 아닙니다. 속도 검증과 답변 품질·안전성 평가는 따로 수행해야 합니다.

자주 묻는 질문

Q1. 작은 모델이 만든 답을 그대로 쓰는 방식인가요?

아닙니다. 작은 모델이나 가벼운 방식은 후보 토큰을 제안할 뿐입니다. 목표 모델이 후보를 검증하고, 받아들인 토큰만 최종 출력에 들어갑니다.

Q2. 추측 디코딩을 쓰면 답변 품질이 떨어지나요?

원 논문이 제시한 정확한 검증과 샘플링 규칙을 따르면 목표 모델의 출력 분포를 유지합니다. 다만 일부 구현의 완화된 채택 옵션이나 근사 방식은 분포를 바꿀 수 있으므로 문서를 확인해야 합니다.

Q3. 항상 작은 보조 모델이 필요한가요?

필수는 아닙니다. 작은 보조 모델이 대표적이지만 프롬프트의 반복 구간을 찾는 방식, 같은 모델의 중간 층, 여러 토큰 예측용 추가 층처럼 다른 초안 방식도 있습니다. 런타임과 모델이 지원하는 구성을 선택합니다.

Q4. KV 캐시를 쓰면 추측 디코딩은 필요 없나요?

둘은 역할이 다릅니다. KV 캐시는 과거 토큰 계산을 재사용하고, 추측 디코딩은 미래 후보를 한 번에 검증합니다. 많은 구현에서 두 기술을 함께 쓰지만 거절된 후보의 캐시 처리까지 지원해야 합니다.

Q5. 어떤 지표로 효과를 판단해야 하나요?

첫 토큰 지연, 토큰 간 지연, 전체 응답 시간, 초당 출력 토큰 수, 목표 모델 실행당 채택 토큰 수, 후보 수락률과 GPU 메모리를 함께 봅니다. 운영 배치 크기에서 p50과 p95를 비교하면 평균값의 착시를 줄일 수 있습니다.

출처

마무리

추측 디코딩은 빠른 초안 방식이 여러 후보 토큰을 먼저 만들고 목표 LLM이 한 번에 검증하도록 해 순차 생성 단계를 줄이는 추론 최적화 기술입니다. 후보가 잘 맞으면 큰 모델의 비싼 실행 한 번으로 여러 토큰을 채택할 수 있습니다.

도입할 때는 작은 모델 하나를 붙이는 데서 끝내지 마세요. 토크나이저 호환성, 초안 비용, 수락률, 배치 크기와 GPU 메모리를 함께 확인해야 합니다. 같은 요청 묶음으로 기준값과 품질을 비교하면 추측 디코딩이 실제 서비스에 도움이 되는지 안전하게 판단할 수 있습니다.