Speculative Decoding 벤치마크 결과 — a = 3.5는 충분하지 않았다

지난 포스트에서 저는 Speculative Decoding (추측적 디코딩)의 핵심 불평등 관계를 설명했습니다:

a > 1 + α + β

수락 길이(Acceptance length) a는 1에 초안/대상 연산 비율(draft/target compute ratio) α와 검증 오버헤드(verification overhead) β를 더한 값보다 커야 합니다. 이 조건을 만족하면 SD가 승리하고, 만족하지 못하면 SD는 패배합니다.

그것은 이론이었습니다. 이 포스트는 실전입니다.

제 컴퓨터에서 실제 A/B 테스트를 수행했습니다. 결과는 예상보다 좋지 않았지만, 더 흥미로웠습니다.

테스트 내용

하드웨어: 12세대 Intel, 64GB RAM (CPU 전용). 네, 이는 SD가 순수 속도 면에서는 항상 패배할 수밖에 없음을 의미합니다. 그것이 핵심은 아니었습니다. 핵심은 다양한 작업 유형에 걸쳐 수락 길이(acceptance length) a를 측정하는 것이었습니다. 속도 수치는 부차적입니다. 그것들은 CPU에서의 불평등 관계를 확인해 줄 뿐이며, 실제 GPU 배포에 적용되는 것은 a 값입니다.

모델 쌍: Qwen2.5-0.5B-Instruct (초안/draft) → Qwen2.5-1.5B-Instruct (대상/target). 동일한 모델 제품군, 동일한 토크나이저(tokenizer)를 사용하는, 어떤 기준으로 보더라도

작업 (Task)	평균 a (Mean a)	중앙값 a (Median a)	p10 a	Zero-accept rounds	Raw t/s	SD t/s	Speedup
code	3.00	4.0	0.0	23.8%	1.9	0.8	-56%
...
Speculative Decoding (SD)은 세 가지 작업 유형 모두에서 49-62% 더 느렸습니다.

수락 길이 (acceptance lengths)는 1 + α + β 임계값보다 훨씬 높았습니다. 하지만 SD는 여전히 패배했으며, 그 격차는 매우 컸습니다.

결과 1: 작업 유형이 모델 크기보다 더 큰 영향을 미친다

수락 길이는 작업에 따라 크게 달랐습니다:

• JSON (구조화된 데이터): a = 3.50 — 초안 모델 (draft model)이 잘 정의된 형식에 대해 대상 모델 (target model)이 생성할 내용을 안정적으로 예측할 수 있었습니다.
• Code (반구조화된 데이터): a = 3.00 — 여전히 양호하지만, 명명 규칙 (naming) 및 로직 패턴에서 변동성이 더 컸습니다.
• Story (창의적 글쓰기): a = 2.11 — 초안 모델이 개방형 텍스트에서 대상 모델의 단어 선택을 예측하는 데 어려움을 겪었습니다.

이는 이론 포스트에서 언급한 분포 변화 (distribution shift) 논거를 확인시켜 줍니다. 동일한 모델 쌍 (0.5B → 1.5B, 동일 제품군, 동일 토크나이저)이라도 무엇을 생성하느냐에 따라 매우 다른 수락률 (acceptance rates)을 보입니다. SD의 속도 향상 (speedup)은 모델 크기보다 작업 유형에 따라 더 크게 달라질 것입니다.

결과 2: 초안 라운드의 16-30%가 낭비된다

가장 놀라운 지표는 평균 a가 아니라, 바로 **zero-accept rate (수락 토큰 0개 비율)**였습니다.

초안 라운드의 15-30%가 정확히 0개의 토큰만을 수락했습니다. 초안 모델이 작동하여 5개의 후보 토큰을 생성했지만, 단 하나도 수락되지 않은 것입니다. 이러한 라운드는 순수한 오버헤드 (overhead)입니다. 초안 실행 비용을 지불하고, 검증 (verification) 실행 비용을 지불했지만, 대상 모델로부터 단 하나의 토큰만을 얻었기 때문입니다.

a = 0인 라운드에서는:

• Raw 모드: 대상 모델 순전파 (forward pass) 1회, 1개 토큰 생성
• SD 모드: 대상 모델 1회 + 초안 모델 순전파 1회, 1개 토큰 생성

SD는 동일한 출력에 대해 2배의 비용이 들었습니다. 그리고 초안 모델은 공짜가 아니기에 — 0.5B 모델조차 실제 연산 비용 (compute cost)이 발생하므로 — 이러한 zero-accept 라운드들이 평균을 깎아먹는 주범입니다.

라운드별 a 값의 히스토그램 (histogram)이 이 상황을 잘 보여줍니다:

code:   [0 0 0 0 0 0 0 0 0 0 1 1 2 2 3 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5]
                            ^^^^^^^^^^                       ^^^^^^^^^^^^^^^^
                            23.8% 낭비 (wasted)               42.9% 완전 적중 (full hits)

최빈값(mode)은 5(완전 적중)이며, 두 번째 최빈값은 0(완전 실패)입니다. 평균(mean)은 3.0으로 그 중간 어디쯤에 위치하지만, 사용자 경험은 3.0이 아니라

