LocalLLaMA 벤치마크: Gemma 4 speculative decoding 평균 처리량 29% 향상 주장

LocalLLaMA 글이 측정한 내용

r/LocalLLaMA 게시글은 Gemma 4 31B에 Gemma 4 E2B를 draft model로 붙인 speculative decoding 벤치마크를 공유했다. 이번 크롤링에 사용한 스레드 스냅샷 기준으로 이 글은 257 업보트, 댓글 88개였다. 테스트 환경도 구체적이다. RTX 5090 32GB VRAM, Windows 11, TurboQuant KV cache가 들어간 llama.cpp 포크, 128K context, Flash Attention, 그리고 --draft-max 8 --draft-min 1 설정이다.

관측된 처리량 증가

작성자는 baseline 평균이 57.17 t/s, speculative decoding 평균이 73.73 t/s라고 적었고, 이는 +29.0% 향상이다. 가장 큰 이득은 구조화된 출력에서 나왔다. 수학 설명은 57.45에서 85.86 t/s, 코드 생성은 57.15에서 86.05 t/s로 올라 각각 약 +50%를 기록했다. 반구조적 설명은 약 +24%, 번역과 분석도 acceptance rate가 42.2%로 낮았지만 여전히 +10.7% 개선됐다고 한다.

핵심은 실패 사례였다

운영 측면에서 더 중요한 정보는 최고 성능 수치보다 실패 원인이다. 작성자는 모델을 다시 내려받기 전 draft 경로가 7.31 t/s까지 떨어졌다고 설명한다. 이유는 llama.cpp가 target과 draft vocabulary가 호환되지 않는다고 경고했기 때문이다. 글에 따르면 원인은 add_bos_token 메타데이터 불일치였다. 2026년 4월 초의 Gemma 4 31B GGUF는 false, 이후 받은 E2B draft는 true였고, 이 차이로 token translation이 강제되면서 기대한 가속이 사라졌다.

실전에서 중요한 설정 포인트

게시글은 이 구성에서 --parallel 1이 사실상 필수라고 주장한다. 자동 parallel 설정은 draft KV allocation을 여러 배로 키워 VRAM을 잠식하고 성능을 무너뜨릴 수 있다는 설명이다. 또 Q4 draft면 충분하고, 이 스택에서는 speculative decoding과 multimodal vision을 함께 쓸 수 없으며, 추가 VRAM은 약 2.3GB라고 적었다. 총 사용량은 128K context에서 약 23.4GB, 256K에서는 약 25.5GB 수준이라는 주장이다.

운영자가 가져갈 수 있는 교훈

더 넓게 보면 speculative decoding의 성능은 단순히 작은 draft model을 붙인다고 얻어지는 것이 아니라, workload 형태와 tokenizer 호환성에 좌우된다는 점이 중요하다. 이 글의 sweep에서는 draft-max 8이 혼합 workload에서 가장 좋은 평균을 냈고, 16은 수학 성능을 더 끌어올렸지만 creative 작업에서 일부를 반납했다. 로컬 LLM 운영자에게는 먼저 vocab 호환성을 확인하고, 그다음 실제 작업 유형에 맞춰 draft 길이를 조정하라는 실전 메모로 읽힌다.

Reddit 토론 스레드