구글, 젬마4 추론 속도 최대 3배 끌어올리는 MTP 드래프터 공개

• 구글이 Gemma 4 제품군용 다중 토큰 예측(MTP) 드래프터를 공개함

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

• 병목은 LLM 추론이 기본적으로 메모리 대역폭에 묶인다는 데 있음

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

• MTP 드래프터는 speculative decoding을 Gemma 4에 맞춰 붙인 구조임

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

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배가 나온다는 건 단일 채팅보다 여러 요청을 묶는 서버형 로컬 워크로드에 더 잘 맞는다는 뜻이에요.