WhiFlash: Accelerating Speculative Decoding with Token-Level Cross-Paradigm Routing Review

0. Introduction

Paper link

Author page

Item	Value
Title	WhiFlash: Accelerating Speculative Decoding with Token-Level Cross-Paradigm Routing
Authors	Young D. Kwon, Miles Williams, Rui Li, Alexandros Kouris, Stylianos I. Venieris
arXiv	2606.07710v1
Submitted	2026-06-05
Status	Under review

Speculative decoding은 autoregressive LLM의 decode latency를 줄이는 가장 실용적인 방법 중 하나다. 작은 draft model이 여러 token을 먼저 제안하고, 큰 target model이 이를 한 번에 검증한다. Draft가 target의 next-token distribution을 잘 따라가면 한 번의 verification round에서 여러 token을 확정할 수 있다.

하지만 기존 speculative decoding은 대체로 draft paradigm을 미리 고정한다. EAGLE-3 같은 autoregressive drafter는 앞에서부터 token을 순차적으로 만들며 reasoning처럼 dependency가 강한 구간에 잘 맞는다. 반대로 DFlash 같은 diffusion-based parallel drafter는 block 내부 token을 병렬로 제안할 수 있어 structured output처럼 local predictability가 높은 구간에서 latency advantage를 만들 수 있다.

문제는 실제 generation sequence가 한 가지 성격으로만 구성되지 않는다는 점이다. Agent workload를 예로 들면 자연어 planning, 수학적 reasoning, API argument, JSON field, code snippet, 반복되는 template이 하나의 response 안에 섞일 수 있다. 초반에는 reasoning dependency가 강하지만, 중간에는 format이 고정되고, 다시 예외 처리가 나오면서 uncertainty가 높아질 수 있다.

WhiFlash는 이 변화에 주목한다. 논문은 drafting accuracy가 같은 sequence 내부에서도 크게 흔들리기 때문에, request 단위나 sequence 단위로 AR 또는 diffusion drafter 하나를 고르는 방식이 잠재 throughput을 놓친다고 본다. 그래서 두 drafting paradigm을 동시에 준비하고, token-level controller가 현재 state에 더 적합한 쪽을 선택하게 한다.

이 아이디어만 보면 dynamic routing 문제처럼 보인다. 그러나 실제 병목은 route decision보다 state synchronization이다. AR drafter와 diffusion drafter는 서로 다른 cache와 generation state를 가진다. Token마다 route를 바꾸면 inactive drafter가 그동안 생성된 prefix를 따라잡아야 하고, 이 비용이 acceptance gain을 모두 상쇄할 수 있다.

WhiFlash는 routing과 cache management를 함께 설계한다. Controller는 entropy-based policy 또는 learned neural policy로 구성할 수 있고, expected token gain과 latency 사이의 operating point를 조절한다. Cache 쪽에서는 Lazy Catch-up과 KV-only Prefill을 도입해 high-frequency switching overhead를 per-round latency의 7% 미만으로 줄였다고 보고한다.

한 줄 요약: WhiFlash는 autoregressive draft와 diffusion-based parallel draft를 token level에서 동적으로 전환하고, Lazy Catch-up과 KV-only Prefill로 cache synchronization 비용을 낮춰 서로 다른 drafting paradigm의 장점을 한 speculative decoding loop 안에서 결합한다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

• Speculative decoding의 선택지를 단일 draft architecture가 아니라 runtime routing 문제로 확장한다.
• Request마다 하나의 drafter를 고르는 coarse routing보다 더 세밀한 token-level adaptation을 제안한다.
• Routing policy만 제안하지 않고, 실제 전환을 가능하게 하는 cache protocol을 함께 설계한다.
• Reasoning과 structured output이 섞이는 agent workload에서 sequence 내부 heterogeneity를 직접 다룬다.
• Acceptance length가 높아져도 switching cost가 크면 wall-clock gain이 사라진다는 systems 관점을 명확히 보여준다.

1. Problem Setting

1-1. Speculative decoding의 기본 cost model

Standard autoregressive decoding은 target model이 매 step 한 token을 만든다. Output length를 $N$이라고 하면 target forward가 대략 $N$번 필요하다.

Speculative decoding에서는 가벼운 draft model $q$가 길이 $K$의 candidate block을 만든다.

\[\hat{y}_{t:t+K-1} \sim q(\cdot \mid y_{<t})\]

그다음 target model $p$가 candidate block을 병렬로 검증하고, accepted prefix를 확정한다. 한 round에서 확정되는 token 수를 $A$라고 하면, practical throughput은 다음 구성 요소에 의해 결정된다.

\[\mathrm{Throughput} \propto \frac{\mathbb{E}[A]}{T_{\mathrm{draft}} + T_{\mathrm{verify}} + T_{\mathrm{route}} + T_{\mathrm{sync}}}\]

여기서 중요한 것은 acceptance length만 높이면 충분하지 않다는 점이다.

