LocalLLaMA 벤치마크, Gemma 4 31B speculative decoding 평균 29% 속도 향상 보고

r/LocalLLaMA에 올라온 새 벤치마크는 speculative decoding이 이제 Gemma 4 로컬 추론에서 꽤 실용적인 기본 옵션이 될 수 있음을 보여준다. 작성자는 Windows 11 환경의 RTX 5090(32GB VRAM)에서 Gemma 4 31B UD-Q4_K_XL을 main model로, Gemma 4 E2B UD-Q4_K_XL을 draft model로 조합해 테스트했고, 평균 throughput이 57.17 tokens/s에서 73.73 tokens/s로 약 29% 올랐다고 보고했다. code generation과 math explanation에서는 50% 안팎의 가속도도 관찰됐다.

흥미로운 지점은 단순히 숫자가 아니라, 처음에는 오히려 더 느렸다는 실패 사례다. 작성자는 초기 조합에서 target model과 draft model의 vocabulary가 호환되지 않아 llama.cpp가 token translation 모드로 들어갔고, 그 결과 speculative decoding이 이득이 아니라 병목이 됐다고 설명했다. 원인을 따라가 보니 early April에 내려받은 Gemma 4 31B GGUF의 add_bos_token metadata와 나중에 받은 E2B 모델의 값이 달랐고, 이 mismatch가 성능을 망쳤다는 것이다. 업데이트된 GGUF를 다시 내려받자 경고가 사라지고, 기대한 속도 향상이 회복됐다.

벤치마크 세부 수치도 꽤 유용하다. 작성자는 code와 math처럼 예측 가능한 출력에서는 acceptance rate가 약 60% 수준으로 올라가며 +50% 가까운 개선을 봤고, explanation류는 +24% 정도, translation과 creative task처럼 예측성이 낮은 작업도 여전히 +10% 수준의 순증이 있었다고 적었다. 또 --draft-max 8이 혼합 workload에서는 가장 균형이 좋았고, --parallel 1은 사실상 필수였다고 강조했다. parallel이 auto(=4)로 잡히면 draft model KV cache가 4배로 할당돼 VRAM을 잡아먹고 성능이 급락한다는 설명도 붙었다.

이 스레드의 핵심은 speculative decoding이 더 이상 일부 고급 실험에만 머물지 않는다는 점이다. 로컬 추론에서는 model size만큼이나 GGUF metadata, tokenizer compatibility, context length, KV cache 동작, multimodal 사용 여부가 중요해지고 있다. 작성자는 Q4 draft 기준으로 추가 VRAM이 약 2.3GB 정도면 충분했다고 보고했는데, 이는 많은 32GB급 카드 사용자에게 현실적인 범위다. 결국 Gemma 4 사용자라면 benchmark를 돌리기 전에 모델 파일 metadata를 먼저 점검하는 것이 가장 값싼 최적화일 수 있다.

출처: r/LocalLLaMA 벤치마크 글.