llama.cpp에서 DFlash 2(PR 빌드)를 Qwen 3.8 27B로 3일간 벤치마크함: 실무 코딩 프롬프트 100개에서 2.26배, n-gram 드래프터 추가 시 4.68배 성능 향상

1. DFlash 2는 실제 코딩 처리량을 두 배 이상 높여주며, 같은 드래프트 폭에서 DFlash 1보다 VRAM은 절반만 쓰면서 성능은 더 좋음

LiveCodeBench 문제 100개를 같은 순서로 스트리밍 재생, ignore_eos, min_tokens, max_tokens 설정 없음. 모든 답변은 모델이 끝내는 지점에서 종료됨.

DFlash 1은 n=7로 다시 돌렸음. 왜냐면 DFlash 1의 최대치인 15로 비교하면 드래프터 성능이 아니라 캡(cap) 성능을 측정하는 꼴이 되니까. 같은 폭으로 맞췄을 때 DFlash 2가 앞서는데, 각 모델 베이스라인 대비 2.26배 vs 2.00배고, 수락률은 60% vs 48%임. 게다가 DFlash 2는 2,720 MiB를 더 쓰는데, 7월에 잰 DFlash 1은 5,554 MiB를 더 썼음. 메모리 차이 일부는 아키텍처가 아니라 양자화 방식 차이(Q4_K_M 1.1 GB 드래프터 vs Q8_0 1.8 GB) 때문이긴 함.

주의할 점 두 가지. 세대 간 비교 행은 통제된 A/B 테스트가 아님. 모델도 다르고, 타겟 양자화도 다르고, 드래프터 양자화도 다름(심지어 드래프터 양자화는 DFlash 2를 돕는 게 아니라 방해함). 절대적인 tok/s는 절대 비교하지 말고 속도 향상 배수만 비교하셈. 두 베이스라인이 0.3% 차이 나는 건 그냥 운빨임.

주장 vs 실제 측정: Inco AI는 이 모델로 SGLang에서 배치 사이즈 1일 때 2.7배에서 3.4배 나온다고 함. 난 llama.cpp 단일 턴 코딩에서 2.26배 찍었음. 그러니까 이건 작업이랑 엔진에 따라 갈리는 거고, 엔진 업데이트되면 아마 더 좋아질 거임.

2. DFlash 2 위에는 룩업 테이블 하나 올리는 게 최강임. 두 개 올리면 오히려 구려짐. DFlash 1이랑 정반대임.

n-gram 드래프터는 컨텍스트에 이미 있는 내용을 복사하는 방식이라, 단일 턴 프롬프트가 최악의 조건임(위에서 +1.2%, 중앙값은 사실 -2.7%). 진짜 중요한 건 코드베이스 작업할 때니까, 18개 고정 프롬프트를 하나의 누적된 대화로 돌려봤음. 1~9턴은 llama.cpp용 Gradio 채팅 클라이언트를 기능별로 짜는 거고, 10~18턴은 그걸 유지보수하는 거임(파일 다시 뽑기, 독스트링, 이름 변경, 버그 수정, 리팩토링, 테스트, README 작성).

빌드 열을 보셈. 10턴은 "최종 app.py 전체 보여줘"인데, 이건 99%가 드래프트 가능해서 모든 추론 방식의 수치를 뻥튀기함. 18턴 전체를 놓고 보면 k4v 스택은 6.03배가 나오는데, 이건 복사형 드래프터한테 시킬 수 있는 가장 쉬운 작업에 대한 실제 수치임.

7월 결과가 반복될 줄 알았음. DFlash 1 때는 draft-dflash,ngram-mod,ngram-map-k4v 조합이 6.01배로 1등이었고 ngram-mod가 n-gram 작업의 거의 전부를 담당했거든. 근데 DFlash 2에서는 k4v 테이블만 쓰는 게 1등이고, mod만 쓰는 게 제일 구리고, 둘 다 쓰면 k4v만 쓸 때보다 느림. 드래프트 토큰 개수 문제인지 초기 구현 문제인지는 두고 봐야 함. DFlash 1은 드래프트 슬롯이 최대 15개였는데 DFlash 2는 7개라, 룩업 드래프터 두 개를 넣으면 서로 자리를 뺏어 먹는 듯.

3. 똑같은 한 줄 변경인데 답이 네 개나 다르게 나오고, 합성 벤치마크는 틀렸음

똑같은 DFlash 2 서버, 똑같은 가중치, --spec-type에 ngram-mod,ngram-map-k4v 추가해서 다시 돌려봄:

aiperf의 합성 벤치마크는 지들 테스트 환경 때문에 수치가 뻥튀기된 거임. ignore_eos랑 min_tokens를 넘겨서 모델이 자연스럽게 멈춰야 할 지점을 지나 루프 돌 때까지 강제로 밀어붙이는데, 룩업 드래프터는 루프를 기가 막히게 잘 복사하거든. 36K까지 돌리면 같은 테스트 환경에서 DFlash 2 + 룩업이 8.39배(498 tok/s)라고 나옴. 근데 실제 프롬프트 100개 돌렸을 땐 그 스택이 고작 +1.2%였음. 8.39배는 특정 상황에서나 나올 법한 수치임.

산문은 정반대임. "아주 긴 이야기 써줘"라고 하면 복사할 컨텍스트가 하나도 없어서, 테이블이 맞지도 않을 추측에 드래프트 슬롯만 다 써버림. 적중률 54%에서 32%로 떡락함. 그 행은 그냥 테스트용으로 한 번 찔러본 거지, 제대로 된 실행 결과가 아님.

실질적인 결론: 반복적인 코딩이나 자기 문맥을 다시 뱉어내는 작업에는 룩업 드래프터(lookup drafters)를 켜고, 일회성 프롬프트나 창의적인 글쓰기에는 꺼두는 게 좋다. VRAM이나 프리필(prefill)을 전혀 잡아먹지 않으니, 수락률(acceptance loss)이 유일한 비용인 셈이다.

4. 권장 드래프트 너비는 이미 정점을 지났고, 7이 사실상 한계치임

livecodebench에서 8K 토큰으로 너비당 16개의 코딩 프롬프트를 돌렸고, cache_prompt false로 설정해서 모든 요청마다 콜드 프리필 비용을 치르게 했다. livecodebench를 사용해서 최악의 상황을 측정하려고 크기를 조절했다.

모델 카드에 나온 7로 돌리면 성능을 11% 정도 손해 보는 꼴이다. 예전에 8개 프롬프트로 돌렸을 땐 5가 아니라 6이 최적이었으니, 그냥 5~6 정도로 보면 된다. 둘 다 7은 정점을 지났다는 데 동의한다. 그리고 7 이상은 올릴 수도 없다. 드래프트 GGUF가 dflash.block_size=8을 들고 있는데, llama.cpp가 n_draft_max = block_size - 1로 제한을 걸어버리고 경고 로그 띄운 뒤 7을 써버리기 때문이다. 어떤 셀은 16개 중 3~7개만 유효한 생성 결과가 나오기도 하니(프롬프트가 잘리면 모델이 바로 EOS를 뱉어버림), 정확한 정점은 대충 참고만 해라.

이 모델에서 MTP는 n=4일 때 정점을 찍고 문맥 전반에 걸쳐 2.5배 근처에서 평탄화된다. Qwen 3.8의 사이드카는 nextn_predict_layers=1로 학습된 헤드 하나를 쓰는데, DFlash 2는 타겟 레이어 5개를 읽는다. 이건 MTP라는 방식 자체가 아니라 해당 사이드카의 특성이다. Qwen 3.6은 헤드가 8개였다.

5. 긴 문맥: 드래프터는 상대적으로 싸지지만 절대적으로는 비싸짐

보통 추측적 디코딩(speculative decoding)은 긴 문맥에서 맛이 간다는 불만이 많다. 그 말속에는 두 가지 비용이 숨어 있다. 드래프터도 프롬프트를 읽어야 하는 프리필 비용은 내가 측정할 수 있었다. 하지만 그 깊이에서의 디코딩은 측정할 수 없었다(주의사항 참고). 콜드 프리필, 깊이당 12개 프롬프트 결과다:

기준 대비 세금(오버헤드)은 깊이가 깊어질수록 줄어든다(24%에서 8%로). 하지만 초 단위로 보면 +0.09초에서 +5.20초로 늘어난다. 둘 다 맞는 말인데, 앞부분만 인용하는 건 유리한 쪽만 보여주는 거다. 프리필 비용은 1K / 4K / 16K에서 각각 13 / 30 / 69개의 출력 토큰으로 상쇄되니까 제대로 된 답변이 나오면 본전은 뽑는다. 하지만 128K 프롬프트 쓰는 사람은 첫 토큰 나올 때까지 5초 더 기다려야 한다. 룩업 드래프터는 여기서 거의 공짜나 다름없고(기준 대비 0.994~0.997), 이게 격차가 드래프터 때문이지 드리프트 때문이 아니라는 걸 증명하는 대조군 역할을 한다. MTP의 세금은 더 작다(1K에서 0.83 vs 0.75).

강제 길이 합성 디코딩 스윕에서 DFlash 2는 512 / 4K / 12K / 36K에서 1.59배 → 2.62배 → 2.96배 → 3.55배를 찍었고, 기준 모델은 67.6 → 59.3 tok/s로 떨어졌다. 7월에 DFlash 1은 자체 최대치인 15로 36K에서 4.44배를 찍었고(이번 달 재측정 시 더 높음), 너비 7로 맞췄을 땐 3.71배였다. 나는 새 드래프터가 다 이길 줄 알았는데 아니다. 실제 프롬프트에선 같은 너비로 이기지만, 합성 긴 문맥 레이스에선 슬롯이 더 많은 옛날 드래프터한테 진다. 7로 제한 걸려 있어서 그렇다.

6. --spec-draft-p-min 은 DFlash 2에서 아무런 작동을 안 하며, MTP에서도 아무런 이득이 없음

적응형 드래프트 절삭(Adaptive draft truncation)은 드래프터가 확신이 없을 때 리소스를 아끼려고 블록을 일찍 끊어버리게 해준다. DeepSeek Dspark 논문에 더 고급진 방법이 있긴 한데, 그건 이제 막 vLLM에 들어갔다. 난 단순히 tok/s만 본 게 아니라 드래프트 너비랑 초당 사이클(cycles per second)도 기록해 봤다:

DFlash 2에서 0.00이랑 0.85일 때 드래프트 너비는 똑같다. common/speculative.cpp에는 드래프터 구현이 네 개 있는데, draft_simple, draft_eagle3, DFlash 1 브랜치, 그리고 draft_mtp는 p_min을 잘 따르거든. 근데 is_dflash2 선택자 브랜치는 이걸 아예 안 본다. 확률이 아니라 선택자 격자(selector lattice)를 읽기 때문이지. 서버는 여전히 시작 배너에 플래그를 띄우니까 로그 기반 체크는 통과하는데, 정작 아무 일도 안 일어나는 거다. 그 행에서 처리량(throughput)이 12.4% 떨어진 건 플래그 때문이 아니라 텍스트 때문이야. 서버는 똑같은 일을 했고(cycles/s가 1.5% 이내), 샘플링된 출력에서 똑같은 토큰 7개 중 더 적은 수만 받아들였을 뿐이지. 하마터면 "p_min 쓰면 12% 손해"라고 글 올릴 뻔했다.

MTP에서는 플래그가 문서에 적힌 대로 정확히 작동하고(너비 3.00 → 2.64, 수락률 90% → 98%), 처리량은 뭐 거의 그대로다. 4.1% 노이즈 플로어 대비 기껏해야 +0.8% 수준임.

내가 쓸 설정

• 반복 코딩, 에이전트, 자기 컨텍스트를 다시 뱉어내는 모든 작업: --spec-type draft-dflash,ngram-map-k4v --spec-draft-n-max 5

• 원샷 프롬프트 및 Q&A: --spec-type draft-dflash --spec-draft-n-max 5

• 산문(Prose): DFlash 2만 사용, 룩업 없음.

• KV 캐시는 일단 f16으로 유지해라. 나중에 안정화되면 테스트해 보든가. 지난 버전엔 문제가 좀 있었는데 난 그냥 기본값 쓴다.

• --spec-draft-p-min은 무시해.

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git fetch origin pull/27342/head:pr-27342
git switch pr-27342

# NVIDIA CUDA
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON
cmake --build build -j

# Apple Silicon
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON
cmake --build build -j

# Best measured config: iterative coding, agents, anything that re-emits its own context
# (4.68x on the multi-turn coding session vs 2.79x for DFlash 2 alone)
./build/bin/llama-server \
  -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
  -hfd incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M \
  --spec-type draft-dflash,ngram-map-k4v \
  --spec-draft-n-max 5 \
  -ngl -1 --spec-draft-ngl all \
  -fa on \
  -c 262144 \
  --parallel 1 \
  --jinja --reasoning off \
  --no-mmproj \
  --host 0.0.0.0 --port 8000 \
  --alias qwen38-dflash2-k4v

주의사항, 전부 다

• 이번엔 정확도 측정 안 했다. 그리디 추론(Greedy speculative decoding)은 구조상 출력 손실이 없고, 7월 연구에서 이미 측정했으니까(MATH-500: 100개 중 87 vs 86, 그 다음 500개 중 440 vs 435). 근데 그건 DFlash 1을 쓴 Qwen 3.6이었고, 이번에 다시 돌리진 않았다. 그냥 LiveCodeBench 스모크 테스트만 함.