• Draft model이 강해도 sequential drafting latency가 길면 전체 gain이 줄어든다.
• Parallel drafter가 빨라도 draft accuracy가 낮으면 target verification round가 자주 반복된다.
• Dynamic routing이 정확해도 route decision과 cache synchronization 비용이 크면 손해가 난다.
• Batch size와 sequence length가 달라지면 각 cost의 상대 비중도 달라진다.

따라서 좋은 speculative decoding system은 quality와 latency를 따로 최적화할 수 없다. Draft acceptance와 draft generation cost, verification cost, state transition cost를 하나의 loop에서 봐야 한다.

1-2. Autoregressive drafter와 diffusion drafter의 trade-off

WhiFlash가 결합하는 두 paradigm은 서로 다른 병목을 가진다.

Draft paradigm	Main strength	Main weakness	잘 맞는 구간의 직관
Autoregressive draft	이전 token을 순차적으로 반영해 dependency를 추적	$K$개 token을 만들려면 sequential step이 필요	Reasoning, branch change, uncertain continuation
Diffusion-based parallel draft	Block token을 병렬로 제안해 draft latency를 낮춤	구조가 급변하거나 token dependency가 강하면 acceptance가 낮아질 수 있음	JSON, code template, 반복 pattern, predictable continuation

AR drafter는 한 token씩 생성하므로 draft block 자체가 sequential하다. Target model보다 훨씬 작더라도 draft length가 길어질수록 latency가 누적된다. 대신 이전 draft token을 바로 condition에 반영하기 때문에 reasoning branch나 semantic transition을 따라가기 쉽다.

Diffusion-based parallel drafter는 block을 동시에 복원하는 방식으로 draft latency를 줄인다. Structured output이나 local pattern이 강한 구간에서는 여러 token을 한 번에 잘 맞힐 수 있다. 그러나 block 내부 dependency가 강하거나 다음 token distribution이 급격히 변하면 parallel proposal의 quality가 떨어질 수 있다.

둘 중 하나가 항상 우월한 것이 아니다. 중요한 변수는 현재 sequence state다.

1-3. Sequence 내부 drafting accuracy volatility

기존 routing을 세 가지 granularity로 나누면 WhiFlash의 문제 정의가 선명해진다.

1. Static routing
   • Deployment에서 AR 또는 diffusion drafter 하나만 사용한다.
   • Implementation은 단순하지만 workload heterogeneity를 무시한다.
2. Request-level routing
   • Prompt 또는 task category를 보고 request마다 drafter를 고른다.
   • Math는 AR, JSON generation은 diffusion처럼 나눌 수 있다.
   • 한 response 안에서 workload character가 바뀌는 문제는 해결하지 못한다.
3. Token-level routing
   • Generation state가 바뀔 때마다 drafter를 다시 선택한다.
   • Fine-grained adaptation이 가능하지만 route overhead와 cache consistency가 핵심 병목이 된다.

논문의 empirical observation은 drafting accuracy가 single sequence 안에서도 크게 변한다는 것이다. 이 현상이 맞다면 request-level label만으로 최적 drafter를 고를 수 없다.

예를 들어 agent response가 다음처럼 진행된다고 하자.

\[\text{plan} \to \text{reasoning} \to \text{tool call JSON} \to \text{result analysis} \to \text{final template}\]

Reasoning 구간에서는 AR drafter가 더 높은 acceptance를 만들 수 있고, JSON과 final template 구간에서는 diffusion drafter가 더 빠를 수 있다. Static choice는 어느 한쪽 구간의 이득을 포기한다.

1-4. Dynamic routing이 바로 작동하지 않는 이유

두 drafter를 준비하고 controller만 붙이면 끝나는 것은 아니다. 각 drafter는 지금까지의 prefix에 대한 internal state를 유지해야 한다.

Autoregressive transformer drafter는 일반적으로 KV cache를 사용한다. Diffusion drafter도 target feature, draft block state, conditioning cache처럼 자체 state를 가질 수 있다. 한 drafter가 여러 token 동안 inactive였다가 다시 선택되면, 그동안 target에서 확정된 token을 자신의 state에 반영해야 한다.

Naive implementation은 매 round 두 drafter를 모두 update할 수 있다. 하지만 실제로 사용하지 않은 drafter까지 계속 실행하면 dynamic routing의 계산 절감이 사라진다. 반대로 inactive drafter를 전혀 update하지 않으면 나중에 route가 바뀔 때 긴 prefix prefill이 필요하다.

이 trade-off를 단순화하면 다음과 같다.

State policy	Advantage	Cost
Eager synchronization	어느 drafter로도 즉시 switch 가능	매 round 두 drafter 계산이 필요
No synchronization	Active drafter만 계산	Switch 시 full catch-up cost 발생
Lazy synchronization	평소에는 active path만 계산하고 switch 시 필요한 만큼 보완	Catch-up protocol과 cache correctness가 필요

