2026-06-06 — 회 조회

Gemma 4 멀티 토큰 예측이 llama.cpp에 도착: 자기 추측 디코딩이 로컬 추론에서 주류로

llama.cpp는 2026년 5월에 네이티브 멀티 토큰 예측(MTP) 추측 디코딩을 병합했으며(PR #22673), Qwen3.6-27B에서 약 72%의 초안 수락률로 단일 스트림 생성이 약 2.4배 빨라졌다고 보고했다. 초안 헤드는 동일한 GGUF에서 로드되며 자체 KV-cache를 갖는다. 2026년 6월 6일, 후속 Gemma 4 MTP PR(#23398)이 검토 준비 완료로

무엇이 출시되었나

llama.cpp는 이제 멀티 토큰 예측(MTP) 추측 디코딩을 네이티브로 지원한다. 핵심 인프라는 PR #22673(“llama + spec: MTP Support”)에서 안착했으며, 2026년 5월 4일에 열려 2026년 5월 16일에 병합되었다. 2026년 6월 6일, 후속 Gemma 4 MTP 작업(PR #23398)이 검토 준비 완료로 표시되어 동일한 메커니즘을 Google의 Gemma 4 제품군으로 확장했다.

로컬 사용자에게 핵심은 단일 스트림 지연이다. 전통적인 추측 디코딩은 별도의 작은 초안 모델을 실행해 다음 몇 개의 토큰을 추측하고 이를 큰 모델이 한 번의 패스로 검증함으로써 생성을 가속한다. MTP는 그 아이디어를 모델 산출물 자체에 접어 넣는다: 경량 예측 헤드가 각 순전파마다 여러 토큰을 제안하므로, 별도의 초안 모델을 조달하고 크기를 맞추고 정렬할 필요 없이 추측 디코딩의 가속을 얻는다.

병합에서 나온 수치

병합된 Qwen3.6-27B 경로에서 PR #22673은 초안 토큰 3개로 약 2.4배의 벽시계 속도 향상(83.8초 대 201초 기준)을 수락률 72.18%로, 그리고 초안 토큰 2개로 약 2.2배를 수락률 82.58%로 보고한다. 또한 Qwen3.6-35BA3B MoE 변형에서도 검증되었다. 이 설계는 동일한 GGUF 파일에서 MTP 헤드를 로드하므로 추가로 배포할 것이 없으며, 자체 컨텍스트와 KV-cache를 유지한다.

Gemma 4 PR은 이를 다른 계통으로 밀어붙인다. 밀집형 31B 모델에서 2배가 넘는 향상을 보고하며, 수락률은 구성에 따라 약 43%에서 70% 사이이고, 한 예에서는 약 40 tok/s에서 약 100 tok/s로 이동한다. Q8 양자화 실행은 약 1.74배에서 1.97배에 안착한다. 이 PR은 31B와 26B-A4B 변형을 다루며 더 작은 E4B와 E2B는 제외한다.

모델 / PR	초안 토큰	수락률	속도 향상
Qwen3.6-27B (PR #22673, merged)	3	~72%	~2.4x
Qwen3.6-27B (PR #22673, merged)	2	~83%	~2.2x
Gemma 4 dense 31B (PR #23398, in review)	varies	~43-70%	over 2x
Gemma 4 31B Q8 (PR #23398, in review)	varies	varies	~1.74-1.97x

한 가지 미묘한 점: Gemma는 방식이 다르다

알아둘 가치가 있는 아키텍처 분기가 있다. Qwen 스타일 경로는 동일한 가중치 안에 패키징된 MTP 헤드를 사용한다. 반면 Gemma 4는 Gemma 4 자체 출력 분포에 정렬된, Google이 훈련한 별도의 “assistant” / drafter 모델(Gemma4AssistantForCausalLM 클래스)과 로더에서 커스텀 매핑이 필요한 새로운 스케일링 텐서를 제공한다. 두 접근 방식 모두 동일한 목표, 즉 검증기가 거의 거부하지 않는 높은 수락률을 추구하지만, 배관과 가져오는 파일은 다르다. 별도의 libllama MTP API(PR #18886)는 여전히 초안 단계여서, 서버 경로는 사용 가능하더라도 이에 대한 공개 C API는 아직 확정되지 않았다.

로컬 장비에 왜 중요한가

수락률이 전부이며, 그것은 워크로드 의존적이다. 코드와 구조화된 출력 같은 예측 가능한 텍스트는 이 범위의 높은 끝에서 수락된다. 자유형 산문은 덜 수락되며 실현되는 속도 향상도 그에 따라 떨어진다. PR 밖의 커뮤니티 보고는 짧고 다양한 생성에 대해 1.7배에서 1.9배에 더 가깝게 모이며, 이는 배치 코드 완성이 아니라 대화형 채팅에 대한 정직한 기대치다. 이 이득은 진짜이지만 한 번에 하나의 스트림에 대한 지연 이득이지, 연속 배칭이 이미 GPU를 포화시키는 바쁜 다중 사용자 서버에 대한 처리량 이득이 아니다.

실무자 노트

로컬에서 단일 사용자 코딩 어시스턴트를 운영한다면, 이것이 지금 얻을 수 있는 가장 저렴한 속도 향상이다: 최근 llama.cpp 빌드를 가져오고, MTP 지원 GGUF(오늘은 Qwen3.6, #23398이 안착하면 Gemma 4)를 사용하며, 초안 토큰 2-3개로 시작하라. 마케팅 배수가 아니라 보고된 수락률을 진짜 벤치마크로 주시하고, 초안 토큰 수를 프롬프트에 맞춰 조정하라. 낮은 수락률의 산문에서 초안이 너무 많으면 이득을 지울 수 있다. 기능이 활성화되었다고 가정하기 전에 빌드가 실제로 MTP 서버 플래그를 노출하는지 검증하라. 이 기능은 최근의 것이고 C API는 여전히 유동적이기 때문이다.

충분히 고려되지 않은 관점

모두가 속도 향상 배수를 인용하지만, 전략적 변화는 누가 초안 모델을 소유하느냐에 있다. Gemma 4의 assistant 변형처럼 별도로 훈련된 drafter가 있으면 모델 공급업체가 수락 품질을 통제하게 되며, 이는 조용히 해자가 될 수 있다: 정확한 출력 분포에 정렬된 1차 drafter는 커뮤니티가 덧붙인 어떤 범용 소형 모델보다 우수할 것이다. 이는 한때 커뮤니티의 만지작거리는 공간이었던 최적화를 집중시키며, 자가 호스팅 사용자에게 더 조용한 질문을 제기한다. 즉, 공급업체가 강력한 베이스 모델을 의도적으로 평범한 drafter와 함께 출시하고 빠른 경로를 다른 라이선스나 출시 주기 뒤에 둘 수 있는가 하는 질문이다.