DFlash — 블록 확산 드래프터로 6배 빨라지는 투기적 디코딩

토큰을 한 개 뽑을 때 GPU 산술 유닛은 거의 놀고 있어요. KV 캐시와 가중치를 SRAM으로 끌어오는 시간이 전부라서, FP16 곱셈기는 빈손으로 버스를 기다리고 있는 셈이에요. 이 빈자리를 어떻게 채워서 latency를 6배까지 줄일 수 있을까요 — 2026년 2월 Z Lab이 공개한 DFlash (Block Diffusion for Flash Speculative Decoding)가 내놓은 답이 바로 이것입니다.

DFlash는 표준 투기적 디코딩(Speculative Decoding) 의 골격은 그대로 두고, 그 안의 드래프터(drafter — 다음 토큰 후보를 빠르게 뽑는 작은 모델) 만 갈아끼워요. 자기회귀 드래프터(한 번에 한 토큰씩 뽑는 구조) 대신 블록 확산 드래프터(block diffusion drafter) 가 들어가서, 한 번의 forward pass에 K개의 토큰을 한꺼번에 만들어 냅니다. 결과적으로 같은 출력 분포를 보장하면서 NVIDIA H200 기준 평균 4.86배, 최대 6.08배의 latency 단축을 보고해요.

트랜스포머 추론의 두 단계: Prefill과 Decode 부록에서 본 것처럼 Decode 단계는 토큰을 한 개씩 뽑는 메모리 대역폭에 묶인(memory-bound) 작업입니다. GPU의 산술 유닛은 거의 놀고 있고, KV 캐시·가중치를 SRAM으로 끌어오는 시간이 병목이에요. 투기적 디코딩은 이 빈 산술 유닛을 활용하려고 "한 번에 여러 토큰을 검증" 하는 구조를 만든 것이고, DFlash는 그 검증 대상을 만드는 비용까지 한 번 더 줄인 것입니다.

한 줄 비유 — 블록 확산 = 빈칸 채우기: 자기회귀 드래프터가 "오늘__" → "오늘 날" → "오늘 날씨" 처럼 한 글자씩 적어 나간다면, 블록 확산 드래프터는 "오늘 [][][_]" 처럼 빈칸 세 개를 한 번에 한 호흡으로 채운다. 빈칸을 동시에 보면서 한꺼번에 풀어도 답이 잘 맞는다는 사실이 — 직관과 어긋나지만 — DFlash의 토대다.

1. 표준 투기적 디코딩 한 번 복습

투기적 디코딩(2023, Leviathan et al.)의 기본 구조는 이래요.

• Draft 단계: 작고 빠른 모델이 K개의 후보 토큰을 자기회귀로 뽑습니다.
• Verify 단계: target 모델이 그 K개를 한 forward pass에서 병렬 검증 해요. 통과한 것은 그대로 채택, 처음 어긋나는 자리부터 target의 분포로 다시 샘플링합니다.

수식상 verify의 결과는 target 모델 단독으로 자기회귀 디코딩한 것과 동일한 분포를 보장합니다(이른바 lossless). 이득은 두 가지 조건이 겹쳐 나와요.

1. Decode가 memory-bound 라서 K개를 동시에 검증해도 target의 latency가 거의 늘지 않음.
2. Draft가 충분히 빠르고, 받아들여지는(acceptance) 비율이 충분히 높음.

표준 방식의 약점은 (2) 안에 있어요. 드래프터가 K개의 토큰을 만들려면 K번의 forward pass 가 필요합니다. 작은 모델이라도 직렬로 K번 돌면 GPU 산술 유닛이 또 놀게 되죠. 즉 드래프터 단계가 그 자체로 작은 memory-bound 디코드 인 거예요. 큰 target은 절약했는데, 그 절약을 위해 작은 드래프터가 똑같이 한 토큰씩 우물거리고 있는 모양이에요.

2. DFlash의 핵심: 드래프터를 한 pass로 만든다

DFlash가 바꾼 것은 (2)예요. 드래프터를 자기회귀 모델에서 블록 확산 모델 로 교체합니다.

Diffusion model (확산 모델) — 마스킹된 위치를 한꺼번에 채워 넣도록 학습된 모델. 이미지 생성에서 잘 알려진 방식이지만, 텍스트에서도 "블록 단위 마스크 예측"으로 적용할 수 있다. 단, 이미지 diffusion이 보통 수십 단계의 denoising을 거치는 것과 달리, DFlash는 1-step masked prediction 으로 동작한다 — 마스크를 한 번에 모두 푼다.

DFlash 드래프터의 한 사이클은 이래요.

