Gemma 4가 최대 3배 빨라진 이유: 미래 토큰을 미리 예측하는 MTP

Google이 Gemma 4 모델군에 Multi-Token Prediction, 줄여서 MTP drafter를 공개했다.

제목만 보면 단순한 성능 개선처럼 보인다.

Gemma 4가 미래 토큰을 예측해서 최대 3배 빨라졌다

그런데 이건 모델이 갑자기 더 똑똑해졌다는 이야기라기보다,
LLM이 답변을 생성하는 방식을 더 효율적으로 바꾼 이야기에 가깝다.

핵심은 단순하다.

기존 LLM은 보통 한 번에 토큰 하나씩 생성한다.
반면 MTP는 작은 보조 모델이 여러 개의 다음 토큰을 미리 제안하고,
큰 모델이 그 제안을 한 번에 검증한다.

쉽게 말하면,

• 큰 모델이 한 글자씩 직접 쓰는 방식에서
• 작은 모델이 초안을 여러 글자 써두고
• 큰 모델이 한 번에 검사해서 맞는 부분만 채택하는 방식으로 바뀐 것이다.

이 방식이 바로 speculative decoding, 한국어로는 보통 추측 디코딩이라고 부르는 기법이다.

먼저 결론부터

Gemma 4의 이번 업데이트를 한 줄로 정리하면 이렇다.

큰 모델이 매번 토큰 하나를 직접 생성하지 않고,
작은 drafter가 여러 토큰을 미리 예측한 뒤
큰 모델이 이를 병렬로 검증해서 추론 속도를 높인다.

Google은 이 방식으로 Gemma 4 모델군에서 최대 3배 속도 향상을 얻을 수 있다고 설명한다.

다만 여기서 중요한 점이 있다.

3배는 모든 상황에서 항상 나오는 숫자가 아니다.
모델 크기, 하드웨어, 배치 크기, 런타임, 프롬프트 성격에 따라 실제 속도 향상은 달라진다.

특히 Gemma 4 26B A4B 같은 MoE 모델은 batch size 1에서 하드웨어 병렬성이 충분하지 않으면 기대만큼 빨라지지 않을 수 있다.
반대로 batch size를 높이면 expert weight 재사용이 늘어나 더 큰 이득을 얻을 수 있다.

즉 이번 발표의 핵심은 "무조건 3배 빠르다"가 아니라,
LLM 추론에서 낭비되던 시간을 줄이는 구조를 Gemma 4에 공식적으로 붙였다는 점이다.

왜 LLM은 느릴까

LLM은 문장을 한 번에 통째로 만들지 않는다.

대부분의 LLM은 autoregressive generation, 즉 자기회귀 방식으로 텍스트를 생성한다.
쉽게 말해 지금까지 나온 토큰을 보고 다음 토큰 하나를 예측하고,
그다음에는 방금 만든 토큰까지 포함해서 또 다음 토큰 하나를 예측한다.

예를 들어 이런 문장이 있다고 해보자.

Actions speak louder than

이 문장 뒤에는 보통 words가 올 가능성이 높다.

사람 입장에서는 너무 뻔한 이어쓰기다.
하지만 일반적인 LLM은 이런 쉬운 예측에도 큰 모델 전체를 한 번 실행한다.

문제는 복잡한 추론을 할 때도, 뻔한 단어 하나를 이어 붙일 때도,
기본 구조상 "다음 토큰 하나"를 만들기 위해 비슷한 흐름을 반복한다는 점이다.

그래서 답변이 길어질수록 지연 시간이 쌓인다.

• 토큰 하나 생성
• 다시 모델 실행
• 토큰 하나 생성
• 다시 모델 실행
• 이 과정을 계속 반복

이 구조에서는 모델이 커질수록 느려지고,
특히 로컬 PC나 모바일 기기처럼 메모리 대역폭이 제한된 환경에서는 병목이 더 크게 느껴진다.

Google도 이번 발표에서 표준 LLM 추론이 메모리 대역폭에 묶이는 경우가 많다고 설명한다.
프로세서가 실제 계산만 하는 게 아니라, 매 토큰마다 수십억 개의 파라미터를 VRAM에서 계산 장치로 옮기는 데 많은 시간을 쓰기 때문이다.

