여러분 안녕하세요,

한 달 전 저는 이곳에 저의 MTP 벤치마크 결과(Gemma 4에서 3.34배)를 게시했습니다. DFlash 지원 기능이 방금 llama.cpp에 병합되었으며(PR #22105), 동일한 장비에서 Qwen 3.6 27B로 실행해 본 결과 모든 초안 길이(draft length)에서 저의 최고 MTP 수치를 뛰어넘었습니다. DFlash는 z-lab의 블록 확산 초안 생성기(block diffusion drafter)를 사용하는 투기적 디코딩 (speculative decoding) 방식입니다. 토큰을 하나씩 생성하는 대신, 한 번의 패스로 15개(현재 제한)의 토큰 블록을 채웁니다. 저장소(repo)에서 docker compose를 가져와 여러분의 하드웨어에서 Llama 서버로 한 번의 클릭만으로 실행할 수도 있습니다.
https://preview.redd.it/pltg3n2i7ubh1.png?width=1700&format=png&auto=webp&s=3aa3306e95908b1c8eddb504c13865e9fbf17bb3

벤치마크 설정 (Benchmark config):

• 속도: NVIDIA aiperf 합성 스윕 (synthetic sweeps), ISL = OSL @ 512 / 4K / 12K / 36K, 고정 길이 (표준편차 0), EOS 무시 + 모든 요청이 전체 크기를 생성하도록 min_tokens 고정
• 크기별 측정된 요청 수: 30 / 10 / 5 / 3 (컨텍스트가 커질수록 적어지지만, 36K에서의 3회 실행은 여전히 약 110K 생성된 토큰임), 각 측정 세트 전 워밍업(warm-up) 요청: 2 / 2 / 1 / 1, 랜덤 시드(random seed) 42
• 탐욕적 디코딩 (Greedy decoding) (temperature 0, top-k 1, top-p 1.0), 동시성(concurrency) 1, 즉 "집에서 스스로 서빙하는" 시나리오.

리더보드 (Leaderboard) (빠른 설정 비교, 코드는 benchmark/leaderboard.py에 있음):

• 모든 실행 및 모든 설정에 대해 동일한 짧은 프롬프트 사용
• 설정당 10회 실행, 실행당 1500개 생성된 토큰, 3000 컨텍스트(ctx) 제한
• Temperature 0, top-k 1, seed 1234, 접두사 캐싱 (prefix caching) OFF, EOS 무시 ON
• tok/s는 llama.cpp 자체 타이밍에서 가져오며, 수락률(acceptance rate)은 draft_n / draft_n_accepted에서 가져옴
• 모든 실행은 CSV에 추가되며, 리더보드는 설정당 최상의 평균값을 유지함
  https://preview.redd.it/4oh5rqgt5ubh1.png?width=1030&format=png&auto=webp&s=3183585fe446b00d2da2fb40e0a9e5c1abb3a919

품질 테스트 (Quality Test):

• MATH-500, 처음 100개 문제, 두 설정 모두 동일한 서브셋 사용, 시드 고정, 추론 (reasoning) OFF. LiveCodeBench도 실행해 보고 싶지만, ai perf 및 패키지 관련 몇 가지 문제를 확인해야 합니다.

사용된 모델:

• 대상 (Target): llama.cpp 서버 (Docker)를 통한 unsloth/Qwen3.6-27B-GGUF (UD-Q4_K_XL)
• 초안 모델 (Draft): post-merge 아키텍처가 적용된 Alittlehammmer/Qwen3.6-27B-DFlash-GGUF-llama.cpp (Q8_0, ~1.9GB)
  하드웨어: AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell | 96GB VRAM | CUDA 13 | Ubuntu
  최상의 결과: 36K 컨텍스트에서 273.04 vs 61.47 tok/s = 4.44배 더 빠름. 리더보드 상의 최적 설정은 n_max=12에서 256 tok/s (3.64배)였습니다. 동일 모델에서 제가 기록한 최상의 MTP (Multi-Token Prediction) 설정은 190 tok/s (2.70배)였습니다.
  품질에 대하여: 지난번에는 성능 저하를 측정하지 못했고 여러분이 이에 대해 정당하게 질문하셨기에, 이번에는 직접 측정했습니다. MATH-500 (100문제) 테스트에서 베이스 모델이 87%, DFlash가 86%를 기록했습니다. 7개 과목 중 6개가 동일했으며, 프리대수 (prealgebra) 문제 하나만 달랐습니다. DFlash 실행 시 270 vs 72 tok/s (3.75배)의 속도로 문제를 풀었습니다. 이전에 몇 번의 실패가 있었고 PC를 다른 용도로 사용해야 했기에 100문제만 실행했습니다. 아키텍처상으로는 대상 모델이 모든 초안 토큰 (drafted token)을 검증하므로 탐욕적 디코딩 (greedy decoding) 시 손실이 없어야 하지만, 이번에는 설계상의 논쟁 대신 실제로 측정해보고 싶었습니다. 초기 구현 단계임을 고려할 때, 이 한 번의 오차는 오차 범위 내에 있다고 생각합니다.
  VRAM에 대하여: 이번에 이 부분도 측정했습니다. DFlash 사용 시 26GB가 로드되어 베이스라인(21GB) 대비 약 5GB의 오버헤드(Q8 초안 모델 가중치 + 버퍼)가 발생했습니다.

요약

1. 속도 향상은 컨텍스트가 길어질수록 커지며, 이는 우리가 익숙한 방식과 반대입니다.
   512 컨텍스트에서 1.44배, 4K에서 2.70배, 12K에서 3.40배, 36K에서 4.44배 향상되었습니다. 보통 모델은 컨텍스트가 커질수록 느려집니다. 여기서는 베이스라인은 성능이 저하되는 반면 DFlash는 유지되기 때문에 격차가 벌어집니다. 98K 컨텍스트에서 추론 (reasoning) 서버를 실행했을 때도 여전히 241 tok/s를 기록했습니다.

동일한 장비에서 DFlash가 모든 초안 길이 (draft length)에서 MTP를 압도했습니다.

사이클당 수락률 (Acceptance per cycle)은 비슷하지만 (tau 약 7.3 대 6.7), MTP는 초안 토큰당 한 번의 순전파 (forward pass) 비용이 발생하는 반면, 디퓨전 초안 모델 (diffusion drafter)은 한 번의 순전파로 전체 블록을 채웁니다. 초안 생성 비용은 훨씬 적으면서 출력되는 토큰은 동일합니다.

수락률이 더 낮아도 더 빠를 수 있습니다.

n_max=12에서의 43% 수락률이 n_max=2에서의 91% 수락률보다 더 뛰어난 성능을 보였습니다.

중요한 것은 수락률(acceptance percentage)이 아니라, 검증 패스(verification pass)당 수락된 토큰(accepted tokens) 수입니다. 현재 llama.cpp 구현에서는 초안 토큰(draft tokens)이 15개로 제한되어 있다는 점에 유의하세요.

이것이 작동하는 이유: 디코딩(decode)은 연산 제한(compute bound)이 아니라 대역폭 제한(bandwidth bound)이기 때문입니다.

제 MTP 포스트와 같은 이야기입니다. 모든 디코딩 단계마다 가중치(weights)를 다시 읽어야 하며, GPU는 대부분 메모리 대기 상태에 머뭅니다. 따라서 초안 모델(drafter)은 여러 수락된 토큰에 걸쳐 그 비용을 분산(amortize)시킵니다. DFlash의 추가적인 트릭은 타겟 모델의 은닉 상태(hidden states)가 모든 초안 레이어에 주입(KV injection)된다는 점입니다. 덕분에 초안 모델은 몇 개의 토큰 후에 성능이 저하되는 대신, 큰 블록의 깊은 곳까지 정확도를 유지할 수 있습니다.

두 가지 주의사항이 있지만, 로컬 사용 측면에서는 거의 공짜나 다름없는 성능 향상입니다.

주의사항 1: nvtop으로 빠르게 테스트해 본 결과, 초안 모델을 사용할 때와 사용하지 않을 때 VRAM 차이가 약 5GB 정도 발생했습니다. 하지만 녹화 중이라 다른 프로그램도 실행 중이었기에 나중에 다시 확인이 필요합니다. 아주 전문적인 테스트는 아니었습니다 xd
주의사항 2: 이것은 낮은 동시성(low concurrency) 환경에서의 이점입니다. 확산 패스(diffusion passes)가 연산 자원을 두고 경쟁하기 시작할 수 있는 높은 배치 생산 서빙(high batch production serving) 환경은 테스트하지 않았습니다.

또한 한 시간을 아껴줄 수 있는 문제 해결 팁을 드리자면: 사용 중인 초안 GGUF 파일은 반드시 architecture dflash를 가지고 있어야 합니다. dflash-draft로 태그된 리포지토리들은 병합 전 버전이라 로드되지 않을 것입니다.
https://preview.redd.it/6kafythk4ubh1.png?width=1700&format=png&auto=webp&s=119da75b6d1f3b4887a715935fe6aa25de508c6d

📦 리소스:
GitHub, 원클릭 Docker 배포, 리더보드 + sweep 스크립트, 모든 CSV 및 차트:
https://github.com/lukaLLM/DFlash

여러분의 결과와 속도는 어떤가요? 이 설정은 DGX Spark와 같은 로컬 128GB AI 박스들이 이 경제적인 환경에서 더 나은 속도를 얻기에 꽤 괜찮은 구성으로 보입니다.
submitted by /u/FantasticNature7590
[link] [comments]