AI Tech Briefing

Gemma 4의 새 초안 모델, 로컬 LLM 속도 병목을 겨냥하다

Google이 Gemma 4용 MTP drafter를 공개했다. 작은 모델이 다음 토큰 후보를 먼저 내고 큰 Gemma가 한꺼번에 확인하는 방식이라, 출력 품질은 목표 모델에 맡긴 채 로컬·엣지·워크스테이션에서 느껴지는 지연을 줄이려는 시도다.

2026-05-06

왜 중요한가

이제 모델을 고를 때는 benchmark 점수만큼이나 같은 품질을 얼마나 빠르고 싸게 낼 수 있는가가 중요해지고 있다.
일반적인 토큰 생성 방식은 큰 모델을 토큰마다 계속 호출해야 해서, 특히 로컬 장비에서는 메모리 대역폭과 대기 시간이 병목이 되기 쉽다.
MTP와 speculative decoding은 작은 drafter가 후보를 먼저 내고 target model이 최종 확인을 맡는 방식이다. 후보가 맞으면 한 번에 여러 토큰을 받아들일 수 있고, 품질 판단은 여전히 큰 모델이 한다.
Google은 Gemma 4 계열에 맞춘 drafter weights를 Apache-2.0으로 공개했고, Hugging Face, MLX, vLLM, SGLang, Ollama, Edge Gallery 같은 실행 경로도 함께 제시했다.
연구실이나 개인 환경에서 local/private model을 쓰려면, 더 큰 모델만 찾기보다 target model, drafter, runtime support, 실제 지연 시간을 함께 봐야 한다는 신호다.

이번 공개의 핵심은 Gemma 4 자체의 똑똑함을 더 키웠다는 이야기라기보다, 같은 목표 모델을 더 덜 답답하게 쓰기 위한 배포 방식에 있다.

작은 drafter가 초안을 내고 큰 Gemma가 검토하는 구조는, 로컬·엣지·워크스테이션 LLM에서 응답 대기 시간을 줄이는 쪽으로 inference 경쟁이 옮겨가고 있음을 보여준다.

개인 개발자: 로컬 LLM이 “답은 괜찮은데 너무 느린” 상황에서 MTP 지원 모델/runtime을 먼저 검토할 수 있다.
제품팀: 챗봇, 문서 QA, IDE assistant, voice app에서 같은 모델 품질을 유지하며 응답성을 높이는 latency optimization layer로 쓸 수 있다.
엔터프라이즈팀: 데이터 거버넌스 때문에 on-prem/local inference가 필요한 경우, 성능·비용 균형을 맞추는 배포 옵션이 된다.
모바일/엣지팀: E2B/E4B 계열과 Edge Gallery 경로는 on-device AI UX를 검토하는 출발점이 된다.

모델 성능 평가에서 accuracy/benchmark뿐 아니라 tokens/sec, first-token latency, acceptance rate, energy/cost per useful token을 같이 보는 실험 설계 기준으로 쓸 수 있다.
민감한 문서/회의록/자료를 외부 API가 아니라 local model로 처리하려 할 때, “느려서 못 씀” 문제를 완화하는 runtime 후보로 볼 수 있다.
둘기 내부에 local/private model fallback을 둘 경우, 작은 모델만 고르는 것보다 target model + drafter + runtime support 조합을 검토하는 편이 낫다.
전날 WebRTC voice relay 신호와 연결해 보면, voice AI는 transport latency뿐 아니라 decoder throughput도 병목이므로 MTP 같은 decoding path가 중요하다.
모델 자체보다 runtime path별 실제 지연을 raw 기록에 남기는 습관이 필요하다.
로컬 LLM이 “답은 괜찮은데 너무 느린” 상황에서 MTP 지원 모델/runtime을 먼저 검토할 수 있다.
챗봇, 문서 QA, IDE assistant, voice app에서 같은 모델 품질을 유지하며 응답성을 높이는 latency optimization layer로 쓸 수 있다.
데이터 거버넌스 때문에 on-prem/local inference가 필요한 경우, 성능·비용 균형을 맞추는 배포 옵션이 된다.
E2B/E4B 계열과 Edge Gallery 경로는 on-device AI UX를 검토하는 출발점이 된다.

Google의 up to 3x는 hardware, runtime, batch size, model pair, prompt distribution, draft acceptance rate에 따라 달라진다.
MTP는 target model을 더 똑똑하게 만드는 기술이 아니다. 같은 target output을 더 빨리 내기 위한 decoding optimization에 가깝다.
assistant drafter weights는 target model과 runtime support가 함께 있어야 의미가 있다. 작은 drafter만 받아서 일반 LLM처럼 쓰는 물건은 아니다.
Ollama 31B MTP route는 64GB로 표시되어, 일반 노트북에서 바로 쓰기에는 부담이 크다.
MoE 모델은 batch size 1에서 기대만큼 이득이 안 날 수 있다는 Google의 설명도 있다.
HN 토론에서도 Gemma/Gemini가 빠르고 싸다는 장점과, 복잡한 구현 품질이 흔들릴 수 있다는 우려가 함께 나왔다. 속도 신호를 품질 신호로 과장하면 안 된다.
이번 hands-on은 algorithm toy simulation과 artifact/runtime 확인이며, 실제 Gemma 4 throughput benchmark는 아니다.

Gemma 4 MTP 조합이 vLLM, SGLang, Ollama, MLX 같은 runtime에서 얼마나 안정적으로 지원되는지 볼 것.
실제 환경에서 tokens/sec, first-token latency, acceptance rate, 비용·전력 대비 유효 토큰 지표가 어떻게 나오는지 비교할 것.
local/private model이나 voice AI처럼 지연 시간이 체감 품질을 좌우하는 사용처에서 MTP가 체크리스트로 자리 잡는지 볼 것.