MTP는 뭘 바꾸는가

MTP는 Multi-Token Prediction의 약자다.

말 그대로 한 번에 여러 토큰을 예측한다.

하지만 여기서 오해하면 안 되는 부분이 있다.
MTP가 큰 모델의 최종 판단을 없애는 것은 아니다.

구조는 이렇게 동작한다.

1. 작은 drafter 모델이 여러 개의 후보 토큰을 미리 만든다.
2. 큰 Gemma 4 target 모델이 그 후보들을 한 번에 검증한다.
3. target 모델이 동의한 토큰은 채택한다.
4. 틀린 토큰이 나오면 그 지점부터는 버리고, target 모델이 올바른 토큰을 만든다.
5. 다시 drafter가 다음 후보들을 제안한다.

즉 drafter는 최종 답변을 마음대로 확정하지 않는다.
최종 결정권은 여전히 큰 Gemma 4 모델에게 있다.

이게 중요한 이유는 품질 때문이다.

작은 모델만 쓰면 당연히 빠를 수 있다.
하지만 품질이 떨어질 수 있다.

반대로 큰 모델만 쓰면 품질은 좋지만 느리다.

MTP는 이 둘 사이에서 타협한다.

• 초안은 작은 모델이 빠르게 만든다.
• 검증은 큰 모델이 한다.
• 맞는 초안은 그대로 통과시킨다.
• 틀린 초안은 큰 모델이 바로잡는다.

그래서 목표는 작은 모델 수준의 빠른 속도와
큰 모델 수준의 품질 유지를 동시에 가져가는 것이다.

비유하면 조교와 교수 구조다

조금 쉽게 비유해보자.

큰 모델은 교수고, drafter는 조교다.

기존 방식은 교수가 답안지를 한 줄씩 직접 쓰는 방식이다.
정확하지만 느리다.

MTP 방식은 조교가 먼저 다음 몇 줄을 써본다.
교수는 그 초안을 보고 맞는 줄은 통과시키고, 틀린 줄이 나오면 그 부분부터 직접 고친다.

여기서 중요한 건 교수의 검토가 마지막에 들어간다는 점이다.
조교가 쓴 내용을 무조건 믿는 게 아니다.

그래서 속도는 빨라지지만,
최종 출력은 여전히 큰 모델의 검증을 거친다.

이게 speculative decoding이 매력적인 이유다.

왜 이게 빨라질 수 있을까

처음 보면 이상하게 느껴질 수 있다.

"모델을 하나 더 쓰면 오히려 더 느려지는 거 아닌가?"

맞는 의문이다.
하지만 LLM 추론에서는 계산 자원이 항상 100% 효율적으로 쓰이지 않는다.

특히 큰 모델이 토큰 하나를 생성할 때는
계산 자체보다 메모리에서 가중치를 불러오는 과정이 병목이 되는 경우가 많다.

이때 작은 drafter가 유휴 계산 자원을 활용해서 여러 토큰을 미리 예측할 수 있다.
그리고 큰 target 모델은 이 여러 후보를 한 번에 검증한다.

기존 방식이 이랬다면,

큰 모델 실행 -> 1토큰
큰 모델 실행 -> 1토큰
큰 모델 실행 -> 1토큰
큰 모델 실행 -> 1토큰

MTP 방식은 이런 느낌에 가깝다.

작은 모델이 후보 4개 제안
큰 모델이 후보 4개를 한 번에 검증
맞는 토큰들을 한꺼번에 출력

물론 항상 4개가 전부 맞는 것은 아니다.
drafter가 예측한 토큰 중 일부는 거부될 수 있다.

그래도 쉬운 구간에서는 여러 토큰이 한 번에 통과될 가능성이 높다.
그럴수록 target 모델을 반복 실행하는 횟수가 줄어든다.

결국 속도 향상은
draft token이 얼마나 많이 accepted 되는가에 달려 있다.

Gemma 4의 MTP drafter가 특별한 점

이번 Gemma 4용 MTP drafter는 단순히 별도의 작은 모델을 하나 붙인 구조가 아니다.

