---
title: "구글, 젬마4 추론 속도 최대 3배 끌어올리는 MTP 드래프터 공개"
published: 2026-05-05T16:14:17.000Z
canonical: https://jeff.news/article/2184
---
# 구글, 젬마4 추론 속도 최대 3배 끌어올리는 MTP 드래프터 공개

구글이 오픈 모델 Gemma 4 제품군용 다중 토큰 예측(MTP) 드래프터를 공개했다. 무거운 본 모델이 최종 검증을 맡고, 가벼운 드래프터가 여러 토큰을 미리 제안하는 speculative decoding 구조로 품질 저하 없이 최대 3배 빠른 추론을 노린다.

- 구글이 Gemma 4 제품군용 다중 토큰 예측(MTP) 드래프터를 공개함
  - Gemma 4는 공개 몇 주 만에 다운로드 6천만 회를 넘겼다고 함
  - 이번 업데이트의 핵심은 모델 자체를 바꾸는 게 아니라, 추론 시 토큰을 뽑는 방식을 더 빠르게 만드는 것임
  - 구글 주장으로는 출력 품질이나 추론 로직 저하 없이 최대 3배 속도 향상이 가능함

- 병목은 LLM 추론이 기본적으로 메모리 대역폭에 묶인다는 데 있음
  - 일반적인 대규모 언어 모델(LLM)은 다음 토큰 하나를 만들 때마다 수십억 개 파라미터를 VRAM에서 연산 장치로 옮겨야 함
  - 이 과정에서 연산 유닛은 놀고 있는데 메모리 이동이 느려서 전체 지연 시간이 늘어나는 상황이 생김
  - 특히 소비자용 GPU, 개인 워크스테이션, 모바일 기기에서는 이 병목이 더 잘 드러남

- MTP 드래프터는 speculative decoding을 Gemma 4에 맞춰 붙인 구조임
  - 무거운 타깃 모델, 예를 들면 Gemma 4 31B가 최종 판단을 맡음
  - 가벼운 MTP 모델은 앞으로 나올 토큰 여러 개를 미리 초안처럼 제안함
  - 타깃 모델은 이 후보 토큰들을 병렬로 검증하고, 맞으면 한 번의 forward pass에서 후보 전체와 추가 토큰 하나까지 받아들일 수 있음

> [!IMPORTANT]
> 포인트는 “작은 모델로 대충 빠르게”가 아님. 최종 검증은 원래 Gemma 4 본 모델이 하므로, 구글은 reasoning과 정확도는 유지하면서 속도만 당긴다고 설명함.

```mermaid
sequenceDiagram
    participant 앱 as 애플리케이션
    participant 드래프터 as MTP 드래프터
    participant 본모델 as Gemma 4 본 모델
    participant 출력 as 사용자 출력
    앱->>드래프터: 현재 문맥 전달
    드래프터->>드래프터: 여러 후보 토큰 예측
    드래프터->>본모델: 후보 시퀀스 제안
    본모델->>본모델: 후보 토큰 병렬 검증
    본모델-->>출력: 승인된 토큰과 추가 토큰 반환
    출력-->>앱: 더 빠른 응답 스트리밍
```

- 개발자 입장에서 제일 체감되는 건 latency임
  - 실시간 채팅, 음성 앱, 에이전트 워크플로에서는 몇백 ms 차이도 UX가 확 달라짐
  - 코딩 어시스턴트나 autonomous agent처럼 여러 단계 계획을 빠르게 돌려야 하는 경우에도 토큰 생성 속도가 병목이 됨
  - 온디바이스 앱에서는 더 빠른 생성이 배터리 절약으로도 이어질 수 있음

- 구글이 강조한 적용 범위도 꽤 넓음
  - 개인 PC와 소비자용 GPU에서 26B MoE, 31B Dense 모델을 더 빠르게 돌리는 로컬 개발 시나리오
  - E2B, E4B edge 모델을 모바일이나 엣지 기기에서 더 효율적으로 쓰는 시나리오
  - 클라우드뿐 아니라 워크스테이션, 모바일, 온디바이스까지 같이 겨냥함

