# Gemma 4 가속하기 : 다중 토큰 예측 drafter로 더 빠른 추론 > Clean Markdown view of GeekNews topic #29214. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29214](https://news.hada.io/topic?id=29214) - GeekNews Markdown: [https://news.hada.io/topic/29214.md](https://news.hada.io/topic/29214.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T10:10:20+09:00 - Updated: 2026-05-06T10:10:20+09:00 - Original source: [blog.google](https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/) - Points: 4 - Comments: 1 ## Topic Body - Google은 [Gemma 4](https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/) 공개 후 몇 주 만에 다운로드 6,000만 회를 넘겼고, Gemma 4 제품군용 **다중 토큰 예측(MTP) drafter**를 공개함 - MTP drafter는 특화된 **추측 디코딩(speculative decoding)** 아키텍처로 출력 품질이나 추론 로직 저하 없이 추론 속도를 최대 3배 높이며, LiteRT-LM, MLX, Hugging Face Transformers, vLLM 사용 하드웨어에서 테스트됨 - 표준 LLM 추론은 단일 토큰 생성을 위해 수십억 개 매개변수를 VRAM에서 연산 유닛으로 옮기느라 **메모리 대역폭** 병목이 커지고, MTP는 가벼운 drafter가 여러 미래 토큰을 제안한 뒤 대상 모델이 병렬 검증하게 만듦 - 대상 모델이 초안 토큰에 동의하면 전체 시퀀스를 단일 순전파에서 받아들이고 추가 토큰 하나도 생성해, 애플리케이션은 보통 단일 토큰 시간에 **초안 시퀀스와 추가 토큰**을 출력할 수 있음 - MTP drafter는 대상 모델 활성값과 **KV 캐시**를 공유하고, E2B·E4B 엣지 모델에는 효율적인 임베더(embedder) 클러스터링을 적용하며, 가중치는 [Hugging Face](https://huggingface.co/collections/google/gemma-4)와 [Kaggle](https://www.kaggle.com/models/google/gemma-4)에서 Apache 2.0 라이선스로 제공됨 --- ### 추측 디코딩이 필요한 이유 - 표준 LLM 추론은 메모리 대역폭에 묶여 있어 지연 병목이 커짐 - 프로세서는 단일 토큰을 생성하기 위해 수십억 개의 매개변수를 VRAM에서 연산 유닛으로 옮기는 데 대부분의 시간을 쓰게 됨 - 이 구조는 특히 소비자용 하드웨어에서 연산 자원을 충분히 활용하지 못하게 만들고 지연을 높임 - 추측 디코딩은 토큰 생성과 검증을 분리함 - 무거운 대상 모델, 예를 들어 Gemma 4 31B를 가벼운 drafter인 MTP 모델과 짝지어, 비어 있는 연산 자원으로 여러 미래 토큰을 한 번에 예측함 - drafter는 대상 모델이 토큰 하나를 처리하는 데 걸리는 시간보다 짧은 시간에 여러 토큰을 제안하고, 대상 모델은 제안된 토큰을 병렬로 검증함 ### MTP가 동작하는 방식 - 표준 대규모 언어 모델은 자기회귀 방식으로 텍스트를 생성하며, 한 번에 정확히 하나의 토큰만 만듦 - 이 방식은 “Actions speak louder than…” 뒤에 “words”를 예측하는 쉬운 이어쓰기와 복잡한 논리 퍼즐 풀이에 같은 양의 연산을 투입함 - MTP는 Google 연구자들이 [_Fast Inference from Transformers via Speculative Decoding_](https://arxiv.org/abs/2211.17192)에서 도입한 추측 디코딩으로 이런 비효율을 줄임 - 대상 모델이 초안 토큰에 동의하면 전체 시퀀스를 단일 순전파에서 받아들이고, 대상 모델 자체도 추가 토큰 하나를 동시에 생성함 - 애플리케이션은 보통 단일 토큰을 생성하는 데 걸리는 시간에 초안 시퀀스 전체와 추가 토큰 하나를 출력할 수 있음 ### 개발자에게 주는 성능 효과 - 개발자에게 추론 속도는 프로덕션 배포의 주요 병목이 되는 경우가 많음 - 빠른 다단계 계획이 필요한 자율 에이전트, 코딩 어시스턴트, 온디바이스로 완전히 실행되는 반응형 모바일 애플리케이션에서는 밀리초 단위 지연도 중요함 - Gemma 4 모델을 해당 drafter와 함께 사용하면 다음 효과를 얻을 수 있음 - ## 응답성 개선 - 거의 실시간 채팅, 몰입형 음성 애플리케이션, 에이전트형 워크플로의 지연을 크게 줄일 수 있음 - ## 로컬 개발 가속 - 개인 컴퓨터와 소비자용 GPU에서 26B MoE 및 31B Dense 모델을 빠르게 실행해 복잡한 오프라인 코딩과 에이전트형 워크플로를 지원함 - ## 온디바이스 성능 향상 - E2B 및 E4B 모델을 엣지 기기에서 더 빠르게 출력하도록 해 기기의 배터리 사용을 줄이는 데 도움이 됨 - ## 품질 저하 없음 - 기본 Gemma 4 모델이 최종 검증을 유지하므로 같은 수준의 추론과 정확도를 훨씬 빠르게 제공함 - Gemma 4 26B를 NVIDIA RTX PRO 6000에서 실행한 예시는 표준 추론과 MTP drafter의 초당 토큰 수 차이를 비교하며, 같은 출력 품질에서 대기 시간이 절반 수준임을 보여줌 - 비교 영상은 [다운로드](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_videos/mtp_speed_2.mp4)해 볼 수 있음 ### MTP drafter의 내부 최적화 - MTP drafter를 빠르고 정확하게 만들기 위해 여러 아키텍처 개선이 적용됨 - 초안 모델은 대상 모델의 활성값을 자연스럽게 활용하고 대상 모델의 KV 캐시를 공유함 - KV 캐시 공유 덕분에 큰 모델이 이미 처리한 문맥을 다시 계산하는 데 시간을 낭비하지 않음 - E2B와 E4B 엣지 모델에서는 최종 로짓 계산이 큰 병목이 되기 때문에, 임베더에 효율적인 클러스터링 기법을 구현해 생성을 더 빠르게 함 - 하드웨어별 최적화도 분석됨 - Apple Silicon에서 26B mixture-of-experts 모델은 배치 크기 1일 때 고유한 라우팅 과제가 있지만, 여러 요청을 동시에 처리하면 로컬에서 최대 약 2.2배 속도 향상을 얻음 - 예시 배치 크기는 4~8이며, NVIDIA A100에서도 배치 크기를 늘릴 때 유사한 향상이 나타남 - 시각적 아키텍처, KV 캐시 공유, 효율적인 임베더의 동작 방식은 [심층 기술 설명](https://x.com/googlegemma/status/2051694045869879749)에서 확인할 수 있음 ### 사용 방법과 제공 위치 - Gemma 4 제품군용 MTP drafter는 Gemma 4와 같은 오픈소스 Apache 2.0 라이선스로 제공됨 - MTP를 Gemma 4와 함께 사용하는 방법은 [문서](https://ai.google.dev/gemma/docs/mtp/overview)에서 확인할 수 있음 - 모델 가중치는 [Hugging Face](https://huggingface.co/collections/google/gemma-4)와 [Kaggle](https://www.kaggle.com/models/google/gemma-4)에서 다운로드할 수 있음 - 더 빠른 추론은 transformers, [MLX](https://huggingface.co/collections/mlx-community/gemma-4-assistant-mtp), [vLLM](https://docs.vllm.ai/projects/recipes/en/latest/Google/Gemma4.html), [SGLang](https://docs.sglang.io/cookbook/autoregressive/Google/Gemma4#speculative-decoding-mtp-server-commands), [Ollama](https://ollama.com/library/gemma4:31b-coding-mtp-bf16)로 실험할 수 있음 - Google AI Edge Gallery에서 [Android](https://play.google.com/store/apps/details?id=com.google.ai.edge.gallery) 또는 [iOS](https://apps.apple.com/us/app/google-ai-edge-gallery/id6749645337)로 직접 사용해볼 수 있음 - Google은 Gemma 생태계인 [Gemmaverse](https://deepmind.google/models/gemma/gemmaverse/)에서 이 속도 향상이 개발을 가속하기를 기대함 ## Comments ### Comment 56910 - Author: neo - Created: 2026-05-06T10:10:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48024540) - Gemma와 Gemini는 다른 모델보다 **출력 토큰을 훨씬 적게** 쓰면서도 최상위 벤치마크 성능에 꽤 근접해 있음 Gemma와 Qwen을 비교하면 Qwen이 조금 더 잘하지만 작업에 22분을 쓰고, Gemma는 버튼 정렬을 틀리더라도 같은 프롬프트를 4분 만에 끝내는 경우가 흔함 겉보기로는 Gemma가 선두 오픈 모델보다 5~10% 낮은 성능을 내지만, **시간은 1/10**만 쓰는 셈임 - 체감상 월 15달러짜리 **Gemini 기본 플랜**으로 하루 종일 코딩해도 한도에 걸리지 않음 Claude나 Codex에서 다른 사람들이 월 100달러 플랜으로 올리는 것처럼 업그레이드할 필요도 못 느낌 다만 Gemini는 지난 1년 동안 몇 번 성능이 낮아졌고, 속도 제한도 빡빡해졌기 때문에 앞으로도 이만큼 좋을지는 모름 - Dwarkesh 팟캐스트에서 SemiAnalysis의 Dylan Patel이 Google은 훨씬 많은 연산 자원과 **TPU** 접근성 덕분에 경쟁사보다 큰 모델을 감당할 수 있다고 했음 같은 지능 단위당 큰 모델이 보통 더 적은 토큰을 쓰므로, 토큰 사용량 차이를 설명할 수 있어 보임 - Gemma가 빠르다 보니 원래는 크기가 부족한 GPU에서도 돌릴 수 있음 4070에서 실행해 봤는데 출력이 엄청 빠르진 않아도 쓸 만했음 아직 복잡한 작업에는 써보지 않았고, 그런 경우엔 다를 것 같음 - 지금은 Claude가 매우 유행하지만, Gemini를 쓰면서 문제를 겪거나 갈아탈 필요를 느낀 적은 없음 Google I/O 이후에는 더 많은 사람이 Gemini가 얼마나 좋은지 알게 될지도 모름 - 맞는 말이지만 공정하게 보려면 **누적 토큰 출력량**을 합산해야 함 정렬 문제가 생기면 이를 고치기 위해 입력·출력 토큰을 한 번 더 써야 함 - llama.cpp에 **MTP 지원**이 추가되고 있고, 적어도 Qwen 모델용으로는 진행 중임([https://github.com/ggml-org/llama.cpp/pull/20533]()) Gemma 4도 곧 따라올 것 같음 최근 몇 달 동안 로컬·자체 호스팅 모델의 품질과 속도 향상이 놀라울 정도임 - 더 최신 PR이 있고 곧 병합될 것 같음: [https://github.com/ggml-org/llama.cpp/pull/22673]() - 며칠 전 개인 용도로 Qwen3.6에서 Gemma 4로 다시 갈아탔는데, 후자의 **26B 버전**이 전자의 27B보다 평균적으로 더 나은 성능을 보여줬음 오랫동안 로컬 모델을 돌려온 입장에서는 정말 흥미로운 시기임 - **DFlash 통합**에도 관심이 커지고 있음: [https://github.com/ggml-org/llama.cpp/issues/21978]() MTP와 비교하면 어떨지 빨리 보고 싶음 - oMLX에서도 이걸 보고 싶음 꽤 괜찮은 도구였음 - MTP 추론이 추론 스택의 어디에 들어가는지는 정확히 모르겠지만, **MLX 생태계**에서 구현 가능한지 아는 사람이 있으면 궁금함 - Google이 서구권 **오픈소스 모델**을 거의 혼자 떠받치고 있음 Gemma 4 31B는 훌륭함 다만 시각 기능과 곧 나올 드래프터까지 포함해 최상의 버전을 **24GB VRAM**에 맞추려면 꽤 고통스러움 내 빌드는 GPU를 더 추가할 수 없고, 최고 성능을 내려면 4090을 하나 더 사야 할 것 같은데 너무 비싸거나, 아니면 아예 교체해야 할 듯함 - llama.cpp에서 `--no-mmproj-offload`를 쓰면 멀티모달 프로젝터, 즉 오디오·이미지·PDF 이해 부분을 시스템 RAM에 둘 수 있음 물론 그러면 GPU 가속은 안 되지만 **VRAM**은 절약됨 - 그래도 Qwen이 Gemma보다 낫다고 봄 작업별로 더 조정할 수도 있어서, 사고와 정확도를 우선할지 **추론 속도**를 우선할지 선택 가능함 - 컴퓨터가 글을 쓰는 걸 보고 있으면 예전 **BBS에 모뎀으로 접속**하던 시절이 떠오름 이건 300 보드에서 1200 보드로 올라간 것 같은 느낌이라 큰 개선이긴 하지만 여전히 꽤 느리고, 언젠가는 우리가 이걸 어떻게 참고 썼는지 의아해할 것 같음 - 요즘 상태는 정말 **전화 접속 시대** 같고, 앞으로의 “광대역” 시대가 어떤 모습일지 계속 생각하게 됨 토큰이 흘러나오는 걸 보는 건 JPEG가 픽셀 몇 줄씩 로드되는 걸 보는 느낌이고, 앱들이 속도가 충분히 빨라지기 전 각자 구현하던 여러 로딩·연결 애니메이션도 떠오름 Cerebras나 Taalas가 하는 작업은 그런 방향에서 무엇이 가능할지 보여주는 흥미로운 단서임 지금 최첨단 모델도 초당 백만 토큰을 아주 낮은 비용으로 쓸 수 있다면 무엇이 가능할지 상상해 보는 것도 재미있음 - 전화 접속 시대를 떠올리게 한다는 건 맞지만, 300에서 1200이라기보다는 **4800 보드**에 더 가까워 보임 Claude가 계산한 모뎀 대 Claude 비교는 이렇음: 2368자 기준 300은 1분 19초, 1200은 19.7초, 2400은 9.9초, 14.4K는 1.6초, 33.6K는 705ms, 56K는 447ms, Claude는 7.9초임 - 여기 올라왔던 어떤 스타트업은 AI가 즉시 응답하게 하는 **맞춤형 하드웨어**를 만들었음 초당 수천 토큰 수준이었음 - Google의 전략은 다른 프런티어 제공자들과 조금 다른 것 같음 순수 성능보다 **연산 대비 성능 효율**에 더 집중하는 듯하고, 그래서 Gemini가 겉보기에는 뒤처져 보이는 걸지도 모름 다른 제공자들은 용량 한계에 부딪히고 추론 비용 보조에도 한계가 오는 중임 Google의 전략은 이 모델들을 기존 수십억 사용자에게 확장하고 배포하는 쪽으로 보임 - Gemini가 뒤처진다고 보지는 않음 오히려 최신 GPT-5와 Claude 계열과는 다른 종류의 지능처럼 느껴짐 후자는 점점 생산성과 업무 자동화에 집중하고, 길고 에이전트적인 자기수정 추론 루프에 최적화되어 있음 Gemini는 훨씬 똑똑한 기본 모델 같고, 특히 **Deep Think 모드**에서는 직관이 훨씬 깊게 느껴지지만, 장거리 자기수정형 에이전트 루프는 그만큼 잘하지 못함 몇 달 동안 내 작업 흐름은 창의적 도약과 통찰에는 Gemini를 쓰고, 반복적이거나 정밀한 작업에는 Codex, Claude, GPT-5.5 Pro를 선호하는 방식이었음 - 그 방향으로 모두의 전략이 바뀌는 중 아닌가 싶음 - 로컬 모델을 한동안 쉬다가 최근 **26B A4B 모델**을 RTX 3090에서 vLLM 4비트로 설정했는데, 1000달러 미만 투자로 얻을 수 있는 속도와 품질에 완전히 놀랐음 처음엔 Qwen으로 해봤지만 불안정했고, 사고 흔적이 터무니없이 길었음 - qwen3.6의 초기 양자화본 중 일부는 깨져 있었음 아직도 까다롭긴 하지만 조금만 손봐주면 정말 대단함 **로컬 모델**이 미래라서 멋짐 - turboquant / Q4를 쓰면 3060에도 올라가고, 약 200달러 카드에서 괜찮은 속도인 **40T/s**가 나옴 - A4B 모델은 엄청 빠르고 일반 질의에 매우 좋음 코딩 작업에서는 Qwen 3.6보다 확실히 떨어지지만, 그건 오히려 **Qwen 모델**이 뛰어나다는 뜻에 가까움 - 31B도 조밀 모델치고는 놀라울 만큼 빠름 내 컴퓨터에서는 다른 30B 모델과 비교했을 때 tg가 기대보다 적어도 두 배 빠른데, 아마 **하이브리드 어텐션** 덕분인 듯함 다만 입력 처리 쪽은 조금 더 느림 - 이걸 **LM Studio**에서 동작시키는 데 성공한 사람이 있는지 궁금함 UI에 옵션은 있는데 활성화가 되는 것 같지 않음 - 아직 mlx[1]나 llama.cpp[2]에는 구현되지 않아서 시간이 좀 걸릴 수 있음 [1] [https://github.com/ml-explore/mlx-lm/pull/990]() [2] [https://github.com/ggml-org/llama.cpp/pull/22673]() - 됨 작은 모델이 없으니 **Gemma 희소 모델**을 쓰고 있지 않은지 확인해야 함 그리고 작업 공간에서 이미지 모델을 전부 제거했음 - 보통 LM Studio가 싫어하는 경우는 폴더 안에 **mmproj 파일**이 있을 때임 가끔 이것들을 지우면 표시되기도 함 이 파일들이 어떻게든 시각 기능과 연결되어 있고 추측 디코딩을 막는 듯한데, 이유는 묻지 말아 달라 Gemma에서는 LM Studio보다 llama-server 경로로 추측 디코딩을 쓰는 쪽이 더 잘 됐음 - 다른 모델로는 동작시킨 적 있음 보통 제공자, 양자화 등에서 서로 완벽히 맞아야 함 짝이 맞는 세트를 구하려면 시간이 좀 걸릴 수 있음 - 내 테스트에서는 Gemma 4 31B 모델이 코딩 작업에서 **Ollama의 MLX 러너**를 쓸 때 가장 큰 속도 향상을 보였고, 대략 2배였음 다만 양자화가 수락률을 크게 깎기 때문에 꽤 강력한 Mac이 필요함 다른 세 개의 더 작은 모델은 드래프트 모델 검증 시간이 성능 향상을 대부분 먹어버려서 그만큼 좋지 않았음 더 나은 성능을 낼 수 있는지 아직 조정 중임 Ollama 0.23.1에서 `ollama run gemma4:31b-coding-mtp-bf16`를 실행해 시험해 볼 수 있음 - llama.cpp에 병합되면 정말 빨리 써보고 싶음 내 환경에서는 Gemma 4 26B-A4B가 Qwen3.6-35B-A3B보다 약 **3배 빠르기** 때문에, 여기에 1.5배 가속이 더해진다는 생각만 해도 끌림 드래프트 모델도 시도했지만 성과는 제한적이었고, 더 작은 3B 드래프트 모델과 조밀 14B Ministral 모델도 이미 너무 많은 오버헤드를 만들었음 - vLLM에서 5090을 쓰면 awq 4비트 양자화와 **MTP 추측 디코딩**으로 120~180TPS가 나옴 Gemma4 26B는 같은 양자화에서 200TPS를 넘음 Qwen은 추론 효율이 극도로 낮다는 점도 중요함 사고 사슬이 평균적으로 Gemma보다 약 3배 김 - 이건 운영체제의 **분기 예측** 같은 건가 싶음 다만 확률이 모델 자체에 내장되어 있으니 훨씬 더 신뢰할 수 있는 형태임 - 비슷한 발상이지만 실패 방식이 더 나음 분기 예측 실패는 사이클을 태워버리지만, 여기서 나쁜 추측은 보통 **보너스 토큰**을 못 얻는 정도임 [https://arxiv.org/abs/2211.17192]()