Gemma 4, MTP 데이터 없이 출시 — 이것이 중요한 이유

Google은 2026년 4월 3일 Gemma 4를 출시했습니다 — 강력한 벤치마크 결과, 멀티모달 기능, 최대 256K 컨텍스트를 갖춘 오픈 웨이트 모델 패밀리입니다. 수치상으로는 인상적인 릴리스입니다. 하지만 몇 시간 만에 커뮤니티는 빠진 것을 발견했습니다: Multi-Token Prediction 헤드가 공개 가중치에서 제거되어 있었던 것입니다.

모델은 MTP로 훈련되었습니다. Google 자체 LiteRT 프레임워크에는 MTP 구성 요소가 포함되어 있습니다. 하지만 모든 사람이 HuggingFace에서 다운로드할 수 있는 버전은? 표준 자기회귀 생성만 가능합니다. 속도 향상도 없고, 추측적 디코딩도 없습니다.

이 글에서는 MTP가 무엇인지, 왜 중요한지, 그리고 이 결정이 자체 하드웨어에서 Gemma 4를 실행하는 모든 사람에게 어떤 의미인지 설명합니다.

Gemma 4란 무엇인가요?

Gemma 4는 Google DeepMind의 최신 오픈 웨이트 모델 패밀리로, Apache 2.0 라이선스로 출시되었습니다. 네 가지 크기로 제공됩니다:

주요 기능으로는 네이티브 멀티모달 지원, 함수 호출, 구조화된 JSON 출력, 140개 이상 언어 훈련이 포함됩니다. 31B 변형은 LMArena 텍스트 리더보드에서 3위를 차지했습니다.

내부적으로 Gemma 4는 여러 아키텍처 혁신을 도입합니다: 교대로 사용되는 로컬 슬라이딩 윈도우 및 글로벌 어텐션 레이어, 비례 RoPE(p-RoPE), Per-Layer Embeddings(PLE), 공유 KV 캐시, 그리고 “Keys equal Values” 메모리 최적화 등입니다.

수치상으로 보면 강력한 릴리스입니다. 문제는 공개 가중치에 포함되지 않은 것입니다.

Multi-Token Prediction이란 무엇인가요?

표준 대형 언어 모델은 한 번에 하나의 토큰씩 텍스트를 생성합니다. 각 토큰에는 모델 전체를 통한 순방향 패스가 필요합니다. 이전 토큰이 완료될 때까지 다음 토큰을 시작할 수 없습니다. 이것이 자기회귀 디코딩이며, 본질적으로 순차적입니다.

**Multi-Token Prediction(MTP)**은 모델에 추가 예측 헤드를 더하여 이를 변화시킵니다. 다음 토큰만 예측하는 대신, 모델은 토큰 N+1, N+2, N+3 등을 단일 순방향 패스에서 모두 예측합니다.

작동 방식은 다음과 같습니다:

1. 훈련 단계: 메인 모델과 함께 추가 경량 예측 헤드가 훈련됩니다. 각 헤드는 서로 다른 미래 위치(1칸 앞, 2칸 앞, 3칸 앞 등)를 예측하도록 학습합니다.
2. 추론 단계: 추가 헤드가 병렬로 “초안” 토큰을 생성합니다. 그런 다음 메인 모델이 단일 순방향 패스에서 모든 토큰을 검증합니다.
3. 검증: 초안 토큰이 메인 모델이 생성했을 것과 일치하면, 모두 한 번에 수락됩니다 — 여러 순차적 디코드 단계를 건너뛰는 것입니다. 초안 토큰이 틀리면 해당 위치로 돌아가 생성을 재개합니다.

이것은 추측적 디코딩과 밀접한 관련이 있지만, 핵심적인 장점이 있습니다: 초안 토큰이 별도의 작은 “초안 모델"이 아닌 모델 자체에서 나온다는 것입니다.

MTP는 얼마나 빠른가요?

속도 향상은 초안 토큰이 정확한 빈도(“수락률”)에 따라 달라집니다. DeepSeek V3가 실제 영향을 보여주었습니다:

수락률 2.4는 평균적으로 메인 모델의 각 순방향 패스가 1개가 아닌 2.4개의 토큰을 생성한다는 의미입니다. 출력은 표준 디코딩과 수학적으로 동일합니다 — 모든 토큰이 검증됩니다. 거의 두 배의 속도로 동일한 품질을 얻을 수 있습니다.