WhiFlash의 systems contribution은 세 번째 operating point를 실제로 구현하려는 데 있다.

2. Core Idea

2-1. Main contribution

WhiFlash의 기여는 네 부분으로 압축할 수 있다.

1. Cross-paradigm speculative decoding
   • AR draft와 diffusion-based parallel draft를 같은 target verification loop 안에 둔다.
   • 서로 다른 architecture의 complementary strength를 runtime에 활용한다.
2. Token-level controller
   • Sequence 또는 request마다 한 번 고르는 대신, generation 중 fine-grained route decision을 수행한다.
   • Entropy-based controller와 learned neural policy 두 option을 제안한다.
3. Gain-latency trade-off control
   • Controller를 expected token gain과 latency 사이의 균형을 조절할 수 있게 parameterize한다.
   • Acceptance만 최대화하지 않고 wall-clock utility를 고려한다.
4. Cache-management optimization
   • Lazy Catch-up과 KV-only Prefill로 inactive drafter state를 효율적으로 복구한다.
   • High-frequency switching overhead를 per-round latency의 7% 미만으로 줄였다고 보고한다.

이 구성을 보면 WhiFlash는 단순한 routing classifier가 아니다. Route decision, state transition, target verification을 함께 묶은 inference system이다.

2-2. Design intuition

1) Draft paradigm을 model identity가 아니라 runtime action으로 본다

기존 speculative decoding은 어떤 draft model을 학습할지가 중심이었다. WhiFlash는 한 step 더 나아가 현재 token state에서 어떤 generation paradigm을 실행할지를 결정한다.

Controller의 decision을 개념적으로 다음처럼 볼 수 있다. 아래 식은 논문의 exact objective를 옮긴 것이 아니라, abstract에 설명된 expected token gain과 latency trade-off를 나타낸 conceptual form이다.

\[U(m \mid s_t) = \widehat{G}(m,s_t) - \lambda \widehat{L}(m,s_t)\]

여기서 $m$은 AR 또는 diffusion route, $s_t$는 현재 generation state, $\widehat{G}$는 예상 token gain, $\widehat{L}$은 예상 latency다. $\lambda$를 조절하면 acceptance를 더 중시하거나 latency를 더 중시하는 operating point를 선택할 수 있다.

이 관점이 중요한 이유는 best route가 task label로 완전히 결정되지 않기 때문이다. 같은 math response에서도 formula 전개는 predictable할 수 있고, proof branch를 선택하는 순간은 uncertainty가 높을 수 있다.

2) Uncertainty를 routing signal로 사용한다

Entropy-based controller는 현재 state의 uncertainty를 lightweight signal로 사용한다. Entropy가 route decision에 어떤 형태로 입력되는지, 어느 model distribution에서 계산되는지, threshold를 어떻게 calibration하는지는 원문 algorithm과 appendix에서 추가 확인이 필요하다.

다만 설계 직관은 명확하다.

• Uncertainty가 높은 구간에서는 sequential dependency를 더 충실히 반영하는 AR draft가 유리할 수 있다.
• Distribution이 sharp하고 local structure가 안정된 구간에서는 parallel diffusion draft가 유리할 수 있다.
• Entropy 하나로 모든 case를 설명하기 어렵기 때문에 learned policy option도 둔다.

Entropy route는 단순성과 낮은 overhead가 장점이다. Learned route는 더 복잡한 state pattern을 학습할 수 있지만, 별도 training과 calibration, distribution shift 대응이 필요하다.

3) Route accuracy보다 realized utility를 본다

Routing system은 ground-truth label을 맞히는 classification 문제가 아니다. AR route가 acceptance를 조금 더 만들더라도 latency가 길면 diffusion route보다 나쁠 수 있다. 반대로 diffusion route가 빠르더라도 rejection이 늘어 target round가 반복되면 손해다.

따라서 meaningful objective는 다음 요소를 함께 봐야 한다.

• Accepted tokens per round
• Draft latency
• Target verification latency
• Switching and synchronization latency
• Route policy overhead
• Memory footprint

WhiFlash가 controller를 tunable하게 만든 이유도 여기에 있다. Deployment마다 GPU, batch size, target model, output distribution이 달라 같은 routing threshold가 최적일 수 없다.

4) Frequent switching은 cache protocol이 있어야 의미가 있다

Token-level routing은 decision granularity가 fine한 만큼 switch 횟수가 많아질 수 있다. 이때 inactive drafter를 catch up하는 비용이 크면, controller가 이상적인 route를 알아도 실행할 수 없다.