Google 문서에 따르면 Gemma 4의 drafter는 target 모델과 완전히 독립된 모델이 아니라,
target 모델의 입력 임베딩 테이블을 공유하고, 마지막 레이어 activation 위에 붙는 방식으로 동작한다.

또한 drafter는 target 모델의 KV cache를 활용해 더 좋은 후보 토큰을 만들 수 있다.

이 부분이 중요하다.

일반적인 작은 draft model을 따로 붙이면,
큰 모델이 이미 계산해둔 문맥 정보를 작은 모델이 다시 계산해야 할 수 있다.

하지만 Gemma 4의 MTP drafter는 target 모델이 이미 계산한 activation과 KV cache를 활용한다.
덕분에 불필요한 재계산을 줄이고, drafter의 예측 품질도 높일 수 있다.

쉽게 말하면, 조교가 처음부터 혼자 문서를 다시 읽는 게 아니라
교수가 이미 정리해둔 노트를 보고 초안을 쓰는 구조에 가깝다.

3배 속도 향상은 어떻게 봐야 할까

Google은 Gemma 4 MTP drafter가 최대 3배 속도 향상을 제공한다고 설명한다.

하지만 이 숫자는 조심해서 봐야 한다.

속도 향상은 다음 요소에 따라 달라진다.

• 사용하는 Gemma 4 모델 크기
• dense 모델인지 MoE 모델인지
• GPU, Apple Silicon, 모바일 NPU 등 하드웨어 종류
• batch size
• 사용하는 런타임
• 프롬프트와 출력의 난이도
• draft token acceptance rate

예를 들어 쉬운 문장 완성이나 반복적인 코드 생성처럼 다음 토큰 예측이 쉬운 상황에서는 drafter가 많은 토큰을 맞힐 가능성이 높다.
이 경우 속도 향상이 크게 나올 수 있다.

반대로 복잡한 추론이나 예측이 어려운 텍스트에서는 drafter가 제안한 토큰이 자주 거절될 수 있다.
그러면 기대한 만큼 빨라지지 않는다.

또 MoE 모델에서는 token마다 활성화되는 expert가 달라질 수 있다.
이 경우 여러 draft token을 한 번에 검증하더라도 expert weight 로딩 비용이 커져서 이득이 줄어들 수 있다.

Google 문서도 Gemma 4 26B A4B 같은 MoE 모델은 batch size 1에서 하드웨어 병렬성이 충분하지 않으면 속도 향상이 제한될 수 있다고 설명한다.

그래서 이 발표는 이렇게 이해하는 게 맞다.

Gemma 4가 항상 3배 빨라졌다는 뜻이 아니라,
특정 조건에서 최대 3배까지 빨라질 수 있는 MTP drafter를 공식 제공한다는 뜻이다.

품질 저하가 없다는 말은 무슨 뜻일까

Google은 이번 MTP drafter가 출력 품질이나 reasoning logic의 저하 없이 속도를 높일 수 있다고 설명한다.

이 말이 가능한 이유는 target 모델이 최종 검증을 하기 때문이다.

drafter가 제안한 토큰을 그대로 무조건 출력하면 품질이 바뀔 수 있다.
하지만 speculative decoding에서는 큰 모델이 후보 토큰을 검증한다.

target 모델이 동의하면 채택하고,
동의하지 않으면 reject한 뒤 target 모델이 올바른 토큰을 생성한다.

그래서 이론적으로는 target 모델이 혼자 생성했을 때와 같은 품질을 유지하면서 속도를 높이는 것이 목표다.

다만 실제 서비스에서는 sampling 설정, 런타임 구현, 배치 처리 방식 등에 따라 세부 동작이 달라질 수 있다.
그래서 "품질 저하 없음"이라는 표현은
target 모델의 검증을 유지하는 speculative decoding 구조 덕분에 가능한 주장으로 이해하는 게 좋다.

개발자 입장에서 왜 중요한가

이번 업데이트가 중요한 이유는 단순히 benchmark 숫자 때문이 아니다.

LLM 제품에서 사용자가 가장 민감하게 느끼는 것 중 하나가 바로 지연 시간이다.

특히 이런 서비스에서는 속도가 매우 중요하다.