비즈니스 성장 준비가 되셨나요?

오늘 무료 평가판을 시작하고 며칠 내로 결과를 확인하세요.

데모 요청 로그인

Gemma 4에 무슨 일이 있었나

HuggingFace 사용자(@shadowlilac )가 Google의 Gemma 4용 LiteRT 패키지에 MTP 예측 헤드와 다중 토큰 예측 기능이 포함되어 있다는 것을 발견했습니다. 하지만 HuggingFace에 공개된 가중치에는 이 중 어떤 것도 포함되어 있지 않습니다.

MTP 구성 요소는 의도적으로 제거되었습니다:

• 체크포인트에 MTP 헤드 없음
• 모델 설정에 MTP 없음
• 순방향 패스에 MTP 없음

Google의 설명

Google 엔지니어(@srikanta-221 )가 이것이 의도적이었다고 확인했습니다:

공개 모델은 “폭넓은 호환성"을 위해 표준 자기회귀 인터페이스만 노출합니다. MTP 헤드는 모델 설정, 순방향 패스, 체크포인트에서 제외됩니다. 이를 통해 HuggingFace Transformers API와의 호환성을 보장하고 일관된 체크포인트 및 런타임 동작을 유지합니다.

Google은 MTP를 핵심 모델 기능이 아닌 “배포 시점 최적화"로 규정합니다. MTP 예측 헤드는 LiteRT로 내보낸 모델 — Google 자체 온디바이스 추론 프레임워크 — 에서만 유지됩니다.

이것이 문제인 이유

이 설명은 면밀히 살펴보면 설득력이 떨어집니다:

1. 모델은 MTP로 훈련되었습니다. 해당 기능은 존재합니다. 릴리스에서 이를 제거하는 것은 기술적 제한이 아닌 선택입니다.

2. 서드파티 엔진이 구현할 수 없습니다. vLLM, llama.cpp, SGLang 및 기타 추론 프레임워크는 예측 헤드 없이 MTP 기반 추측적 디코딩을 사용할 수 없습니다. 이러한 엔진은 오픈소스 LLM 배포의 대다수를 담당합니다.

3. 사용자는 느린 버전을 받게 됩니다. MTP 없이 Gemma 4는 표준 자기회귀 속도로 실행됩니다. 성능 차이는 이미 실제 사용에서 나타나고 있습니다:

4. 생태계 종속을 만듭니다. Google 자체 LiteRT 프레임워크가 속도 이점을 가집니다. 다른 모든 사용자는 더 느린 모델을 받습니다. “오픈 웨이트” Apache 2.0 릴리스로서 이것은 상당한 비대칭입니다.

추측적 디코딩의 작동 원리 (그리고 MTP가 더 나은 이유)

누락된 MTP 헤드가 왜 중요한지 이해하려면, 추론 최적화의 발전 과정에서 MTP가 어디에 위치하는지 살펴보는 것이 도움이 됩니다.

접근 방식 1: 전통적 추측적 디코딩

별도의 작은 “초안 모델"이 토큰을 제안합니다. 메인 모델이 이를 병렬로 검증합니다. 초안이 정확하면 단계당 여러 토큰이 수락됩니다.

• 장점: 모든 모델 쌍에서 작동
• 단점: 두 번째 모델의 유지 및 로딩 필요; 초안 모델의 품질이 속도 향상을 제한; 추가 메모리 오버헤드

접근 방식 2: MTP (내장 예측 헤드)

메인 모델이 자체 경량 예측 헤드를 가지고 있어 초안 토큰을 생성합니다. 별도 모델이 필요 없습니다.

• 장점: 추가 모델 불필요; 더 긴밀한 통합으로 더 높은 수락률; 더 낮은 메모리 오버헤드
• 단점: 예측 헤드가 릴리스에 포함된 경우에만 작동

MTP가 우수한 이유

MTP 예측 헤드는 메인 모델과 함께 훈련됩니다. 동일한 내부 표현을 공유하고 모델 자체의 토큰 분포를 학습합니다. 이는 일반적으로 외부 초안 모델보다 더 높은 수락률을 생성하며, 이는 검증 단계당 더 많은 토큰이 수락되고 전체적으로 더 빠른 생성을 의미합니다.

