DFlash-2: 정확도 및 처리량 향상을 위한 DFlash의 후속 모델 벤치마킹

얼마 전, 우리는 확산 모델을 사용하는 초안 토큰 예측 기법인 DFlash에 대해 다룬 적이 있습니다. 당시에는 Gemma-4-12b-it-QAT로 테스트를 진행했으며, 네이티브 Assistant 모델이 더 나은 성능을 보여서 DFlash가 명확한 우위를 보이지 못했습니다.

하지만 최근 'DFlash-2'라는 후속 모델이 등장했는데, 이는 기존 디자인 위에 여러 개선 사항을 추가한 것입니다.

2026년 8월 기준으로 소수의 모델만이 이를 지원합니다. 기본 모델만 사용하거나 DFlash, 그리고 DFlash-2를 순차적으로 사용하여 각각의 방식이 실제로 어떤 부분에서 효과가 있는지, 그리고 어떤 파라미터 설정이 가장 좋은 성능을 내는지 살펴보았습니다.

DFlash-2란 무엇인가?

DFlash는 Z-Lab에서 개발한, 다가올 출력 토큰을 미리 예측하여 생성을 가속화하는 기법입니다. 여러 DFlash 모델들이 다양한 LLM 패밀리를 위해 출시되었습니다.

[Input Token (N)] --> [Main Model] -- h_on ----------------------------------------> [Predicted: N+1]
                                       |
                                       v                                             ^
                                       |
... 

그림 1: DFlash 메커니즘 (이 구조는 DFlash-2에서도 변경되지 않았으며, 이전 DFlash 글에서 재사용되었습니다)

DFlash는 비인과적 모델(위의 확산 모델)을 사용하여 초안 생성을 가속화함으로써 기존의 자기회귀적(autoregressive) 초안 작성보다 더 나은 처리량(throughput)을 목표로 합니다.

단점은 확산 모델이 어느 정도의 정확도 손실을 유발한다는 것입니다. 이전 글에서 우리는 이 부분에 대해 다루었으며, 직접 비교했을 때 Gemma-4의 Assistant 모델에 뒤처졌습니다.

inco.ai는 이를 개선하기 위해 노력해 왔습니다. 회사에 대한 세부 정보는 부족하지만, Hugging Face의 inco.ai 페이지 관리자는 Z-Lab을 이끄는 사람인 Zhijian Liu입니다. 따라서 이 연구소와 연결된 스핀오프 팀이나 스타트업일 가능성이 높습니다.

DFlash-2는 원래 메커니즘 위에 두 가지 요소를 추가했습니다:

• 경량 경로 선택기 (Lightweight Path Selector) — 정확한 토큰 순서 지정 기존 DFlash의 강점은 내부 확산 모델(diffusion model)이 전체 블록의 토큰을 순서대로 한 번에 출력할 수 있다는 것이었습니다. 문제는 각 토큰의 순서가 독립적으로 생성되기 때문에, 결과 시퀀스가 내부적으로 일관성이 없을 수 있으며, 이것이 예측이 거부되는 일반적인 이유로 보였습니다.1

이를 해결하기 위해 DFlash-2는 후보 토큰 시퀀스가 '가장 자연스러운 순서'인지 확인하고 그렇지 않은 것을 걸러내는 매우 경량의 내부 모델을 추가했습니다. 이것이 바로 Lightweight Path Selector입니다. 이 모듈은 drafter 모델 내부의 Target LM Head 레이어 바로 뒤에 위치합니다.

• 지역 컨볼루션 (Local Convolution) — 블록 후반부 정확도 저하 문제 해결 이 레이어는 토큰들을 연결할 때 각 토큰의 즉각적인 이웃에게 정보 교환을 제한합니다. Path Selector와 함께 작동하며, '접미사 감쇠(suffix decay)'—블록 후반부에서 예측된 토큰의 수용률이 급격히 떨어지는 현상—에 대응합니다. Local Convolution 레이어는 어텐션(attention)과 MLP 레이어 사이에 여러 곳에 삽입됩니다.

종합적으로 볼 때, DFlash-2는 draft-token 순서 지정의 정확도를 특히 개선한 DFlash의 향상 버전이라고 설명할 수 있습니다.

현재 두 가지 모델이 사용 가능합니다:

• Qwen3.8-27B-DFlash2
• Muse-Glimmer-30B-DFlash2

두 모델 모두 Z-Lab 및 inco.ai 저장소에 공개되었으며, llama.cpp용 GGUF 빌드가 제공됩니다.

원래는 Gemma-4-12b-it-qat에서 실행할 계획이었으나, 현재 이 조합만 제공되고 있고 추론(inference) 발자국이 더 가볍다는 점을 고려하여, Meta가 출시한 모델인 Muse Glimmer 30B에 적용하고 그곳에서 평가하기로 결정했습니다.

Muse Glimmer 30B를 선택한 이유는 간단합니다. 이 모델이 최근 저희의 일상적인 기본 모델로 자리 잡았고, Gemma-4-12b-qat-Assistant를 대체했기 때문입니다.

llama.cpp에서 실행하기

2026년 8월 현재 llama.cpp의 현황은?

2026년 8월 23일 기준으로 DFlash-2 지원 기능이 아직 llama.cpp의 master 브랜치에 반영되지는 않았습니다. 하지만 Z-Lab에서 이미 pull request를 제출했으며, 이를 기반으로 빌드하면 DFlash-2 지원을 갖춘 추론 엔진(inference engine)을 얻을 수 있습니다.

spec: add DFlash2 support (local convolution + candidate selector) — #27342

https://github.com/ggml-org/llama.cpp/pull/27342

이 PR을 적용하여 llama.cpp를 빌드하면 DFlash-2를 지원하는 추론 엔진을 얻게 됩니다:

# PR #27342가 적용된 llama.cpp 빌드
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
...

여기서 다음과 같이 실행하면 작동하는 추론 엔진을 얻게 됩니다:

../dflash/llama.cpp/build/bin/llama-server \
--model ./models/Muse-Glimmer-30B-UD-Q2_K_XL.gguf \
-t 12 -np 1 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 \
...

인수(argument)에 대한 간략한 설명:

설정은 SSH 터널을 통해 접근 서버에 연결하여 대상 인스턴스에 도달합니다. llama.cpp의 서비스 포트는 양쪽 끝 모두에서 localhost와 원격 인스턴스 간에 8001 포트를 통해 중계됩니다.

 Home                                 Highreso: GPUSOROBAN
+----------------+                  +------------------+      +--------------------+ 
| [>_]  8001/tcp |==(SSH tunnel)==> | [>_]  8001/tcp   |----->| [llama.cpp]        |
...

그림 3: GPUSOROBAN을 통한 연결 설정

사용된 인스턴스

이번 테스트를 위해 NVIDIA RTX A4000 GPU를 사용했습니다. 전체 인스턴스 사양은 아래와 같습니다.

사용된 모델 파일

4비트 양자화(quantization)에서도 Muse Glimmer의 가중치만으로도 16GiB를 초과합니다. KV-cache 오버헤드를 고려하여 Unsloth Dynamic 2.0으로 최적화된 2비트 양자화 빌드를 사용했습니다.

다음 파일들을 Unsloth의 Muse Glimmer 저장소에서 다운로드했습니다:

테스트 케이스

• 목표: 세 가지 구성(메인 모델만, DFlash, DFlash-2)에 걸친 처리량(throughput)을 측정하고 비교합니다.
  • 속도만 측정하며, 출력 내용은 평가하지 않습니다.
  • 벽시계 시간(wall-clock time), 토큰 수(token count), 생성 시 토큰 처리량(token throughput)을 기록합니다.
  • 이 수치들은 llama.cpp 자체 로그 출력에서 직접 가져온 것입니다.
• 방법: llama.cpp 웹 프런트엔드를 사용하여 두 가지 패턴을 실행했으며, 각 패턴 사이에 세션을 지웠습니다:
  • 단일 턴(Single-turn), 일본어 중심 패턴:

메모리 사용량은 다음과 같습니다. (Main 모델만 제외)

MTP 모델의 가중치 데이터와 컴퓨트 버퍼가 소폭 증가한 것을 제외하고는 메모리 사용량이 본질적으로 변함이 없습니다. 추가된 레이어(셀렉터 및 컨볼루션 레이어)가 증가분을 차지하지만, 이들이 결합되어도 100MiB 미만입니다.

토큰 처리량 비교 (Main / DFlash / DFlash-2)

단일 턴, 일본어 중심 결과

표 4: 각 구성을 위한 읽기 및 생성 처리량

응답 과정 전반에 걸쳐 생성 처리량이 어떻게 변했는지 살펴보겠습니다:

처리량은 초기 영어 부분에서는 비교적 빨랐다가, 일본어 섹션이 시작되면서 눈에 띄게 떨어졌습니다. 그럼에도 불구하고 DFlash-2는 전체 과정 동안 DFlash보다 앞섰습니다.

이 단일 턴의 일본어 중심 케이스만 하더라도, 두 드래프트 모델 모두 큰 기여를 하지 못했습니다.

다중 턴, 코드 중심 결과

여기서 흥미로운 점이 발생합니다. 다음은 다중 턴, 코드 중심 비교입니다.

DFlash와 DFlash-2 모두 여기서 강력한 처리량을 보였습니다. 전반적인 트렌드는 MTP(Multi-Turn Prompting)의 일반적인 특징입니다. 코딩 에이전트 스타일 워크로드에서 DFlash-2는 상당한 처리량 증가를 제공합니다.

이는 이전 DFlash 테스트에서 다루지 못했던 점을 확인시켜 줍니다. 즉, '다중 턴(multi-turn), 코드 중심' 시나리오에서는 Gemma-4와 달리 자체 목적 기반의 어시스턴트 스타일 MTP 모델을 제공하지 않는 Muse Glimmer 같은 모델에게 DFlash가 진정으로 유용하다는 것입니다.

게다가 DFlash-2의 새로운 추가 기능들은 수용률(acceptance)을 더욱 높여, 이는 직접적으로 더 빠른 출력으로 이어집니다.

'다중 턴, 코드 중심'은 일반적인 코딩 에이전트 사용 사례에 대한 합리적인 대리 지표(proxy)이기도 하므로, 이 설정이 대량의 토큰을 생성하는 워크로드에서 특히 효과적임을 시사합니다.

토큰 수용률 비교 (Token Acceptance Rate Comparison)

예측된 토큰 수용률을 살펴보겠습니다.

단일 턴, 일본어 중심 (Single-Turn, Japanese-Heavy)

여기서는 수용률이 상당히 낮습니다. 특히 DFlash는 2% 미만으로 떨어지는데, 이는 일반적으로

수용률(Acceptance)이 눈에 띄게 높습니다. 특히 DFlash-2는 3턴에서 평균 길이(mean length)를 설정된 최대치인 4를 초과하는데, 이는 매우 강력한 결과입니다.

수용률이 높다는 것은 예측된 토큰 중 더 많은 토큰이 사용된다는 의미이며, 이는 처리량(throughput)을 증가시키고 — 이 두 가지는 함께 움직이는 경향을 보입니다.