Field Log · Entry

Speculative Decoding: Draft·Verify·Acceptance와 Serving 설계 (6/10)

Draft model이 후보 token을 제안하고 target model이 한 번에 검증한 뒤 acceptance ratio로 prefix를 채택하며 rejected suffix KV를 rollback하는 구조

오늘의 결론

  • Speculative decoding은 작은 proposer가 미래 token을 먼저 만들고 큰 target이 여러 위치를 한 번에 검증해, target의 serial decode step 수를 줄입니다.
  • Sampling에서 draft token을 단순히 target top-1과 비교하면 원래 분포가 보존되지 않습니다. min(1, p/q) acceptance와 rejection 시 residual distribution을 사용하면 target distribution을 exact하게 유지할 수 있습니다.
  • 속도는 acceptance rate 하나로 결정되지 않습니다. Draft 시간, target verification 길이, committed token 수, batch expansion, KV write·rollback, scheduler interference를 모두 포함해야 합니다.
  • Draft를 길게 만들면 한 번에 많이 전진할 기회와 첫 rejection 뒤 버리는 candidate가 함께 늘어납니다. Workload별 accepted-prefix 분포로 adaptive length를 정합니다.
  • RAG Agent에서는 긴 retrieved prompt의 TTFT가 아니라 output decode 구간만 주로 빨라집니다. 짧은 JSON tool call, grammar constraint, tool 경계에서는 overhead가 이득보다 클 수 있습니다.

앞 글에서는 과거 token의 KV를 block으로 저장·공유했습니다. 이번 글은 아직 생성되지 않은 미래 token 후보를 먼저 계산하고, target model의 결과를 바꾸지 않으면서 일부를 확정하는 방법을 다룹니다.

current accepted prefix
  → draft proposes γ future tokens cheaply
  → target verifies γ positions in one parallel forward
  → accept consecutive prefix
  → on rejection sample corrected token, or add bonus token if all accepted
  → commit accepted KV and rollback rejected suffix
  → repeat

이 글에서 답하는 질문

  1. 여러 미래 token을 어떻게 target 한 번으로 검증하는가?
  2. p/q acceptance가 target sampling distribution을 보존하는 이유는 무엇인가?
  3. Acceptance rate와 accepted length는 어떻게 다른가?
  4. Draft model·Medusa·EAGLE·n-gram·tree 방식은 무엇이 다른가?
  5. Rejected candidate의 KV와 scheduler budget은 어떻게 회수하는가?
  6. 어떤 RAG Agent workload에서 speculation을 끄는 편이 나은가?

Draft model이 x1부터 x4까지 후보 token chain과 확률 q를 만들고 target model이 한 번의 verification으로 각 위치의 p를 계산한 뒤 x1과 x2를 accept하고 x3에서 reject하여 residual token y를 선택하며 x3과 x4 KV를 rollback하고 committed token과 serving metric을 검증하는 흐름

그림 1. Target은 후보 전체를 병렬 평가하지만 acceptance는 왼쪽부터 순서대로 결정한다. 첫 rejection 뒤의 candidate와 KV는 유효한 context가 아니므로 폐기한다.


1. Autoregressive Decode의 Serial Dependency

일반 decode는 target model p를 token마다 한 번 실행합니다.

prefix → target → x1
prefix+x1 → target → x2
prefix+x1+x2 → target → x3

K개 token을 생성하려면 target forward도 대략 K번 순차 실행됩니다. 각 step의 batch token이 작아 weight read와 launch·collective 비용을 충분히 amortize하지 못할 수 있습니다.

2. 핵심 관찰: Verify는 병렬화할 수 있다

작고 빠른 draft model q가 후보 x1, x2, ..., xγ를 autoregressive하게 만듭니다. Target은 그 후보를 prompt처럼 한 번에 넣고 causal mask 아래에서 각 위치의 next-token distribution을 계산할 수 있습니다.

draft:  q(x1|c), q(x2|c,x1), ..., q(xγ|c,x<γ)