WhiFlash는 cache update를 routing design의 일부로 본다. Lazy Catch-up과 KV-only Prefill은 route flexibility를 실제 wall-clock gain으로 연결하는 장치다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	Sequence 내부 변화에 맞춰 AR draft와 diffusion draft를 token level에서 선택
Target path	Draft candidate를 검증하고 accepted prefix를 확정하는 target LLM
Draft path A	Sequential autoregressive drafter
Draft path B	Parallel diffusion-based drafter
Router option A	Lightweight entropy-based policy
Router option B	Learned neural policy
Cost control	Expected token gain과 latency 사이의 tunable balance
State optimization	Lazy Catch-up and KV-only Prefill
Main baselines	EAGLE-3 and DFlash
Reported outcome	Higher acceptance length and category-specific throughput gains

3-2. Dual-drafter execution graph

WhiFlash의 execution graph에는 target model과 두 drafter가 있다.

1. Target model
   • Draft token을 검증한다.
   • Accepted prefix를 global committed state로 만든다.
   • Final output distribution의 기준이 된다.
2. AR drafter
   • Current prefix에서 token을 순차적으로 제안한다.
   • Dependency가 강하거나 uncertainty가 높은 구간을 담당할 수 있다.
3. Diffusion drafter
   • Candidate block을 병렬로 제안한다.
   • Structured and locally predictable region에서 draft latency를 줄일 수 있다.
4. Controller
   • Current state에서 사용할 draft paradigm을 선택한다.
   • Entropy-based 또는 learned policy를 사용할 수 있다.
5. Cache manager
   • Active drafter와 inactive drafter의 prefix state를 추적한다.
   • Switch가 발생하면 stale state를 필요한 만큼 복구한다.
6. Target verifier
   • Chosen drafter의 candidate를 검증하고 accepted prefix를 확정한다.
   • Rejection이 발생하면 target rule에 따라 continuation을 진행한다.

이 구조에서 global truth는 target이 확정한 prefix다. 두 drafter의 cache는 이 committed prefix와 논리적으로 일치해야 한다.

3-3. Token-level controller

Controller는 매 routing point에서 두 draft path의 expected utility를 비교한다. Abstract 기준으로 두 controller variant가 있다.

1) Entropy-based controller

Entropy-based controller는 model uncertainty와 관련된 lightweight statistic을 사용한다. 이 방식의 장점은 다음과 같다.

• Neural router보다 decision overhead가 작다.
• Behavior를 threshold나 scalar parameter로 해석하기 쉽다.
• Hardware profile에 맞춰 latency preference를 조절하기 쉽다.
• Failure analysis에서 route choice의 근거를 추적하기 쉽다.

그러나 entropy가 높다고 항상 AR이 유리하고, 낮다고 항상 diffusion이 유리한 것은 아니다. Token type, syntax boundary, context length, draft calibration에 따라 같은 entropy에서도 acceptance behavior가 달라질 수 있다.

2) Learned neural policy

Learned policy는 entropy 하나로 포착하기 어려운 state pattern을 사용할 수 있다. Potential input은 current uncertainty, recent acceptance history, token position, drafter state, latency estimate 등이 될 수 있지만, exact feature set과 architecture는 원문에서 추가 확인이 필요하다.

Learned policy의 장점은 richer routing boundary다. 단점은 다음과 같다.

• Router training data가 deployment workload와 달라지면 policy가 drift할 수 있다.
• Router latency가 작아도 high-frequency decision에서는 누적될 수 있다.
• Policy가 acceptance만 학습하면 실제 latency-optimal route와 달라질 수 있다.
• Black-box route는 debugging과 safety fallback을 어렵게 만들 수 있다.

논문은 두 controller 모두 expected token gain과 latency의 trade-off를 조절할 수 있도록 parameterize한다고 설명한다. 즉 learned policy도 pure accuracy classifier로 읽으면 안 된다.

3-4. Lazy Catch-up

Token-level routing에서는 inactive drafter가 stale해지는 문제가 생긴다. Lazy Catch-up은 두 drafter를 매 token마다 eager synchronization하지 않고, inactive drafter가 다시 필요해질 때 누락된 prefix state를 따라잡게 하는 optimization으로 이해할 수 있다.

개념적으로 committed prefix 길이를 $t$, AR cache가 반영한 길이를 $c_{AR}$, diffusion cache가 반영한 길이를 $c_{D}$라고 하자.

\[\Delta_{AR} = t - c_{AR}, \qquad \Delta_D = t - c_D\]

현재 AR route만 사용한다면 diffusion cache를 매 round update할 필요가 없다. Diffusion route로 switch할 때 $\Delta_D$에 해당하는 missing prefix만 catch up하면 된다.

이 방식은 다음 trade-off를 만든다.

• Route가 오래 유지되면 inactive path 계산을 크게 절약한다.
• Switch가 자주 발생하면 catch-up cost가 늘어난다.
• Controller는 route quality뿐 아니라 future switch cost도 고려해야 한다.
• Cache manager는 각 drafter가 어느 committed position까지 synchronized됐는지 정확히 추적해야 한다.

