빠른 추론

대역폭 병목

Transformer 디코딩은 한 번에 한 토큰씩 생성한다. 각 step에서 모델 전체 파라미터를 메모리에서 읽어와 곱셈을 수행하고, 다음 토큰 하나를 뽑는다. 문제는 GPU 연산 능력이 메모리 대역폭보다 훨씬 빠르다는 점이다. 모델이 크고 배치가 작을 때, GPU는 파라미터를 기다리며 대부분의 시간을 놀게 된다. 이것이 메모리 대역폭 병목(memory bandwidth bound)이다.

구체적으로, 100B 파라미터 모델을 FP16으로 읽는 데 약 200GB가 필요하다. H100 HBM 대역폭이 ~3TB/s라 해도 한 토큰 생성에 수십 밀리초가 걸린다. 배치 크기가 작으면 병렬 처리로 숨길 수 있는 지연도 적다. 결과적으로 추론 비용은 토큰당 파라미터 읽기 횟수에 비례한다.

해법의 핵심은 한 번 읽은 파라미터로 여러 토큰을 동시에 평가하는 것이다. Draft-verify 구조가 이를 가능하게 한다.

Draft-Verify 메커니즘

기본 흐름은 다음과 같다. 먼저 작고 빠른 draft 모델이 k개의 후보 토큰을 제안한다. 그 다음 target 모델이 이 k개 후보를 한 번의 forward pass로 병렬 평가한다. Target은 각 위치에서 확률 분포를 계산하고, draft 확률과 비교해 어디까지 accept할지 결정한다. Reject된 지점부터는 target의 분포를 따라 새로 sampling하고, 다음 draft step으로 넘어간다.

중요한 특성이 있다. 출력 분포는 target 단독 autoregressive와 수학적으로 동등하다. 근사가 아니다. Rejection sampling이 분포를 보정하기 때문에, 얼마나 많은 후보를 accept하든 최종 토큰 분포는 target과 같다. 이 lossless 특성이 production 배포의 전제 조건이다.

Leviathan et al. (2023, arXiv 2211.17192)이 T5-XXL 11B 모델에서 2×–3× 속도 향상을 보고하며 이 구조를 확립했다. 병렬 작업으로 Chen et al. (2302.01318)도 같은 시기에 같은 아이디어를 제안했다. Draft 모델을 별도로 유지해야 한다는 점이 첫 번째 제약이었다.

Target 내장 방식

Medusa (Cai et al., 2024, arXiv 2401.10774)는 draft 모델을 없앴다. Target 모델에 여러 개의 decoding head를 추가해서, 하나의 forward pass로 “다음 토큰”, “그 다음 토큰”, “그 다음다음 토큰”을 독립적으로 예측하게 만든다. Tree attention으로 가능한 후보 경로들을 효율적으로 검증한다. 메모리 오버헤드가 작고, 별도 모델 유지 부담이 없다.

EAGLE (Li et al., 2024, arXiv 2401.15077)는 한 단계 더 깊이 들어갔다. 토큰 레벨이 아니라 feature 레벨에서 예측한다. Target의 마지막 hidden state를 가져와 가벼운 autoregressive 모델로 다음 hidden state들을 예측하고, 이를 LM head에 통과시켜 토큰으로 변환한다. Feature uncertainty를 직접 모델링하기 때문에 accept rate가 더 높다.

이 시점까지는 추론 시점에서 draft와 verify를 조합하는 방식이었다. 학습과 추론이 분리되어 있었다.

Multi-Token Prediction: Draft의 내재화

Multi-Token Prediction (Gloeckle et al., 2024, Meta, arXiv 2404.19737; DeepSeek-V3 Technical Report, arXiv 2412.19437)은 학습 단계부터 모델이 여러 토큰을 동시에 예측하도록 만든다. 각 위치에서 t+1, t+2, …, t+n 토큰을 모두 예측하는 auxiliary head들을 추가하고, 학습 시 모두 함께 최적화한다.

추론 때는 한 step에서 여러 토큰을 동시에 생성한다. Draft가 체크포인트 안에 들어 있기 때문에, 별도 모듈을 attach할 필요가 없다. DeepSeek-V3가 이를 제품화했고, 디코딩 속도가 약 1.8배 향상되었다고 보고했다.