• 딥 컨텍스트 디코딩 안 했다. 64K랑 128K에서는 생성마다 토큰 하나 뱉고 멈춰버려서, 그 깊이에서의 프리필(prefill)은 유효하지만 디코딩은 사실상 없는 거나 마찬가지임.

• 실험 중 딱 하나만 반복 측정했다(p_min 제어). 나머지는 전부 샘플 하나짜리다. 그 반복 측정에서 나온 4.1%랑 14.7%라는 편차가 이 글 전체의 노이즈 플로어다.

• 멀티턴 하네스는 엉뚱한 걸 측정할 수도 있다. 툴을 안 쓴다고 선언해도 기본 샘플링 하에서는 모델이 가끔 <tool_call> 블록으로 답하고 결과가 오길 기다리는데, 결과가 안 오니까 그냥 멈춘다. 툴 호출 XML은 예측 가능해서 그 세션은 엄청 빨리 끝나버림. 실제로 한 번 그런 일이 있어서(다른 애들은 50K-73K 토큰인데 혼자 1,134 토큰) 토큰 수 보고 걸러서 다시 돌렸다.

• 이건 동시성 1인 환경에서 한 기기로 돌린 한 가지 워크로드(코딩)일 뿐이다. 96GB 카드 쓰는 사람 별로 없잖아. 드래프터는 1.1GB고 KV 연산은 카드랑 상관없으니까 24-32GB 카드에서도 컨텍스트 줄이면 비슷하게 나올 거라 보는데, 직접 재보진 않았다.

• DFlash 2는 PR 빌드다. 머지되면 수치 바뀔 수 있음.

리소스

• Repo (두 연구 다 포함, 이번 건 맨 위에): https://github.com/lukaLLM/DFlash2_Qwen3.8_3.6_27B_LlamaCPP

• 영상 가이드 (전반부는 메커니즘, 경로 선택기, 컨볼루션 설명이고, 후반부는 점수 등에 대해 더 깊게 다룸):

  Watch

• 원클릭 설정, PR 이미지 빌드, 모델 다운로드, 스모크 테스트 후 서버 실행까지 한 번에: ./scripts/setup_dflash2.sh --arm dflash2_ngram (arm 종류: base, dflash2, mtp, ngram, dflash2_ngram). Compose 파일은 docker/docker-compose-qwen38-dflash2.yaml 사용; LLAMA_SPEC_TYPE=... 및 LLAMA_SPEC_N=5로 어블레이션 테스트 가능.

• 전체 연구 재현 순서: ./scripts/run_all_benchmarks.sh 실행 후 run_matched_n.sh, run_context_scaling.sh, run_bench_ngram.sh, run_nmax_redo.sh, run_pmin_agentic.sh 순으로 진행.

• 모든 수치는 기계 판독 가능한 파일 하나에 정리됨: benchmark/results_summary.csv (표 8-14가 이번 연구 내용). 원본 아티팩트는 artifacts/q38_*/ 아래에 있고, 온도 로그는 artifacts/thermal/, 제외된 실행 결과와 그 이유는 artifacts/_suspect/README.md에 있음.

• 차트가 포함된 상세 보고서: 저장소 내 report/dflash2-report.html.

• 블로그 주소: https://inco.ai/blog/dflash2/

• 이전 게시물: 7월에 올린 DFlash 1 https://www.reddit.com/r/LocalLLaMA/comments/1uq0h4o/i_tested_freshly_merged_dflash_in_llamacpp_on/ 및 n-gram 스택 관련 영상

  Watch

이 글을 편집하는 데 AI를 아주 갈아 넣었음.

질문:

• 혹시 이 모델로 SGLang이나 vLLM에서 동시성 1로 DFlash 2 돌려본 사람 있음? 2.7~3.4배 성능 향상 주장이 거기서도 먹히는지, 그리고 내가 측정한 2.26배와의 차이가 엔진 차이 때문인지 궁금함.

• 4090이나 5090 쓰면서 24~32GB VRAM 예산 내에서 돌리는 사람 있나? n=5가 여전히 7보다 잘 나오는지, 그리고 k4v 전용 스택은 본인들의 멀티턴 코딩 환경에서 어느 정도 성능 나오는지 궁금함.

• 내가 생각 못한 다른 조합 시도해 본 사람 있음?

좋은 발견이네요, 감사합니다!