Mixture-of-Experts (MoE) mimarisinde eğlenceli bir soru var: bir modelin router’ını çalıştırırken top-k değerini artırırsan ne olur? Yani her token için 8 uzman yerine 32 uzman aktif etsen? Teoride bu, aktif parametre sayısını 2-3 kat artırır — ekstra kapasitede genelleştirme, daha iyi cevaplar beklenir.
Pratikte ise çoğu zaman daha kötü sonuçlar geliyor. Neden?
GitHub üzerinde hikarioyama’nın qwen36-a6b deposu, tam bu soruyu Qwen 3.6 35B-A3B modeli üzerinde ele almış. Kaba özet: naif top-k artırma çalışmıyor, ama küçük bir softmax renormalization düzeltmesi ile aktif parametreyi bedavaya 3B’den 6B’ye çıkarabiliyorsunuz. Sıfır ek eğitim, sıfır ağırlık değişikliği. Bir runtime parametresi ile.
Bu, MoE mimari araştırmalarında dikkat çekici bir bulgu. Detaylara inelim.
Qwen 3.6 35B-A3B: baseline
Deneyin temel modeli: Qwen 3.6 35B-A3B. Alibaba’nın 2026 orta sürümü.
- Toplam parametre: 35B.
- Aktif parametre (A3B): ~3B.
- Uzman sayısı: 256.
- Router: Her token için top-8 uzman aktif edilir.
- Baseline MMLU: %84.67 (508/600).
Bu, Qwen 3.6 ailesinin küçük ama etkin varyantı. A3B, “small footprint, high impact” kategorisinde tercih edilen bir model.
A6B deneyi: top-k 8 → 32
Fikir basit: eğer top-8 uzman aktif ediyorsak, top-32 aktif edelim. Bu, ~3B aktif parametreyi ~6B’ye çıkarır. Toplam parametre değişmiyor (35B), sadece her forward pass’te daha fazla uzman devrede.
Beklenen sonuç: performans artar. Çünkü daha fazla uzman = daha çok bilgi transformation kapasitesi.
Gerçek sonuç: performans düşüyor.
- Top-8 (A3B baseline): %84.67 MMLU
- Top-32 naive (A6B): %81.50 MMLU — -3.17 puan kayıp
3 tam puan MMLU kaybı, ciddi bir düşüş. Sanki modeli zayıflatıyorsun.
Neden?
Softmax renormalization problemi
MoE router’ları çoğu zaman softmax + top-k formatında çalışır:
logits = router(hidden_state) # 256 uzman için skorlar
probs = softmax(logits) # 256 üzerinden olasılık dağılımı
top_k_indices, top_k_probs = topk(probs, k=8) # en yüksek 8’i seç
top_k_probs = normalize(top_k_probs) # top-8 toplamı 1 olsun
# Sonra bu 8 uzmanın çıktıları top_k_probs ile ağırlıklı olarak birleştirilirKritik nokta: seçilen 8 uzmanın olasılıkları yeniden normalize ediliyor. Yani seçilen 8 uzmanın toplam ağırlığı 1 olacak şekilde ölçekleniyor. Bu, model eğitiminde “doğru” kabul edilen davranıştır.
Şimdi k=32’ye geçince ne oluyor? Yeni 24 uzman devreye giriyor. Ama bu 24 uzman, orijinal 8’in olasılık kütlesini seyreltiyor. Yani ilk seçilen 8 uzman, artık toplam ağırlığın belki %70’ini alıyor; kalan %30, sonraki 24 uzman arasında dağılıyor.
Bu, ilk 8 uzmanın rolünü zayıflatıyor. Model, eğitim sırasında bu 8 uzmana “asıl işi yaparsınız” olarak öğrenmişti. Şimdi ağırlıkları düştüğü için, kritik uzman çıktıları yeterince güçlü şekilde yansıtılmıyor.
Sonuç: MMLU 3 puan düşüyor.
Fix: –router-tail-scale (α) parametresi
Deneydeki asıl yenilik: α (router-tail-scale) adlı runtime parametresi. Bu, k=32’deki “tail” uzmanlarının (yani ilk 8’in dışındaki 24 uzman) olasılık ağırlığını rescale ediyor.
Formülü kabaca:
if index in top_8:
prob = original_prob
else: # index in tail (9-32)
prob = original_prob * αSonra toplam yeniden normalize ediliyor.
α=1 durumu naif k=32 (yani hiçbir müdahale yok). α=0 durumu ise pratik olarak k=8’e geri dönüş (tail ağırlıkları sıfırlanıyor).
Arada ne oluyor? Sonuçlar tablosu:
| α değeri | MMLU % | Δ (α=1’e göre) |
|---|---|---|
| 0 (≡ k=8) | 84.67 | — |
| 0.25 | 84.33 | +2.83 |
| 0.5 | 84.50 | +3.00 |
| 0.75 | 82.83 | +1.33 |
| 1.0 (naive k=32) | 81.50 | — |
Bulgu: α ≤ 0.5 için -3.17 puanlık kayıp tamamen ödeniyor. Yani k=32 aktifleştirme + α ≤ 0.5 ile baseline seviyesine dönebiliyorsunuz.
Grafik olarak: 0 ile 0.5 arasında MMLU eğrisi neredeyse düz. 0.5’ten sonra hızla düşüyor. 1.0’da tam kayba dönüşüyor.
Ne öğreniyoruz bu deneyden?
Birkaç önemli çıkarım:
1. MoE router’ları training-time-fragile. Model, eğitim sırasında hangi k değeriyle çalıştıysa, o davranışa göre optimize olur. Sonradan k’yi değiştirmek, olasılık dağılımını bozar.
2. Weight değişikliği olmadan mimari değişikliği mümkün. α parametresi bir hyperparameter — ağırlıklara dokunulmuyor. Yani “post-training routing tuning” kavramı işliyor.
3. Aktif parametre sayısı bedavaya artırılabilir. α=0.5 ile hem k=32 uzmanının katkısını alıyorsunuz (0.5 ölçekli), hem de orijinal k=8’in gücünü koruyorsunuz. Sonuç: teknik olarak “6B aktif parametre” ama kayıp yok.
4. Ama gerçek kazanım hala belirsiz. α=0.5 durumunda MMLU %84.50 — baseline (%84.67) ile pratik aynı. Yani “bedavaya A6B” iddiası doğru ama gerçek performans artışı yok. Sadece “kaybetmedik” diyebilirsiniz.
5. Fine-tune ile hikaye değişebilir. α=0.5 ile k=32 kullanıp modeli biraz fine-tune ederseniz, teoride model bu yeni routing dağılımına adapte olur. Zamanla optimal α yükselir. Yani k=32 kapasitesi gerçek kazanıma dönüşebilir. Ama deney bu adımı atmamış.
Neden önemli?
MoE mimari araştırmalarında bu tür pratik “runtime dial”lar altın değerinde. Nedenleri:
Inference esnekliği. Aynı ağırlıklarla, kullanıcı senaryosuna göre model davranışını ayarlayabilirsiniz. Yüksek kalite gerekiyorsa α artırın; hızlı yanıt gerekiyorsa α düşürün (k=8 ile aynı hız).
Deployment optimization. Model provider’lar aynı checkpoint’ten farklı SLA katmanları sunabilir. Free tier: k=8 (hızlı, ucuz). Premium: k=32 with α=0.5 (biraz daha yüksek quality potansiyeli).
Fine-tune direction. α=0.5 ile başlayıp modeli yeni routing dağılımına fine-tune etmek, MoE post-training için yeni bir yön açar. LoRA + α tuning kombinasyonu ilginç.
Diğer modellere transfer. Bu teknik Qwen 3.6’a özel değil. Kimi K3 (896 uzman), DeepSeek V3 (256 uzman), Mixtral (8 uzman) gibi diğer MoE modellerde de uygulanabilir. Her modelde optimal α farklı olacak.
Deneyin sınırları
Repo, kendini “research log” olarak sunuyor — bitmiş bir ürün değil. Şu anki sınırlar:
- Sadece MMLU üzerinde test edildi (600 soru). Diğer benchmark’lar (HellaSwag, ARC, GSM8K, HumanEval) test edilmedi.
- Sadece ~500 sample. İstatistiksel olarak dar.
- Sadece Qwen 3.6 35B-A3B’de. Diğer MoE modellerde replikasyon yok.
- α optimal noktası (0.25-0.5 arası) task-specific olabilir. Kod için farklı, reasoning için farklı, dil çevirisi için farklı olabilir.
- Latency ölçümü yok. k=32 forward pass, k=8’e göre 4x hesaplama gerektirir — hızda ne kayıp var, bilinmiyor.
Ama bu bir research log olarak değerli. Şu adımları başkaları alıp genişletebilir.
MoE topluluk için pratik notlar
Eğer kendi MoE modelinizle deneme yapıyorsanız (Qwen, Mixtral, DeepSeek, Kimi K3):
- Naif top-k artırma yapmayın. Softmax renormalization problemini yaşarsınız. Modeli zayıflatırsınız.
- Tail rescale parametresini deneyin. Router çıktısını modify eden bir hook ekleyin. α = 0.25-0.5 aralığında test edin.
- Task-specific optimal α arayın. Farklı benchmark’lar için farklı α’lar deneyin. Optimal noktalar farklı olabilir.
- Fine-tune ile α’yı iyi kullanın. α=0.5 ile fine-tune ederseniz model uyum sağlar. Zamanla α’yı artırıp daha büyük kapasiteye ulaşabilirsiniz.
Sonuç: MoE’nin gizli bir kolu
MoE mimari, son 2 yılın en popüler ölçekleme tekniği. DeepSeek V3, Kimi K3, Mixtral, Qwen — hepsi MoE. Ama çoğu geliştirici, MoE’yi “top-k uzman aktif et” kutucuğu olarak görüyor. Bunun ötesindeki tuning surface’ini bilmiyor.
hikarioyama’nın qwen36-a6b repo’su, MoE’nin gizli bir kolunu ortaya koyuyor: router-tail-scale (α). Küçük bir hyperparameter, büyük bir esneklik. Ağırlıklara dokunmadan aktif parametre sayısını 2x’e katlayabilirsiniz.
Gerçek performance kazanımı mı? Henüz belirsiz — deney sadece “kaybetmedik” noktasına ulaştı. Ama araştırma yönü açık: α + fine-tune kombinasyonu, MoE post-training için yeni bir yön. Önümüzdeki aylarda büyük MoE modellerinde (Kimi K3 dahil) bu teknik ile uğraşan çok araştırmacı olacak.
Kısa yol: eğer MoE modeliyle çalışıyorsanız, ağırlıklara dokunmadan mimari deneyler yapmak istiyorsanız, router-tail-scale bir başlangıç noktası. GitHub’dan kodu indirin, Qwen 3.6 35B-A3B üzerinde çalıştırın, sonra kendi modelinize adapte edin. 30 satır kod, potansiyel olarak 2x aktif parametre kapasitesi.
Bir yanıt yazın