현재 LLM 추론 가속화 분야에서 가장 뜨거운 주제 중 하나는 **Speculative Decoding (추측적 디코딩)**입니다.

DSpark는 동일한 처리량(throughput)에서 60%~85%의 단일 사용자 속도 향상을 주장합니다. Google은 SpecTr, block verification, SpecRouter 등 이와 관련된 일련의 연구를 발표해 왔습니다.

듣기에는 아주 좋아 보이죠? 작은 모델(draft model, 초안 모델)이 초안을 작성하면, 큰 모델이 이를 배치 검증(batch-verify)하여 속도를 높이는 방식입니다.

하지만 이를 지켜보는 프로덕션 엔지니어라면 즉시 두 가지 질문이 떠오를 것입니다:

"블록 생성(Block generation) — 이것이 환각(hallucination)을 증폭시키지 않을까요?"

"적중 여부와 상관없이 추가 모델을 실행하고 있는데 — 이것은 컴퓨팅 자원(compute) 낭비 아닌가요?"

이 두 질문은 Speculative Decoding의 수학적 약속과 엔지니어링 비용의 핵심을 정확히 찌릅니다.

과장이나 공포(FUD) 없이, 수치를 통해 살펴보겠습니다.

1. 수학적 약속: 왜 블록 생성이 환각을 증폭시키지 않는가

이 부분은 Speculative Decoding에서 가장 오해를 많이 받는 부분입니다. 직관적으로는 "5개의 토큰을 추측했는데, 하나만 틀려도 나머지는 쓰레기가 된다"라고 생각할 수 있으며, 이는 맞습니다. 하지만 Speculative Decoding은 바로 그 "쓰레기"가 "틀린 것"이 되지 않도록 설계되었습니다.

검증 메커니즘은 "모두 수락하거나 모두 거부하는" 방식이 아니라, **토큰 단위(token-by-token)**로 이루어집니다.

초안 모델(draft model)이 후보 블록 [t1, t2, t3, t4, t5]를 생성합니다. 타겟 모델(target model)은 단 한 번의 순전파(forward pass)로 5개 위치 모두를 검증합니다. 결과는 다음과 같습니다:

• t1 정답 → 수락
• t2 정답 → 수락
• t3 오답 → 거부; 타겟 모델은 t3부터 다시 생성함
• t4, t5 → 폐기 (잘못된 t3를 기반으로 생성되었기 때문)

모든 출력 토큰은 타겟 모델에 의해 확인되었습니다. 환각이 "증폭"되는 것이 아니라, 첫 번째 오류 지점에서 단순히 잘려 나가는 것입니다. 확률 분포 측면에서 Speculative Decoding의 출력은 타겟 모델의 자기회귀(autoregressive) 출력과 **수학적으로 동일(mathematically equivalent)**하며, 이는 증명 가능한 속성입니다.

따라서 첫 번째 질문에 대한 답은 다음과 같습니다: 손실 없는 품질(lossless quality). 그 약속은 유효합니다.

한 가지 주의할 점은: 이 등가성은 초안 모델(draft model)과 타겟 모델(target model)이 **동일한 토크나이저 (tokenizer)**를 공유한다는 것을 전제로 합니다. 만약 두 모델이 서로 다르다면 (예: 하나는 BPE를 사용하고 다른 하나는 Unigram을 사용하는 경우), 검증 과정에서 정렬 오버헤드 (alignment overhead)가 발생할 것입니다. 이는 Speculative Decoding의 버그가 아니라, 프로덕션에 배포하기 전에 반드시 확인해야 할 사항입니다.

2. 엔지니어링 비용: 왜 "손실 없음"이 "공짜"는 아닌가

두 번째 질문은 답하기 더 어렵습니다.

"어쨌든 추가 모델을 실행하고 있는데" — 이 비용을 어떻게 계산해야 할까요?

먼저 전제 조건이 있습니다: 소형 모델의 순전파 (forward pass) 비용은 일반적으로 타겟 모델 비용의 1/10에서 1/20 정도입니다. 이는 Speculative Decoding의 핵심 가정이 초안 모델이 _작다_는 것이기 때문입니다. 흔히 사용되는 조합은 70B 모델을 위해 7B 모델을 초안 모델로 사용하는 것입니다. 아래의 모든 수학적 계산은 이 가정을 바탕으로 합니다.

초안 길이(draft length)가 5인 세 가지 시나리오를 살펴보겠습니다:

시나리오 A: 완전 적중 (최선의 경우)

시나리오 B: 완전 불일치 (최악의 경우)

시나리오 C: 부분 적중 (일반적인 경우)

패턴이 보이시나요? Speculative Decoding은 "항상 더 빠른" 것이 아닙니다. 이것은 고위험 고수익 (high-risk, high-reward) 베팅입니다. 성공하면 연산 자원을 아끼지만, 실패하면 추가 비용을 지불해야 합니다.

3. 핵심 부등식: Speculative Decoding이 이득을 보는 시점은 언제인가?

위의 수학적 내용을 하나의 부등식으로 공식화해 보겠습니다.

다음과 같이 정의합니다:

• k = 초안 길이 (draft length, 추측당 토큰 수)
• α = 타겟 모델 대비 초안 모델의 연산 비율 (compute ratio, 7B/70B 쌍의 경우 α ≈ 0.05–0.1)
• β = 토큰당 검증 단계 오버헤드 (verification phase overhead)
• a = 평균 수락 길이 (average acceptance length, 라운드당 검증을 통과하는 토큰 수)

Speculative Decoding이 자기회귀 (autoregressive) 방식보다 엄격하게 더 나은 경우는 다음과 같습니다:

a > 1 + α + β

즉, 말로 풀어서 설명하면: 평균 수락 길이(a)가 1을 초과해야 하며 (라운드당 최소 한 개의 토큰은 수락되어야 함), 그 초과분이 초안 모델의 연산 및 검증 오버헤드를 상쇄할 수 있어야 합니다.

• a = 5 (모두 적중) → 큰 이득 (big win)
• a = 1 (한 개 적중) → 순손실 (net loss) — 초안 실행을 위해 비용을 지불했지만 얻은 것이 없음
• a < 1 (적중 없음) → 심각한 손실 (severe loss) — 아예 사용하지 않는 것보다 느림

k를 어떻게 선택할 것인가? 너무 작으면 속도 향상이 미미합니다. 너무 크면 거의 확실히 거절될 꼬리 토큰(tail tokens)들에 연산을 낭비하게 됩니다. 엔지니어링 경험에 따르면: k = 4–6이 최적의 지점(sweet spot)입니다. 4 미만이면 가속 효과를 거의 느낄 수 없고, 6을 넘어가면 한계 효용이 급격히 감소합니다.

분포 변화(distribution shift)의 함정. 만약 작업 분포가 초안 모델의 학습 분포와 크게 다르다면 — 예를 들어, 70B 모델의 시(poetry) 작성을 위해 7B 모델을 초안 모델로 사용하는 경우 — 7B 모델은 70B 모델이 단어를 어떻게 선택할지 전혀 알 수 없습니다. 이 경우 수락률(acceptance rate)이 10% 미만으로 떨어질 수 있습니다. 그 시점에는 a < 1이 되며, Speculative Decoding은 자기회귀 방식보다 엄격하게 더 나쁜 성능을 보입니다. 그리고 k가 증가할수록 상황은 더 악화됩니다. 이것이 실제 운영 환경(production)에서 주의 깊게 살펴봐야 할 가장 중요한 요소입니다.

Speculative Decoding이 하는 일은 결국 매 라운드마다 이 부등식 게임을 수행하는 것뿐입니다.

빠른 현실 점검: 실제로 잘 매칭된 초안/대상(draft/target) 쌍(동일 계열, 유사한 학습 데이터)은 코드 및 구조화된 텍스트 작업에서 a = 2.5–4.0을 달성하며, 이는 1 + α + β 임계값을 여유롭게 상회합니다. 매칭되지 않은 쌍(서로 다른 모델 계열, 서로 다른 토크나이저(tokenizer), 또는 자유 형식 대화와 같은 고엔트로피(high-entropy) 작업)은 종종 a = 1.0–1.5에 머무르며, 오버헤드(overhead)가 이득을 갉아먹는 한계 영역에 위치하게 됩니다. 이것이 바로 성능 차이가 _모델 크기_보다 _작업(task)_에 따라 더 크게 나타나는 이유입니다.

4. 자신의 수락률(Acceptance Rate) 측정하기 — 월요일 아침 체크리스트

어떤 벤치마크(benchmark)라도 맹신하기 전에, 직접 자신의 a를 측정하십시오.

방법은 다음과 같습니다:

1단계: 검증 경계(verification boundary)에 계측 도구 설치. 초안 모델(draft model)과 대상 모델(target model)의 검증 단계 사이에 로깅 훅(logging hook)을 삽입하십시오. 각 요청에 대해 초안 길이 k, 수락 길이 a, 그리고 재생성(regeneration) 단계 횟수를 기록하십시오. SD(Speculative Decoding)를 지원하는 모든 추론 프레임워크(TensorRT-LLM, speculative decoding 기능이 포함된 vLLM, assistant_model을 사용하는 HF generate())는 이러한 카운터(counter)를 노출하거나, 약 50줄 정도의 코드로 직접 패치하여 구현할 수 있습니다.

2단계: 작업 유형별로 500개 이상의 샘플 수집. 모든 트래픽을 평균 내지 마십시오. 코드 완성(code completion) 요청과 창의적 글쓰기(creative writing) 요청은 a 값이 극명하게 다를 것입니다. 다음 기준으로 분류하십시오: 작업 카테고리, 프롬프트(prompt) 길이 버킷, 응답 길이 버킷. 버킷당 500개의 샘플을 확보하면 안정적인 평균값과 유용한 p50/p90/p99 분포를 얻을 수 있습니다.

3단계: 최하위 10% 구간(worst decile) 확인. 평균 a가 3.2일지라도, 하위 10%의 요청에서 a < 1이 나타난다면, 해당 요청들은 SD를 사용하지 않았을 때보다 _더 많은 비용을 지불_하고 있는 셈입니다. 지연 시간(latency)에 민감한 시스템에서는 평균보다 p10 a 값이 더 중요합니다.