Exact catch-up scheduling과 rollback rule은 원문 algorithm에서 재확인할 필요가 있다. 그러나 핵심은 synchronization을 every-token tax가 아니라 on-demand cost로 바꾸는 것이다.

3-5. KV-only Prefill

Inactive transformer drafter가 missing prefix를 따라잡으려면 보통 prefill을 다시 수행해야 한다. Naive prefill은 각 position의 output logits까지 계산할 수 있지만, catch-up 목적에서는 과거 token을 다시 예측할 필요가 없다. 필요한 것은 이후 draft generation에 사용할 KV state다.

KV-only Prefill은 이 redundancy를 줄이는 방향의 optimization이다. Catch-up 구간에서 full token prediction path 대신 cache construction에 필요한 computation을 중심으로 수행한다.

이 설계가 의미 있는 이유는 다음과 같다.

• Historical token의 logits를 다시 계산해도 route decision에는 직접 쓰이지 않을 수 있다.
• Switch cost가 줄어야 controller가 fine-grained route를 실제로 사용할 수 있다.
• Cache synchronization과 output generation을 분리하면 systems-level optimization이 가능하다.
• High-frequency switching에서 catch-up cost의 상한을 낮출 수 있다.

논문은 Lazy Catch-up과 KV-only Prefill을 함께 사용해 switching overhead를 per-round latency의 7% 미만으로 줄였다고 보고한다. 이 수치는 switch cost가 0이라는 뜻이 아니라, routing gain을 압도하지 않는 수준으로 제한했다는 의미로 읽어야 한다.

3-6. End-to-end decoding round

WhiFlash의 한 round를 high-level로 정리하면 다음과 같다.

1. Target이 확정한 current prefix와 drafter cache status를 확인한다.
2. Controller가 entropy-based rule 또는 learned policy로 route를 선택한다.
3. Chosen drafter가 stale하면 Lazy Catch-up을 실행한다.
4. 필요한 missing KV state는 KV-only Prefill로 보완한다.
5. Chosen drafter가 candidate token 또는 block을 생성한다.
6. Target model이 candidate를 검증한다.
7. Accepted prefix를 committed state에 추가한다.
8. 각 drafter의 synchronized position을 update한다.
9. 다음 routing point에서 같은 과정을 반복한다.

이 flow에서 correctness-critical component는 target verifier와 cache position accounting이다. Router가 suboptimal route를 선택하면 performance가 낮아질 수 있지만, cache state가 틀리면 output correctness 자체가 깨질 수 있다. Production implementation에서는 두 failure를 분리해서 monitoring해야 한다.

3-7. 기존 방법과 차이

Method family	Draft paradigm	Routing granularity	Main optimization target
EAGLE-3 style	Autoregressive	Static	Strong AR draft acceptance
DFlash style	Diffusion parallel	Static	Low-latency block drafting
Request router	Multiple possible	Request level	Task category별 drafter selection
WhiFlash	AR plus diffusion	Token level	Local acceptance-latency utility plus low-cost switching

WhiFlash의 차별점은 두 architecture를 ensemble한다는 사실만이 아니다. Router가 fine-grained decision을 내릴 수 있도록 state transition cost를 설계한 것이 핵심이다.

4. Training / Data / Recipe

4-1. 무엇이 학습되고 무엇이 고정되는가

WhiFlash는 base target LLM을 새로 pretrain하는 논문이라기보다 inference-time orchestration method다. System에는 이미 학습된 target과 두 draft path가 필요하다.

구성 요소별로 보면 다음과 같다.

Component	Role	Additional learning requirement
Target LLM	Final verification	Existing checkpoint 사용
AR drafter	Sequential candidate generation	Compatible draft training 필요
Diffusion drafter	Parallel block candidate generation	Compatible diffusion draft training 필요
Entropy controller	Lightweight route decision	Threshold and trade-off calibration 필요
Learned controller	Richer route decision	별도 policy training 필요
Cache manager	State synchronization	Training보다 systems implementation이 핵심

논문 abstract는 controller variant와 high-level objective를 설명하지만, learned policy의 exact architecture, training target, feature set, data construction은 원문 본문과 appendix에서 추가 확인이 필요하다.

4-2. Controller calibration

Routing policy를 실제 deployment에 붙일 때는 offline accuracy보다 latency-aware calibration이 중요하다.

추천되는 validation 관점은 다음과 같다.

1. Route-specific acceptance profile
   • 같은 token state에서 AR과 diffusion의 accepted length를 비교한다.
   • Task 평균뿐 아니라 position별 variation을 본다.
2. Route-specific latency profile
   • Draft latency와 verification latency를 따로 측정한다.
   • Cache warm, cache stale, switch case를 분리한다.
3. Switching frequency
   • Route가 너무 자주 바뀌면 controller noise나 threshold instability를 의심한다.
   • Acceptance gain보다 synchronization cost가 커질 수 있다.
