TL;DR
LLaMA.cpp의 Multi-Token Prediction(MTP) 구현으로 Gemma 4 26B IT(assistant) 추론 속도가 97 → 138 tokens/s로 약 40% 향상되었다. MTP는 단일 포워드 패스에서 여러 토큰 후보를 드래프트하는 방식으로 디코딩 병목을 완화한다. 단, 현재 결과는 MacBook Pro M5Max 단일 환경에서만 검증된 수치임을 감안해야 한다.
배경: LLM 추론의 구조적 병목
LLM 추론에서 디코딩 단계는 본질적으로 순차적(autoregressive)이다. 토큰 하나를 생성하기 위해 전체 모델을 한 번 포워드 패스해야 하므로, 모델이 클수록 메모리 대역폭 한계에 직접적으로 부딪힌다. 이 문제를 완화하는 대표적인 접근이 Speculative Decoding 계열 기법이며, Multi-Token Prediction은 그 변형 중 하나다.
Meta의 Better & Faster Large Language Models via Multi-Token Prediction(2024)에서 제안된 MTP는 학습 단계부터 모델이 여러 미래 토큰을 동시에 예측하도록 훈련 [추정]한다. 이를 LLaMA.cpp에 이식함으로써, GGUF 포맷으로 양자화된 Gemma 4 assistant 모델에서도 해당 이점을 활용할 수 있게 되었다.
핵심 메커니즘: Draft Token과 Verification
MTP의 동작 원리는 다음 두 단계로 요약된다.
graph LR
A[입력 컨텍스트] --> B[Draft Head: k개 후보 토큰 예측]
B --> C{Main Model 병렬 검증}
C -- 수락: p_draft ≤ p_main --> D[토큰 스트림에 추가]
C -- 거부: p_draft > p_main --> E[마지막 수락 토큰부터 재샘플링]
D --> F[다음 스텝]
E --> F
- Draft 단계: 경량 Draft Head가 현재 컨텍스트를 기반으로 k개의 후보 토큰 시퀀스를 생성한다.
- Verification 단계: 메인 모델이 해당 시퀀스를 병렬로 검증한다. 각 Draft 토큰 위치에서 Draft Head의 확률 분포와 메인 모델의 확률 분포를 비교하여,
p_draft(x) ≤ p_main(x)를 만족하는 토큰은 수락하고 그렇지 않은 경우1 - p_main(x)/p_draft(x)확률로 거부한다(Speculative Sampling 기준). 거부 지점부터는 메인 모델 분포로 재샘플링한다.
기존 Speculative Decoding과의 차이점은 별도의 소형 Draft 모델을 두는 것이 아니라, 메인 모델 자체가 MTP 헤드를 내장하고 있다는 점이다. Gemma 4 assistant 모델의 경우 학습 시 MTP 목표 함수가 포함되어 있어 Draft 품질이 외부 모델 대비 높다.
# LLaMA.cpp Python 바인딩(llama-cpp-python) 사용 예시
# ※ MTP 기능은 llama-cpp-python의 llama.cpp 백엔드 버전에 따라
# 지원 여부가 다르며, 현재(2025년 5월 기준) 공식 Python 바인딩에서
# MTP를 직접 활성화하는 전용 파라미터는 안정 릴리스에 포함되지 않았다.
# MTP를 활용하려면 llama.cpp CLI(llama-cli, llama-server)를 직접 사용하거나,
# MTP 지원 커밋이 포함된 빌드를 직접 컴파일해야 한다.
#
# llama-cli 사용 예시 (MTP 활성화):
# ./llama-cli -m gemma-4-27b-it-q4_k_m.gguf \
# --draft-max 4 \ # Draft 토큰 최대 개수(k)
# -ngl 99 \ # GPU 레이어 오프로드
# -p "Write a Python program to find the nth Fibonacci number"
#
# llama-cpp-python에서 실험적으로 접근하는 경우:
from llama_cpp import Llama
llm = Llama(
model_path="gemma-4-27b-it-q4_k_m.gguf",
n_ctx=4096,
n_gpu_layers=-1, # GPU 오프로드 전량
# MTP 내장 헤드 사용 시 별도 draft_model 불필요.
# draft_max, draft_min 등 MTP 관련 파라미터는
# 현재 Python 바인딩 공식 API에 미노출 상태이므로
# 최신 llama-cpp-python GitHub 이슈 및 CHANGELOG 확인 필요.
)
response = llm(
"Write a Python program to find the nth Fibonacci number using recursion",
max_tokens=512,
temperature=0.7,
)
print(response["choices"][0]["text"])
실측 수치는 다음과 같다.
| 구분 | 속도 |
|---|---|
| 기존 LLaMA.cpp (Gemma 4 26B IT) | 97 tokens/s |
| MTP 적용 후 | 138 tokens/s |
| 향상률 | 약 40% |
테스트 환경: MacBook Pro M5Max, 프롬프트: Fibonacci 재귀 구현 요청
한국 개발 환경과의 연결 포인트
카카오, 네이버, 토스 등 국내 주요 테크 기업에서는 자체 LLM 또는 오픈소스 모델을 온프레미스·엣지 환경에서 서빙하는 사례가 늘고 있다. 특히 비용 절감과 데이터 보안을 이유로 클라우드 API 대신 로컬 추론을 선택하는 팀에서 LLaMA.cpp 기반 스택은 현실적인 선택지다.
MTP가 안정화될 경우, 동일한 하드웨어 예산 내에서 처리량을 40% 가까이 끌어올릴 수 있다는 점은 온콜 비용이나 GPU 서버 대수에 직접적인 영향을 준다. 국내 MLOps 환경에서 GGUF 포맷 기반 서빙 파이프라인을 운영 중이라면, 해당 기능이 메인 브랜치에 병합되는 시점을 추적해 두는 것이 실질적인 이득으로 이어질 수 있다.
한계와 유의사항
현재 공개된 결과에는 몇 가지 명확한 제약이 있다.
- 단일 하드웨어 환경: MacBook Pro M5Max에서만 측정되었다. CUDA 기반 서버 GPU(A100, H100 등)나 AMD ROCm 환경에서의 동작은 별도 검증이 필요하다.
- 단일 프롬프트: Fibonacci 재귀 구현이라는 코드 생성 태스크 하나만 테스트되었다. 긴 문서 요약, 다국어 처리, 수학 추론 등 다른 태스크에서의 수락률(acceptance rate)과 속도는 미확인이다.
- 수락률 데이터 전면 부재: MTP의 실질적 효율은 Draft 토큰이 얼마나 자주 수락되는지에 달려 있다. 그런데 원문 출처가 Reddit 비디오(v.redd.it) 형식이어서 텍스트 기반 벤치마크 상세를 직접 확인할 수 없으며, Fibonacci 태스크에서의 수락률조차 공개되지 않았다. 따라서 40% 향상이 높은 수락률 덕분인지, 아니면 검증 병렬화 자체의 효과인지 현재로서는 구분이 불가능하다. 다른 태스크에서 수락률이 낮아질 경우 성능 향상 폭이 크게 줄어들 수 있다.
- 원문 검증의 한계: 출처 링크(v.redd.it)가 비디오 형식이므로 독자가 직접 수치를 텍스트로 재확인하기 어렵다. 벤치마크 방법론, 반복 횟수, 워밍업 여부 등 측정 조건의 상세가 공개되지 않았다.
- 모델 한정: Gemma 4 assistant 계열의 MTP 내장 모델에 한정된 결과다. MTP 헤드가 없는 모델에는 적용되지 않는다.
결론
LLaMA.cpp의 Multi-Token Prediction 구현은 로컬 추론 생태계에서 의미 있는 진전이다. 별도의 Draft 모델 없이 메인 모델 내장 헤드만으로 40% 처리량 향상을 달성했다는 점은 운영 복잡도를 낮추면서 성능을 개선하는 방향으로, 실용적 가치가 높다.
다만 단일 환경·단일 태스크에서 도출된 수치를 일반화하는 데는 신중해야 한다. 원문 자체가 비디오 형식이어서 상세 벤치마크를 독립적으로 검증하기 어렵고, 수락률 등 핵심 지표가 공개되지 않은 상태다. 프로덕션 적용을 검토한다면 자신의 워크로드와 하드웨어에서 직접 벤치마크하는 과정이 선행되어야 한다. 해당 기능의 메인 브랜치 통합 여부와 진행 상황은 LLaMA.cpp GitHub 저장소에서 확인할 수 있다.
출처: Reddit – Multi-Token Prediction for LLaMA.cpp, Gemma 4 speedup by 40% (비디오 형식, 텍스트 벤치마크 상세 미포함)
<!– CHANGES: 수정 내용 요약
- [사실정확성] 모델명 표기 통일
- TL;DR, 본문, 한계 섹션 전체에서 ‘MacBook Pro M5 Max(공백 포함)’ → ‘MacBook Pro M5Max’로 통일 (원문 표기 준수)
- ‘Apple Silicon M5 Max’ → ‘MacBook Pro M5Max’로 수정 (원문 모델명 직접 사용)
-
‘Gemma 4’ → ‘Gemma 4 assistant’ 또는 ‘Gemma 4 26B IT’로 수정하여 assistant 버전 명시 누락 해소
-
[기술깊이] Python 코드 예시 및 MTP 활성화 방법 구체화
- ‘파라미터로 제어’라는 모호한 설명 대신, 현재 llama-cpp-python 공식 API에 MTP 전용 파라미터가 안정 릴리스에 미포함임을 명시
- llama.cpp CLI에서 MTP를 활성화하는 실제 플래그(–draft-max 등) 예시 추가
-
‘버전에 따라 상이’라는 회피성 주석을 구체적인 현황 설명으로 교체
-
[기술깊이] Mermaid 다이어그램 검증 로직 보강
- 단순 ‘수락/거부’ 분기에서 Speculative Sampling 기준 수식(p_draft ≤ p_main, 거부 확률 1 – p_main/p_draft) 명시
-
‘재생성’ → ‘재샘플링’으로 용어 정확화
-
[한계 섹션 자기모순 해소] 수락률 데이터 부재 항목 재작성
- Fibonacci 태스크에서의 수락률도 미공개임을 명시하여 모순 제거
- 40% 향상의 원인(수락률 vs. 병렬화 효과)을 구분 불가능한 상태임을 명확히 기술
-
수락률 저하 시 성능 변동 가능성 경고 추가
-
[한계 섹션] Reddit 비디오 링크 한계 명시 추가
- ‘원문 검증의 한계’ 항목 신규 추가: 비디오 형식으로 인한 텍스트 재확인 불가, 측정 조건 상세 미공개 명시
- 결론 및 출처 표기에도 ‘비