target one pass:
        p(x1|c), p(x2|c,x1), ..., p(xγ|c,x<γ), p(next|c,x≤γ)

Target verification도 더 많은 token을 계산하므로 공짜는 아니지만, γ번의 작은 serial decode보다 한 번의 넓은 forward가 빠를 수 있습니다.

3. Greedy Decoding의 가장 단순한 형태

Temperature 0의 greedy generation이라면 왼쪽부터 target argmax와 draft token을 비교합니다.

draft:  [서울, 은, 한국, 의]
target: [서울, 은, 대한민국, ...]

accept: 서울, 은
mismatch at position 3: commit target token 대한민국
discard later draft token 의

첫 mismatch 전까지 target도 같은 prefix를 보았으므로 token이 유효합니다. Mismatch 위치에는 target argmax를 넣고 다음 cycle로 갑니다.

4. Sampling은 단순 Match가 아니다

Temperature·top-p sampling에서는 target의 top-1과 일치하는지만 보면 target 분포가 바뀝니다. Draft가 자주 내는 token을 과도하게 선택하거나, rejection 처리에서 probability mass를 왜곡할 수 있습니다.

Lossless speculative sampling은 draft distribution q_i와 target distribution p_i를 모두 사용합니다. Temperature·top-k·top-p 같은 transform을 적용한다면 각 단계에서 정규화된 실제 sampling distribution을 일관되게 정의해야 합니다.

5. Acceptance Ratio

Draft가 위치 i에서 token x_i를 제안했다면 uniform random u_i ~ U(0,1)를 뽑아 다음 조건으로 accept합니다.

$$ u_i\leq\min\left(1,\frac{p_i(x_i)}{q_i(x_i)}\right) $$

  • Target이 draft보다 해당 token을 더 높은 확률로 보는 경우 항상 accept합니다.
  • Target 확률이 더 낮으면 p/q 비율만큼 accept합니다.
  • Acceptance는 i=1부터 순차적으로 진행합니다.

Draft는 후보 token뿐 아니라 q_i(x_i) 또는 rejection correction에 필요한 distribution 정보를 보존해야 합니다.

6. Rejection의 Residual Distribution

위치 i에서 draft token이 reject되면 target p_i에서 그냥 다시 sample하지 않습니다. 이미 draft acceptance 과정이 사용한 probability mass를 보정하기 위해 residual distribution에서 token을 뽑습니다.

$$ p’_i(x)=\frac{\max(0,p_i(x)-q_i(x))}{\sum_v\max(0,p_i(v)-q_i(v))} $$

그 corrected token을 commit하고 i+1 이후 draft 후보는 모두 버립니다. 이 rejection sampling 구성은 최종 token이 target p_i에서 직접 sample한 것과 같은 분포를 갖게 합니다.

7. 모두 Accept되면 Bonus Token

γ개 후보가 모두 accept되면 target verification이 이미 계산한 다음 위치 distribution에서 token 하나를 더 sample할 수 있습니다.

draft candidates: x1 x2 x3 x4
all accepted:     x1 x2 x3 x4
target bonus:                 x5
committed this cycle = 5 tokens

그래서 한 verification cycle의 최대 전진은 보통 γ+1 token입니다. Implementation이 bonus token을 실제로 사용하는지 metric에 포함합니다.

8. 분포 보존의 의미

Lossless 알고리즘은 같은 target sampling distribution을 보존합니다. 이는 다음과 다릅니다.

  • 같은 random seed에서 반드시 같은 문자열을 만든다는 뜻이 아닙니다. RNG 호출 순서와 kernel numerical detail이 달라질 수 있습니다.
  • Approximate acceptance나 relaxed tree verification까지 자동으로 lossless라는 뜻이 아닙니다.
  • Greedy mode에서는 token-by-token parity를 직접 확인할 수 있습니다.

Sampling은 많은 run의 token·sequence 통계와 task quality로 검증합니다.

9. Cycle의 Pseudocode

def speculative_cycle(context, draft, target, gamma, rng):
    candidates, q_distributions = draft.propose(context, gamma)
    p_distributions = target.verify(context, candidates)

    committed = []
    for i, token in enumerate(candidates):
        p = p_distributions[i]
        q = q_distributions[i]
        accept_prob = min(1.0, p[token] / q[token])

        if rng.uniform() <= accept_prob:
            committed.append(token)
            continue

        residual = normalize(clamp_min(p - q, 0.0))
        committed.append(rng.sample(residual))
        return committed, i  # accepted prefix length before correction

    committed.append(rng.sample(p_distributions[len(candidates)]))
    return committed, gamma

실제 구현은 vocabulary distribution memory, top-p transform, fused acceptance kernel, distributed sampling을 최적화합니다.

10. Acceptance Rate와 Accepted Prefix Length

accepted draft tokens / proposed draft tokens만 보면 cycle 전진을 오해할 수 있습니다. 첫 rejection 뒤 token은 검증 결과가 있어도 commit할 수 없습니다.

중요한 지표:

  • Per-position acceptance a_i
  • 첫 rejection position
  • Accepted draft prefix length A
  • Bonus token rate
  • Committed tokens per target verification A+1
  • Wasted verified suffix tokens

독립이고 위치별 acceptance가 모두 α라는 단순 가정에서는 기대 committed token 수가:

$$ E[committed]\approx\sum_{i=0}^{\gamma}\alpha^i =\frac{1-\alpha^{\gamma+1}}{1-\alpha} $$

실제 acceptance는 위치와 context에 상관되어 있으므로 trace에서 직접 측정합니다.

11. 속도 식

거친 speedup은 다음처럼 생각할 수 있습니다.

$$ speedup\approx \frac{E[committed]\times T_{target,decode}} {T_{draft}+T_{target,verify}(\gamma)+T_{accept}+T_{rollback}} $$

  • T_target,decode: baseline target 한 token step
  • T_draft: 후보 chain 생성 시간
  • T_target,verify: γ candidate의 target parallel verification
  • T_accept: probability correction과 sampling
  • T_rollback: rejected KV·state 정리

Acceptance가 높아도 draft가 크거나 target verification이 비싸면 느려질 수 있습니다.

12. Draft Model의 조건

좋은 draft는 단순히 작은 model이 아닙니다.

  • Target과 vocabulary·tokenizer가 호환됩니다.
  • Target distribution과 충분히 비슷합니다.
  • Target 한 decode보다 여러 candidate를 훨씬 빨리 만듭니다.
  • Target의 chat template·domain·language를 따라갑니다.
  • 같은 sampling constraint를 적용할 수 있습니다.
  • GPU memory와 scheduler slot을 과도하게 쓰지 않습니다.

Parameter가 너무 작으면 빠르지만 rejection이 많고, 너무 크면 acceptance는 높아도 draft overhead가 큽니다. (draft revision, target revision, workload)를 하나의 deployment pair로 관리합니다.

13. Draft는 어디에서 실행할까

같은 GPU

  • Network transfer가 없습니다.
  • Target과 HBM·compute를 경쟁합니다.
  • Draft weight까지 resident memory가 필요합니다.

별도 GPU

  • Pipeline overlap 가능성이 있습니다.
  • Candidate·state 통신과 synchronization이 생깁니다.
  • Draft/target pool imbalance를 운영해야 합니다.

CPU 또는 다른 Accelerator

  • GPU HBM을 절약할 수 있습니다.
  • Host compute와 transfer latency가 병목일 수 있습니다.

Draft가 target verification의 critical path와 실제로 overlap되는지 timeline으로 확인합니다.

14. Draft Length γ의 Trade-off

짧은 Draft

  • Rejected waste와 verification expansion이 작습니다.
  • Target call 감소 기회가 작습니다.
  • Fixed scheduling overhead 비중이 큽니다.

긴 Draft

  • Easy region에서 많은 token을 commit할 수 있습니다.
  • 첫 rejection 뒤 suffix 계산을 많이 버립니다.
  • Target verification activation·KV와 graph variant가 커집니다.
  • 다른 request의 ITL을 지연할 수 있습니다.

최근 accepted length, entropy, task class, grammar state, queue load로 γ를 adaptive하게 선택할 수 있습니다.

15. Entropy와 Acceptance

일반적으로 target distribution이 뾰족하고 draft와 target이 동의하는 쉬운 구간에서는 acceptance가 높습니다.

often easier:
  punctuation · boilerplate · common code · repeated text

often harder:
  rare entity · multilingual switch · exact number
  reasoning branch · retrieval-specific fact · high temperature

그러나 target entropy만으로 draft agreement를 완전히 알 수 없습니다. KL(p||q), proposed token ratio, position별 acceptance를 cohort로 측정합니다.

16. Tree Speculation

한 개 candidate chain은 첫 분기에서 틀리면 뒤를 모두 버립니다. 여러 likely continuation을 tree로 제안하면 target이 tree attention mask로 여러 branch를 한 번에 검증할 수 있습니다.

             ┌─ x2a ─ x3a
prefix ─ x1 ─┤
             └─ x2b ─ x3b

SpecInfer는 tree-based speculative inference와 verification을 serving 관점에서 다룹니다. Tree width·depth가 커지면 acceptance 기회와 verification token·KV·mask 비용이 함께 늘어납니다.

17. Medusa: 여러 Decoding Head

Medusa는 target model 위에 여러 lightweight decoding head를 추가해 미래 위치 후보를 병렬 예측합니다.

target hidden state
  ├─ head 1 → next token candidates
  ├─ head 2 → +2 position candidates
  └─ head 3 → +3 position candidates

별도 full draft model을 resident하지 않아도 되지만 head를 학습하고 tree candidate를 구성해야 합니다. Verification rule이 lossless인지 relaxed인지 configuration을 확인합니다.

18. EAGLE 계열: Feature·Token Drafting

EAGLE은 second-to-top-layer feature 수준의 autoregression과 shifted token을 사용해 작은 speculative module로 후보를 만듭니다. EAGLE-3는 multi-layer feature fusion과 direct token prediction 방향으로 확장됐습니다.

이 계열은 target 내부 feature에 의존하므로 높은 agreement를 노릴 수 있지만:

  • Target checkpoint별 draft training이 필요합니다.
  • Serving engine이 feature·tree verification을 지원해야 합니다.
  • Fine-tune·adapter 뒤 compatibility를 재검증해야 합니다.
  • Reported speedup을 target hardware·batch·task에서 다시 측정해야 합니다.

19. N-gram·Prompt Lookup Drafting

별도 model 없이 prompt나 이전 output에서 현재 suffix와 같은 n-gram을 찾아 그 뒤 token을 후보로 씁니다.

prompt contains:  "def parse_record(...): ... return result"
output suffix:    "def parse_record("
lookup proposes:  ... ): ... return result

Copy·edit, code, 문서 변환처럼 반복이 많은 workload에서 매우 싸게 draft할 수 있습니다. 새로운 reasoning이나 unseen fact에서는 match가 적습니다. Candidate는 target verification을 거치므로 exact verifier를 유지할 수 있습니다.

20. Lookahead와 Self-speculation

Lookahead Decoding은 별도 draft model 없이 Jacobi iteration에서 얻은 n-gram을 병렬 검증하는 exact decoding 방향을 제시합니다. 다른 self-speculative 방법은 target의 일부 layer를 skip해 draft를 만들고 full model로 verify할 수 있습니다.

방법 이름보다 다음 질문이 중요합니다.

  1. Proposer cost는 얼마인가?
  2. Target distribution을 정확히 보존하는가?
  3. Additional weights·training·cache가 필요한가?
  4. Batch serving과 long context에서 kernel이 지원되는가?
  5. Rollback과 graph capture가 production engine에 구현됐는가?

21. KV Cache Lifecycle

Draft와 target은 서로 다른 model이므로 KV를 보통 별도로 가집니다. Target verification은 candidate positions의 target KV를 계산합니다.

candidate x1 x2 x3 x4
accept    x1 x2
reject          x3

target KV:
  commit x1, x2, corrected token y
  discard candidate x3, x4 KV

draft KV:
  rollback to committed context
  ingest corrected token y before next proposal

Paged KV에서는 verified candidate block을 temporary ownership으로 두고 accepted prefix만 request table에 commit합니다. Partial block copy-on-write와 refcount race를 test합니다.

22. Bonus Token과 KV 정합성

모든 candidate가 accept되면 target이 계산한 bonus token도 context에 들어갑니다. 다음 draft cycle 전에 draft model은 그 bonus token을 자신의 KV에 반영해야 합니다.

Draft·target의 committed length, token IDs, position IDs가 한 token이라도 어긋나면 이후 acceptance 계산이 잘못됩니다. Cycle마다 다음 invariant를 assert할 수 있습니다.

target_committed_tokens == draft_context_tokens
target_position          == draft_position
accepted_KV_length       == committed_token_length

23. Scheduler의 Token Budget

Speculative request 하나는 한 iteration에 γ개 verification token을 사용하지만 user-visible로는 1~γ+1개를 commit합니다.

scheduled compute tokens ≠ committed output tokens

Scheduler가 request 하나를 decode token 1개로만 세면 batch가 갑자기 커져 ITL과 memory peak가 깨집니다. 다음을 budget에 넣습니다.

  • Draft proposal tokens
  • Target verification tokens·tree nodes
  • Active speculative sequences
  • Temporary target KV blocks
  • Acceptance kernel과 logits workspace
  • Rollback·compaction cost

Queue가 붐빌 때 γ를 줄이거나 speculation을 끄는 load-aware policy가 필요합니다.

24. Continuous Batching의 어려움

Request마다 accepted length가 다르므로 cycle 뒤 logical time이 서로 달라집니다.

A commits 5 tokens
B commits 1 token
C commits 3 tokens

Fixed-shape CUDA Graph를 위해 candidate length·tree size bucket을 만들 수 있지만 padding waste가 생깁니다. Draft와 verify phase를 별도 queue로 만들면 throughput은 좋아질 수 있으나 target verify를 기다리는 draft result가 stale하거나 memory를 점유할 수 있습니다.

25. High Batch에서 느려질 수 있다

Baseline decode는 batch가 커지면 target weight read를 많은 sequence가 공유합니다. 이미 GPU utilization이 높은 상황에서는 speculative verification이 extra token을 추가해 compute·KV bandwidth를 늘리고, draft가 target과 자원을 경쟁합니다.

따라서 다음을 분리해 측정합니다.

  • Batch 1 interactive latency
  • 중간 concurrency의 SLO goodput
  • Saturated offline throughput
  • Short·long context
  • TP·PP·expert parallel configuration

한 환경의 2× latency speedup을 모든 serving load에 적용하지 않습니다.

26. Long Context의 손익

Long context target decode는 매 step 긴 KV를 읽어 비쌉니다. 여러 token을 target 한 pass에서 verify하면 이득이 커질 수 있지만, verification attention도 각 candidate position에서 context를 읽고 temporary KV를 씁니다.

Draft model 역시 long context KV를 읽는다면 proposer cost가 커집니다. Prefix cache hit, KV quantization, attention backend와 함께 profile합니다.

27. Structured Generation과 Grammar

JSON schema·regex grammar는 매 position 허용 token을 제한합니다.

안전한 원칙:

  • Draft와 target distribution에 같은 constraint state를 적용합니다.
  • Candidate token마다 grammar state를 advance합니다.
  • Rejection 시 grammar state도 accepted prefix로 rollback합니다.
  • Residual distribution은 constraint 적용 후 정규화된 pq로 계산합니다.
  • EOS·stop sequence가 candidate 중간에 나오면 뒤를 commit하지 않습니다.

Grammar가 다음 token을 강하게 제한하면 acceptance가 높아질 수 있지만 state-management overhead도 측정합니다.

28. RAG Agent에서의 적용 조건

긴 Retrieved Prompt

Speculation은 이미 수행한 prefill을 줄이지 않습니다. Retrieval context 때문에 TTFT가 병목이면 prefix cache, context selection, chunked prefill을 먼저 봅니다.

짧은 Tool Call

{"tool":"search","query":"..."}처럼 출력이 짧으면 warm-up과 첫 draft cycle 전에 끝날 수 있습니다. Endpoint별 minimum expected output length gate를 둡니다.

Structured Repetition

Tool schema, code edit, 기존 document 변환은 n-gram이나 trained draft가 잘 맞을 수 있습니다. Acceptance를 tool·language·grammar별로 계측합니다.

Retrieval-specific Entity

Draft가 최신 document의 rare name·number를 모르고 target과 자주 불일치할 수 있습니다. Evidence span 주변 acceptance drop을 봅니다.

Multi-step Latency

한 call의 TPOT를 줄여도 tool I/O가 대부분이면 Agent end-to-end 이득은 작습니다. Stage trace에서 model decode 비중을 먼저 확인합니다.

29. 어떤 요청에서 끌까

Online gate 예시:

disable or shorten speculation when:
  expected output is very short
  recent accepted length is low
  target batch is already saturated
  memory headroom is low
  unsupported adapter / grammar / dtype path
  high-temperature or OOD cohort regresses
  draft cold-load exceeds deadline slack

Model pair 전체를 on/off하는 것보다 request cohort별 routing이 유리할 수 있습니다.

30. Correctness Test

Greedy

  • Baseline과 token-by-token exact parity
  • EOS·stop·max token parity
  • Logits processor·repetition penalty parity
  • Page·graph·draft boundary parity

Sampling

  • Toy vocabulary에서 exact probability를 계산해 empirical frequency 비교
  • Large sample의 token marginal·sequence statistic
  • KL·total variation과 confidence interval
  • Temperature·top-k·top-p·seed matrix
  • Rejection residual이 0에 가까운 edge case

Model Quality

  • Task score와 structured-output validity
  • RAG groundedness·citation correctness
  • Code execution·tool argument validation
  • Approximate mode는 별도 quality budget

31. Performance Metric

  • Draft tokens/s와 draft latency
  • Target verification tokens/s와 latency
  • Per-position acceptance
  • Accepted prefix length histogram
  • Committed tokens/target call
  • Bonus token rate
  • Rejected suffix·wasted verification tokens
  • Target·draft temporary KV byte
  • Rollback time와 block leak
  • Speculation on/off TPOT·ITL·TTFT
  • SLO goodput/GPU와 energy/token
  • Cohort별 enable rate와 fallback reason

“Acceptance 80%”보다 target call 1회당 3.4 committed tokens, end-to-end ITL 1.7× 개선처럼 보고합니다.

32. Benchmark Matrix

target/draft pair
draft length:       1, 2, 4, 8, adaptive
method:             model, Medusa, EAGLE, n-gram, tree
batch:              1, 8, 32, saturation
context:            512, 8K, 32K+
output:             short tool, chat, code, reasoning
sampling:           greedy, temperature, top-p
feature:            grammar, LoRA, TP, prefix hit

Baseline과 speculative run은 같은 prompt·arrival trace·SLO를 사용합니다. Draft warm/cold, graph warm/cold도 분리합니다.

33. 최소 도입 순서

  1. Baseline decode에서 target step time과 output length 분포를 측정합니다.
  2. Greedy external draft로 candidate→verify→prefix accept를 구현합니다.
  3. Temporary KV ownership과 rollback invariant를 test합니다.
  4. Sampling acceptance·residual correction을 toy distribution으로 검증합니다.
  5. Draft length별 accepted prefix와 speed equation 항을 측정합니다.
  6. Scheduler가 verification token과 temporary KV를 budget하게 합니다.
  7. Grammar·EOS·stop·logits processor를 통합합니다.
  8. Endpoint·language·task별 adaptive enable gate를 만듭니다.
  9. Medusa·EAGLE·n-gram·tree를 같은 benchmark contract로 비교합니다.
  10. Production-shaped open-loop load에서 SLO goodput과 quality를 release gate로 둡니다.