1. 마지막으로 채택된 토큰 하나를 anchor 로 고정.
2. 그 뒤로 길이 B의 빈 자리를 만들어 (B-1)개를 모두 마스킹.
3. 드래프터가 한 번의 forward pass에서 (B-1)개 위치를 병렬로 예측.
4. Target이 길이 B 블록을 한 forward pass에서 verify.

논문이 사용한 블록 크기 B는 Qwen3 계열에서 16, LLaMA-3.1-8B에서 10 이에요. K=16에서 이미 이론적 최대 speedup의 90% 이상을 가져온다고 보고합니다(Google TPU 측정 기준).

시간축으로 본 한 사이클

draft·verify 가 어떻게 겹치는지를 시간축에 풀어 그리면 차이가 더 분명해져요. 아래는 K=4 가정입니다.

d1..d4는 자기회귀 드래프터의 한 토큰씩 forward, D(4)는 블록 확산 드래프터의 4개 동시 forward, V(4)는 target의 4-토큰 병렬 verify예요. 5 단계가 2 단계로 줄어드는 것이 DFlash의 본질입니다.

깜짝 사실 — "동시에 푸는데 정답률이 떨어지지 않는다"

직관적으로는 토큰 1을 정한 다음에 그것을 보고 토큰 2를 정해야 더 잘 맞을 것 같죠. 그런데 acceptance length 6.49(블록 16에서 평균 6.49개 통과)는 블록 안의 (B-1)개를 일제히 풀어도 자기회귀로 한 토큰씩 뽑은 EAGLE-3 (acceptance ~3)을 두 배 가까이 뛰어넘어요. 이유는 두 가지예요 — (a) 드래프터가 target hidden state를 직접 받기 때문에 "토큰 1을 안 봤는데도 토큰 1이 뭐였을지에 대한 정보"는 이미 들고 있고, (b) 잘 틀려야 할 위치가 앞쪽일수록 acceptance가 거기서 끊기므로, 뒤쪽 토큰의 정확도는 사실 평균에 별로 안 들어옵니다(한 번 어긋나면 그 자리 이후는 어차피 버려져요). 그래서 "동시 디노이징해도 손해 없음"이 성립합니다.

Target과의 결합 — KV Injection

블록 안의 (B-1)개 토큰을 한꺼번에 만들려면, 드래프터가 target의 의도를 충분히 이해하고 있어야 해요. DFlash는 드래프터의 매 layer에 target의 hidden state를 직접 주입 합니다.

이 구조 덕에 드래프터는 5개 layer만으로도 target의 분포를 잘 흉내 내요(Qwen3-Coder만 8 layer). 드래프터가 작아질 수 있는 이유이자, 추가 메모리 부담이 적어지는 이유입니다.

드래프터는 자기 KV를 만들 때 target의 KV를 옆에서 빌려 써요. 이 그림이 1B 짜리 작은 모델로도 8B target의 분포를 흉내 낼 수 있는 이유입니다.

3. 추가로 필요한 하드웨어 리소스

DFlash 1차 출처(arXiv 논문, Z Lab GitHub, HuggingFace 모델 카드 18종)에서 확인된 사실만 정리할게요.

3.1 드래프터 가중치 — 약 0.5B–1B (BF16)