MTP는 draft를 모델 안으로 가져왔지만, 동시에 두 갈래 질문을 남겼다. Draft를 더 정확하게 만들 수 있는가? Verification 낭비를 줄일 수 있는가?

MTP 이후의 계보 분기

EAGLE-3: Feature 제약 제거

EAGLE-3 (Li et al., 2025, arXiv 2503.01840)는 MTP와 EAGLE-1 사이의 피드백 루프를 보여준다. 논문에서 밝히듯, EAGLE이 DeepSeek-V3의 MTP 설계에 영감을 주었고, MTP 경험이 다시 EAGLE-3의 새로운 설계를 만들었다.

EAGLE-1의 핵심 제약은 hidden state를 정확히 맞춰야 한다는 점이었다. EAGLE-3는 이를 버렸다. Target의 저·중·고 레이어 feature를 모두 융합하고, 융합 feature에서 바로 토큰을 예측한다. 더 중요한 것은 training-time test다. 학습 중에 multi-step drafting을 시뮬레이션해서, draft 모델이 2단계, 3단계 이후에도 분포 안에 머물도록 훈련한다. 이전 방식들은 1-step drift만 제어했지만, EAGLE-3는 cascade 오차를 직접 최적화한다.

성능은 vanilla autoregressive 대비 최대 6.5×, EAGLE-2 대비 약 1.4×였다. SGLang에서 batch size 64일 때 throughput은 1.38배 향상되었다. Draft 정확도를 끌어올린 방향이다.

DSpark: Verification 낭비 해결

DSpark (Cheng et al., 2026, Peking + DeepSeek-AI, arXiv 2607.05147)는 다른 문제를 해결한다. MTP로 draft가 모델 안에 들어왔지만, 병목은 verification으로 이동했다. DeepSeek-V4 서빙에서 관찰한 현실은 다음과 같다. 고정된 k개 토큰을 검증하면, 높은 동시성에서 대부분 reject될 토큰에도 target batch를 소비한다. 정적 MTP-3/5 설정은 throughput을 오히려 해쳤다.

DSpark는 두 가지 메커니즘을 도입한다. 첫째, semi-autoregressive draft다. 순수 병렬 draft는 suffix decay와 multimodal collision 문제가 있다. DSpark는 병렬 backbone (DFlash, arXiv 2602.06036)에 순차 Markov head를 붙여 block 내부 위치들이 서로 의존하게 만든다. 둘째, confidence-scheduled verification이다. Confidence head가 각 위치의 prefix survival 확률을 추정한다. 첫 토큰은 70% 이상 살아남지만 마지막 토큰은 10% 미만이다. Hardware-aware scheduler는 엔진 부하를 보고 몇 개 토큰을 검증할지 결정한다. 높은 부하일 때는 상위 B개 prefix만 검증해서, reject될 토큰에 target batch를 쓰지 않는다.

DeepSeek-V4 서빙에 실 트래픽으로 배포되었다. Baseline은 MTP-1 (기존 production 설정)이다. 같은 throughput에서, V4-Flash는 사용자당 생성 속도가 60%–85% 더 빨랐고, V4-Pro는 57%–78% 더 빨랐다. Lossless 특성은 유지된다. 논문은 661%/406% SLA 비율을 헤드라인으로 쓰지 않는다—그 지점들은 frontier가 새로 가능해졌다는 것을 보여줄 뿐, 잘 활용된 baseline 대비 대표적인 speedup이 아니라고 스스로 밝힌다.

vLLM PR #47808이 confidence-scheduled verification을 구현했다. enable_adaptive_verification 플래그로, 동시성 256까지 이득을 유지한다고 보고했다.

두 방향은 명확히 구분된다. EAGLE-3는 draft 정확도를 극대화한다. DSpark는 production 부하에서 verification 비용을 줄인다. 둘 다 MTP 이후의 질문에 답한다.

실패 모드

Acceptance 붕괴

Draft-verify의 이득은 accept length에 비례한다. 긴 컨텍스트나 높은 동시성에서 acceptance가 붕괴하면, verify 비용이 이득보다 커진다. TensorRT-LLM Issue #16767은 disaggregated serving에서 generation batch >1일 때 accept length 붕괴를 보고했다. r/LocalLLaMA 2026-08-14 thread에서 u/McFlurriez는 20k context에서 무슨 일이 일어나는지 marketing multiplier가 절대 말하지 않는다고 지적했다.

