Gemma 4, MTP Verileri Olmadan Yayınlandı — İşte Bunun Neden Önemli Olduğu

Google, 3 Nisan 2026’da Gemma 4’ü yayınladı — güçlü karşılaştırma sonuçları, çok modlu yetenekler ve 256K’ya kadar bağlam uzunluğu sunan bir açık ağırlıklı model ailesi. Kağıt üzerinde etkileyici bir sürüm. Ancak saatler içinde topluluk eksik bir şey keşfetti: Multi-Token Prediction başlıkları halka açık ağırlıklardan çıkarılmıştı.

Model MTP ile eğitilmişti. Google’ın kendi LiteRT çerçevesi MTP bileşenlerini içeriyor. Ama herkesin HuggingFace’den indirebileceği sürüm? Yalnızca standart otoregresif üretim. Hız artışı yok. Spekülatif kod çözme yok.

Bu yazı, MTP’nin ne olduğunu, neden önemli olduğunu ve bu kararın Gemma 4’ü kendi donanımında çalıştıran herkes için ne anlama geldiğini açıklıyor.

Gemma 4 Nedir?

Gemma 4, Google DeepMind’ın Apache 2.0 lisansı altında yayınlanan en son açık ağırlıklı model ailesidir. Dört boyutta sunulmaktadır:

Temel yetenekler arasında doğal çok modlu destek, fonksiyon çağırma, yapılandırılmış JSON çıktısı ve 140’tan fazla dilde eğitim bulunmaktadır. 31B varyantı, LMArena metin sıralamasında 3. sırada yer almaktadır.

Mimari açıdan Gemma 4, birçok yenilik getirmektedir: dönüşümlü yerel kayan pencere ve global dikkat katmanları, oransal RoPE (p-RoPE), Katman Başına Gömme (PLE), paylaşımlı KV önbellek ve “Anahtarlar eşittir Değerler” bellek optimizasyonu.

Rakamlara bakıldığında bu güçlü bir sürüm. Sorun, halka açık ağırlıklarda olmayan şey.

Multi-Token Prediction Nedir?

Standart büyük dil modelleri metni her seferinde bir token üretir. Her token, modelden tam bir ileri geçiş gerektirir. Bir sonraki token, önceki tamamlanana kadar başlayamaz. Bu otoregresif kod çözmedir ve doğası gereği sıralıdır.

Multi-Token Prediction (MTP), modele ekstra tahmin başlıkları ekleyerek bunu değiştirir. Yalnızca bir sonraki tokeni tahmin etmek yerine, model N+1, N+2, N+3 ve sonraki tokenleri — hepsini tek bir ileri geçişte tahmin eder.

İşleyiş şöyledir:

1. Eğitim aşaması: Ana modelin yanında ek hafif tahmin başlıkları eğitilir. Her başlık, farklı bir gelecek konumu tahmin etmeyi öğrenir (1 ileri, 2 ileri, 3 ileri vb.)
2. Çıkarım aşaması: Ekstra başlıklar paralel olarak “taslak” tokenler üretir. Ana model daha sonra hepsini tek bir ileri geçişte doğrular.
3. Doğrulama: Taslak tokenler, ana modelin üreteceğiyle eşleşirse, hepsi bir kerede kabul edilir — birden fazla sıralı kod çözme adımı atlanmış olur. Bir taslak token yanlışsa, üretim o konuma geri döner.

Bu, spekülatif kod çözme ile yakından ilişkilidir, ancak önemli bir avantajı vardır: taslak tokenler, ayrı, daha küçük bir “taslak model” gerektirmek yerine modelin kendisinden gelir.

MTP Ne Kadar Hızlı?

Hızlanma, taslak tokenlerin ne sıklıkta doğru olduğuna (“kabul oranı”) bağlıdır. DeepSeek V3, gerçek dünyadaki etkiyi göstermiştir:

2,4’lük bir kabul oranı, ortalamada ana modelden her ileri geçişin 1 yerine 2,4 token ürettiği anlamına gelir. Çıktı, standart kod çözmeyle matematiksel olarak aynıdır — her token doğrulanır. Aynı kaliteyi neredeyse iki kat hızda elde edersiniz.

İşinizi büyütmeye hazır mısınız?

Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.

Demo talep et Giriş yap

Gemma 4 ile Ne Oldu?