예측 헤드는 또한 크기가 작습니다 — 일반적으로 모델 전체 파라미터 수의 1-3%만 추가됩니다. 별도의 초안 모델을 로딩하는 것과 비교하면 메모리 오버헤드는 무시할 수준입니다.

뉴스레터 가입

최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.

이메일 주소

구독

더 넓은 영향

이것은 단순히 Gemma 4만의 문제가 아닙니다. 이 결정은 “오픈” 오픈 웨이트 릴리스가 실제로 얼마나 개방적인지에 대한 선례를 만듭니다.

사용자가 잃는 것:

• 모든 서드파티 추론 엔진에서의 MTP 기반 추측적 디코딩
• MTP 헤드를 미세 조정하거나 실험할 수 있는 능력
• Google 자체 배포 도구와의 성능 동등성

사용자가 여전히 가지는 것:

• 기본 모델 가중치 (진정으로 우수한 품질)
• 별도 초안 모델을 사용한 전통적 추측적 디코딩 (vLLM 이슈 #38893 에서 Gemma 4용 Eagle3 지원 추적 중)
• 표준 양자화 및 최적화 기술

커뮤니티 반응은 직접적이었습니다. 24시간 내 합의는 Gemma 4의 벤치마크 결과가 경쟁력 있다는 것 — Qwen 3.5와 동등하거나 약간 뒤처지는 수준 — 이지만, 제품이 “완성되지 않았다"는 것이었습니다. 속도, 안정성, 도구 지원이 필요합니다. 추가 문제로는 HuggingFace Transformers에서 초기에 Gemma 4 아키텍처 지원이 부족했던 것, PEFT가 새로운 레이어 유형을 처리하지 못하는 것, Mac 사용자가 대형 모델 로딩 시 충돌을 경험하는 것 등이 있습니다.

무엇을 할 수 있나요?

배포를 위해 Gemma 4를 평가하고 있다면, 다음과 같은 실용적 옵션이 있습니다:

전통적 추측적 디코딩을 사용하세요. 외부 초안 모델은 여전히 Gemma 4 추론을 가속화할 수 있습니다. vLLM과 같은 프레임워크가 Gemma 4용 Eagle3 추측적 디코딩 지원을 추가하고 있습니다. 내장 MTP만큼의 속도 향상은 아니지만, 아무것도 없는 것보다 낫습니다.

속도가 중요한 워크로드에는 대안을 고려하세요. Qwen 3.5는 동등한 하드웨어에서 상당히 더 높은 초당 토큰 수를 제공합니다. 추론 속도가 가장 중요한 제약이라면, Qwen이 현재 더 나은 속도 대 품질 비율을 제공합니다.

커뮤니티 해결 방법을 주시하세요. LiteRT 내보내기에는 MTP 헤드가 포함되어 있습니다. 연구자들이 이를 추출하여 HuggingFace 가중치에 다시 연결하는 방법을 찾을 수 있지만, Google은 공식적으로 이 경로를 지원하지 않고 있습니다.

피드백을 제공하세요. Google 엔지니어들이 HuggingFace 토론 스레드를 적극적으로 모니터링하고 있습니다. MTP 헤드 공개에 대한 명확하고 기술적인 요청은 영향력이 있습니다.

결론

Gemma 4는 진정한 아키텍처 혁신과 강력한 벤치마크 결과를 갖춘 유능한 모델 패밀리입니다. 공개 릴리스에서 MTP 예측 헤드를 제거하면서 Google 자체 LiteRT 프레임워크에는 유지하기로 한 결정은 오픈 웨이트의 “오픈"을 훼손합니다.

MTP는 사소한 최적화가 아닙니다. 출력 품질에 전혀 영향 없이 1.5~2배의 추론 속도 향상을 제공할 수 있습니다. 모델이 명확히 MTP로 훈련되었음에도 공개 가중치에서 이를 보류하는 것은 이중 체제를 만듭니다: Google 도구를 위한 빠른 추론, 그 외 모든 사용자를 위한 느린 추론.

오픈소스 AI 커뮤니티에게 메시지는 명확합니다: 벤치마크만이 아니라 실제로 가중치에 무엇이 포함되어 있는지 확인하세요. 오픈 라이선스가 항상 오픈 릴리스를 의미하지는 않습니다.

FlowHunt 로 제작되었습니다. 오픈소스 AI의 최신 개발 소식을 블로그 에서 확인하세요.