Problem — drafting이 critical path에 있다
§1 Introduction
Speculative decoding은 drafting → verification이 엄격히 순차라서, draft model이 도는 시간이 그대로 전체 latency에 얹힌다. VSR을 올리려는 기법들은 오히려 drafting을 더 길게 만들어 이 병목을 키운다.
SD의 이득은 acceptance rate에 극도로 민감하다. reject가 잦으면 drafting 비용만 추가되어 일반 autoregressive decoding보다 느려질 수도 있다. 그래서 선행 연구는 VSR을 올리는 데 집중했는데(Medusa, EAGLE, OPT-tree, TETRIS), 이들은 model 복잡도나 sampling overhead 때문에 drafting 단계를 늘린다.
“In standard speculative decoding, drafting and verification are executed sequentially, placing drafting directly on the critical path and fundamentally limiting achievable speedups.”
§1 Introduction, ¶2여기서 자연스러운 착상이 나온다 — draft model은 target보다 훨씬 작으니, 그 연산을 target의 verification과 겹쳐버리면 drafting이 공짜가 된다. 문제는 verification이 drafting의 출력에 의존한다는 것. 이 의존성을 어떻게 끊느냐가 논문의 출발점이다.
“Since the verification stage inherently depends on the outputs of the drafting stage, implementing parallelism in speculative decoding is nontrivial.”
§1 Introduction, ¶3기존 접근법 — 무엇을 쪼갰는가
§2 Related Work · 핵심은 “분할 축”의 차이다
| 방식 | 쪼갠 축 | 대가 |
|---|---|---|
| Minions (Wang 2024) DSI (Timor 2025) | model 인스턴스 — 여러 draft/target을 동시 실행 | GPU·VRAM 대폭 증가 |
| Medusa (Cai 2024) EAGLE (Li 2024) | token — 한 request 안에서 tree로 여러 경로 draft | drafting은 여전히 verify 앞에 순차 |
| ParallelSpec (Xiao 2024) | token — draft model이 한 번에 다중 token 출력 | draft model 전용 학습 단계 필요 |
| PEARL (Liu 2025a) | time — pre/post-verify로 의존성 낙관적 절단 | single-request 전제, batch 확장 곤란 |
| TETRIS (Wu 2025) EAGLE-2, AdaSpec | draft 길이 — 가변 길이·선별 검증 | draft 수 자체가 verify 부담에 막힘 |
| MineDraft | request 집합 — 두 batch가 draft/verify 역할 교대 | GPU 1장 + KV cache 2m 상주 |
앞의 다섯은 전부 token 축 또는 model 인스턴스 축을 쪼갠다. MineDraft만 request 축을 쪼갠다. 이것이 논문이 “새로운 병렬화 패러다임”이라 부르는 근거다.
“Whereas MineDraft adopts a new parallelism paradigm, Batch Parallelism, requiring only one additional GPU over standard SD, balancing resource usage with reduced overhead, and eliminating a dedicated training stage.”
§2 Parallel speculative decoding가장 가까운 선행 연구: PEARL은 실제로 어떻게 도는가
PEARL(Liu et al., ICLR 2025)이 겨냥한 건 mutual waiting problem이다 — draft model이 추측하는 동안 target이 놀고, target이 검증하는 동안 draft가 논다. 원인은 비동기 실행과 고정된 draft 길이다.
하드웨어 배치는 MineDraft와 동일하다
| 장치 | 담당 |
|---|---|
| GPU 5 | draft model (예: Qwen3-1.7B, TP=1) |
| GPU 1~4 | target model (예: Qwen3-32B, TP=4) |
MineDraft 실험에서 PEARL도 GPU 5장을 쓴다(그래서 §6.4 정규화에서 같은 그룹). 물리 구성이 같으므로 차이는 오직 “무엇을 겹치느냐”다 — MineDraft는 다른 batch를, PEARL은 같은 요청의 미래를 겹친다.
실행 예제 — γ = 4, prefix = “대한민국의 수도는”
Round 1 · pre-verify 모드 — 두 GPU 그룹이 동시에 다른 일을 한다.
| GPU 5 (Drafter) | GPU 1~4 (Target) | |
|---|---|---|
| 하는 일 | prefix 뒤로 4개를 순차 생성 | prefix 하나만 넣고 1회 forward |
| 결과 | 서울 이고 인구 는 | p(다음 토큰 | "대한민국의 수도는") |
Target이 계산하는 건 prefix 다음 위치의 분포일 뿐이다. draft가 무엇을 뽑았는지 알 필요가 없다. 그래서 drafting과 동시에 돌릴 수 있다.
drafting이 끝나면 첫 token만 대조한다.
- accept → 4개를 잠정 채택하고 post-verify 모드로 전환 (2~4번째는 아직 미검증)
- reject →
norm(max(0, p − q₁))에서 1개 재샘플링, 나머지 3개는 폐기, pre-verify 유지
reject 시 3개를 버리지만 그 생성 시간이 target 실행과 겹쳐 있어 손해가 아니다. 어려운 요청에서 자동으로 draft 길이가 짧아지는 효과 — 이것이 adaptive draft length다.
Round 2 · post-verify 모드 — 역할이 바뀐다.
| GPU 5 (Drafter) | GPU 1~4 (Target) | |
|---|---|---|
| 하는 일 | 다음 4개를 미리 생성 (5~8번째) | 잠정 4개를 병렬 검증 |
| 결과 | 약 950 만 명 | p₁ p₂ p₃ p₄ 계산 |
- 4개 전부 accept → 미리 뽑은 4개까지 합쳐 총 8개(
2γ)를 한 번에 확정, post-verify 유지 - 하나라도 reject → 미리 뽑은 4개는 prefix가 달라져 전량 폐기, pre-verify로 복귀
결과적으로 draft 길이가 요청 난이도에 따라 1 ~ 2γ 사이에서 자동 조절된다. 추가 학습은 전혀 필요 없다.
왜 batch에서 무너지는가
post-verify의 조건은 “전부 accept”다. 단일 request라면 acceptance rate가 높을 때 자주 걸린다. 그런데 batch에서는 batch 안의 모든 request가 전량 통과해야 한다.
m = 16→0.516 ≈ 0.0015
사실상 항상 pre-verify로 되돌아간다. pre-verify의 추가 target forward 비용은 매 라운드 치르면서 post-verify의 이득은 거의 못 받으니, Fig. 3에서 PEARL(보라색)이 standard SD(회색)보다도 아래에 깔린다.
“…its performance degrades when prerequisites for post-verification are not satisfied, a limitation that becomes especially severe in batched request settings.”
§1 Introduction, ¶3MineDraft는 도박을 하지 않는다. B를 verify하는 동안 A를 draft하므로 예측이 필요 없다. 대신 2m개를 상주시켜야 한다 — 이 교환이 논문 전체의 손익 구조다. 실제로 논문은 PEARL이 효율이 크게 낮다며 이후 실험에서 제외한다.
| PEARL | MineDraft | |
|---|---|---|
| 의존성 절단 방식 | 낙관적 예측 (전량 accept 가정) | 다른 batch를 준비 (예측 불필요) |
| 성공 조건 | draft가 전부 accept | 두 batch가 정원 유지 |
| batch 확장성 | m에 대해 지수적으로 붕괴 | m이 클수록 유리 |
| draft 길이 | 가변 (1 ~ 2γ) | 고정 k (TETRIS 결합 시 가변) |
| 추가 GPU | 불필요 (Appendix F의 weight-padding) | 1장 필요 |
MineDraft §7은 future work로 “PEARL Appendix F의 weight-padding 기법으로 추가 GPU 요구를 없앨 수 있는지” 연구하겠다고 밝힌다. 실험에서 밀어낸 baseline의 부록에서 해법을 빌려오겠다는 것이다.
해결 방식 — Batch Parallelism
§5 Framework · Fig. 1, Fig. 2, Fig. 9, Fig. 10
이름은 Minecraft에서 왔다. 플레이어가 현재 chunk와 상호작용하는 동안 게임 엔진이 다음 chunk를 background loading하는 것 — 그게 MineDraft가 drafting을 숨기는 방식이다.
“This ‘background loading’ is exactly how MineDraft hides drafting latency.”
§1 Introduction, ¶4
구성 요소 4개
| 컴포넌트 | 역할 |
|---|---|
| Batch Manager | 최대 2m개를 Batch 0/1로 나누고 batch ID 부여·회수 |
| Scheduler | vLLM 요청 lifecycle 관리 + KV block 할당 patch |
| Drafter | 전용 GPU 1장(TP=1)에서 draft token 생성 → Verifier로 broadcast |
| Verifier | target model(TP=4)이 검증 → sampler output을 Drafter로 P2P 전송 |
Batch Manager의 상태 변수와 규칙 (§5.1)
| 변수 | 정의 |
|---|---|
skip_batch | 이번 step에 draft만 하는 batch (= draft batch). verify를 “skip”한다는 뜻 |
| target batch | skip_batch가 아닌 나머지. 이번 step에 verify되는 쪽 |
balance | |Batch 1| − |Batch 0|. 초기값 0, skip_batch 초기값 1 |
- 첫 SD step —
assign()이 진짜 load balancer로 동작.balance ≥ 0이면 Batch 0에, 아니면 Batch 1에 넣고balance조정 →2m개를 반반으로 분배 - 첫 step 이후 — 신규 request는 무조건 현재
skip_batch로. draft token이 없는 채 verify로 보내면 1 token만 sampling하는 낭비 step이 생기기 때문 recycle()— finish/preempt/abort 시balance를 역방향으로 되돌림
완료는 verify를 통해서만 일어나므로 항상 target batch에서 발생한다. 그런데 sync point에서 역할이 교대되어 그 target batch가 곧 다음 step의 draft batch가 된다. 즉 빠진 자리와 채워지는 자리가 같은 batch다.
“This policy typically preserves balance between the two batches, since after the first SD step, a waiting request can be scheduled only when a request in the target batch finishes.”
§5.1 Batch ID assignmentScheduler patch — KV block 과할당 제거 (§5.3)
Drafter는 KV block을 읽기만 하고 채우지 않는다. 실제로 KV cache를 쓰는 건 Verifier다. 그런데 기본 vLLM scheduler는 모든 running request에 매 step 할당하므로, draft batch에 대해 접근은 되지만 쓰이지 않는 block이 낭비된다.
“…this causes redundant allocations for requests in the draft batch, which are drafted but not verified, leaving allocated blocks accessed but unwritten.”
§5.3 Over-allocation issue in default scheduler해법은 has_deferred 집합으로 “이미 한 번 스킵한 request”를 추적해, decode 단계에서는 draft batch에만 KV block을 할당하는 것. 첫 SD step의 target batch가 할당을 놓치는 사고를 막는 장치도 함께 들어간다.
m = 4, 총 12개 요청의 전 생애. 주황 = Batch 0, 파랑 = Batch 1, 빨강 = 완료. Drafting 행과 Verifying 행이 한 칸씩 어긋나며 교대하다가, step 10에서 draft token이 없어 fallback이 발동한다.
전달하려는 메시지: “교대가 실제로 어떻게 보이는지” — 그리고 tail 구간에서 병렬성이 끝난다는 한계를 스스로 그림에 표시했다.
이론 (§4) — 왜 최소 37%인가
draft model의 Pareto frontier f(t)를 도입한다: drafting 시간 예산 t에서 달성 가능한 최대 VSR. 검증 token 수를 고정하면
Theorem 1: f(t) = 1 − e^(−αt)이고 αV ≈ 1.68일 때 T_SD ≳ 1.59 T_PSD → 37% 이상 감소. 이상적 상한은 50%.
Lemma 2가 알려주는 최적점이 핵심이다 — T_PSD는 t* = V, 즉 drafting 시간과 verification 시간이 정확히 같을 때 최소가 된다. 이 조건이 이후 모든 실험 결과를 지배한다.
max(V, t) 안에 통신 비용 항이 없다. 그런데 Drafter/Verifier는 물리적으로 다른 GPU에 있어 매 step broadcast + P2P 왕복이 필요하고, Table 1에 따르면 이 비용은 k=1에서 latency의 50~58%를 차지한다. 이론이 무시한 항이 최소 10%대이므로, 실측이 50%에 못 미치는 건 “확률적 변동” 이전에 모델의 구조적 누락 때문이다.
Figure별 주장과 근거 — 한눈에
각 figure가 독자를 설득하려는 명제
| Figure | 설득하려는 주장 | 근거로 쓰는 것 |
|---|---|---|
| Fig. 1 | drafting은 없앨 수 없지만 숨길 수 있다 | 두 파이프라인 타임라인 대조 |
| Fig. 2 | 이건 개념이 아니라 vLLM에 실제로 꽂히는 설계다 | Scheduler 상태도 + 실행 타임라인 |
| Fig. 3 | 모든 데이터셋·draft model에서 일관되게 빠르다 | 3 setting × 4 dataset = 12 subplot |
| Fig. 4 | EAGLE·TETRIS와 직교(orthogonal)하다 — 얹으면 더 빨라진다 | Llama-70B, Vicuna-EAGLE 설정 |
| Fig. 5 | 큰 draft model에서는 standard SD가 아예 못 돈다 (OOM) | Qwen3-8B draft, standard SD 곡선 부재 |
| Fig. 6 | throughput만이 아니라 latency도 줄었다 | E2EL 최대 −39.51% |
| Fig. 7 | GPU 1장 더 쓴 걸 보정해도 이긴다 | ÷5 vs ÷4 정규화 |
| Fig. 8 | 이득의 조건과 스케일 축을 스스로 해부했다 | 4개 ablation (모델/e/n/m) |
| Fig. 16 | 병렬화해도 VSR은 그대로다 — 품질을 안 건드렸다 | throughput·E2EL·VSR 3행 비교 |
| Fig. 19 | m이 클수록 유리하다 | m = 8/16/32/64 스윕 |
| Fig. 21 | Spec-Bench의 VSR 이상치는 우리 탓이 아니다 | trimming percentile 분석 |
| Fig. 25 | 이득/손해의 경계는 drafting time ≤ verification time | Nsight Systems 실측 ms |
| Tab. 1 | k가 작을 때 지는 이유는 통신 비용이다 | 통신 latency 비율 실측 |
| Tab. 2 | tail effect는 무시할 만하다 | 평균 병렬화율 99.19% |
실험 결과 — 무엇이 좋아져서 향상됐는가
§6 Experiments · target Qwen3-32B(TP=4) 등 7개 setting, 4개 dataset, draft는 전용 GPU 1장
공통 읽는 법 — 모든 그래프의 x축은 k(step당 draft token 수, 1~5). ↑는 best baseline 대비 평균 개선률, Δ는 standard SD 대비 최대 격차. extra=e는 TETRIS 결합 시 request마다 추가로 뽑는 draft token 수.
실험 하드웨어 — 그리고 논문이 말하지 않는 인터커넥트
| Setting | Target (TP=4) | Draft (TP=1) | GPU | m |
|---|---|---|---|---|
| 1~4 | Qwen3-32B | Qwen3-0.6B / 1.7B / 4B / 8B | L40S × 5 | 16 |
| 5 | Llama-3.3-70B-Instruct-AWQ-INT4 | Llama-3.1-8B-Instruct | H100 × 5 | 64 |
| 6~7 | vicuna-33b-v1.3 / 13b-v1.3 | EAGLE-Vicuna-33B / 13B | L40S × 5 | 16 |
| §C.10 | Qwen3-235B-A22B-Instruct-2507-FP8 (MoE) | Qwen3-14B | H100 × 5 | 64 |
소프트웨어는 PyTorch 2.7.0, Transformers 4.53.3, vLLM 0.9.2. 기본값은 temperature 1.0, n=1, 출력 256 token (§C.1).
[논문에 없음] L40S에는 NVLink가 없다
논문은 GPU 모델명만 적고 인터커넥트를 한 줄도 언급하지 않는다. 그런데 이건 Table 1을 해석하는 데 결정적이다.
| NVIDIA L40S | NVIDIA H100 | |
|---|---|---|
| 아키텍처 | Ada Lovelace | Hopper |
| 메모리 | 48 GB GDDR6 (864 GB/s) | 80 GB HBM3 |
| GPU 간 연결 | NVLink 미지원 PCIe Gen4 x16 | NVLink 4 (SXM 기준) |
| 대역폭 | 약 64 GB/s 양방향 (단방향 ≈ 32 GB/s) | 약 900 GB/s 양방향 |
| 격차 | 약 14배 (단방향 기준 ≈ 28배) | |
Table 1의 통신 오버헤드 수치(k=1에서 50.49~57.93%)는 Settings 1~3에서 측정됐다. 그런데 이 세 설정은 전부 L40S, 즉 NVLink 없이 PCIe로만 통신하는 환경이다.
- MineDraft는 매 SD step마다 draft broadcast + sampler output P2P 왕복이 필요하다
- L40S에서 이 왕복은 PCIe Gen4를 타야 한다 — H100 NVLink 대비 한 자릿수 이상 느리다
- 즉 Fig. 7에서
k가 작을 때 정규화 latency가 지는 현상은 알고리즘의 한계라기보다 하드웨어 선택의 결과일 수 있다
NVLink 노드에서 같은 실험을 돌리면 k=1~2 구간의 열세가 사라지거나 크게 줄어들 가능성이 있다. 논문은 이 가설을 검증하지 않았고, H100을 쓴 Setting 5에 대해서는 통신 비율을 아예 보고하지 않는다.
또 하나의 교란 요인 — L40S에서는 target model의 TP=4 자체도 매 layer마다 all-reduce를 PCIe로 수행한다. 즉 standard SD baseline도 같은 페널티를 받고 있어, 두 방법의 상대 비교는 유지되지만 절대 수치는 NVLink 환경과 크게 달라질 수 있다.
Fig. 7의 정규화는 정확히 무엇을 한 것인가
§C.5의 규칙은 다음과 같다. GPU 수는 병렬 기법 5장(target TP=4 + draft 1), standard SD 4장(draft를 같은 4장에 얹음)이다.
| 지표 | 병렬 기법 (MineDraft, PEARL) | Standard SD |
|---|---|---|
| throughput | ÷ 5 | ÷ 4 |
| E2E latency | × 1.25 | 그대로 |
1.25 = 5/4이므로 두 지표에 같은 비율이 일관되게 적용된다. latency를 곱하는 것 자체는 방향이 맞다.
① latency × GPU는 latency가 아니다. throughput ÷ GPU는 tokens/s/GPU라는 말이 되는 rate 지표다. 반면 latency × GPU는 단위가 GPU·ms, 즉 “요청 하나에 든 GPU-시간”이라는 비용 지표다. Fig. 7의 y축은 Normalized E2E Latency (ms)로 표기되어 있지만 엄밀히는 ms가 아니며, 사용자가 체감하는 응답 시간과 다른 물건이다.
② 선형 확장을 가정한다. 5번째 GPU는 draft model(TP=1)을 돌리는 완전히 다른 일을 하는 장치지 교체 가능한 균질 단위가 아니다. 더 얄궂은 건 논문 자신이 §C.5에서 통신 오버헤드를 설명하며 Universal Scalability Law(Gunther, 2008)를 인용한다는 점 — “확장은 선형이 아니다”라고 말하는 바로 그 문단에서 선형 나눗셈을 한다.
③ 5-GPU standard SD를 실제로 돌리지 않았다. 진짜 공정 비교는 standard SD에도 5장을 주고 측정하는 것인데, 산술 계수로 갈음했다. 그 계수는 “standard SD가 5장으로 완벽히 확장된다”는 가정인데, Fig. 19를 보면 batch를 m→2m으로 키워도 throughput은 2배가 되지 않는다.
오히려 Fig. 19의 MineDraft(m) vs standard SD(2m) 가 산술 계수 없이 실제로 돌린 메모리 기준 비교다. 논문은 이걸 §C.8에 묻어두고 §6.4의 산술 정규화를 전면에 내세운다.
네 데이터셋은 성능을 재려는 게 아니라 서로 다른 텍스트 분포를 확보하려고 고른 것이다. draft model의 예측 난이도가 분포마다 달라지므로, VSR과 throughput이 어떤 workload에서도 유지되는지 확인하는 용도다.
사용된 벤치마크 4종 — 무엇을 재려고 골랐나
네 데이터셋은 성능을 재려는 게 아니라 서로 다른 텍스트 분포를 확보하려고 고른 것이다. draft model의 예측 난이도가 분포마다 달라지므로, VSR과 throughput이 어떤 workload에서도 유지되는지 확인하는 용도다.
| 벤치마크 | 출처 · 규모 · 라이선스 | 성격 | MineDraft에서의 역할 |
|---|---|---|---|
| ShareGPT Anon, 2023 |
사용자가 공개 링크로 공유한 실제 ChatGPT 대화 약 94k건 수집. Vicuna용 정제본은 영어만 남기고 53k로 축소, 2048 token 단위로 분할 Apache 2.0 |
멀티턴, 실사용 분포. 코딩·번역·글쓰기·잡담이 뒤섞임 | 가장 현실적인 baseline. 실서비스 트래픽에 가장 가까운 분포 |
| Arena Zheng et al., 2023 |
Chatbot Arena에서 수집한 33K 대화 + 쌍대 선호 투표. 20개 모델, 13K개 고유 IP, 2023년 4~6월 CC |
익명 블라인드 대결에서 나온 in-the-wild 프롬프트. 모델 실패 사례가 다수 포함 | 가장 거친 분포. 필터링이 약해 예측 난이도 편차가 큼 |
| Spec-Bench Xia et al., 2024 |
6개 subtask × 80개 = 480건. MT-bench(멀티턴), 번역(WMT14 DE-EN), 요약(CNN/DailyMail), QA(Natural Questions), 수학(GSM8K), RAG(DPR top-5 문서 + NQ) Apache 2.0 |
SD 전용으로 설계된 유일한 벤치마크. 요약·RAG는 입력과 출력이 크게 겹쳐 draft가 쉬움 | SD 커뮤니티 표준 비교 기준. 단 480건뿐이라 요청이 빨리 소진 → §C.9 VSR 이상치의 원인 |
| Tough YAV-AI, 2024 |
100개 도메인 × 10문항 = 1,000건의 합성 난이도 질문. 수학, 유체역학, 신경과학 등 전문 분야 MIT |
싱글턴, 전문 용어 밀도 높음. train/val/test 분할 없음 | 가장 어려운 분포. draft model이 전문 용어를 못 맞혀 VSR이 낮아질 조건 |
짧은 예시와 기대 응답
아래는 원문 데이터를 그대로 옮긴 것이 아니라, 각 벤치마크의 전형적인 형태를 재구성한 예시다.
| 벤치마크 | 프롬프트 (재구성 예시) | 기대 응답 형태 | draft 난이도 |
|---|---|---|---|
| ShareGPT | “파이썬으로 CSV 읽어서 컬럼별 평균 내는 코드 짜줘” → (이어서) “판다스 말고 표준 라이브러리로” |
설명 한두 줄 + 코드 블록 + 사용법 안내. 멀티턴으로 이어짐 | 중간 — 코드는 토큰 패턴이 반복적이라 draft가 잘 맞음 |
| Arena | “고양이가 왜 상자를 좋아하는지 설명해줘. 근데 해적처럼 말해줘” | 자유 형식. 길이·톤이 제각각이고 정답 개념이 없음 | 중간~높음 — 창작·역할극은 다음 token 분포가 넓어 예측이 어려움 |
| Spec-Bench (요약) |
“다음 기사를 3문장으로 요약하시오: [CNN 기사 본문 …]” | 기사 문장을 상당 부분 그대로 재사용한 요약문 | 낮음(쉬움) — 입력에 정답이 들어 있어 draft 적중률이 매우 높음 |
| Spec-Bench (수학) |
“한 상자에 사과가 12개 들어 있다. 5상자를 사서 7개를 먹었다면 몇 개가 남는가?” | 단계별 풀이 후 #### 53 형태로 정답 제시 (GSM8K 포맷) | 높음 — 숫자와 논리 전개는 draft model이 자주 틀림 |
| Spec-Bench (RAG) |
“[검색된 문서 5개] 위 문서를 참고해 답하시오: 에펠탑은 언제 완공되었는가?” | 문서에서 인용한 짧은 사실 답변 | 낮음 — 답이 입력 문서에 이미 존재 |
| Tough | “난류 경계층에서 Reynolds 응력 텐서의 비등방성이 벽면 마찰에 미치는 영향을 설명하시오” | 전문 용어가 조밀한 장문 서술. 참조 정답 없음 | 가장 높음 — 도메인 어휘는 draft model의 확률 분포가 target과 크게 어긋남 |
Speculative decoding은 lossless다. 어떤 draft를 뽑든 최종 출력 분포는 target model 단독 실행과 동일하므로, 정확도를 잴 이유가 없다. 실제로 MineDraft가 측정하는 건 throughput(tokens/s), E2E latency(ms), VSR 세 가지뿐이고, 참조 정답은 한 번도 쓰이지 않는다.
그래서 벤치마크 선택의 기준도 “정답이 있느냐”가 아니라 “draft model이 얼마나 잘 맞히는 분포냐”다. Tough에 참조 정답이 없어도 문제가 되지 않는 이유가 이것이다.
Spec-Bench는 480건뿐이다. MineDraft는 정원이 2m이므로 standard SD(m)보다 2배 빨리 요청을 소진한다. 그 결과 Spec-Bench에서만:
- Table 2의 병렬화율이 93~99%로 유독 낮음 (다른 데이터셋은 99.5% 이상)
- §C.9의 VSR 이상 현상이 82~86% 지점부터 발생
- Fig. 7의 정규화 latency 열세(
k=2, +2.08%)도 Spec-Bench에서 관측
즉 세 개의 이상 현상이 모두 같은 데이터셋에 몰려 있고, 원인도 하나다 — 데이터셋이 작아 batch가 정원을 유지하지 못한다. 논문은 이를 §C.9에서만 해명하고, Table 2·Fig. 7의 이상치와는 연결하지 않는다.
동시에 드러나는 한계: 아래 행(4B draft)은
k>3에서 곡선이 꺾인다. drafting이 verification을 넘어서면 이득이 사라진다.
주의: EAGLE 설정(아래 행)의 ↑는 1.06~7.51%로 눈에 띄게 작다. 이미 좋은 drafter를 쓰면 숨길 시간 자체가 줄어든다.
동시에: 빨간 standalone이 모든
extra 변형을 압도한다. draft model이 이미 무거우면 TETRIS의 여분 생성은 순손해다.
읽을 때 주의: “37% 예측 vs 38.94% 실측”이 논문의 유일한 이론 검증인데, 이론 구간이 37~50%라 그 사이 아무 값이나 “부합”이 된다. 게다가 비교 대상이 평균이 아니라 전 설정 중 최댓값이다.
스스로 인정한 패배:
k가 작을 때는 정규화 latency에서 standard SD에 진다 — Spec-Bench k=2에서 +2.08%. 원인은 아래 Table 1이 밝힌다.
k=1일 때 통신이 E2E latency의 50.49~57.93%, k=2에서 20.96~34.18%, k>2에서는 9.14~13.44%로 급락.
이 표가 하는 일: Fig. 7의 패배를 해명한다. k가 작으면 step당 계산량이 적어 GPU 간 통신이라는 고정 비용이 전체를 지배한다. Universal Scalability Law로 설명되는 분산 시스템의 전형적 현상.[논문에 없음] 뒤집어 읽으면: 이 표는 §4 이론이 통신 항을 누락했다는 증거이기도 하다. 그런데 논문은 두 사실을 연결하지 않는다.
Ablation — 이득의 조건을 스스로 해부하다
왜 1.7B가 최적인가: 0.6B는 너무 작아 VSR이 낮고, 4B는 품질은 좋지만 너무 느려 verification 그늘을 벗어난다. 1.7B만
k>3에서도 안 꺾인다.
t* = V가 실물로 확인된다. 두 시간이 같으면 최대 이득, drafting이 넘어서면 그만큼 critical path로 튀어나온다. Fig. 3·5·8의 모든 “꺾임”이 이 한 장으로 설명된다.
m = 8/16/32/64. MineDraft(m)와 standard SD(m) 짝 비교. throughput 최대 +75.81%, latency −40.79%.
논문의 주장: k가 4~5에 이르면 MineDraft(m)의 성능이 standard SD(2m)에 근접한다 — batch PSD로서의 효율 증명.[논문에 없음] 뒤집어 읽으면: MineDraft는 실제로
2m개를 상주시키므로 standard SD(2m)와의 비교가 메모리 기준 공정 비교다. 즉 이 문장은 “KV 예산을 맞추면 throughput 우위가 상당 부분 상쇄되고, 게다가 GPU를 1장 더 썼다”로도 읽힌다. 그리고 m=64까지 단조 증가로 끝났다는 건 compute-bound 포화점에 도달하지 못했다는 뜻이다.
VSR 이상치 방어 (§C.9)
Spec-Bench에서만 MineDraft의 VSR이 standard SD와 어긋났다. 이걸 방치하면 “병렬화하면서 draft 품질이 나빠졌다”는 반론이 성립한다. 논문의 해명 사슬은 이렇다.
m 미달→TETRIS 후보 pool 축소→저품질 draft 선택→평균 VSR 희석
n=2로 올리면 그 지점이 92%로 밀린다.
왜 이게 증거가 되나: 손해가 꼬리 구간에만 국한되고, 요청이 많아질수록 문제가 사라진다는 관계가 일관되게 나타난다. 원인이 병렬 구조가 아니라 요청 고갈이라는 뜻.[논문에 없음] 남는 의문: 이건 정황 증거다. 가설의 핵심 고리인 “batch가 정원 미달이 된다”를 step별 batch 점유율 시계열로 직접 측정하지 않았다. 그리고 “MineDraft는
2m을 요구하므로 같은 workload에서 standard SD보다 먼저 굶는다”는 사실 자체는 방어된 게 아니라 확인됐다.
주의 깊게 보면: Spec-Bench 열만 93~99%로 유독 낮다. 특히
k=1에서 93.00~94.32%. 요청이 적은 workload에서는 tail effect가 실제로 작동한다는 뜻이고, §C.9의 VSR 이상치와 같은 원인의 두 얼굴이다.
e · (c) request당 시퀀스 수 n · (d) batch size m.
네 plot의 역할: (a)와 (b)는 같은 원리를 두 축에서 보여준다 — drafting ≤ verification을 지키면 이득, 넘으면 손해. (b)의 결론은 e ≤ 2는 이득, e ≥ 3은 손해, 최고점은 k=3, e=1.(c)
n은 이득 축이 아니다 — 같은 prompt에서 갈라진 시퀀스라 Batch Manager 입장에선 여전히 request 1개다. 일종의 음성 대조군.(d)
m이 진짜 이득 축이다.
Conclusion
§7
Batch Parallelism으로 PSD를 실현했고, 이론 분석(최소 latency 이득의 특성화)과 다양한 model family·크기·하이퍼파라미터·dataset 실험으로 검증했다. Future work로 세 가지를 명시한다.
- vLLM v1 엔진 지원
- chunked prefill (Sarathi) 지원
- PEARL의 weight-padding 기법으로 추가 GPU 1장 요구를 없앨 수 있는지 연구
“We also plan to study whether the current requirement for an additional GPU in Batch Parallelism can be eliminated by leveraging the weight-padding method…”
§7 ConclusionProblem — drafting이 verification 앞에 순차로 놓여 critical path를 차지한다.
Idea — 요청을 두 batch로 쪼개 A를 verify하는 동안 B를 draft. double buffering.
Cost — GPU 1장 추가 + KV cache 2m 상주.
전제조건 — drafting time ≤ verification time, 요청이 2m 이상 꾸준히 유지, chunked prefill off.
가장 강한 근거 — throughput 수치보다도, standard SD가 OOM으로 못 돌리는 설정에서 MineDraft만 동작한다는 점.
Appendix 주요 내용
본문에 없어 놓치기 쉬운 부분 — 특히 §A Limitations
§A Limitations — 저자가 직접 인정한 4가지
| 한계 | 내용 | 제시된 완화책 |
|---|---|---|
| 복구 불가능한 batch 불균형 | abort·preemption·chunked prefill로 격차가 생기면 되돌릴 수단이 없음 | assign()을 첫 step 이후에도 항상 켜둠. 대가는 request당 최대 1회의 비효율 step |
| Batch exhaustion / tail effect | 한쪽 batch가 비면 standard SD로 fallback | PEARL식 낙관적 선(先)drafting + 실패분 re-draft (제안만, 미구현) |
| workload 적응 부재 | 요청 수가 2m 밑으로 자주 떨어지면 병렬성 희석. m이 너무 크면 compute-bound | adaptive scheduling — future work |
| request별 난이도 미반영 | 난이도와 무관하게 draft를 고르고 있음 | AdaEDL의 entropy 기반 난이도 proxy 활용 — future work |
“…it is assumed that the number of requests in the system seldom drops below the nominal capacity of 2m.”
§A Adaptive to varying workload§D FAQ — 리뷰어 질문 3개
Q1. 왜 이론상 최대 50%를 못 찍었나?
답변: 50%는 drafting과 verification 시간이 완벽히 일치하는 이상적 가정에서만 나온다. 실제로는 system overhead, resource contention, time multiplexing 때문에 확률적으로 흔들려 그 정밀한 정렬이 불가능하다.
보충: Fig. 25가 이 답을 뒷받침한다. 조절 손잡이가 k라는 정수뿐이라 t = V를 연속적으로 맞출 수가 없다 — k=3에서 49.60 vs 48.62ms로 거의 완벽하다가 k=4면 25% 초과로 튄다.
Q2. 왜 batch를 2개만 두나?
답변: SD가 drafting/verification 2단계이므로 겹칠 대상이 둘뿐이다. batch를 더 늘려도 추가 병렬성은 없고 스케줄링 오버헤드만 생긴다.
이 답은 두 단계의 소요 시간이 비슷할 때만 성립한다. Fig. 25 (e)(f)에서 Setting 3은 drafting이 verification보다 29.86%, 65.52% 길다. 이때는 Drafter GPU를 2장 두고 batch를 3개로 늘려 느린 단을 복제하는 게 표준적인 파이프라인 해법이다. 논문은 이 가능성을 검토 없이 닫고, 큰 draft model에서는 그냥 성능이 떨어지는 것으로 결론낸다. 세 질문 중 Q2만 “더 나은 설계가 있을 수 없다”는 강한 주장을 펴고, 그래서 반박 여지도 가장 크다.
Q3. 왜 prefill은 병렬화에 포함하지 않나?
답변: 현재 설계는 chunked prefill이 꺼져 있다고 가정한다. 이 설정에서 vLLM은 신규 요청의 prefill을 전용 step에서 끝낸 뒤 decode로 넘기므로, prefill 요청은 MineDraft가 도는 SD step과 애초에 분리되어 있다.
[논문에 없음] 남는 문제: ① prefill step 동안 5번째 GPU(Drafter)는 놀고 있다 — §C.5의 ÷5 정규화는 추가 GPU가 항상 일한다고 가정하므로 prefill 비중이 큰 workload에서 우위가 과대평가된다. ② “나중에 지원하겠다”는 Q3의 답과 “지금 구조로는 깨진다”는 §A의 한계가 같은 사안의 앞뒷면인데, FAQ에서는 그 연결을 언급하지 않아 난이도가 실제보다 가벼워 보인다.
기타 부록 요약
| 절 | 내용 |
|---|---|
| §B | Lemma 1·2와 Theorem 1의 완전한 증명. Lambert W 함수로 t*를 풀고, T_PSD의 최적점이 t* = V임을 보인다 |
| §C.3 | ↑(best baseline 대비 평균 개선)와 Δ(standard SD 대비 최대 격차)의 정확한 정의 |
| §C.6 | draft model 크기 ablation — 1.7B가 속도·품질 균형점 |
| §C.7 | TETRIS e ablation — e≤2 이득, e≥3 손해 |
| §C.10 | Qwen3-235B-A22B MoE + 14B draft. standard SD는 VRAM 제약으로 실행 불가, MineDraft는 k=4에서 1200~1600 tokens/s |
| §C.11 | Nsight 프로파일링 — Fig. 25의 근거 서술 |
| §C.12 | 병렬화 커버리지 99.19% |
request 수만으로 하는 batch 분할의 한계
논문이 다루지 않는 층위 — KV cache와 포화 batch
MineDraft는 batch balance를 request 개수의 문제로만 모델링했다. balance = |Batch 1| − |Batch 0|는 순전히 개수 차이이고, 각 request가 소비하는 KV 용량은 균형 판단에 전혀 들어가지 않는다.
① KV 압박은 “예외적 preemption”을 상시화한다
vLLM은 KV block이 고갈되면 running request를 preempt한다(swap 또는 recompute). Fig. 2 좌측에 Preempt by recompute, Preempt by swap 경로가 그려져 있는 이유다. 그런데 preemption은 verify와 무관하게 draft batch 쪽에서도 자리를 비운다 — “빠진 자리 = 다음 draft batch”라는 자동 균형의 전제가 깨지는 유일한 통로다.
“When a request is terminated due to user abort or preemption, MineDraft may fail to recover from the resulting imbalance because new replacement running requests are consistently assigned to the draft batch.”
§A Irrecoverable from biased batch workload논문은 이걸 “exceptional”이라는 단어로 처리한다. 하지만 KV가 빡빡한 workload에서 preemption은 사고가 아니라 정상 동작이다. 이 빈도 의존성은 논의되지 않는다.
“복원력”이 아니라 “보존력”이다
정상 상태의 자동 균형은 격차를 줄이지 못하고 유지만 한다. 13 : 7 상태에서 Batch 1의 request가 끝나면 보충도 Batch 1로 들어가 다시 13 : 7. 되돌리는 피드백 제어기가 없고 보존 법칙만 있는 구조라, assign()이 꺼지는 순간의 격차가 그대로 동결된다. 이것이 논문이 말하는 irrecoverable의 정확한 의미다.
② 같은 KV 예산에서 step당 verify 물량이 반토막
MineDraft는 Verifier에 매 step m개를 보내기 위해 2m개를 상주시킨다. KV block은 상주 request 전체에 필요하므로 실질 소요가 2배다. 뒤집으면, KV 예산이 고정되어 최대 M개만 상주 가능할 때:
| Standard SD | MineDraft | |
|---|---|---|
| 상주 request | M | M (= 2 × M/2) |
| step당 verify | M | M / 2 |
| 이득 | — | drafting latency 은닉 (최대 37~50%) |
| 손실 | — | Verifier batch 절반 → GPU 효율 저하 |
LLM decode는 memory-bound라 batch를 키울수록 throughput이 거의 선형으로 오른다. KV 여유가 있으면 손실이 0이라 이득만 남지만(= 논문의 실험 조건), 여유가 없으면 손실 항이 살아나 standard SD보다 느려질 수 있다. 논문은 이 손익분기를 계산하지 않는다.
저자 측 반론과 그 한계
저자들은 정반대 논거를 편다 — draft model을 전용 GPU로 옮겼으니 target GPU의 VRAM이 해방되어 KV가 오히려 늘어난다(Fig. 5, §C.10의 OOM 사례). 맞는 말이지만 스케일이 다르다.
2m × context_length에 비례
context가 길어지거나 m이 커지면 우변이 좌변을 압도한다. 즉 이 반론은 short-context 영역에서만 성립한다.
③ max throughput 운영과의 충돌
§4의 이론은 “the number of tokens sent for verification at each step is fixed”라는 제약 아래 전개된다. 그런데 batch를 꽉 채우는 운영이란 정확히 capacity C가 이미 포화라는 뜻이다. 그러면 둘 중 하나다 — m을 절반으로 줄여 가정을 위반하거나, 유지하려면 KV 2배가 필요해 애초에 “꽉 채운” 상태가 아니었다는 뜻이 된다.
§A: “if the user-configured batch size m is too large, it is desirable to automatically turn off speculative decoding or adaptively adjust m to prevent the compute-bound scenarios… It is left as a future direction.” 인용된 TurboSpec·MagicDec이 바로 “batch가 커지면 SD 자체가 손해”를 다룬 연구다. 즉 이 regime의 존재를 인정한 뒤, 판단 로직은 만들지 않았다.
게다가 batch를 꽉 채우면 verify 부하가 m × k이므로 k를 1~2로 줄여야 한다. 그런데 Table 1이 보여주듯 그 구간은 통신 오버헤드가 지배하는, MineDraft에 가장 불리한 지점이다. 논문의 최고 성능 지점(k=3)은 batch에 여유가 있어야 쓸 수 있는 값이다.
④ chunked prefill이 균형을 깨는 진짜 이유
흔한 오해와 달리 chunked prefill은 KV cache를 자르는 게 아니라 prompt의 forward pass를 여러 step에 나눠 처리하는 기법이다. balancing과의 연결고리는 KV가 아니라 “request가 언제 decode 상태가 되느냐”다.
3, 0, 3, 0, 1…로 불규칙→skip_batch는 2-step 주기로 규칙적 교대→위상 어긋남 → 한쪽 쏠림
긴 prompt 하나가 여러 step을 통째로 잡아먹는 동안에는 졸업 0개, 짧은 것들이 몰려 끝나는 step에는 여러 개가 한꺼번에 — 이 burst가 규칙적 교대와 어긋나면 특정 batch로만 적재가 쏠린다. 그리고 교정기 assign()은 이미 첫 step에서 꺼졌다.
문제의 본질은 “chunk 수만큼 쪼개져 반만 센다”가 아니라 「정원 2m을 채우는 데 걸리는 step 수 > 균형 로직이 켜져 있는 step 수(=1)」다. chunked prefill을 끄면 좌변이 1이라 딱 맞고, 켜면 5~10 step으로 늘어나며 어긋난다. 논문의 완화책이 “assign()을 계속 켜라”인 이유도 정확히 이것 — 좌변을 줄일 수 없으니 우변을 늘리는 것.
⑤ 논문이 세지 않는 KV — Drafter GPU 쪽
[논문에 없음] Drafter도 2m개 전부에 대해 draft model의 KV cache를 들고 있어야 한다. 그런데 Drafter는 TP=1, 단일 GPU다. Setting 5처럼 8B draft에 m=64(→128 concurrent), context가 길어지면 target이 아니라 draft GPU가 먼저 터지거나 preemption을 유발할 수 있다. draft-side KV 용량은 논문에서 한 번도 분석되지 않는다.
유효 적용 범위
| 축 | MineDraft 유리 | MineDraft 불리 |
|---|---|---|
| batch 상태 | KV·compute에 여유 있는 중간 부하 | C 포화까지 채운 max-throughput 운영 |
| context 길이 | short (논문 실험: output 256 token) | long-context |
k | 3 전후 (통신비 희석) | 1~2 강제 (통신비 지배) |
| prefill 정책 | chunked prefill off | chunked prefill on |
| 모델 배치 | draft+target이 한 GPU에 안 들어가는 경우 | 이미 잘 들어가는 경우 |
| 요청 유입 | 2m 이상 꾸준히 유지 | 유입이 들쭉날쭉하거나 부족 |
MineDraft가 겨냥한 건 “batch를 꽉 채우는 운영”이 아니라 그 반대편 — 자원에 여유가 있고 GPU를 1장 더 붙일 수 있는 환경이다. §A가 그 경계 판단(SD를 끌지, m을 줄일지)을 adaptive scheduling으로 넘겨 future work로 명시한 것이 이를 뒷받침한다.