Bir HuggingFace kullanıcısı (@shadowlilac ), Google’ın Gemma 4 için LiteRT paketinin MTP tahmin başlıkları ve çok tokenli tahmin işlevselliği içerdiğini keşfetti. Ancak HuggingFace’de halka açık yayınlanan ağırlıklarda bunların hiçbiri yok.

MTP bileşenleri kasıtlı olarak çıkarılmış:

• Kontrol noktasında MTP başlıkları yok
• Model yapılandırmasında MTP yok
• İleri geçişte MTP yok

Google’ın Açıklaması

Bir Google mühendisi (@srikanta-221 ) bunun kasıtlı olduğunu doğruladı:

Halka açık model, “geniş uyumluluk” için yalnızca standart bir otoregresif arayüz sunmaktadır. MTP başlıkları model yapılandırmasından, ileri geçişten ve kontrol noktasından çıkarılmıştır. Bu, HuggingFace Transformers API’leri ile uyumluluğu sağlar ve tutarlı kontrol noktası ve çalışma zamanı davranışını korur.

Google, MTP’yi temel bir model özelliği yerine bir “dağıtım zamanı optimizasyonu” olarak çerçeveliyor. MTP tahmin başlıkları yalnızca LiteRT ile dışa aktarılan modellerde korunuyor — Google’ın kendi cihaz üzerinde çıkarım çerçevesi.

Bunun Neden Sorun Olduğu

Açıklama, yakından incelendiğinde tutarlı değil:

1. Model MTP ile eğitildi. Yetenek mevcut. Bunu sürümden çıkarmak bir tercih, teknik bir sınırlama değil.

2. Üçüncü taraf motorlar bunu uygulayamıyor. vLLM, llama.cpp, SGLang ve diğer çıkarım çerçeveleri, tahmin başlıkları olmadan MTP tabanlı spekülatif kod çözme kullanamaz. Bu motorlar, açık kaynak LLM dağıtımlarının büyük çoğunluğuna hizmet vermektedir.

3. Kullanıcılar yavaş sürümü alıyor. MTP olmadan Gemma 4, standart otoregresif hızlarda çalışır. Performans farkı pratikte zaten görülmektedir:

4. Ekosistem kilitlenmesi yaratıyor. Google’ın kendi LiteRT çerçevesi hız avantajını alıyor. Diğer herkes daha yavaş bir model alıyor. “Açık ağırlıklı” Apache 2.0 sürümü için bu önemli bir asimetri.

Spekülatif Kod Çözme Nasıl Çalışır (ve MTP Neden Daha İyi)

Eksik MTP başlıklarının neden önemli olduğunu anlamak için, MTP’nin çıkarım optimizasyonunun evrimindeki yerine bakmak faydalıdır.

Yaklaşım 1: Geleneksel Spekülatif Kod Çözme

Ayrı, daha küçük bir “taslak model” tokenler önerir. Ana model bunları paralel olarak doğrular. Taslaklar doğruysa, adım başına birden fazla token kabul edilir.

• Avantajlar: Herhangi bir model çiftiyle çalışır
• Dezavantajlar: İkinci bir modelin yönetilmesi ve yüklenmesi gerekir; taslak model kalitesi hızlanmayı sınırlar; ekstra bellek yükü

Yaklaşım 2: MTP (Yerleşik Tahmin Başlıkları)

Ana modelin taslak tokenler üreten kendi hafif tahmin başlıkları vardır. Ayrı bir modele gerek yoktur.

• Avantajlar: Ekstra model gerekmez; daha sıkı entegrasyon daha yüksek kabul oranları sağlar; daha düşük bellek yükü
• Dezavantajlar: Yalnızca tahmin başlıkları sürüme dahil edilmişse çalışır

MTP Neden Kazanır

MTP tahmin başlıkları ana modelin yanında eğitilir. Aynı dahili temsilleri paylaşır ve modelin kendi token dağılımını öğrenir. Bu, genellikle harici bir taslak modelden daha yüksek kabul oranları üretir; bu da doğrulama adımı başına daha fazla token kabulü ve genel olarak daha hızlı üretim anlamına gelir.

Tahmin başlıkları ayrıca küçüktür — genellikle modelin toplam parametre sayısına yalnızca %1-3 ekler. Bellek yükü, ayrı bir taslak model yüklemeyle karşılaştırıldığında ihmal edilebilir düzeydedir.