4. Calibration under workload shift
   • Math, code, chat, JSON, tool use에서 entropy distribution이 달라질 수 있다.
   • Offline threshold를 그대로 production에 쓰면 route imbalance가 생길 수 있다.
5. Cost-aware objective
   • Route label accuracy가 아니라 realized tokens per second를 objective로 둔다.
   • P50뿐 아니라 P95 latency와 batch throughput도 본다.

4-3. Cache correctness test

Cache optimization은 performance feature이면서 correctness-critical feature다. 최소한 다음 test가 필요하다.

• Route를 AR only로 고정했을 때 baseline AR SD와 output이 일치하는가.
• Route를 diffusion only로 고정했을 때 baseline diffusion SD와 output이 일치하는가.
• 매 round route를 강제로 교대해도 target output이 일치하는가.
• Long inactive interval 뒤 switch해도 cache position이 맞는가.
• Rejection과 rollback 뒤 두 drafter cache가 committed prefix와 일치하는가.
• Batch 내 sequence마다 route가 달라도 cache index가 섞이지 않는가.
• Early stop, EOS, tool delimiter, structured decoding constraint에서 state가 안전한가.

이 test 없이 speed benchmark만 보면 cache bug를 performance gain으로 오인할 수 있다.

4-4. Serving engineering notes

1) Memory footprint를 먼저 계산해야 한다

두 drafter를 동시에 resident하게 만들면 parameter memory와 cache memory가 늘어난다. Target보다 draft가 작더라도 production에서는 replica density가 줄어들 수 있다. Throughput gain은 single request latency가 아니라 GPU당 concurrent request 수와 함께 평가해야 한다.

2) Continuous batching과 route divergence를 봐야 한다

Batch 안의 sequence가 서로 다른 route를 선택하면 kernel homogeneity가 깨질 수 있다. One-request benchmark에서 route가 잘 작동해도 continuous batching에서는 launch overhead와 padding waste가 커질 수 있다.

3) Route hysteresis가 필요할 수 있다

Controller score가 boundary 근처에서 흔들리면 AR과 diffusion 사이를 반복해서 오가는 thrashing이 생길 수 있다. Minimum dwell time, switch penalty, confidence margin 같은 stabilization rule을 함께 검토할 가치가 있다.

4) Fallback path가 필요하다

Learned router가 distribution shift를 만나거나 cache synchronization error가 감지되면, safe static route로 즉시 fallback할 수 있어야 한다. Router가 system correctness의 single point of failure가 되면 안 된다.

5) Metric을 route별로 기록해야 한다

최소 logging 항목은 다음과 같다.

• AR route ratio
• Diffusion route ratio
• Mean and tail switching frequency
• Route별 acceptance length
• Route별 draft latency
• Catch-up latency
• KV-only Prefill latency
• Verification latency
• Rejection position
• Tokens per second and memory usage

4-5. 공개 artifact 상태

Review 시점에 arXiv page와 저자 publication page에서는 논문 PDF와 BibTeX link는 확인되지만, WhiFlash official code link는 확인되지 않았다. 따라서 cache protocol과 controller를 직접 재현하려면 원문 algorithm을 기준으로 별도 implementation이 필요하다.

이 점은 결과의 의미를 낮추지는 않지만, production-ready recipe로 받아들이기 전에는 다음을 확인해야 한다.

• Controller architecture and training data
• Entropy definition and threshold
• Route decision frequency
• Lazy Catch-up exact scheduling
• KV-only Prefill kernel scope
• Batch and hardware settings
• Draft model compatibility requirement

5. Evaluation

5-1. Abstract에서 확인되는 main results

현재 공개 metadata와 abstract에서 직접 확인되는 결과는 다음과 같다.

Result	Reported value	올바른 해석
Switching overhead	Per-round latency의 7% 미만	Frequent routing을 가능하게 하는 systems result
Acceptance behavior	Static baselines보다 높은 acceptance length	두 drafter의 complementary strength를 활용
Throughput vs EAGLE-3	Category-specific 최대 69.6% gain	모든 task 평균 gain으로 해석하면 안 됨
Throughput vs DFlash	Category-specific 최대 37.3% gain	Hardware and workload condition 확인 필요
Paper status	arXiv v1, under review	Camera-ready result로 간주하면 안 됨

가장 중요한 표현은 category-specific과 up to다. 69.6%와 37.3%는 전체 workload 평균을 보장하는 숫자가 아니다. 어떤 category에서 AR과 diffusion의 complementarity가 가장 컸는지, 다른 category에서 gain이 얼마나 줄었는지는 원문 table을 확인해야 한다.

5-2. Acceptance length보다 wall-clock이 중요하다

Speculative decoding paper에서 acceptance length는 핵심 metric이지만 단독으로 보면 부족하다. WhiFlash에서는 특히 그렇다.