4단계: 버킷별로 부등식 실행. 각 버킷의 a 값을 a > 1 + α + β에 대입하십시오. 만약 코드 완성은 통과하지만 자유 형식 대화가 실패한다면, 다음과 같은 배포 전략을 세울 수 있습니다: 코드 경로에는 SD를 활성화하고, 채팅 경로에는 SD를 비활성화하십시오.

이것은 선택적인 보정(calibration)의 문제가 아닙니다. 이는 "SD가 지연 시간(latency)을 40% 절감한다"와 "SD가 p99를 악화시키는데 원인을 파악할 수 없다" 사이의 차이입니다.

5. DSpark의 강점: 신뢰도 기반 스케줄링 (Confidence-Based Scheduling)

위의 불평등 관계를 이해하고 나면, DSpark의 핵심 기여가 명확해집니다: 바로 **신뢰도 기반 스케줄링 (Confidence-based Scheduling)**입니다.

DSpark는 초안 모델(draft model)에 신뢰도 헤드(confidence head)를 추가합니다. 각 초안 토큰(draft token)에 대해 "생존 확률(survival probability)"을 출력합니다. 스케줄러는 이를 사용하여 검증할 토큰의 수를 동적으로 결정합니다:

• 신뢰도가 높은 접미사(suffix) → 더 많은 토큰을 검증; 더 긴 블록, 더 큰 속도 향상
• 신뢰도가 낮은 접미사(suffix) → 조기에 절단(truncate); 틀릴 가능성이 높은 토큰을 검증하느라 연산 자원(compute)을 낭비하지 않음

불평등 프레임워크 관점에서 보면: DSpark는 신뢰도 헤드를 통해 k를 동적으로 조정하며, 낭비되는 오버헤드 α를 최소화하는 동시에 기대 수락 길이(expected acceptance length) a를 최대화합니다.

성공하면 가속화하고, 실패하면 손실을 조기에 차단합니다. 이는 Speculative Decoding을 맹목적인 베팅에서 정보에 기반한 도박(informed gambling)으로 탈바꿈시킵니다.

6. 그래서, 사용할 가치가 있는가?

이것은 예/아니오의 문제가 아닙니다. "상황에 따라 다르다"가 정답입니다.

이럴 때 사용하세요:

• 작업 분포(task distribution)가 예측 가능하고 초안 모델의 적중률(hit rate)이 높을 때 (코드 완성, 일반적인 QA 패턴)
• 요청당 속도 향상이 복리로 작용하는 배치 추론(batched inference)을 수행할 때
• 타겟 모델과 토크나이저(tokenizer)를 공유하는 작은 모델을 이미 보유하고 있을 때

이럴 때는 사용하지 마세요:

• 작업이 개방형이고 예측 불가능하며, 초안 모델의 추측을 신뢰할 수 없을 때 (창의적 글쓰기, 복잡한 추론 — 적중률이 급락할 수 있음)
• 요청량이 적어 추가 모델 배포에 따른 오버헤드를 상쇄(amortize)할 수 없을 때
• 지연 시간에 민감하며 악화된 p99 꼬리 지연(tail latency)을 허용할 수 없을 때 (완전히 실패할 경우, SD는 더 느리기 때문입니다)

실용적인 규칙:

대규모 LLM 추론 (inference)을 수행하고 있다면, Speculative Decoding (추측적 디코딩)을 검토할 가치가 있습니다. 하지만 "85% 속도 향상"이라는 수치를 맹신하지 마세요. 당신의 데이터와 당신의 모델 쌍으로 A/B 테스트를 수행하십시오. 실제 수락률 (acceptance rate)을 측정하세요. 그리고 이를 a > 1 + α + β 식에 대입해 보십시오.

조건이 충족된다면 사용하십시오. 충족되지 않는다면 사용하지 마십시오. 간단합니다.

결론 (Closing)

Speculative Decoding은 초안 작성 및 검증 (draft-verify) 메커니즘을 통해 손실 없는 품질과 더 빠른 추론을 제공하는 우아한 수학적 체계입니다.

하지만 손실 없음(lossless)이 곧 공짜(free)를 의미하지는 않습니다.

이 방식이 환각 (hallucination)을 증폭시키지는 않습니다. 하지만 연산 오버헤드 (compute overhead)를 추가합니다. 적중률 (hit rate)이 높을 때, 그 오버헤드는 상당한 가속을 가져다줍니다. 하지만 적중률이 낮을 때, 이는 단순히 가속에 실패하는 것을 넘어 시스템의 속도를 늦춰버립니다.

최고의 최적화 기술은 항상 승리하는 기술이 아니라, 언제 꺼야 하는지를 알고 있는 기술입니다.

다음에 수락률 (acceptance rate)이나 최악의 경우의 동작 (worst-case behavior)에 대한 언급 없이 오직 "X% 속도 향상"만을 보고하는 Speculative Decoding 논문을 보게 된다면, 이 포스트를 그들에게 보내주십시오.