Bültenimize katılın

En son ipuçlarını, trendleri ve teklifleri ücretsiz alın.

E-posta adresi

Abone ol

Daha Geniş Etki

Bu sadece Gemma 4 ile ilgili değil. Bu karar, “açık” ağırlıklı sürümlerin gerçekte ne kadar açık olduğu konusunda bir emsal teşkil ediyor.

Kullanıcıların kaybettiği:

• Herhangi bir üçüncü taraf çıkarım motorunda MTP tabanlı spekülatif kod çözme
• MTP başlıklarını ince ayar yapma veya deneme olanağı
• Google’ın kendi dağıtım araçlarıyla performans eşitliği

Kullanıcıların hâlâ sahip olduğu:

• Temel model ağırlıkları (gerçekten iyi olan)
• Ayrı bir taslak model kullanarak geleneksel spekülatif kod çözme (vLLM sorun kaydı #38893 Gemma 4 için Eagle3 desteğini takip ediyor)
• Standart niceleme ve optimizasyon teknikleri

Topluluk tepkisi doğrudan oldu. 24 saatlik genel kanı, Gemma 4’ün karşılaştırma sonuçlarının rekabetçi olduğu — Qwen 3.5 ile eşleştiği veya biraz gerisinde kaldığı — ancak ürünün “tamamlanmamış” olduğu yönündeydi. Hız, kararlılık ve araç desteği çalışma gerektiriyor. Ek sorunlar arasında HuggingFace Transformers’ın başlangıçta Gemma 4 mimari desteğinden yoksun olması, PEFT’in yeni katman türlerini işleyememesi ve Mac kullanıcılarının daha büyük modelleri yüklerken çökme yaşaması yer alıyor.

Ne Yapabilirsiniz?

Gemma 4’ü dağıtım için değerlendiriyorsanız, işte pratik seçenekler:

Geleneksel spekülatif kod çözme kullanın. Harici taslak modeller yine de Gemma 4 çıkarımını hızlandırabilir. vLLM gibi çerçeveler, özellikle Gemma 4 için Eagle3 spekülatif kod çözme desteği ekliyor. Hızlanma yerleşik MTP ile eşleşmeyecektir, ancak hiç yoktan iyidir.

Hız açısından kritik iş yükleri için alternatifleri değerlendirin. Qwen 3.5, eşdeğer donanımda önemli ölçüde daha iyi token/saniye performansı sunuyor. Çıkarım hızı birincil kısıtlamanızsa, Qwen şu anda daha iyi bir hız-kalite oranı sunmaktadır.

Topluluk çözümlerini takip edin. LiteRT dışa aktarmaları MTP başlıklarını içeriyor. Araştırmacılar bunları çıkarıp HuggingFace ağırlıklarına yeniden ekleyecek yollar bulabilir, ancak Google bu yolu resmi olarak desteklememektedir.

Geri bildirim sağlayın. Google mühendisleri HuggingFace tartışma başlıklarını aktif olarak takip ediyor. MTP başlıklarının yayınlanması için net, teknik talepler etkili olabilir.

Sonuç

Gemma 4, gerçek mimari yenilikler ve güçlü karşılaştırma sonuçlarına sahip yetenekli bir model ailesidir. MTP tahmin başlıklarını halka açık sürümden çıkarıp bunları Google’ın kendi LiteRT çerçevesinde koruma kararı, açık ağırlığın içindeki “açık"lığı zayıflatmaktadır.

MTP küçük bir optimizasyon değildir. Çıktı kalitesinde sıfır etki ile 1,5–2 kat çıkarım hızlanması sağlayabilir. Model açıkça MTP ile eğitilmişken bunu halka açık ağırlıklardan esirgemek iki katmanlı bir sistem yaratmaktadır: Google’ın araçları için hızlı çıkarım, diğer herkes için yavaş çıkarım.

Açık kaynak yapay zeka topluluğu için mesaj açıktır: yalnızca karşılaştırma sonuçlarına değil, ağırlıkların içinde gerçekte ne olduğuna bakın. Açık bir lisans, her zaman açık bir sürüm anlamına gelmez.

FlowHunt ile oluşturuldu. Açık kaynak yapay zeka alanındaki en son gelişmeleri bloğumuzda takip edin.