AR drafter가 더 많은 token을 맞혀도 draft latency가 길 수 있다. Diffusion drafter가 block을 빠르게 만들더라도 rejection이 늘 수 있다. Dynamic route가 acceptance를 높여도 switch overhead가 추가된다.

따라서 다음 decomposition이 필요하다.

\[T_{\mathrm{round}} = T_{\mathrm{route}} + T_{\mathrm{catchup}} + T_{\mathrm{draft}} + T_{\mathrm{verify}}\]

그리고 effective cost per accepted token은 다음처럼 볼 수 있다.

\[C_{\mathrm{token}} = \frac{T_{\mathrm{round}}}{\mathbb{E}[A]}\]

WhiFlash의 핵심 claim은 route quality와 cache optimization을 함께 사용해 이 ratio를 낮춘다는 것이다.

5-3. 실험에서 반드시 분리해서 볼 항목

1) Static AR vs static diffusion vs dynamic routing

Dynamic method의 gain을 해석하려면 두 static oracle과 비교해야 한다.

• Always AR
• Always diffusion
• Request-level route
• Token-level entropy route
• Token-level learned route
• Offline oracle route

Offline oracle이 있다면 upper bound와 controller gap을 볼 수 있다. Exact comparison set은 원문 table에서 확인이 필요하다.

2) Router gain과 cache optimization gain

WhiFlash의 성능이 좋아진 이유는 두 부분으로 나뉜다.

• Better route selection으로 acceptance-latency trade-off 개선
• Lazy Catch-up and KV-only Prefill로 switch cost 감소

따라서 ablation은 다음을 포함해야 한다.

• Dynamic routing with naive synchronization
• Lazy Catch-up only
• KV-only Prefill only
• Both cache optimizations
• Entropy controller vs learned controller

Abstract는 combined switching overhead만 알려주므로, 각 component의 individual contribution은 원문 figure와 table에서 재확인해야 한다.

3) Workload category별 route pattern

Cross-paradigm routing의 설득력은 route visualization에서 강해진다.

• Reasoning token에서 AR route가 늘어나는가.
• Structured span에서 diffusion route가 늘어나는가.
• Route가 semantic boundary와 맞물리는가.
• Learned policy가 entropy rule과 다른 case를 잡는가.
• Long sequence에서 route distribution이 drift하는가.

이 분석이 있어야 controller가 단순히 한 route를 대부분 선택하는 것이 아니라, 실제로 complementary behavior를 활용하는지 알 수 있다.

4) Hardware and batch sensitivity

Speculative decoding gain은 hardware와 batch size에 민감하다.

• Small batch에서는 target decode latency 절감이 크게 보일 수 있다.
• Large batch에서는 target verification과 memory bandwidth가 병목이 될 수 있다.
• 두 drafter를 resident하게 하면 memory pressure가 높아질 수 있다.
• Diffusion draft의 parallelism은 GPU utilization에 따라 gain이 달라질 수 있다.

따라서 single-stream speedup만으로 serving throughput을 일반화하면 안 된다.

5-4. 무엇이 진짜 의미 있는가

이 논문에서 가장 의미 있는 experimental message는 최대 throughput 숫자보다 다음 세 가지다.

1. Best drafting paradigm이 sequence 내부에서 바뀐다
   • Static drafter 선택이 구조적으로 비최적일 수 있다는 근거다.
2. Fine-grained route를 쓰려면 state management가 필요하다
   • Algorithmic oracle만으로는 practical speedup이 나오지 않는다.
3. Controller는 acceptance와 latency를 동시에 최적화해야 한다
   • Route classification accuracy가 production metric이 아니다.

이 세 메시지는 WhiFlash를 단순 benchmark winner보다 systems design paper로 읽게 만든다.

6. Limitations

1. 두 drafter의 memory and maintenance cost
   • AR drafter와 diffusion drafter를 모두 준비하고 serving해야 한다.
   • Parameter memory, cache memory, checkpoint lifecycle, kernel dependency가 늘어난다.
   • Single-request throughput gain이 GPU fleet cost 절감으로 바로 이어지는 것은 아니다.
2. Controller calibration이 workload에 의존한다
   • Entropy distribution과 route utility는 model, prompt, task, batch size에 따라 달라질 수 있다.
   • Learned policy도 training distribution 밖에서는 suboptimal route를 고를 수 있다.
3. Token-level switching은 thrashing risk가 있다
   • Small score fluctuation으로 route가 반복 전환되면 catch-up cost가 누적된다.
   • Switch penalty, hysteresis, minimum dwell time이 필요할 수 있다.
4. Cache protocol은 correctness-critical하다
   • Stale KV, position mismatch, rollback error가 생기면 speed가 아니라 output correctness가 깨진다.
   • Multi-batch and continuous batching 구현 난도가 높다.
5. Reported gain은 category-specific maximum이다
   • EAGLE-3 대비 69.6%, DFlash 대비 37.3%는 모든 model과 task에서의 평균이 아니다.
   • Exact benchmark, hardware, batch, sequence length를 확인한 뒤 해석해야 한다.
