DFlash (디플래시)

한 줄 정의

DFlash는 LLM의 다음 토큰 생성을 빠르게 하려는 추측 디코딩 방식이야. 작은 확산 draft 모델이 여러 후보 토큰을 한 번에 만들고, 더 큰 target 모델이 그 후보를 검증해. 그래서 DFlash는 새 foundation model 이름이라기보다 추론 가속 파이프라인에 붙는 방법 이름으로 읽는 게 맞아.

핵심은 “draft는 병렬로 빨리 만들고, 정답성은 target 모델 검증으로 지킨다”는 분업이야. arXiv 논문은 2026년 2월 5일 제출됐고, 자동회귀 draft가 순차적으로 토큰을 뽑는 병목을 블록 확산 draft로 바꾸는 쪽을 제안해.

어떻게 작동하나

일반적인 추측 디코딩은 작은 draft 모델이 몇 개의 다음 토큰을 먼저 제안하고, target 모델이 한 번의 forward pass로 그 후보를 확인해. 기존 강한 방법인 EAGLE-3도 target model의 feature를 쓰지만, draft 자체는 여전히 자동회귀 흐름이라 후보를 순서대로 뽑는 비용이 남아.

DFlash는 이 draft 단계를 바꿔. 블록 확산 모델이 mask된 여러 위치를 동시에 예측해서 token block을 만든다. 논문 본문은 target 모델의 여러 layer hidden state를 뽑아 fused 컨텍스트 feature로 만들고, 그 정보를 draft layer의 Key/Value 쪽에 주입한다고 설명해. draft가 혼자 다음 단어를 맞히는 게 아니라 target 모델이 이미 계산한 문맥 신호를 계속 들고 후보를 만드는 구조야.

그다음 target 모델이 후보를 검증해. 후보가 맞으면 여러 토큰을 한 cycle에서 받아들이고, 어긋나면 target 모델의 출력으로 되돌아간다. 이 검증 단계가 있어서 논문은 lossless acceleration을 말할 수 있어. 다만 실제 구현에서는 greedy argmax parity, sampling 규칙, stop token 처리까지 맞아야 “빠른데 답이 바뀌지 않는다”는 말을 할 수 있어.

어디에 쓰이나

가장 직접적인 쓰임은 SGLang, vLLM, Transformers, MLX 같은 런타임에서 생성 구간을 줄이는 일이야. z-lab의 공식 README는 Qwen3.5-9B, Qwen3.5-27B, Qwen3.6-27B, Qwen3.5-35B-A3B 같은 draft 모델을 따로 공개하고, SGLang과 vLLM 실행 예시에서는 speculative 설정으로 target 모델과 DFlash draft 모델을 같이 넘겨.

로컬 LLM 문맥에서는 DFlash가 더 구체적으로 보인다. Lucebox의 포트는 RTX 3090 24GB에서 Qwen3.5-27B를 GGUF Q4_K_M target과 BF16 draft로 묶고, DDTree budget 22를 맞춘 사례야. README는 HumanEval에서 autoregressive 37.8 tok/s, DFlash+DDTree 129.5 tok/s, 3.43배를 제시해. 같은 문단의 207.6 tok/s demo 숫자는 별도 demo 조건이라 평균 benchmark와 섞으면 안 돼.

Apple Silicon 쪽 Reddit 글은 또 다른 구현 사례야. 작성자는 M5 Max 64GB, MLX, CUDA 없음 조건에서 Qwen3.5-9B BF16을 1024 tokens 생성 기준 85 tok/s로 봤고, baseline 26 tok/s 대비 3.3배라고 적었어. 그런데 이 값은 generation only, no prefill 조건이야. 긴 프롬프트를 매번 읽는 에이전트 작업에서는 prefill과 KV 캐시 성장이 같이 들어오니 체감이 달라질 수 있어.

왜 중요한가

DFlash가 중요한 이유는 추론 가속을 “더 작은 모델로 바꾸자”가 아니라 “같은 target 모델을 더 적은 sequential step으로 쓰자”에 가깝게 보여 주기 때문이야. 논문은 Qwen3-4B/8B non-thinking 표에서 DFlash 평균 speedup을 약 4.9배로 제시하고, SGLang 평가에서는 Qwen3-8B Math500 concurrency 1에서 baseline 230 tok/s, DFlash 1175 tok/s, 5.1배를 보여 줘.

이 숫자는 코딩 에이전트나 긴 reasoning 출력에서 특히 눈에 띄어. 모델이 길게 말해야 할수록 token-by-token 병목이 커지고, draft가 한 번에 여러 후보를 잘 맞히면 target 모델이 같은 시간에 더 많은 토큰을 받아들일 수 있어. 그래서 DFlash는 모델 품질 점수보다 serving 비용, 지연 시간, GPU 활용률을 볼 때 의미가 커진다.

다만 DFlash는 버튼 하나가 아니야. 실제 판단은 아래 순서로 해야 해.

• target 모델과 맞는 DFlash draft 모델이 있는지 확인해.
• SGLang, vLLM, Transformers, MLX 중 어떤 backend가 실제로 지원하는지 확인해.
• target 가중치, draft 가중치, KV 캐시, verify tree나 buffer가 한 장비 메모리에 들어가는지 계산해.
• benchmark가 prefill 포함인지 generation only인지, 출력 길이가 1024인지 2048인지 먼저 적어.

이 네 가지가 빠지면 6배, 5.1배, 85 tok/s 같은 숫자가 너무 쉽게 과장돼.

주의해서 볼 점

첫째, DFlash는 target 모델을 바꾸지 않는다고 해도 메모리를 공짜로 쓰는 건 아니야. 별도 draft 모델과 중간 상태가 필요하고, Lucebox 사례처럼 Q4_K_M target 약 16GB와 BF16 draft 3.46GB를 같이 올리는 식의 계산이 붙어. 24GB 카드에서는 KV 캐시와 tree state까지 합쳐야 해서 여유가 생각보다 빨리 줄어.

둘째, target이 너무 빨라지면 draft가 병목이 될 수 있어. Reddit 글은 4bit target에서는 verify가 빨라져서 BF16 draft 쪽이 병목이 된다고 적어. 그러면 DFlash를 붙였는데도 speedup이 작아질 수 있다. 양자화가 강할수록 target과 draft의 균형을 다시 봐야 해.

셋째, 긴 컨텍스트는 따로 봐야 해. 같은 Reddit 글은 2K tokens 뒤로 KV cache growth 때문에 speedup이 떨어진다고 적었고, Lucebox는 TQ3_0 KV cache 같은 별도 선택으로 24GB 안의 긴 context를 맞추려 해. 즉 DFlash 자체와 KV cache 압축, DDTree, GGUF 포트는 서로 다른 층위의 선택이야.

마지막으로, DFlash draft 모델은 target 모델과 잘 맞아야 해. z-lab README는 지원 모델 목록을 계속 넓히고 있지만, 모든 fine-tuned 모델이나 사내 모델에 자동으로 맞는 draft가 있다는 뜻은 아니야. 실무에서 쓰려면 작은 prompt 몇 개로 tok/s만 재지 말고, 같은 입력 묶음에서 답변 일치율, accepted tokens per cycle, p95 latency, prefill 포함 총 시간을 같이 기록해야 해.