Gemma 4로 만든 앱이 답은 꽤 잘하는데, 사용자가 기다리는 시간이 길다면 질문은 단순합니다. "이제 MTP 드래프터를 붙이면 해결되는가?" 하지만 이 기능은 공짜 성능 버튼이라기보다, 메모리와 복잡도를 더 써서 지연시간을 줄이는 배포 선택지에 가깝습니다.
이번에 Google은 Gemma 4 계열을 위한 Multi-Token Prediction, 즉 MTP 드래프터를 공개했고, 관련 보도와 공식 설명은 "품질 저하 없이 최대 3배 빠른 추론"을 핵심 메시지로 내세웁니다.12 중요한 이유는 Gemma 4가 워크스테이션, 모바일, 클라우드까지 폭넓게 쓰이는 오픈 모델이라는 점입니다. 속도 개선이 실제라면 모델 선택 기준 자체가 달라집니다.
핵심은 3배가 아니라 병목이 어디 있느냐다
일반적인 LLM 생성은 한 토큰씩 순서대로 진행됩니다. 큰 모델은 매 토큰마다 많은 파라미터를 메모리에서 읽어와야 하므로, 실제 병목은 연산량보다 메모리 대역폭인 경우가 많습니다. Google도 MTP 드래프터의 배경을 이 문제로 설명합니다.2
MTP 드래프터는 작은 보조 모델이 몇 개의 다음 토큰을 미리 제안하고, Gemma 4 본 모델이 이를 한 번에 검증하는 방식입니다. 본 모델이 최종 검증자이기 때문에, 제안이 틀리면 본 모델의 토큰이 사용됩니다. 그래서 "출력 품질 저하가 없다"는 주장이 성립합니다.
다만 이 말은 "항상 체감 속도가 3배"라는 뜻이 아닙니다. 시간 첫 토큰, 즉 TTFT가 문제인 앱이라면 MTP의 효과는 제한적일 수 있습니다. MTP가 주로 줄이는 것은 첫 응답 이후의 디코딩 시간입니다. 짧은 챗봇 답변보다 코드 생성, 긴 요약, 에이전트의 다단계 출력에서 체감이 커지는 이유입니다.
잘 맞는 경우와 애매한 경우가 분명하다
가장 이상적인 조건은 큰 dense 모델을 batch 1 또는 적당한 배치로 길게 생성하는 상황입니다. 예를 들어 Gemma 4 31B Dense처럼 매 토큰마다 읽어야 할 모델이 크면, 드래프터의 추가 비용을 회수하기 쉽습니다.
반대로 작은 모델에서는 드래프터 자체가 오버헤드가 될 수 있습니다. E2B, E4B 같은 엣지 모델은 가볍기 때문에, 몇 개 토큰을 미리 볼지 신중히 조정해야 합니다. Google은 이 계열에서 최종 logit 계산 병목을 줄이기 위한 별도 최적화도 언급합니다.2
26B A4B MoE는 더 미묘합니다. MoE 모델은 토큰마다 다른 expert를 활성화할 수 있습니다. 여러 후보 토큰을 병렬 검증할 때 expert 로딩이 늘어나면 speculative decoding의 이득이 줄어듭니다. 관련 분석에서는 Apple Silicon의 batch 1에서 26B MoE의 이득이 제한적이고, batch 4~8에서 약 2.2배 수준의 개선이 가능하다고 정리합니다.3
즉 MTP는 "Gemma 4라면 무조건 켜라"가 아닙니다. dense 31B, 긴 출력, 서버 배치 처리, 로컬 코딩 어시스턴트에는 매력적입니다. 반면 짧은 응답, VRAM이 빠듯한 환경, MoE batch 1, Python 레벨의 실험적 루프에서는 기대보다 실망할 수 있습니다.
켜기 전에 봐야 할 체크리스트
먼저 tokens/sec만 보지 말고 TTFT와 디코딩 속도를 분리해서 측정해야 합니다. 사용자가 불만을 느끼는 지점이 첫 응답 지연인지, 긴 출력 대기인지가 다릅니다.
둘째, acceptance rate를 확인해야 합니다. 드래프터가 제안한 토큰을 본 모델이 얼마나 받아들이는지가 실제 속도를 좌우합니다. 후보를 많이 던진다고 항상 빨라지지 않습니다. 검증 비용과 거절률이 같이 올라갈 수 있습니다.
셋째, VRAM 여유를 계산해야 합니다. MTP 드래프터는 보조 모델입니다. 본 모델, KV cache, 컨텍스트 길이, 배치 크기, quantization 설정 옆에 또 하나의 메모리 항목이 생깁니다. 단일 24GB GPU나 통합 메모리 Mac에서는 모델 크기나 컨텍스트를 줄여야 할 수 있습니다.
넷째, 추론 엔진을 봐야 합니다. Google은 LiteRT-LM, MLX, Hugging Face Transformers, vLLM, SGLang, Ollama 등 다양한 경로를 언급하지만, speculative decoding은 구현 품질에 민감합니다.2 단순 Python 루프로 붙이면 검증 오버헤드 때문에 오히려 느려질 수 있다는 커뮤니티 실험도 있습니다.4
모델 선택 기준이 '성능표'에서 '추론 생태계'로 이동한다
Gemma 4 MTP 드래프터의 진짜 변화는 "한 모델이 더 빨라졌다"보다 넓습니다. 앞으로 오픈 모델을 고를 때는 벤치마크 점수만 볼 수 없습니다. 같은 수준의 지능이라도, 어떤 추론 엔진에서 speculative decoding이 잘 붙는지, KV cache 공유가 가능한지, 모바일 런타임이 있는지, 배치 처리에서 이득이 유지되는지가 중요해집니다.
지금 당장 신경 써야 할 사람은 명확합니다. Gemma 4로 긴 출력을 많이 생성하는 로컬 앱, 코딩 도구, 에이전트, 서버형 챗 서비스를 운영하는 개발자입니다. 반대로 짧은 Q&A 중심이고 메모리가 빠듯하다면, MTP는 우선순위가 아닐 수 있습니다. "최대 3배"라는 숫자보다 먼저 물어야 할 질문은 하나입니다. 내 서비스의 병목은 정말 디코딩 속도인가?
참고
2Accelerating Gemma 4: faster inference with multi-token prediction drafters
3Gemma 4 MTP drafter: 3x speedup for Dense, limited gains on 26B MoE at batch 1
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.