• 실시간 채팅
• 코딩 어시스턴트
• 로컬 에이전트
• 모바일 온디바이스 AI
• 음성 인터페이스
• 자동화 워크플로우
• 긴 응답을 자주 생성하는 도구

모델이 아무리 똑똑해도 응답이 너무 느리면 제품 경험이 나빠진다.
특히 로컬 LLM에서는 속도 차이가 더 크게 체감된다.

MTP drafter는 여기서 꽤 실용적인 선택지다.

모델 자체를 더 작게 줄이는 것이 아니라,
큰 모델을 유지하면서 생성 과정을 더 빠르게 만드는 방식이기 때문이다.

즉 개발자 입장에서는 이런 선택지가 생긴다.

• 더 작은 모델로 낮은 품질을 감수한다.
• 큰 모델을 그대로 쓰고 느린 속도를 감수한다.
• 큰 모델에 MTP drafter를 붙여 속도와 품질 사이를 개선한다.

Gemma 4의 MTP는 세 번째 선택지를 공식적으로 열어준 셈이다.

온디바이스 AI와도 연결된다

Google은 이번 발표에서 edge device와 on-device 성능도 강조했다.

이건 꽤 중요한 포인트다.

모바일이나 노트북에서 LLM을 돌릴 때는 서버 GPU처럼 넉넉한 자원이 없다.
메모리도 제한적이고, 배터리도 신경 써야 한다.

토큰 생성이 빨라지면 단순히 답변이 빨라지는 것만이 아니다.

• 사용자가 기다리는 시간이 줄어든다.
• 같은 작업을 더 짧은 시간에 끝낼 수 있다.
• 배터리 사용량을 줄이는 데 도움이 될 수 있다.
• 로컬 AI 앱의 체감 품질이 좋아진다.

특히 Gemma 4의 작은 모델군은 모바일과 edge 환경을 고려하고 있기 때문에,
MTP drafter는 단순 서버 최적화가 아니라 온디바이스 AI 경험 개선과도 연결된다.

실제 사용은 어떻게 하나

Google 문서 기준으로는 target 모델과 assistant 모델을 함께 로드해서 사용한다.

예를 들어 Hugging Face Transformers에서는 대략 이런 흐름이다.

from transformers import AutoProcessor, AutoModelForCausalLM

TARGET_MODEL_ID = "google/gemma-4-E2B-it"
ASSISTANT_MODEL_ID = TARGET_MODEL_ID + "-assistant"

processor = AutoProcessor.from_pretrained(TARGET_MODEL_ID)

target_model = AutoModelForCausalLM.from_pretrained(
    TARGET_MODEL_ID,
    torch_dtype="auto",
    device_map="auto",
)

assistant_model = AutoModelForCausalLM.from_pretrained(
    ASSISTANT_MODEL_ID,
    torch_dtype="auto",
    device_map="auto",
)

messages = [
    {
        "role": "user",
        "content": "Speculative decoding을 쉽게 설명해줘."
    }
]

input_text = processor.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)

inputs = processor(
    text=input_text,
    return_tensors="pt",
).to(target_model.device)

outputs = target_model.generate(
    **inputs,
    assistant_model=assistant_model,
    max_new_tokens=256,
    do_sample=False,
)

response = processor.decode(
    outputs[0][inputs["input_ids"].shape[1]:],
    skip_special_tokens=True,
)

print(response)

핵심은 assistant_model=assistant_model 부분이다.

이 assistant model이 drafter 역할을 하고,
target model은 최종 검증자 역할을 한다.

또 draft token 수는 고정할 수도 있고,
런타임에서 acceptance rate에 따라 동적으로 조절할 수도 있다.

draft token을 너무 많이 만들면 많이 맞을 때는 빠르지만,
틀렸을 때 낭비가 커진다.

반대로 너무 적게 만들면 안정적이지만,
속도 향상 폭이 작아진다.

그래서 실제 운영에서는
얼마나 많은 토큰을 미리 예측할지가 중요한 튜닝 포인트가 된다.

이번 발표의 핵심을 다시 정리하면

Gemma 4 MTP drafter의 핵심은 다음과 같다.