z-lab/*-DFlash HuggingFace 컬렉션에 공개된 사전 학습 드래프터의 파라미터 수예요.

가중치 메모리는 params × 2 bytes로 산출한 값이에요. HuggingFace 카드 본문에는 GB 단위가 명시되어 있지 않아요. Embedding과 LM head는 target과 공유하므로 추가 메모리에 들어가지 않습니다.

"왜 1–2GB만 더 필요한가" 의 답은 단순해요. 드래프터 본체가 5개의 transformer layer + KV injection 어댑터 뿐이고, 어휘·embedding·LM head는 target에서 빌려 쓰기 때문입니다.

3.2 드래프터 KV 캐시·diffusion 버퍼 — 1차 출처 미명시

블록 길이 B의 마스크 채우기 자체는 추가 hidden state 버퍼가 필요한데, 정확한 GB 환산은 논문·README에 적혀 있지 않아요. 자료 작성 시 "드래프터 본체 + 동일한 모양의 KV 캐시(레이어 수가 5–8로 적음)" 정도로만 표기하는 편이 정직합니다.

3.3 GPU 등급 — 1차 출처는 권장 등급을 제시하지 않음

논문이 실험한 GPU는 다음 두 가지예요.

• NVIDIA H200: Transformers backend 기준 offline 측정(Table 1, 2)
• NVIDIA B200: SGLang + FlashAttention-4 기준 LLaMA-3.1-8B 측정(Table 4)

GitHub 이슈에서는 RTX 4090 + FP8, DGX Spark, MI300A(ROCm) 까지 동작 보고가 있어 실제 가용 GPU 폭은 넓어요. 다만 "L40S 48GB로 7B/13B 충분, 70B는 H100/A100 80GB 필요" 식의 문장은 일부 외부 블로그에서 본 추정이고, DFlash 1차 출처(논문·README)에는 그런 등급별 권고가 없습니다. 자료에 인용하려면 1차 출처 미명시라고 명시해야 해요.

3.4 학습 비용 — 드래프터는 target마다 별도 학습

DFlash 드래프터는 target 모델별로 한 번씩 학습해야 해요. Z Lab은 이미 18종을 사전 학습해 공개 했고(LLaMA·Qwen3·Qwen3-Coder·Qwen3.5·Qwen3.6·Gemma-4·gpt-oss·Kimi·MiniMax 등, 모두 MIT 라이선스) 추가로 DeepSeek-V4·MiniMax-M2.7·GLM-5.1을 "Coming soon"으로 표기했습니다.

한 줄 요약: "target마다 한 번 학습이 필요하지만, Z Lab이 주요 모델 18종을 이미 공개해 두었기 때문에 사용자 입장에서는 추가 학습 부담이 없다."

3.5 다른 투기적 디코딩 기법과의 비교

DFlash 논문은 속도 비교만 제시하고 메모리·파라미터 추가량 비교 표는 따로 두지 않았어요. 정직하게 표기하면 다음과 같습니다.

EAGLE-3·Medusa의 정확한 메모리 비교는 각 논문을 별도로 봐야 해요. DFlash 단독으로는 속도 우위(EAGLE-3 대비 ~2.5배) 만 1차 자료로 인용 가능합니다.

3.6 소프트웨어 통합 상태

4. 향상되는 기대 속도

1차 출처에서 직접 읽은 수치만, 반드시 측정 조건과 함께 정리할게요.

4.1 한 줄 요약

수치 인용 시 주의: "DFlash 6배" 라는 표현은 Qwen3-8B / MATH-500 / T=0 / H200 / 단일 스트림 의 단일 최댓값이에요. 평균은 4.86배, 채팅은 2배대로 떨어집니다.

4.2 모델별 결과 (논문 Table 1, T=0, H200, block 16)

Acceptance length(평균 수락 길이): 한 번의 verify에서 채택되는 평균 토큰 수. 6.49는 16개 블록 중 평균 6.49개가 통과한다는 뜻이에요. 1에 가까우면 spec decoding은 거의 이득이 없고, K에 근접하면 이상적이에요.

같은 8B 규모라도 LLaMA-3.1보다 Qwen3가 약 두 배 잘 받는다는 점이 눈에 띄어요. 이유는 단순합니다. DFlash 드래프터는 target self-distillation 으로 학습되고, Qwen3 계열이 학습 응답이 더 규칙적이라 acceptance가 더 높아요. 어떤 target 모델 위에 DFlash를 얹을지 결정할 때 의미 있는 단서입니다.

4.3 작업 종류별 (Qwen3-8B, T=0, H200)

규칙은 분명해요.

• 출력이 길고 결정적인 작업(수학·코드)일수록 잘 받습니다. CoT처럼 토큰 분포가 좁으면 드래프터가 잘 맞춰요.
• 출력이 짧고 분포가 넓은 작업(채팅) 에서는 acceptance가 낮아져 2배대로 내려갑니다.
• 입력 컨텍스트가 길어지면(SWE-Bench) target verify 비용이 늘면서 DFlash의 이득이 희석됩니다.

4.4 동시 요청(concurrency) 의존성 — 실제 서빙에서 가장 중요

배치 1과 배치 32의 거동이 완전히 달라요. 운영 환경에서는 후자가 현실입니다.

Qwen3-8B / MATH-500 / SGLang / H200 (논문 Table 3)

LLaMA-3.1-8B / B200 / SGLang (논문 Table 4)

이유: 배치가 커지면 target verify 자체가 GPU 산술 유닛을 거의 채우게 되어, decode가 memory-bound에서 compute-bound로 옮겨가요. 투기적 디코딩의 전제 조건이 약해져요. DFlash도 이 일반 법칙에서 벗어나지 못해요.

핵심 인사이트는 이거예요. concurrency 32에서도 DFlash가 EAGLE-3보다 절대 speedup이 더 높습니다(LLaMA GSM8K에서 1.6x vs 1.0x). 즉 EAGLE-3가 사실상 무력화되는 부하에서도 DFlash는 일정 수준의 이득을 유지해요.

4.5 TPU에서의 결과 (Google Developers Blog)

DFlash는 NVIDIA만의 기법이 아니에요. Google이 vLLM의 tpu-inference 백엔드에 통합해 TPU v5p에서 측정한 결과를 공개했습니다.

측정 조건: TPU v5p, JAX backend, greedy decoding, out-of-the-box checkpoint(추가 fine-tuning 없이). NVIDIA H200의 6배보다는 낮지만, TPU에서도 spec decoding이 잘 동작한다는 점이 의미가 있어요.

4.6 후속 연구 — DDTree (외부 그룹의 8.22x 보고)

DFlash 위에 트리형 드래프트 검증을 얹은 DDTree (arXiv 2604.12989, 2026-04-14, Ringel & Romano)가 있어요. Z Lab과는 별개 그룹 의 후속 연구입니다.

자료 작성 시 주의: 외부 자료에 흩어져 있는 "DFlash 8배" 라는 표현은 이 후속 논문의 단일 모델·단일 태스크 최댓값을 DFlash 본체의 결과로 잘못 인용한 경우 가 많아요. "DFlash 위에 DDTree (외부 그룹의 후속 트리 검증) 를 얹어서 30B-MoE의 HumanEval에서 8.22배" 라고 정확히 적어야 합니다.

5. 한계와 적용이 어려운 조건

논문이 직접 보고한 약점이에요.

부정적 결과(slowdown)는 논문이 보고한 모든 조합에서 발견되지 않았어요. 즉 "DFlash가 기존 자기회귀 디코딩보다 느려지는 경우" 는 1차 출처 안에서는 없습니다.

6. FP8/FP4 KV 양자화와의 비호환 — 메모리 절약 흐름과의 충돌

DFlash 드래프터는 마스크 채우기를 위해 non-causal attention 을 쓰므로(블록 내 모든 위치를 동시에 참조), FP8/FP4 KV 캐시 양자화와 근본적으로 호환되지 않아요. vLLM 이슈 #41559에 명시된 사실입니다.

이는 다른 부록에서 다룬 두 흐름과 정면으로 부딪혀요.

• KV 캐시 부록에서 다룬 MLA·Hybrid Attention 같은 KV 압축 구조: 캐시를 줄이려는 방향
• 메모리·대역폭 부록에서 본 FP8/NVFP4 KV 양자화 도입 흐름: 캐시를 더 줄이려는 방향

DFlash는 그 줄어든 캐시를 다시 풀어야 동작해요. 즉 "latency를 6배 빨리 하기 위해 KV 캐시 메모리는 양보해야 한다" 는 trade-off가 있습니다. spec decoding이 실제 시스템 설계에서 메모리·연산 사이의 균형을 어떻게 흔드는지 보여주는 깔끔한 사례예요.

또 한 가지, 트랜스포머 추론 부록에서 본 Decode가 memory-bound 라는 사실이 DFlash의 전제 조건이라는 점도 짚어둘 만해요. 만약 미래의 어떤 가속기가 Decode를 compute-bound로 바꾸어 놓는다면(예: 충분히 빠른 HBM4e가 산술 유닛을 다시 굶기지 않게 만든다면) DFlash 같은 spec decoding 기법의 이득은 자동으로 줄어들어요.

7. 비유에는 한계가 있다

서두의 "빈칸 채우기" 비유는 블록 안의 여러 자리를 한 호흡에 정한다는 핵심을 잘 포착하지만, 두 가지에서는 한계가 있어요.

• DFlash는 본격적인 diffusion이 아니에요. 이미지 diffusion이 노이즈 → 깨끗한 그림으로 수십 단계의 denoising을 거치는 반면, DFlash는 1-step masked prediction으로 한 번에 모든 마스크를 풉니다. "확산"이라는 이름은 학습 시 토큰 마스킹 비율을 random하게 섞는 학습 절차에서 온 것이지, 추론 시점의 다단계 denoising 때문이 아니에요.
• 드래프터는 사실 target의 그림자에 가까워요. KV injection 덕에 드래프터의 5개 layer는 자체 추론을 하기보다 target의 hidden state를 풀어내는 디코더 역할에 가깝습니다. "작은 모델이 큰 모델 흉내" 라기보다 "큰 모델이 흘려준 정보를 짧은 회로로 펼치기" 가 더 정확한 그림이에요.

비유의 한계를 인정한 채, 큰 그림 — K개 토큰을 만드는 비용을 O(K)에서 O(1)로 줄인다 — 만 가져가면 충분합니다.

8. 정리

1차 출처

• DFlash 논문: arXiv 2602.06036 abstract · arXiv 2602.06036 HTML v1
• DFlash 코드·체크포인트: github.com/z-lab/dflash · HuggingFace z-lab · Z Lab 프로젝트 페이지
• TPU 통합: Google Developers Blog
• 후속 연구 DDTree: arXiv 2604.12989 · 프로젝트 페이지
• vLLM 통합 상태: PR #36767 · PR #39703 (ROCm) · Issue #41559 (FP8 KV 비호환)