로컬에서 LLM을 구동할 때 가장 힘든 점은 모델의 똑똑함보다도 대기 시간이다. Mac에서 어느 정도 크기가 있는 모델을 실행하면, 토큰이 한 글자씩 띄엄띄엄 나오는 속도가 한계에 부딪히며, 에이전트에게 긴 작업을 맡길수록 체감 성능이 떨어진다. 이를 설정 변경 없이 단축한 것이 6월 30일에 출시된 Ollama v0.31.1이다. 화려한 신규 모델 발표는 아니기에 일본어로는 아직 거의 화제가 되지 않고 있지만, Apple Silicon 위에서 Gemma 4를 사용하는 사람에게는 효과가 매우 큰 변경 사항이므로 그 구조를 깊이 있게 파헤쳐 보고자 한다.

릴리스 노트의 한 문장이 요점을 말하고 있다(원문 그대로).

Gemma 4 is now significantly faster in Ollama on Apple Silicon, generating tokens nearly 90% faster on average across a coding-agent benchmark by leveraging multi-token prediction (MTP).

코딩 에이전트 계열의 벤치마크에서 Apple Silicon 상의 Gemma 4가 평균적으로 약 90%(=대략 1.9배) 더 빠르게 토큰을 생성하게 되었다는 주장이다. Ollama 공식 블로그에 따르면 측정은 실제 코딩 태스크를 수행하는 Aider polyglot 벤치마크에서 이루어졌으며, 심지어 "기본 활성화·설정 불필요·출력은 동일함"이라고 명시되어 있다. 빨라지는데 정답은 한 글자도 변하지 않는다. 이 "공짜로 빨라지는 것"이 어떻게 가능한지가 이번 내용의 흥미로운 지점이다.

참고로 전제 조건을 확인하자. Gemma 4는 Google이 2026년 3월 말에 공개한 Gemma의 최신 세대로, E2B·E4B·12B·26B(MoE)·31B(dense) 등의 계열이 있다(Gemma 릴리스 이력, 모델 개요). Gemma 3의 다음 세대에 해당하는 실재하는 계열이며, 이 부분은 사실이다.

Transformer의 생성은 자기회귀(Autoregressive), 즉 "다음 1토큰을 예측하고, 그것을 입력에 더해 다시 다음을 예측하는" 과정의 반복이다. 1토큰을 낼 때마다 모델의 모든 가중치(Weight)를 다시 읽어 들여 1회 순전파(Forward)를 수행한다. 문제는 이 처리가 계산 그 자체보다 **메모리 대역폭 (Memory Bandwidth)**에서 병목이 발생한다는 점에 있다. 가중치를 VRAM/유니파이드 메모리(Unified Memory)에서 읽어오는 시간이 지배적이기 때문에, GPU의 연산 유닛은 절반은 잠든 채로 다음 1토큰을 기다리게 된다. 로컬 생성이 "빠른 GPU를 탑재해도 생각만큼 성능이 늘지 않는" 이유가 바로 이것이다.

역으로 말하면, 1회의 순전파(Forward)로 여러 토큰을 한꺼번에 확정할 수 있다면 이 대기 시간을 통째로 절약할 수 있다. 이를 위한 장치가 투기적 디코딩 (Speculative Decoding)이며, 이번에 Gemma 4에서 효과를 보고 있는 것도 이 중 하나다.

고전적인 투기적 디코딩은 작고 빠른 "초안 작성용 모델(Draft Model)"을 별도로 준비한다. 초안 모델이 몇 토큰 앞을 한꺼번에 예측하면, 본체 모델이 그것을 1회의 순전파(Forward)로 묶어서 검증하고, 맞는 부분까지를 확정한다. 빠르긴 하지만 어떤 초안 모델을 선택할지가 고민이며, 궁합이 맞지 않으면 수락률(Acceptance Rate)이 떨어진다.

Gemma 4가 하고 있는 방식은 이 초안 작성 역할을 Google이 공식적으로 준비하여 동봉하는 형태다. Google의 발표(2026년 5월 5일)는 "Gemma 4 패밀리를 위한 Multi-Token Prediction (MTP) Drafter를 공개한다"라고 했으며, 이는 본체에 내장하는 것이 아니라 본체와 쌍으로 동작하는 작은 전용 드래프트 모델이라고 명시했다. Ollama 측의 설명도 "Gemma 4에는 본체 옆에서 실행되며 몇 토큰 앞을 제안하는 작고 빠른 드래프트 모델이 부속된다"라는 표현으로 일치한다. Gemma 4의 문서에도 모든 사이즈에 대해 투기적 디코딩용 전용 드래프트 모델이 준비되어 있다고 적혀 있다.

이 부분은 오해하기 쉬우므로 구분해 두어야 한다. "MTP 헤드(Head)를 본체의 가중치에 심어 모델이 스스로 초안이 되는" 타입(DeepSeek-V3나 Qwen3-Next 등이 채택)과, "본체와는 별개의 작은 드래프트 모델을 곁들이는" 타입은 별개다. Sebastian Raschka의 해설이 정리한 MTP는 전자의 내장 헤드형이며, 거기에 Gemma의 이름은 언급되지 않았다. Gemma 4는 후자, 즉 별개의 모델이지만 공식적으로 조정된 초안을 배포하는 방식이라고 이해하는 것이 정확하다. 수동으로 궁합을 찾아야 하는 번거로움이 사라지는 것이 고전적인 투기적 디코딩에 대한 실질적인 이점이다.

| 고전적인 투기적 디코딩 | Gemma 4의 MTP 드래프터 | |
|---|---|
| 초안 출처 | 사용자가 선택하는 별도 모델 | 공식 배포 전용 드래프트 모델 |
| ... |
"예측을 미리 했다고 정확도가 떨어지지 않을까"라고 경계하지만, 그렇지 않다. 핵심은, 초안(draft)은 후보에 불과하며, 채택할지 여부는 본체 모델의 검증이 결정한다는 것이다. 이 검증 단계는 본체가 스스로 토큰별로 생성한 결과와 일치하는지 받아들이거나 거부한다. 맞으면 여러 토큰을 묶어 확정하고, 틀리면 그 직전에서 끊어 일반적인 생성으로 돌아간다. 따라서 속도는 오르내릴 수 있지만, 최종 출력은 초안 없이 실행했을 때와 동일하다. Google이 "출력 품질에도 추론의 논리에도 저하가 없다(no degradation in output quality or reasoning logic)"고, Ollama가 "output is unchanged"라고 단언할 수 있는 것은 이 특성 때문이다. 온도나 샘플링 동작을 변경하는 최적화가 아니다.

여기부터는 나의 견해인데, 9할이라는 숫자가 코딩 에이전트의 벤치마크에서 측정되었다는 점에 의미가 있다. 투기적 디코딩의 속도는 초안이 얼마나 많이 채택되는지(acceptance rate)로 거의 결정된다. 예측하기 쉬운 토큰이 이어질수록, 묶어 확정할 수 있는 횟수가 늘어나 빨라진다. Ollama 블로그도 "코드에서는 특히 예측하기 쉽다. 닫는 괄호, 반복되는 식별자, 정형적인 기술로 가득 차 있다"와 같은 논리를 제시하고 있다. 산문 일본어 채팅보다 채택률이 높게 나올 수 있으므로, 코딩 용도에서 성능 향상이 클 것은 이치에 맞는다. 반대로 시나 자유로운 발상의 글에서는 같은 9할을 내기 어려울 것이다. 자신의 워크로드로 다시 측정해 볼 가치는 있다.

숫자의 출처는 나누어 살펴보고 싶다. Ollama의 "약 9할"은 Apple Silicon 상, 단일 요청 코딩 에이전트 측정치이고, Google이 별도로 제시하는 "최대 3배"는 여러 하드웨어를 아우르는 값이며, Apple Silicon에서는 배치(batch) 4~8의 동시 처리를 통해 최대 약 2.2배로 보고하고 있다. 측정 방식이 다르므로, 같은 전장에서의 수치로 나란히 놓지 않는 것이 좋다.

이것이 Apple Silicon 중심인 이유는, 고속화가 Ollama의 MLX 엔진 측 작업이기 때문이다. Ollama의 기본 엔진은 llama.cpp/GGML 계열이지만, Apple Silicon용으로 별도의 MLX 기반 엔진(런너)을 가지고 있으며, Gemma 4의 MTP 경로는 이 MLX 엔진 위에서 작동한다. v0.31.1의 릴리스 노트에는 "MLX 엔진을 최신 버전으로 업데이트하고 새로운 small-batch matmul 커널을 추가", "MLX 엔진에서의 Gemma 4 MoE 모델 로드를 강화함", "Gemma 4의 MTP 성능을 개선"이라고 적혀 있다. Ollama 블로그에 따르면, 이 소규모 배치용 커널은 그들 스스로 MLX에 기증한 것이며, Gemma 4의 최대 행렬 곱셈(matmul)을 2~2.5배 빠르게 한다고 한다. MTP의 검증은 작은 배치 크기의 행렬 곱셈을 대량으로 수행하기 때문에, 이 소규모 배치용 커널이 효과를 발휘하는 것이다 (여기는 나의 보충 설명이지만) 논리적인 설명이다.

필요한 것은 Ollama를 0.31.1 이상으로 올리고 Gemma 4를 구동하는 것뿐이다. MTP는 기본적으로 활성화되어 있어, 따로 활성화할 플래그는 없다. 모델 태그는 Ollama 라이브러리에서 확인할 수 있으며, gemma4:12b
등 외에도 gemma4:12b-mlx
와 같은 MLX 버전 태그도 나열되어 있다.

# macOS는 Homebrew로 Ollama 본체를 업데이트
brew upgrade ollama
# 버전 확인(0.31.1 이상인지)
...

체감으로 판단하지 말고, --verbose
를 붙여 eval rate(tokens/sec)을 업데이트 전후로 비교하는 것이 정확하다. 코드 생성이나 에이전트적인 작업에 적용해 보면, 채택률이 높은 만큼 차이가 더 명확하게 보인다.

1차 출처는 이 근방이다. 모두 공식적이므로, 대조하여 사실 여부를 확인할 수 있다.

• 릴리스 노트 (Release Notes): https://github.com/ollama/ollama/releases/tag/v0.31.1
• Ollama 공식 블로그: https://ollama.com/blog/faster-gemma-4-mlx-mtp
• Google 공식 블로그 (MTP Drafter): https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/
• Gemma 4 문서: https://ai.google.dev/gemma/docs/core

새로운 모델 출시 소식에 비하면 다소 소박해 보일 수 있으나, MTP Drafter와 같은 런타임 (Runtime) 측면의 최적화는 동일한 모델과 동일한 출력을 유지하면서도 로컬의 처리량 (Throughput)을 높여준다는 점에서 실무적인 효용이 매우 크다. 게다가 구조상 리스크도 적다. 출력이 변하지 않기 때문에 전환에 따른 심리적 비용이 거의 제로에 가깝다. 향후 Gemma 외에도 공식 Drafter나 내장 MTP를 갖춘 모델이 늘어난다면, 이는 로컬 추론 (Local Inference)의 표준 경로가 될 것이며, v0.31.1은 그 입구로서 주목해 둘 만하다.