Code (a = 3.0): 3.0 >> 1.07 ✅ 명확한 승리. 초안 토큰(Draft tokens)이 오버헤드(overhead)를 소모하는 속도보다 3배 더 빠르게 수락됨.JSON (a = 3.5): 3.5 >> 1.07 ✅ 명확한 승리. 초안 모델(draft model)이 구조화된 출력(structured output)에서 타겟 모델과 거의 완벽하게 일치함.Story (a = 2.1): 2.1 > 1.07 ✅ 근소한 승리. 임계값(threshold)은 넘었지만, 이득을 깎아먹는 '0-수락(zero-accept)' 라운드가 더 많음.

이 부등식은 유효합니다. Speculative Decoding (SD)이 GPU에서는 승리하고 CPU에서는 패배할 것임을 정확히 예측합니다. 또한 스토리 생성(story generation)이 코드 생성(code generation)보다 더 위험하다는 점도 정확히 예측합니다.

하지만 모든 것을 포착하지는 못합니다. '0-수락률(zero-accept rate)'은 별개의 차원이며, 이는 처리량(throughput)보다 p99 지연 시간(latency)에 더 큰 영향을 미칩니다. 만약 제가 부등식을 다시 작성한다면, 분산(variance) 항을 추가할 것입니다.

자신만의 a를 측정하는 방법 (20줄 이내)

복잡한 벤치마크 프레임워크는 필요하지 않습니다. 핵심 측정 루프는 다음과 같습니다:

def measure_acceptance(model, draft, tokenizer, prompt, k=5, max_tokens=128):
    """각 speculative generation 라운드에 대해 a와 k를 기록합니다."""
    inputs = tokenizer(prompt, return_tensors="pt")
...

위의 커스텀 루프를 사용하면 라운드별 로깅(logging)이 가능합니다. HuggingFace의 generate()를 사용 중이라면, 내장된 assistant_model 파라미터가 더 적은 코드로 동일한 가속을 제공하지만, 기본적으로 라운드별 a 값을 노출하지는 않습니다. 측정 시에는 커스텀 루프를 사용하고, 프로덕션(production) 환경에서는 내장 기능을 사용하세요.

작업 유형별로 100개 이상의 샘플에 대해 실행하고 작업 카테고리별로 나누십시오. 모든 트래픽을 평균 내지 마십시오. 코드 완성(code completions)과 채팅 응답(chat responses)은 매우 다른 a 값을 가질 것입니다.

프로덕션 엔지니어를 위한 네 가지 시사점

1. 벤더(vendor)의 벤치마크를 신뢰하기 전에 자신만의 a를 측정하십시오. 저희 모델 쌍은 작업에 따라 2.1에서 3.5 사이의 값을 달성했습니다. 누군가 "85% 속도 향상"이라고 주장한다면, 다음과 같이 물으십시오: 어떤 작업에서, 어떤 모델 쌍을 사용했으며, 수락률(acceptance rate)은 얼마였습니까?

2. 작업을 평균 내지 마십시오. 전체 워크로드에 대해 단일한 평균 $\alpha$ 값을 사용하는 것은 실제 상황을 가립니다. 트래픽 유형별로 나누십시오. 만약 코드 경로(code routes)의 $\alpha = 3.5$이고 채팅 경로(chat routes)의 $\alpha = 1.8$이라면, 코드 경로에만 SD (Speculative Decoding)를 활성화하십시오.

3. 평균뿐만 아니라 수락률 0(zero-accept rate)을 주시하십시오. 수락률 0의 비율이 높다는 것은 p99 지연 시간(latency)이 악화됨을 의미합니다. 2초 이내에 응답해야 하는 시스템에서, 30% 더 느려질 확률이 15%나 된다는 것은 용납될 수 없습니다.

4. SD는 GPU 최적화입니다. $\alpha$가 매우 작을 때(초안 모델(draft model)이 타겟 모델(target model)에 비해 거의 비용이 들지 않을 때) 효과적입니다. CPU 환경이나, 초안 모델이 타겟 모델과 메모리 대역폭(memory bandwidth)을 두고 경쟁하는 플랫폼에서는 해당 불평등 관계가 무너집니다. 반드시 타겟 하드웨어에서 벤치마크를 수행하십시오.

결론

이론은 SD가 손실이 없지만(lossless) 공짜는 아니라고 말합니다. 실제 사례는 이를 확인시켜 주며, 더 미묘한 차이(nuance)를 더합니다.

손실 없음(Lossless): 그렇습니다. 출력 분포(output distribution)는 동일합니다. 환각(hallucination)이 증폭되지 않았습니다.

공짜가 아님(Not free): 단순한 1 + α + β 모델이 시사하는 것보다 더 비용이 많이 듭니다. 수락률 0의 분산(variance), 작업에 따라 달라지는 $\alpha$, 그리고 하드웨어에 따라 달라지는 $\alpha$ 모두가 이론적인 속도 향상(speedup)을 갉아먹습니다.

불평등 관계는 여전히 유효합니다. 이 테스트의 모든 결과를 정확하게 예측했습니다. 하지만 $\alpha$의 점 추정치(point estimate)만으로는 충분하지 않습니다. 분포(distribution) 또한 필요합니다.

최고의 최적화 기술은 항상 승리하는 기술이 아닙니다. 언제 꺼야 하는지를 아는 기술입니다. 이제 여러분은 언제 꺼야 하는지를 측정하는 방법을 알게 되었습니다.

*Qwen2.5 모델, transformers 5.12, torch 2.12 (CPU), Python 3.14, Windows 10 (64GB RAM, 12th Gen Intel) 환경에서 테스트되었습니다.