LLM 제품을 만들 때 가장 답답한 병목은 종종 "정답을 못 맞힌다"가 아니라 "사용자가 기다린다"입니다. 특히 채팅, 코딩 도우미, 음성 인터페이스, 에이전트처럼 여러 번 왕복하는 서비스에서는 1초 차이가 제품 품질처럼 느껴집니다.
이 맥락에서 Gemma 4용 MTP Drafter는 새로 더 똑똑한 모델이라기보다, 같은 모델을 더 빠르게 쓰기 위한 추론 구조의 변화에 가깝습니다. Google은 Gemma 4 모델군에 Multi-Token Prediction drafter를 공개하며 speculative decoding을 통해 최대 3배의 tokens-per-second 향상을 제시했습니다.1
왜 LLM은 한 단어씩 느리게 말하는가
일반적인 LLM은 다음 토큰을 하나 예측하고, 그 토큰을 문맥에 붙인 뒤 다시 다음 토큰을 예측합니다. 문제는 매번 거대한 모델 가중치를 읽어야 한다는 점입니다.
흥미로운 부분은 병목이 항상 연산량 자체는 아니라는 점입니다. 대형 모델 추론에서는 GPU 연산 유닛이 계산을 못 해서 쉬는 것이 아니라, VRAM에서 파라미터를 가져오는 메모리 대역폭 때문에 기다리는 경우가 많습니다. "Actions speak louder than..." 뒤에 "words"가 올 가능성이 높아도, 모델은 여전히 큰 모델 전체를 거쳐 다음 토큰 하나를 계산합니다.
MTP Drafter는 이 비효율을 겨냥합니다. 작은 보조 모델이 앞으로 나올 토큰 여러 개를 먼저 써보고, 큰 Gemma 4 본 모델이 그 초안을 한 번에 검토합니다. 초안이 맞으면 여러 토큰이 한꺼번에 확정됩니다. 틀리면 본 모델이 바로잡습니다.
실무적으로 중요한 점은 "작은 모델이 답을 대신한다"가 아니라는 것입니다. 최종 판단은 여전히 target model이 합니다. 그래서 Google은 reasoning logic과 출력 품질 저하 없이 속도만 높일 수 있다고 설명합니다.1
최대 3배라는 숫자를 그대로 믿으면 안 되는 이유
"최대 3배"는 매력적인 숫자지만, 모든 환경에서 자동으로 나오는 보장은 아닙니다. speculative decoding의 효과는 drafter가 제안한 토큰을 본 모델이 얼마나 많이 받아들이는지에 달려 있습니다.
예를 들어 코드 생성, JSON 출력, 템플릿 기반 응답처럼 다음 토큰이 비교적 예측 가능한 작업에서는 acceptance rate가 높아질 가능성이 큽니다. 반대로 창의적 글쓰기, 열린 대화, 추론 경로가 자주 갈리는 문제에서는 drafter의 초안이 자주 거절될 수 있습니다.
한 실무 평가 글도 이 점을 지적합니다. 구조화 추출 작업에서는 처리량 개선이 비교적 뚜렷했지만, 개방형 요약에서는 개선폭이 작았고 품질 지표를 별도로 확인해야 한다고 설명합니다.2 이 결과를 일반화할 수는 없지만, 도입 판단에는 유용한 경고입니다.
즉 MTP는 "항상 빠른 버튼"이 아니라 "예측 가능한 출력일수록 유리한 가속 경로"에 가깝습니다.
로컬, 서버, 모바일에서 봐야 할 체크포인트
Gemma 4 MTP Drafter가 흥미로운 이유는 서버뿐 아니라 로컬과 온디바이스 환경도 겨냥한다는 점입니다. Google은 Hugging Face Transformers, MLX, vLLM, SGLang, Ollama, LiteRT-LM 등을 실험·실행 경로로 언급했고, Apache 2.0 라이선스로 제공한다고 밝혔습니다.1
하지만 실제 도입 전에는 런타임이 speculative decoding을 제대로 지원하는지 확인해야 합니다. 단순히 drafter 파일을 받는 것만으로 속도가 나는 것이 아니라, KV cache 공유, activation 활용, 병렬 검증 경로가 서빙 엔진 안에서 효율적으로 구현되어야 합니다.
vLLM 같은 서빙 엔진은 PagedAttention, continuous batching, prefix caching, speculative decoding 등 추론 최적화를 핵심 기능으로 내세웁니다.3 이런 런타임 위에서는 MTP의 이점이 더 잘 살아날 수 있습니다. 반대로 Python 레벨에서 단순 루프를 돌리는 실험은 오히려 오버헤드 때문에 기대보다 느릴 수 있습니다.
하드웨어와 batch size도 중요합니다. Google은 Apple Silicon에서 Gemma 4 26B MoE가 batch size 1에서는 라우팅 문제로 최적 성능이 나오기 어렵지만, batch size 4~8에서는 로컬에서도 약 2.2배 가속이 가능하다고 설명했습니다.1 이는 1인 로컬 챗봇과 다중 요청 서버가 전혀 다른 결과를 낼 수 있다는 뜻입니다.
도입 여부는 "품질 유지"보다 "내 워크로드에서 빠른가"로 판단해야 한다
MTP Drafter의 핵심 가치는 모델 능력 향상이 아닙니다. 같은 모델의 응답 지연을 줄여 제품 경험을 바꾸는 데 있습니다.
따라서 도입 판단은 세 가지 질문으로 좁혀야 합니다.
첫째, 내 출력은 예측 가능한가. 코드, 구조화 데이터, 반복 양식이라면 우선 실험할 가치가 큽니다.
둘째, 내가 쓰는 런타임이 MTP를 제대로 최적화하는가. vLLM, SGLang, MLX, Ollama 등 이름이 언급되더라도 버전과 구현 상태를 확인해야 합니다.
셋째, 평균 속도뿐 아니라 tail latency와 실패율을 측정했는가. 사용자는 평균적으로 빠른 시스템보다 가끔 멈칫거리는 시스템을 더 나쁘게 기억합니다.
Gemma 4를 이미 쓰고 있고 응답 속도가 병목이라면 MTP Drafter는 가장 먼저 시험해볼 만한 옵션입니다. 다만 "최대 3배"보다 중요한 숫자는 당신의 프롬프트, 당신의 하드웨어, 당신의 서빙 경로에서 나온 p95 latency입니다.
참고
1Gemma 4 MTP Drafter와 Speculative Decoding으로 LLM 추론 가속 이해하기
2What Gemma 4's multi-token prediction head actually means for your eval pipeline
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.