6. Controller and cache implementation detail의 공개 범위가 제한적이다
   • Review 시점에 official code link를 확인하지 못했다.
   • Learned policy training, entropy definition, Lazy Catch-up pseudocode, KV-only kernel 범위를 재현하려면 원문 확인과 engineering work가 필요하다.
7. Router overhead 외의 system cost가 남는다
   • Model loading, memory fragmentation, kernel launch, synchronization, batch divergence가 production latency에 영향을 준다.
   • Per-round switching overhead 7% 미만이 end-to-end fleet efficiency를 보장하지 않는다.
8. Under-review v1 결과다
   • 현재 arXiv v1이며 under review로 표시된다.
   • 후속 revision에서 experiment setting이나 result table이 바뀔 수 있다.

7. My Take

7-1. Why this matters for my work

WhiFlash의 가장 큰 의미는 “좋은 drafter를 하나 고르는 문제”를 “현재 token state에 맞는 generation paradigm을 실행하는 문제”로 바꿨다는 데 있다.

LLM inference optimization은 보통 model-level choice로 설계된다.

• Dense or MoE
• Full attention or sparse attention
• AR draft or diffusion draft
• Large model or small model

하지만 실제 request의 difficulty와 structure는 sequence 안에서 계속 바뀐다. WhiFlash는 이 variability를 runtime control variable로 끌어올린다. 이 관점은 speculative decoding을 넘어 adaptive depth, sparse attention, KV policy, expert routing에도 연결된다.

특히 agent workload에서는 잘 맞는다.

• Planning and reasoning span은 AR route
• Tool argument and JSON span은 diffusion route
• Repetitive template은 parallel route
• Unexpected observation 뒤에는 AR route

물론 논문이 이런 semantic label을 직접 rule로 사용한다고 단정할 수는 없다. 중요한 것은 workload가 heterogeneous하다는 사실을 controller가 활용한다는 점이다.

7-2. Reuse potential

1) Router를 standalone policy로 분리한다

Serving stack에서 route policy를 model code 안에 hard-code하지 않고, profiling 가능한 module로 분리할 수 있다.

• State feature extraction
• Expected gain prediction
• Latency prediction
• Switch penalty
• Safe fallback

이렇게 분리하면 model이나 hardware가 바뀔 때 router만 recalibration할 수 있다.

2) Acceptance history를 online feature로 사용한다

최근 몇 round의 acceptance length는 local draft quality를 직접 보여준다. Entropy signal과 함께 사용하면 route utility를 더 안정적으로 추정할 수 있다.

다만 online feedback을 쓰면 route oscillation과 delayed response 문제가 생길 수 있으므로 smoothing이 필요하다.

3) Cache freshness를 first-class state로 둔다

Router가 drafter quality만 보고 route를 선택하면 switch cost를 놓친다. Candidate utility에 cache staleness를 함께 넣어야 한다.

예를 들어 diffusion route가 조금 더 높은 acceptance를 기대하더라도 cache가 오래 stale했다면 AR route를 한 round 더 유지하는 것이 빠를 수 있다.

4) Batch-aware routing으로 확장한다

Production에서는 request별 optimal route와 batch-level optimal route가 다를 수 있다. 같은 route를 선택한 sequence를 micro-batch로 묶거나, route divergence cost를 controller objective에 넣는 확장이 필요하다.

5) Route observability를 제품 metric으로 만든다

Dynamic system은 평균 throughput만 보면 debugging이 어렵다. Route timeline, cache age, switch reason, accepted span을 trace로 남기면 다음을 확인할 수 있다.

• Router가 semantic boundary를 잡는가.
• 한 route로 collapse하는가.
• 특정 token type에서 thrashing하는가.
• Cache catch-up이 tail latency를 만드는가.

7-3. Follow-up papers

• EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test
• DFlash: Block Diffusion for Flash Speculative Decoding
• Speculative Decoding with a Speculative Vocabulary
• SpecRouter: Adaptive Routing for Multi-Level Speculative Decoding in Large Language Models
• Speculative Decoding: Performance or Illusion?

8. Summary

• WhiFlash는 AR draft와 diffusion-based parallel draft를 token-level controller로 통합한다.
• Entropy-based policy와 learned neural policy를 제공하고, expected token gain과 latency 사이의 operating point를 조절한다.
• Lazy Catch-up과 KV-only Prefill은 frequent switching의 cache synchronization 비용을 낮추는 핵심 systems component다.
• Abstract 기준 switching overhead는 per-round latency의 7% 미만이며, category-specific throughput은 EAGLE-3 대비 최대 69.6%, DFlash 대비 최대 37.3% 개선된다.
• 핵심 교훈은 dynamic routing의 성능이 route accuracy만이 아니라 cache state, switching cost, batch behavior까지 함께 설계할 때 나온다는 점이다.