들어가며: 왜 추측 디코딩의 평가가 중요한가?
LLM 서빙 비용과 지연 시간을 획기적으로 줄일 수 있는 추측 디코딩(Speculative Decoding, SD) 기술이 주목받고 있습니다. SD는 가벼운 드래프트 모델(draft model)이 여러 개의 미래 토큰을 먼저 예측하고, 타겟 모델(target model)이 이를 병렬로 검증하는 방식입니다. 이론적으로는 출력 분포를 유지하면서 처리량(throughput)을 크게 향상시킬 수 있죠.
하지만 문제는 평가 방식에 있습니다. 기존 벤치마크는 데이터 다양성이 부족하고, 입력 시퀀스 길이가 짧으며, 배치 사이즈 1에 고정된 경우가 많았습니다. 실제 운영 환경과는 거리가 먼 조건에서 측정된 성능은 현장에서 전혀 다른 결과를 보여줍니다.
이러한 격차를 해소하기 위해 NVIDIA 연구팀이 공개한 SPEED-Bench는 SD 알고리즘을 **다양한 의미 도메인(semantic domain)**과 **현실적인 서빙 환경(serving regime)**에서 평가할 수 있는 통합 벤치마크입니다. 이 글에서는 SPEED-Bench의 설계 철학과 실제 사용법을 살펴보고, 실무에 적용할 때 주의할 점을 함께 정리해보겠습니다.
SPEED-Bench의 두 가지 핵심 데이터셋
SPEED-Bench는 SD의 두 가지 측면을 각각 평가하기 위해 Qualitative split과 Throughput split으로 구성됩니다.
Qualitative split: 의미 다양성과 드래프트 정확도
이 분할은 **의미적 다양성(semantic diversity)**을 최대화하여 드래프트 모델의 정확도를 측정합니다. 18개의 공개 데이터 소스에서 수집한 데이터를 11개 카테고리(코딩, 수학, 인문학, STEM, 글쓰기, 요약, 롤플레이, RAG, 다국어, 추론, QA)로 구성했으며, 각 카테고리당 80개 샘플(총 880개 프롬프트)을 포함합니다.
핵심은 의미적 중복을 최소화하는 선택 알고리즘입니다. 각 후보 프롬프트를 openai/text-embedding-3-small로 임베딩한 뒤, 카테고리 내 평균 코사인 유사도(pairwise cosine similarity)가 최소가 되도록 샘플을 선정합니다. 이렇게 하면 저엔트로피(low-entropy) 영역(예: 코딩, 수학)과 고엔트로피(high-entropy) 영역(예: 롤플레이, 글쓰기) 간의 SD 성능 차이를 명확하게 드러낼 수 있습니다.
Throughput split: 현실적인 서빙 워크로드
시스템 수준의 속도 향상(speedup)을 평가하기 위해 설계된 분할입니다. **입력 시퀀스 길이(ISL)**를 1k~32k 토큰까지 고정 버킷으로 나누고, 각 버킷마다 저/중/고 엔트로피 영역에서 512개씩(총 1,536개) 프롬프트를 제공합니다.
생산 환경에서는 높은 동시성(concurrency)과 긴 컨텍스트가 일반적입니다. 배치 사이즈가 커질수록 추론은 **메모리 바운드(memory-bound)**에서 **컴퓨트 바운드(compute-bound)**로 전환되며, SD의 비용-효익 균형이 완전히 달라집니다. Throughput split은 이러한 현실을 정확히 반영합니다.
주의사항: SPEED-Bench는 랜덤 토큰 입력을 사용하지 않습니다. 랜덤 토큰은 수용 길이(acceptance length)를 왜곡하고, MoE 모델의 전문가 라우팅(expert routing)을 비현실적으로 만들어 측정값을 약 23% 과대평가하는 것으로 나타났습니다.
통합 측정 프레임워크: 엔진 간 공정한 비교
SD 벤치마킹의 또 다른 함정은 인퍼런스 엔진 간의 차이입니다. 각 엔진은 채팅 템플릿, BOS 토큰 처리, 토크나이저 방식이 달라 동일한 입력이라도 다른 시퀀스를 생성할 수 있습니다.
SPEED-Bench는 **사전 토큰화된 시퀀스(pre-tokenized sequences)**를 모든 엔진에 전달하여 이 문제를 해결합니다. 현재 TensorRT-LLM, vLLM, SGLang을 공식 지원하며, 스트리밍 응답에서 세밀한 타이밍 정보를 추출하여 수용 행동, 단계 지연 시간, 사용자별 TPS, 전체 처리량을 계산합니다.
다음은 TensorRT-LLM에서 Llama 3.3 70B Instruct(타겟) + EAGLE3(드래프트) 조합으로 Qualitative split을 실행하는 예시입니다:
mpirun -n 1 --oversubscribe python3 run.py \
--model_dir meta-llama/Llama-3.3-70B-Instruct \
--tokenizer meta-llama/Llama-3.3-70B-Instruct \
--draft_model_dir yuhuili/EAGLE3-LLaMA3.3-Instruct-70B \
--dataset speed --dataset_path data/speed/qualitative \
--tp_size 8 --ep_size 1 --draft_length 3 \
--output_length 4096 --engine TRTLLM --concurrency 32 \
--show_progress
실행 결과는 다음과 같은 주요 지표를 제공합니다:
Acceptance Length Histogram
{1: 57385, 2: 36968, 3: 24441, 4: 61182}
Conditional acceptance rate
1 1.0
2 0.681151931368627
3 0.6984444208791836
4 0.7145509968116043
Acceptance Rate Results
┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Category ┃ Average AR ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ coding │ 3.0001 │
│ humanities │ 2.3699 │
│ math │ 2.4710 │
│ multilingual │ 1.7277 │
│ qa │ 2.3184 │
│ rag │ 2.7502 │
│ reasoning │ 2.6142 │
│ roleplay │ 2.0407 │
│ stem │ 2.4306 │
│ summarization │ 2.6026 │
│ writing │ 2.6364 │
├─────────────────┼────────────┤
│ Overall Average │ 2.4511 │
└─────────────────┴────────────┘
Output TPS 2518.1464055829188
Output TPS/gpu 314.76830069786485
SPEED-Bench가 밝혀낸 세 가지 인사이트
1. 도메인에 따른 정확도와 속도 향상의 차이
SD의 수용 길이(acceptance length)는 도메인에 크게 의존합니다. 저엔트로피 영역(코딩, 수학)은 일관되게 높은 수용 길이를 보이는 반면, 고엔트로피 영역(롤플레이, 글쓰기)은 추측이 어렵습니다. 또한 드래프트 방법 간에도 차이가 큽니다:
| 도메인 | Llama 3.3 70B + N-Gram | GPT OSS 120B + EAGLE3 | Qwen3-Next + MTP |
|---|---|---|---|
| Coding | 1.54 | 2.46 | 3.34 |
| Math | 1.43 | 2.46 | 3.13 |
| Roleplay | 1.15 | 1.87 | 2.09 |
| Writing | 1.33 | 1.98 | 2.46 |
| Mean AL | 1.41 | 2.25 | 2.81 |
| Mean Speedup | 0.88x | 1.34x | 1.20x |
흥미로운 점은 N-Gram 방식이 오히려 속도가 느려질 수 있다는 것(net slowdown)입니다. 또한 MTP(Multi-Token Prediction) 헤드를 기본 모델과 함께 처음부터 공동 학습(co-training)한 경우가 EAGLE3 같은 사후 훈련(post-trained) 방식보다 훨씬 높은 수용 길이를 보여줍니다.
2. 어휘 가지치기(Vocabulary Pruning)의 장단점
EAGLE3에서 사용하는 어휘 가지치기는 최종 투영 레이어의 계산 비용을 줄이지만, 롱테일(long-tail) 입력에서는 수용 길이를 크게 저하시킵니다. 특히 다국어, RAG, 요약 카테고리에서 그 영향이 두드러집니다. 이러한 효과는 다양성이 낮은 기존 벤치마크에서는 완전히 가려집니다.
3. 랜덤 토큰은 절대 사용하지 마라
많은 연구에서 랜덤 토큰으로 프롬프트 부하를 시뮬레이션하지만, 이는 SD 평가에 치명적입니다. 모델이 노이즈를 감지하고 **예측 가능한 응답(trivial response)**을 생성하거나, 특정 키워드에 고정되는 토픽 래칭(topic latching) 현상이 발생하여 수용 길이가 왜곡됩니다. SPEED-Bench 실험 결과, 랜덤 토큰을 사용하면 SD 처리량이 실제보다 약 23% 과대평가되었습니다.
한국 개발 생태계에서의 적용 맥락
국내에서도 LLM 서빙 최적화에 대한 관심이 높아지고 있습니다. 특히 네이버의 HyperCLOVA, KT의 믿음, 그리고 다양한 스타트업의 자체 모델들이 실제 서비스에 배포되면서 추론 비용 절감이 핵심 과제로 떠올랐습니다.
SPEED-Bench는 이러한 상황에서 다음과 같은 실무적 가치를 제공합니다:
- 한국어 특화 도메인 평가: 현재 Qualitative split에 다국어 카테고리가 포함되어 있지만, 한국어에 특화된 데이터셋은 부족합니다. 향후 한국어 코딩 어시스턴트, 한국어 RAG, 한국어 요약 등의 도메인을 추가하여 평가한다면 더욱 현실적인 벤치마크가 될 것입니다.
- 국내 클라우드 환경에 맞춘 튜닝: 국내에서는 NVIDIA A100, H100 GPU를 사용하는 경우가 많지만, 배치 사이즈나 ISL 분포는 서비스마다 크게 다릅니다. SPEED-Bench의 Throughput split을 활용해 자사 서비스의 실제 워크로드에 가장 적합한 SD 알고리즘을 선택할 수 있습니다.
- 오픈소스 엔진 활용: vLLM과 SGLang은 오픈소스로 활발히 개발되고 있어 국내 스타트업에서도 쉽게 도입할 수 있습니다. SPEED-Bench의 통합 측정 프레임워크를 사용하면 엔진 간 공정한 비교가 가능합니다.
결론: SPEED-Bench로 더 현실적인 SD 평가를 시작하세요
SPEED-Bench는 추측 디코딩 평가의 표준을 한 단계 끌어올렸습니다. 기존 벤치마크가 간과했던 의미적 다양성, 현실적인 서빙 워크로드, 엔진 간 공정성을 모두 해결한 점이 가장 큰 강점입니다.
다만, SPEED-Bench에도 한계는 있습니다:
- 드래프트 모델의 크기와 아키텍처에 따른 영향은 아직 충분히 분석되지 않았습니다.
- 멀티턴 대화(multi-turn conversation) 시나리오는 아직 포함되지 않았습니다.
- 비용(cost) 측면의 평가(예: FLOPs 대비 처리량)는 제공되지 않습니다.
다음 단계 학습 방향
- 직접 실행해보기: SPEED-Bench의 측정 프레임워크를 클론하여 자체 모델에 적용해보세요. (근거자료)
- 다양한 SD 알고리즘 비교: EAGLE3 외에도 Medusa, Lookahead Decoding, Self-Speculative Decoding 등을 같은 조건에서 비교해보면 흥미로운 인사이트를 얻을 수 있습니다.
- 한국어 데이터셋 확장: 자체적인 한국어 SD 평가 데이터셋을 구축하여 SPEED-Bench의 Qualitative split에 추가하는 방법을 고려해보세요.
함께 보면 좋은 글: