로컬 LLM 추론 속도 2배, Gemma 4 MTP가 바꾼 게임의 룰

로컬 모델을 돌릴 때마다 한 글자씩 느릿느릿 나오는 커서를 멍하니 바라보는 건 여간 고역이 아니다. 그런데 드디어 기다리던 게 터졌다. llama.cpp에 Gemma 4 MTP(Multi-Token Prediction) 지원 PR이 머지되면서 추론 속도가 말 그대로 두 배로 뛰었다. RTX 5090 기준으로 초당 55~60토큰 나오던 게 100+ t/s를 찍어버린다(이 정도면 글자가 화면에 쏟아지는 수준이다).

MTP가 뭔데, 왜 지금 설레는가

Multi-Token Prediction은 한 번의 forward pass에서 여러 토큰을 동시에 예측하는 기법이다. 기존 autoregressive 방식은 토큰을 하나씩 순차적으로 생성해야 해서 병목이 명확했다. 생성 속도가 모델의 연산량이 아니라 메모리 대역폭에 묶이는 구조적 한계, 이른바 “메모리 바운드” 문제다.

MTP는 이 병목을 speculative decoding의 변형으로 돌파한다. 작은 보조 모델(draft model)이 먼저 여러 토큰을 “추측”하고, 메인 모델이 이를 한 번에 검증하는 방식. 틀린 토큰은 거기서 잘리지만, 맞춘 토큰은 한 번에 확보된다. 추측이 정확할수록 거의 배치 처리에 가까운 효율이 나온다.

Gemma 4는 설계 단계부터 MTP를 염두에 두고 훈련되었다. 즉, 별도의 draft 모델을 외부에서 가져올 필요 없이 모델 자체에 MTP 헤드가 내장되어 있다. 이것이 구현의 복잡도를 크게 낮추면서도 정확도를 유지하는 핵심이다.

실제 벤치마크: 숫자로 말한다

r/LocalLLM에서 가장 주목받은 테스트 환경은 RTX 5090이었다.

지표	MTP 적용 전	MTP 적용 후
생성 속도	55-60 t/s	100+ t/s
프롬프트 처리	동일	동일
VRAM 사용량	약간 증가	QAT GGUF로 최적화

속도 향상이 체감 수준이라는 점이 중요하다. 60 t/s도 나쁘지 않지만, 100 t/s가 넘어가면 일반적인 타이핑 속도보다 빠르게 응답이 화면에 채워진다. “기다림”이라는 인지적 비용이 사라지는 임계점이다(인간의 인내심은 생각보다 훨씬 짧다).

주의할 점도 있다. MTP의 속도 이득은 모델의 작은 크기일수록, batch size가 1일수록 극대화된다. 이미 배치 처리로 GPU를 꽉 채우는 서버 환경에서는 이득이 미미할 수 있다. MTP의 진정한 무대는 개인 로컬 환경이라는 뜻이다.

GGUF 생태계와의 만남

llama.cpp 구현에서 핵심 역할을 한 것은 QAT(Quantization-Aware Training) 기반 GGUF 보조 모델이다. Gemma 4의 MTP 헤드를 양자화된 GGUF 포맷으로 함께 제공함으로써, 추가 메모리 부담을 최소화하면서 MTP 기능을 활성화할 수 있게 했다.

다만 커뮤니티에서 GGUF 파일 네이밍 컨벤션에 대한 혼란도 있었다. 어떤 파일이 MTP 지원용인지, 일반 모델과 어떻게 구분하는지 초기 가이드가 불충분했던 탓. 현재는 llama.cpp 문서와 Hugging Face 모델 카드에 명시되어 정리된 상태다.

사용법 자체는 간단하다. 기존 llama.cpp 실행에 MTP용 GGUF 모델 경로만 추가하면 된다.

# 기본 모델 + MTP draft 모델 실행 예시
./llama-server \
  -m gemma-4-27b-it-Q4_K_M.gguf \
  --mlock \
  --parallel 1 \
  --draft gemma-4-27b-it-mtp-draft-Q4_K_M.gguf \
  --draft-n 5

--draft 플래그로 보조 모델을 지정하고, --draft-n으로 한 번에 추측할 최대 토큰 수를 설정한다. 5가 일반적인 기본값이며, 높일수록 잠재적 속도 이득은 커지지만 검증 실패 시 버려지는 연산도 늘어난다.

왜 지금 주목해야 할까

세 가지 맥락에서 이 업데이트의 의미가 남다르다.

첫째, 로컬 LLM의 실용성 임계점 이동. 100 t/s는 단순한 숫자가 아니다. 실시간 코드 보완, 대화형 에이전트, 오프라인 개발 보조 도구 등 “로컬에서 돌리기엔 느리다”고 미뤄뒀던 사용 사례들이 당장 가능해진다. 클라우드 API 비용이 눈덩이처럼 불어나는 상황에서, 로컬의 성능 한계를 돌파하는 것은 단순한 기술적 성취를 넘어 비용 구조의 재편을 의미한다.

둘째, 모델 아키텍처와 추론 엔진의 공진화. MTP는 모델 설계 단계에서 포함된 기능이며, llama.cpp가 이를 추론 수준에서 최적화했다. 이런 “모델-엔진 공설계” 패턴이 앞으로 로컬 LLM 생태계의 표준이 될 가능성이 높다. Qwen, Mistral 등 다른 모델 패밀리도 유사한 speculative decoding 지원을 준비 중이라는 소식이다.

셋째, 오픈소스 생태계의 속도. Gemma 4 발표 후 MTP 지원이 llama.cpp에 병합되기까지 걸린 시간은 짧았다. 커뮤니티 주도 개발이 클로즈드 소스 대비 가질 수 없는 장점—즉각적인 피드백 루프와 병렬 구현 시도—이 빛을 발한 사례다.

정리

Gemma 4 MTP의 llama.cpp 지원은 “로컬 LLM은 느리다”는 오래된 편견에 대한 가장 구체적인 반박이다. 두 배의 속도 향상은 마케팅 수사가 아니라 실측 데이터이며, 적용 방법도 기존 워크플로에 최소한의 변경만 요구한다.

클라우드 API 의존도를 줄이고 싶은 개발자, 오프라인 환경에서 AI를 활용해야 하는 연구자, 혹은 단순히 “내 GPU를 더 똑똑하게 쓰고 싶은” 사람 모두에게 MTP는 당장 시도해볼 가치가 있다. 2026년 로컬 LLM의 화두가 “돌릴 수 있느냐”에서 “얼마나 빠르게, 얼마나 똑똑하게 돌리느냐”로 넘어가는 분기점에 서 있는 것이다.