- 내부 구조도 그냥 작은 모델 하나 붙인 수준은 아님
  - 드래프트 모델이 타깃 모델의 activations를 활용함
  - KV cache도 공유해서 큰 모델이 이미 처리한 문맥을 다시 계산하지 않음
  - E2B와 E4B edge 모델에서는 마지막 logit 계산이 병목이라, embedder에 효율적인 clustering 기법도 넣었다고 함

- 하드웨어별 최적화 얘기도 있음
  - 26B mixture-of-experts 모델은 Apple Silicon에서 배치 크기 1일 때 라우팅 때문에 까다로운 문제가 있음
  - 하지만 여러 요청을 동시에 처리해 배치 크기 4-8로 올리면 로컬에서 최대 약 2.2배 속도 향상이 나온다고 함
  - Nvidia A100에서도 배치 크기를 키울 때 비슷한 이득을 봤다고 함

- 배포 경로는 개발자 친화적으로 꽤 넓게 열어둠
  - MTP 드래프터는 Gemma 4와 같은 Apache 2.0 오픈소스 라이선스로 제공됨
  - 모델 가중치는 Hugging Face와 Kaggle에서 받을 수 있음
  - transformers, MLX, vLLM, SGLang, Ollama에서 실험할 수 있고, Android와 iOS의 Google AI Edge Gallery에서도 바로 써볼 수 있음

---
## 기술 맥락

- 일반 LLM 추론은 토큰을 하나씩 만드는 구조라서 느려요. 특히 큰 모델은 매 토큰마다 파라미터를 메모리에서 계속 읽어야 해서, GPU 연산 성능보다 VRAM 대역폭이 먼저 병목이 되는 경우가 많거든요.

- Speculative Decoding은 이 병목을 “예측”과 “검증”으로 나눠서 풀어요. 작은 드래프터가 여러 토큰을 미리 써보고, 큰 본 모델은 그 후보가 자기 출력과 맞는지 한 번에 확인하는 식이에요.

- Gemma 4의 MTP 드래프터가 중요한 이유는 품질 책임을 본 모델에 남겨둔다는 점이에요. 사용자는 더 작은 모델의 답을 받는 게 아니라, 같은 Gemma 4가 승인한 토큰을 더 빨리 받는 구조라서 품질 저하 논란을 줄일 수 있어요.

- KV cache 공유도 꽤 실전적인 포인트예요. 드래프터가 문맥을 처음부터 다시 계산하면 속도 이득이 줄어드는데, 타깃 모델이 이미 들고 있는 캐시를 같이 쓰면 중복 계산을 줄일 수 있거든요.

- 로컬 LLM 개발자에게는 배치 크기 이야기도 중요해요. Apple Silicon에서 26B MoE가 배치 1에서는 라우팅 문제로 까다롭지만, 배치 4-8에서는 최대 약 2.2배가 나온다는 건 단일 채팅보다 여러 요청을 묶는 서버형 로컬 워크로드에 더 잘 맞는다는 뜻이에요.

## 핵심 포인트

- Gemma 4는 공개 몇 주 만에 6천만 다운로드를 넘겼고, 이번에는 추론 효율 개선이 초점임
- MTP 드래프터는 speculative decoding으로 여러 미래 토큰을 미리 제안하고 본 모델이 병렬 검증함
- 구글은 출력 품질이나 reasoning logic 저하 없이 최대 3배 속도 향상을 주장함
- 26B MoE 모델은 Apple Silicon에서 배치 크기 4-8일 때 로컬 최대 약 2.2배 속도 향상을 보였음
- 모델 가중치는 Apache 2.0 라이선스로 Hugging Face, Kaggle에서 받을 수 있고 transformers, MLX, vLLM, SGLang, Ollama 등을 지원함

## 인사이트

LLM 추론 최적화가 이제 ‘더 작은 모델로 바꾸자’가 아니라 ‘같은 모델의 검증력을 유지하면서 토큰 생성 파이프라인을 바꾸자’로 가는 흐름이 선명함. 로컬 코딩 에이전트나 온디바이스 앱 만드는 개발자한테는 꽤 실전적인 업데이트임.