vLLM의 adaptive verification 보고(블로그 2026-08-14)에 따르면, c≤64일 때 ±3% 이내이지만, c=256에서 fixed 7-token이 no-spec 대비 33% 아래로 가라앉을 때 동적 스케줄링이 win을 보존한다. 이것이 DSpark의 존재 이유다.

Verification 비용

고정된 k개 검증은 부하에 따라 독이 된다. SGLang의 원래 DeepSeek-V4 레시피는 high-throughput 설정에서 MTP를 disabled했다—saturation에서 verify step이 절약보다 비용이 더 크다는 DSpark 논문의 static MTP-3/5 관찰과 같다.

r/LocalLLaMA 2026-08-08 thread에서 한 사용자는 DSpark draft on llama-server로 V4-Flash 1–2 t/s를 보고했다 (MTP 30–40 t/s 기대치 대비). u/notdba는 0731 DSpark draft가 preview MTP draft보다 훨씬 크고 swapping to/from disk이 likely라고 지적했다. Operator 경험은 갈렸다. 적절히 설정된 환경과 그렇지 않은 환경 사이의 차이다.

Groq는 다른 축

Groq의 OpenRouter 속도는 LPU와 on-chip SRAM에서 온다. Draft-verify와 다른 silicon 축이다. Groq를 EAGLE/DSpark와 같은 범주에 넣으면 안 된다. NVIDIA의 2026 Groq 3 LPX + Vera Rubin 블로그가 “external-drafter speculative decoding”을 언급하지만, 이것은 NVIDIA 하드웨어 pairing 블로그지 GroqCloud API 변경사항이 아니다.

Cerebras도 마찬가지다. Wafer-scale SRAM이 primary 속도다. 2024-10-24 릴리스에서 speculative decoding 구현을 추가했고 Llama 3.1-70B에서 2,100 tok/s를 보고했지만, 이 숫자는 custom hardware baseline 위의 speculation 기여분을 분리하지 않는다.

남은 싸움

엔진들이 EAGLE-3와 DSpark를 따라잡았다. vLLM에 adaptive verification이 구현되었고, SGLang은 EAGLE-3를 기본 권장으로 삼았다. llama.cpp는 PR #25173으로 DSpark를, PR #18039로 EAGLE-3를 first-class architecture로 추가했다. TensorRT-LLM은 PR #15808으로 DSparkDecodingConfig를 머지했지만, 공식 문서 페이지는 아직 lag한다.

Neo-cloud 프로바이더들도 움직였다. Fireworks는 default drafter를 대부분 모델에 자동 첨부하고 FireOptimizer로 workload별 speculator를 학습시킨다. Together는 ATLAS (adaptive speculator + confidence-aware controller)로 DeepSeek-V3.1에서 최대 500 TPS, Kimi-K2에서 최대 460 TPS를 주장한다. Friendli는 proprietary draft model을 curated target에 페어링한다. 이것들은 벤더 수치다—직접 재현하기 전까지는 claim으로 다뤄야 한다.

남은 싸움은 두 가지다. 첫째, 부하에서의 verification이다. Adaptive scheduling이 이론적으로 작동하지만, production profiling 버그 (vLLM #54046)와 긴 컨텍스트 acceptance 붕괴는 shipped의 솔직한 texture다. 둘째, default-on 서빙이다. Draft를 어떻게 배포하고, 언제 끄고, 어떻게 fallback하는지에 대한 operational playbook이 아직 형성 중이다.

알고리즘 계보는 여기까지 왔다. 이제 엔진과 프로바이더가 production 경험을 쌓는 단계다.

엔진과 프로바이더

알고리즘 레이어의 진화는 위와 같다. 실제 서빙 인프라—vLLM, SGLang, llama.cpp, TensorRT-LLM 같은 엔진들과 Fireworks, Together, Friendli 같은 프로바이더들—의 구현 상태, 벤치마크 수치, 그리고 operator 경험은 별도 페이지에 정리했다.

엔진과 프로바이더 상세 →