• 기존 LLM은 보통 한 번에 하나의 토큰을 생성한다.
• 이 방식은 긴 답변에서 지연 시간이 크게 쌓인다.
• MTP drafter는 여러 토큰을 미리 예측한다.
• Gemma 4 target 모델은 그 후보들을 병렬로 검증한다.
• 맞는 후보는 한 번에 채택된다.
• 틀린 후보는 버리고 target 모델이 올바른 토큰을 만든다.
• 최종 검증은 큰 모델이 하기 때문에 품질 유지가 가능하다.
• 실제 속도 향상은 모델, 하드웨어, 배치 크기, 프롬프트에 따라 달라진다.

즉 이번 업데이트는
모델의 지능을 바꾼 것이라기보다
모델이 답변을 더 빠르게 뱉도록 추론 경로를 최적화한 것이다.

개인적으로 인상 깊었던 부분

가장 인상 깊은 점은 MTP가 "더 작은 모델로 대체하자"가 아니라는 점이다.

LLM 최적화는 보통 이런 방향으로 많이 간다.

• 모델을 작게 만든다.
• 양자화한다.
• KV cache를 줄인다.
• attention을 최적화한다.
• 추론 엔진을 빠르게 만든다.

MTP는 여기에 다른 축을 더한다.

큰 모델은 그대로 두고, 쉬운 다음 토큰 예측을 작은 drafter에게 맡긴다.

이 방식은 꽤 현실적이다.

모든 토큰이 어려운 것은 아니다.
코드에서 반복되는 패턴, 흔한 문장 구조, 뻔한 이어쓰기, 포맷이 정해진 출력은 작은 모델도 꽤 잘 맞힐 수 있다.

그렇다면 큰 모델이 모든 토큰을 같은 비용으로 직접 생성하는 건 낭비일 수 있다.

Gemma 4 MTP는 바로 이 낭비를 줄인다.

한계도 분명하다

물론 MTP가 모든 문제를 해결하는 것은 아니다.

첫째, draft token acceptance rate가 낮으면 속도 향상이 줄어든다.
drafter가 자주 틀리면 제안한 토큰을 버리는 일이 많아지고, 그만큼 이득이 줄어든다.

둘째, MoE 모델에서는 하드웨어와 batch size 영향이 더 크다.
토큰마다 다른 expert를 불러와야 할 수 있기 때문에, batch size 1에서는 속도 향상이 제한될 수 있다.

셋째, 메모리 사용량도 고려해야 한다.
assistant 모델을 함께 로드해야 하므로, 환경에 따라 추가 메모리 부담이 생길 수 있다.

넷째, 3배라는 숫자는 최대치에 가깝게 봐야 한다.
실제 프로젝트에서는 직접 벤치마크를 해보고 도입 여부를 판단하는 게 맞다.

마무리

Gemma 4의 MTP drafter는 단순한 속도 패치가 아니다.

LLM이 텍스트를 생성하는 방식의 병목을 정확히 찌른다.

지금까지 큰 모델은 다음 토큰 하나를 만들기 위해 계속 같은 과정을 반복했다.
MTP는 이 과정을 바꿔서, 작은 drafter가 미래 토큰을 미리 제안하고 큰 모델이 한 번에 검증하게 만든다.

그 결과 특정 환경에서는 최대 3배까지 더 빠른 생성 속도를 기대할 수 있다.

이 발표가 흥미로운 이유는
"더 큰 모델"이 아니라
같은 모델을 더 빠르게 쓰는 방법에 초점을 맞췄기 때문이다.

앞으로 로컬 LLM, 온디바이스 AI, 코딩 에이전트, 실시간 음성 인터페이스에서는
모델 성능만큼이나 응답 속도가 중요해질 것이다.

그런 점에서 Gemma 4의 MTP drafter는 꽤 실용적인 방향이다.

LLM이 더 똑똑해지는 것도 중요하지만,
사용자가 기다리지 않게 만드는 것도 그만큼 중요하다.

참고 자료

• Google Blog - Accelerating Gemma 4: faster inference with multi-token prediction drafters
• Google AI for Developers - Speed-up Gemma 4 with Multi-Token Prediction
• Google AI for Developers - Gemma 4 MTP using Hugging Face Transformers
• Hugging Face - google/gemma-4-31B-it-assistant
• arXiv - Fast Inference from Transformers via Speculative Decoding