# Gemma 4 MTP 은폐후 커뮤니티가 파헤치고, Google이 뒤늦게 우회 지원

> Clean Markdown view of GeekNews topic #29219. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29219](https://news.hada.io/topic?id=29219)
- GeekNews Markdown: [https://news.hada.io/topic/29219.md](https://news.hada.io/topic/29219.md)
- Type: news
- Author: [darjeeling](https://news.hada.io/@darjeeling)
- Published: 2026-05-06T13:00:21+09:00
- Updated: 2026-05-06T13:00:21+09:00
- Original source: [reddit.com](https://www.reddit.com/r/LocalLLaMA/comments/1shgo1x/update_on_gemma_4_having_mtp_reverse_engineering/)
- Points: 6
- Comments: 2

## Topic Body

Google이 MTP로 학습시킨 Gemma 4에서 해당 기능을 공개 배포판에서 제거했다가, 커뮤니티의 리버스 엔지니어링으로 들통난 후 외부 보조 모델 형태로 뒤늦게 지원을 시작했다.  
  
  
오픈소스 개발자들이 Google이 배포한 모바일/엣지 디바이스용 포맷인 `.litertlm`(TFLite 기반) 파일을 분석하던 중 충격적인 사실을 발견했다. HuggingFace에 공개된 표준 모델 가중치에는 존재하지 않는 **MTP(Multi-Token Prediction, 다중 토큰 예측) 아키텍처**가 엣지용 컴파일 파일에만 포함되어 있었던 것이다.  
  
이를 공개적으로 문제 제기하자, Google 측은 사실을 시인하며 이렇게 답했다:  
  
> *"MTP 관련 예측 헤드는 HuggingFace Transformers API와의 호환성을 위해 공개 모델에서 의도적으로 제외했다. LiteRT 런타임에는 온디바이스 성능 향상을 위해 보존했다."*  
  
##### MTP란 무엇인가  
  
일반 LLM은 토큰을 하나씩 순차적으로 생성한다. MTP는 한 번의 forward pass에서 여러 토큰을 동시에 예측하는 기법으로, 투기적 디코딩(Speculative Decoding)과 결합하면 **출력 품질 변화 없이** 추론 속도를 크게 높일 수 있다. 이론적으로 손실이 없는(lossless) 최적화다.  
  
##### 커뮤니티의 리버스 엔지니어링 시도  
  
원 발견자가 `.litertlm` 파일에서 여러 `.tflite` 파일 추출에 성공하고, HuggingFace에 추출 파일과 재현 절차를 공개하며 C++ 가능자들의 협력을 요청했다. 이후 커뮤니티 기여자들이 본격적인 리버스 엔지니어링에 착수했다.  
  
**기술적 난관**: TFLite 커널 구조가 극악이었다. 1024-wide 어텐션 벡터를 INT8로 양자화 → INT8 가중치와 곱셈 → 결과를 재양자화 → 다시 역양자화하는 구조였다.  
  
**결과**: 수일간의 집중 작업 끝에 다음을 재구성하는 데 성공했다:  
- GQA(Grouped-Query Attention) 구조 및 외부 KV 캐시 매핑  
- 슬라이딩 로컬 윈도우 동작  
- pre_project / q_proj / MLP / o_proj / post_project 양자화 경로  
- 부분 RoPE 동작  
- **end-to-end TFLite 패리티 20/20 top-1 매치 달성**  
  
라이선스는 Apache 2.0이라 법적 문제는 없다.  
  
##### 실제 성능: 얼마나 빠른가  
  
커뮤니티 실측 결과(Strix Halo 기준):  
  
| 작업 | 기존 | MTP 적용 후 |  
|---|---|---|  
| 코드 생성 | 8 tps | 25 tps (**약 3x**) |  
| 일반 글쓰기 | 7~8 tps | 11~14 tps |  
  
기존 LLaMA/Qwen3 계열의 투기적 디코딩이 보통 1.5~1.7x, 최대 2x 수준인 것과 비교하면 코딩에서 3x는 이례적인 수치다. 코드 생성 특성상 반복적인 보일러플레이트가 많아 드래프트 토큰 수락률이 높기 때문으로 분석된다.  
  
##### 커뮤니티의 반응과 의혹  
  
비판은 크게 두 방향으로 쏟아졌다.  
  
**① 미문서화(Undocumented) 비판**: MTP로 학습시켜 놓고 공개 배포판에서 고의로 제거하면서 아무런 언급도 없었다는 점.  
  
**② 상업적 의도 의혹**: *"로컬에서 구동되는 오픈소스 31B 모델이 너무 빨라지면 자사 상용 API(Flash Lite 등)의 경쟁력을 위협하기 때문에 의도적으로 너프했다"*는 주장. 유출 후 삭제된 122B 모델 역시 같은 맥락으로 거론됐다.  
  
##### Google의 구조적 선택  
  
| 배포 채널 | MTP 포함 여부 |  
|---|---|  
| HuggingFace 공개 가중치 | ❌ 의도적 제거 |  
| LiteRT (엣지/모바일) | ✅ 내장 |  
| gemma4_assistant (5/5 신규) | ✅ 외부 보조 모델로 우회 지원 |  
  
##### Google의 뒤늦은 공식 대응 (5월 5~6일)  
  
커뮤니티 압박이 거세지자 Google은 5월 5일 **`gemma4_assistant`** 보조 모델을 HuggingFace에 별도 릴리스하고, 공식 블로그를 통해 Gemma 4 MTP 드래프터를 발표했다. 본래 모델 안에 있어야 할 기능을 외부 모델로 떼어내 우회 지원하는 형태다.  
  
- **속도**: 품질 저하 없이 최대 3배 추론 속도 향상  
- **어시스턴트 모델**: 약 500M 파라미터 수준의 경량 드래프터  
- **사용법**: `generate()` 함수의 `assistant_model=` 인자로 넘기기만 하면 작동. 커스텀 MTP 구현 불필요  
- **지원 환경**: HuggingFace Transformers, vLLM, MLX(Apple Silicon), LiteRT-LM  
  
---  
  
> 💡 **한 줄 요약**: Google이 MTP로 학습시킨 Gemma 4에서 해당 기능을 공개 배포판에서 제거했다가, 커뮤니티의 리버스 엔지니어링으로 들통난 후 외부 보조 모델 형태로 뒤늦게 우회 지원을 시작했다.

## Comments



### Comment 56931

- Author: clastneo
- Created: 2026-05-06T13:43:59+09:00
- Points: 1

122B모델이 있었다니 ㄷㄷ

### Comment 56929

- Author: darjeeling
- Created: 2026-05-06T13:12:46+09:00
- Points: 1

https://huggingface.co/google/gemma-4-31B-it-assistant  
  
https://github.com/huggingface/transformers/blob/main/src/transformers/models/gemma4_assistant/modeling_gemma4_assistant.py  
  
  
https://github.com/Blaizzy/mlx-vlm/pull/1112  
  
https://huggingface.co/collections/mlx-community/gemma-4-assistant-mtp