추측 디코딩으로 두 배 빨라진 31B

DGX Spark 1대에서 Gemma 4 31B(FP8)를 vLLM으로 돌리면 디코딩이 6.4 tok/s였습니다. 모델도 양자화도 그대로 두고 구글이 공개한 Gemma 4 드래프터(google/gemma-4-31B-it-assistant, Apache 2.0, 939 MB)를 vLLM의 추측 디코딩으로 붙였더니 13.7 tok/s가 됐습니다. 답의 품질은 같은 벤치마크로 확인했습니다.

숫자

	드래프터 없음 (10-04 밤, 빈 GPU)	드래프터 켬 (10-05 오전, 3회)
디코딩 테스트 (약 190토큰)	6.3 / 6.4 tok/s	13.5 / 13.7 / 13.8 tok/s
SM 클럭 · 전력 (디코딩 중)	2528 MHz · 36 W	2528 MHz · 36~37 W
veneta-bench 12문항(기억 능력, hybrid 검색, 1회)	12 / 12 · 턴 중앙값 49.5초	12 / 12 · 턴 중앙값 23.1초

같은 클럭, 같은 전력에서 디코딩이 2.1배, 도구 읽기와 Critic까지 포함한 한 턴 전체도 2.1배 빨라졌습니다. 12문항은 판정이 모두 같았습니다(답 문장은 샘플링이라 글자까지 같지는 않습니다). 추측 디코딩은 드래프터가 제안한 토큰을 본 모델이 검증하므로 출력 분포는 원래 모델의 것입니다. 품질이 떨어질 이유가 없고, 떨어지지 않았다는 것을 12문항으로 한 번 확인한 것입니다.

켜는 법 (vLLM 0.27.1, 컨테이너)

드래프터를 먼저 받아 두고(오프라인 모드라면 캐시에 있어야 합니다), 기존 서빙 명령에 한 줄만 더합니다.

--speculative-config '{"method":"mtp","model":"google/gemma-4-31B-it-assistant","num_speculative_tokens":3}'

로그에 Resolved architecture: Gemma4MTPModel과 Gemma4 MTP: draft layer 0~3 매핑이 보이면 붙은 것입니다. 모델 32.6 GB 적재에 약 3분, 컴파일과 워밍업까지 약 6분. 드래프터는 메모리를 0.9 GB쯤 더 씁니다. vLLM이 “num_speculative_tokens > 1은 수락률을 낮출 수 있다”고 경고하는데, 3으로 두고 잰 결과가 위 표입니다. 2나 4가 더 나은지는 측정하지 않았습니다.

조건과 모르는 것

DGX Spark GB10 1대, DGX OS 7.2.3, 드라이버 580.173.02, vLLM 0.27.1(사용자 지정 이미지), RedHatAI gemma-4-31B-it-FP8-Dynamic, 컨텍스트 16k, --gpu-memory-utilization 0.55, 동시 요청 1개. 테스트는 200토큰 출력 한 번이라 짧은 답 기준이고, 긴 생성이나 동시 요청이 많을 때의 배수는 측정하지 않았습니다. 다른 모델(OTel 31B 등)에는 같은 드래프터를 그대로 쓸 수 없고, 해당 모델용 드래프터가 있어야 합니다. 커뮤니티에서 직접 학습한 한국어 Eagle-3 드래프터는 같은 장비에서 1.3~1.5배를 보고했는데, 구글 공식 드래프터가 그보다 나았습니다.

관련 노트: DGX Spark 운영 노트 · 로컬 LLM 고르기

같은 31B 모델이 두 배 빨라졌습니다 — Gemma 4 드래프터로 추측 디코딩 켜기

같은 31B 모델이 두 배 빨라졌습니다 — Gemma 4 드래프터로 추측 디코딩 켜기

숫자

켜는 법 (vLLM 0.27.1, 컨테이너)

조건과 모르는 것