Gemma 4와 Qwen 3.6에서 vLLM 및 llama.cpp의 MTP 테스트 결과 — 3.34배 빠른 추론 성능 (RTX 6000 PRO)
I tested MTP on vLLM and llama.cpp for Gemma 4 & Qwen 3.6 — 3.34x faster inference, here are my findings RTX 6000 PRO.
핵심 요약
MTP(다중 토큰 예측)를 활용해 Gemma 4와 Qwen 3.6 모델의 추론 속도를 최대 3.34배 향상시킨 벤치마크 분석입니다.
- MTP 성능 — Gemma 4 및 Qwen 3.6 모델에서 추론 속도가 2.59배에서 3.34배까지 향상됨
- 엔진 비교 — Gemma 4는 vLLM이, Qwen 3.6은 llama.cpp가 우수한 성능을 보임
- 최적화 지점 — speculative 토큰 개수는 무조건 많다고 좋은 것이 아니며 모델별 최적값이 존재함
- 병목 현상 — 디코딩 단계는 연산보다 메모리 대역폭의 영향을 크게 받음
안녕 형들,
지난 몇 주 동안 로컬 GGUF, FP8 환경에서 vLLM이랑 llama.cpp를 써서 Gemma 4 31B랑 Qwen 3.6 27B 모델로 Multi-Token Prediction(MTP) 벤치마크를 돌려봤어. MTP는 지금 주요 AI 연구소들이 다들 조용히 자기들 스택에 집어넣고 있는 추론 트릭인데, 결과 보고 진짜 깜짝 놀랐다.
벤치마크 설정:
- 세션당 10회 실행
- 실행당 1500 토큰
- vLLM은 모델 두 개를 동시에 풀로 돌릴 수가 없어서 Sequential 모드로 진행
- 모든 실행에 동일한 프롬프트 사용
- Prefix caching 끔
사용 모델:
- unsloth/Qwen3.6-27B-MTP-GGUF (Q8_0) via llama.cpp
- RedHatAI/gemma-4-31B-it-FP8-block via vLLM
- Qwen/Qwen3.6-27B-FP8 via vLLM
하드웨어: AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell |
96GB VRAM | 92GB RAM | CUDA 13.1 | Ubuntu 24.04
전체 리더보드 결과는 여기 있어:
최고 결과: 132.52 vs 39.69 tok/s = 3.34배 더 빠름. 품질 저하 문제는 시간 관계상 깊게 파보진 못했어. 근데 아키텍처를 뜯어보니까 구조적으로 품질이 떨어지기가 힘든 설계더라. 타겟 모델이 토큰을 수락하기 전에 매번 검증을 거치니까, 출력 경로 자체는 표준 디코딩이랑 똑같거든. VRAM 차이는 제대로 측정할 시간이 없어서 대충 봤는데 거의 무시해도 될 수준이었어. 드래프트 모델이 워낙 작아서(Gemma 4 기준 76M 파라미터) 아키텍처상으로도 말이 됨. 그래도 이건 확정된 팩트라기보단 대략적인 관찰 결과 정도로만 생각해 줘.
내가 얻은 5가지 핵심 결론:
- Gemma 4에서는 vLLM이 llama.cpp보다 나음 — 근데 Qwen에서는 llama.cpp도 꽤 괜찮음
vLLM은 Gemma 4에서 n=5일 때 132.52 tok/s 찍었어. llama.cpp는 Qwen 3.6 Q8, n_max=3에서 117.70 tok/s로 정점을 찍었고. 중요한 건 llama.cpp가 아직 Gemma 4 MTP를 완벽하게 지원하는 게 아니라서 엔진 간 1:1 비교는 아니라는 점. vLLM 쪽 구현이 llama.cpp보다 MTP 지원이 먼저 돼서 좀 더 성숙한 상태야.
- 최적의 추론 토큰 개수가 무조건 많은 게 아님
vLLM + Gemma 4: n=5가 제일 좋았음 (132.52 tok/s)
llama.cpp + Qwen 3.6: n=3이 스윗스팟이었음 (117.70 tok/s). n=4, n=5로 갈수록 성능이 널뛰기하더라. 추론 토큰을 많이 쓴다고 무조건 빨라지는 게 아님. 모델이랑 엔진 조합마다 스윗스팟이 있으니까 직접 벤치마크 돌려봐야 해. 프롬프트에 따라서도 예측값이 달라질 수 있으니까 여러 프롬프트로 테스트해서 평균 내는 걸 추천함.