실전 체크리스트

  • Draft와 target의 tokenizer·vocabulary가 호환된다.
  • Candidate token과 draft probability를 함께 보존한다.
  • Sampling acceptance에 min(1,p/q)를 사용한다.
  • Rejection 시 normalized positive residual에서 sample한다.
  • 첫 rejection 뒤의 candidate를 commit하지 않는다.
  • All-accepted cycle의 target bonus token을 처리한다.
  • Lossless distribution과 same-seed string을 구분한다.
  • Acceptance rate와 accepted prefix length를 분리한다.
  • Draft·verify·accept·rollback latency를 각각 측정한다.
  • Draft length를 workload별로 조정한다.
  • Draft model의 memory와 target 자원 경쟁을 포함했다.
  • Tree node와 verification token을 scheduler가 budget한다.
  • Temporary target KV의 commit·rollback invariant가 있다.
  • Bonus·corrected token을 draft context에 동기화한다.
  • Grammar·EOS·stop state도 rollback한다.
  • High batch와 long context에서 별도 측정했다.
  • Short tool output에는 disable gate가 있다.
  • Task·language·temperature별 acceptance를 본다.
  • Greedy parity와 sampling 통계 검증을 통과했다.
  • SLO goodput이 baseline보다 좋아야 release한다.

스스로 확인하기

Q1. Draft token이 target top-1과 다르면 sampling에서도 무조건 reject하면 되는가?

아닙니다. Sampling은 target과 draft의 전체 확률을 고려해 min(1,p/q)로 accept하고, rejection 시 positive residual max(0,p-q)에서 corrected token을 sample해야 target 분포를 보존할 수 있습니다.

Q2. Target은 후보 4개를 한 번에 봤는데 세 번째가 reject되면 네 번째를 쓸 수 있는가?

그대로는 쓸 수 없습니다. 네 번째 distribution은 rejected 세 번째 token을 prefix로 계산됐으므로 corrected token 뒤의 올바른 분포가 아닙니다. 첫 rejection 뒤 suffix를 버립니다.

Q3. Acceptance rate가 높으면 항상 빨라지는가?

아닙니다. Draft 시간, target verification expansion, acceptance kernel, KV rollback, batch·scheduler interference가 절약한 target call보다 클 수 있습니다.

Q4. Speculative decoding이 긴 RAG prompt의 TTFT를 줄이는가?

주 목적은 output decode step을 줄이는 것입니다. 긴 prompt prefill이 TTFT 병목이면 context selection, prefix reuse, chunked prefill, prefill worker 설계를 먼저 봅니다.

Q5. Distribution-preserving이면 같은 seed에서 baseline과 항상 같은 문장이 나오는가?

반드시 그렇지는 않습니다. Acceptance 과정이 random number를 추가로 사용하고 kernel 수치·RNG 순서가 달라질 수 있습니다. Greedy는 token parity, sampling은 통계적 분포 동등성을 검증합니다.

다음 글

이번 글은 한 model replica의 serial decode step을 줄였습니다. 다음 글 분산 LLM 추론: Tensor·Pipeline·Expert Parallel과 Prefill/Decode 분리에서는 model이 한 GPU에 맞지 않거나 한 replica의 capacity를 넘어설 때 compute·weight·KV·통신을 여러 device와 worker에 배치하는 방법을 다룹니다.

참고문헌

검증 메모 — 알고리즘과 문헌은 2026년 7월 16일 확인했습니다. Speculative backend의 지원 방식, lossless mode, graph·KV integration은 engine revision마다 다릅니다. 논문 speedup은 각 논문의 model·hardware·batch·task 조건에서 나온 값이므로 target workload에서 다시 측정해야 합니다. 본문의 식은 normalized draft·target sampling distribution을 전제로 합니다.