Mixture of Experts Nedir?

Eylül 4, 2026

| Yorumlar&nbsp0

DeepSeek-V3’ün 671 milyar parametresi var ama ürettiği her token için bunların sadece 37 milyarını çalıştırıyor. Kulağa hile gibi geliyor; değil. Bu yazıda Mixture of Experts mimarisini adım adım kuracağız — router’ın kararını elle hesaplayacağız, “8x7B neden 56 milyar etmiyor” sorusunu cevaplayacağız ve bu tasarımın hangi faturayı ödeyerek bu tasarrufu yaptığını göreceğiz.

Klasik bir dil modelinde tuhaf bir israf var. Modele “merhaba” mı yazdınız, yoksa 400 satırlık bir C++ dosyasında segfault mı arıyorsunuz — fark etmiyor. Üretilen her token için modelin bütün parametreleri belleğe okunuyor ve hepsiyle çarpma yapılıyor. 70 milyar parametreli bir model, “merhaba”ya cevap verirken de 70 milyar parametrenin tamamını çalıştırıyor.

İnsan beyni böyle çalışmıyor. Siz de matematik problemi çözerken beyninizin tamamını aynı anda ateşlemiyorsunuz. Mixture of Experts (uzman karışımı, kısaca MoE) tam olarak bu sezginin mimariye dönüşmüş hali: modeli birbirinden bağımsız alt ağlara — expert‘lere — böl, ve gelen her token için bunların sadece birkaçını çalıştır^[15]^[25].

Fikir yeni değil; 1991’e dayanıyor. Ama 2026’da açık ağırlıklı büyük modellerin neredeyse tamamı bu mimariyi kullanıyor. Neden geri döndüğünü, nasıl çalıştığını ve nerede pahalıya patladığını sırayla kuralım.

1. Önce Şu “Dense” Modelde Ne Oluyor?

Bir Transformer bloğunun içinde iki ana parça var: attention katmanı (token’ların birbirine bakıp bağlam kurduğu yer) ve feed-forward network (FFN — her token’ın tek başına içinden geçtiği, iki katmanlı geniş bir sinir ağı). Attention ilişki kurar; FFN ise modelin “bilgisinin” saklandığı yerdir ve tipik bir modelde parametrelerin yaklaşık üçte ikisi buradadır^[16].

Dense (yoğun, yani klasik) modelde her token bu devasa FFN’in tamamından geçer. MoE’nin yaptığı müdahale tek cümleyle özetlenebilir:

FFN katmanını N tane küçük FFN’e böl, ve her token için bunların sadece k tanesini çalıştır. Attention katmanı olduğu gibi kalır, herkes onu ortak kullanır.

İşte bu kadar. Geri kalan her şey — router, load balancing, expert parallelism — bu tek cümleyi çalışır hale getirmek için gereken mühendislik.

Şekil 1 — MoE, Transformer bloğunun sadece FFN kısmına dokunuyor. Attention katmanı paylaşılmaya devam ediyor; asıl değişiklik, tek büyük FFN’in yerini bir router ve bir expert kümesinin almasında.

2. Fikir 1991’den Geliyor

MoE’yi 2023 icadı sanmak yaygın bir yanılgı. Robert Jacobs, Michael Jordan, Steven Nowlan ve Geoffrey Hinton’ın 1991’de yayımladığı Adaptive Mixtures of Local Experts makalesi bugün kullandığımız mimarinin bütün ana parçalarını tarif ediyordu: birbirinden ayrı expert ağları, hangi expert’in devreye gireceğine karar veren bir gating network, ve expert’lerin farklı vaka türlerinde uzmanlaşmasını sağlayan bir eğitim düzeni^[1].

Makaledeki deney çok konuşuluyor: birden fazla konuşmacının seslerinden sesli harf ayırma görevinde MoE, aynı doğruluğa klasik bir backpropagation ağından belirgin biçimde daha az epoch’ta ulaştı — ve expert’ler kendiliğinden işi paylaştı, her biri belirli sınıf çiftlerine yoğunlaştı^[2].

Sonra fikir uzun süre rafta bekledi. Geri getiren üç adım şu:

Yıl	Çalışma	Getirdiği şey
1991	Jacobs, Jordan, Nowlan, Hinton^[1]	Expert + gating network fikri
2017	Shazeer ve ark. — “Outrageously Large Neural Networks”^[3]	Seyrek (sparse) MoE katmanını LSTM’e taktılar; 137 milyar parametreye çıktılar ve noisy top-k gating‘i tanıttılar
2021	Fedus ve ark. — Switch Transformer^[4]	Yönlendirmeyi tek expert’e (top-1) indirip trilyon parametreye çıktılar; T5-XXL’e göre pre-training’de ~4 kat hızlanma^[5]
2023	Mistral — Mixtral 8x7B^[6]	Herkesin indirip çalıştırabildiği ilk güçlü açık MoE

3. Router Kararını Nasıl Veriyor?

Router (yönlendirici) kulağa karmaşık geliyor ama şaşırtıcı derecede küçük bir şey: token’ın vektörünü alıp expert sayısı kadar sayı üreten tek bir linear katman. Başka hiçbir şey yok. Şu üç adımı yapıyor:

Skor üret. Her expert için bir logit hesapla.
En iyi k tanesini seç. Mixtral’da k = 2, Switch Transformer’da 1, DeepSeek-V3’te 8.
Ağırlıklandır. Sadece seçilen logit’leri softmax’ten geçir — böylece ağırlıklar 1’e toplanır — ve expert çıktılarını bu ağırlıklarla topla.

Rakamlarla görelim. 8 expert’li, top-2 yönlendirmeli bir katmanda tek bir token için router şu logit’leri üretmiş olsun:

Şekil 2 — Router bir linear katmandan ibaret. Üç adım yukarıdan aşağı ilerliyor; her adımdaki sekiz sütun hep aynı sekiz expert’i gösteriyor, yani bir sütunu yukarıdan aşağı takip ederek o expert’in başına ne geldiğini okuyabilirsiniz.

Kodu da anlatıldığı kadar kısa. Aşağıdaki hali öğrenmek için birebir; gerçek kütüphaneler aynı matematiği token’ları expert’e göre gruplayan optimize edilmiş kernel’lerle yapar, çünkü şu iç içe döngü GPU’da felaket olur^[27]:

import torch
import torch.nn.functional as F

class MoELayer(torch.nn.Module):
    def __init__(self, d_model, n_experts=8, top_k=2):
        super().__init__()
        self.router  = torch.nn.Linear(d_model, n_experts, bias=False)
        self.experts = torch.nn.ModuleList(
            [FeedForward(d_model) for _ in range(n_experts)])
        self.top_k = top_k

    def forward(self, x):                          # x: (token, d_model)
        logits    = self.router(x)                 # (token, n_experts)
        vals, idx = logits.topk(self.top_k, -1)    # en yüksek k logit
        w         = F.softmax(vals, dim=-1)        # SADECE seçilenler normalize edilir

        out = torch.zeros_like(x)
        for slot in range(self.top_k):
            for e, expert in enumerate(self.experts):
                mask = idx[:, slot] == e           # bu expert'e düşen token'lar
                if mask.any():
                    out[mask] += w[mask, slot, None] * expert(x[mask])
        return out

Bir ayrıntıya dikkat edin: bu karar her katmanda yeniden veriliyor. 32 katmanlı bir modelde tek bir token, 32 ayrı router kararından geçiyor. Yani “bu soru matematik sorusu, matematik expert’ine gitsin” gibi tek seferlik bir dağıtım yok — 6. bölümde bunun üstüne döneceğiz.

4. “8x7B” Neden 56 Milyar Etmiyor?

Mixtral 8x7B’nin adı insanı yanıltıyor. 8 × 7 = 56 diyorsunuz, ama modelin toplam parametresi 46,7 milyar. Sebep birinci bölümde kurduğumuz şey: çoğaltılan tek parça FFN blokları. Attention katmanları, embedding’ler ve normalizasyon parametreleri tek nüsha duruyor ve bütün expert’ler tarafından ortak kullanılıyor^[5]^[14].

Aynı mantık aktif parametre tarafında da işliyor. Token başına iki expert çalıştığı için hesaba katılan parametre ~12,9 milyar: yani Mixtral bellekte 47 milyarlık yer kaplarken, hızı 13 milyarlık bir dense modele yakın^[5]^[6]. Buna rağmen kalite tarafında Llama 2 70B’yi geçiyor ve instruction-tuned sürümü insan değerlendirmelerinde GPT-3.5 Turbo’nun önüne çıkıyor^[6].

2026’da bu oran çok daha uç noktalara gitti. Bugünün büyük açık modellerinde aktif parametre oranı %10’un, çoğunda %5’in altında:

Şekil 3 — Model büyüdükçe aktif oran düşüyor. Mimarinin temel vaadi bu: parametre sayısını (yani modelin kapasitesini) artırırken token başına hesabı sabit tutmak, hatta düşürmek [5][6][8][11][24].

Neden işe yarıyor? Model kalitesi kabaca iki şeye bağlı: ne kadar bilgi depolayabildiği (parametre sayısı) ve her token için ne kadar hesap yaptığı. MoE bu ikisini birbirinden ayırıyor. Depolamayı ucuza (VRAM) alıp hesabı (GPU FLOP’ları) pahalı tutmayı seçiyorsunuz — ve 2026’da GPU saatinin fiyatı düşünülürse bu makul bir takas.

5. Asıl Zor Kısım: Load Balancing

Şimdiye kadar her şey güzel görünüyor. Peki router’ı kim eğitiyor? Cevap: kimse ayrıca eğitmiyor, o da modelin geri kalanıyla birlikte gradient descent’le öğreniyor. Ve tam burada mimarinin en can sıkıcı sorunu çıkıyor.

Düşünün: eğitimin başında router rastgele davranıyor. Diyelim ki 3 numaralı expert şans eseri biraz daha fazla token aldı. Daha fazla token = daha fazla gradient = daha iyi eğitilmiş expert = router’ın onu seçmek için daha çok sebebi. Döngü kendini besliyor. Birkaç bin adım sonra elinizde birkaç şişman expert ve hiç kullanılmamış onlarca ölü expert kalıyor. Literatürde bunun adı routing collapse^[10]. Sonuç acı: parametrelerin büyük kısmı VRAM’de yer kaplayan ama hiçbir işe yaramayan ölü ağırlıklara dönüşüyor.

Şekil 4 — Load balancing’in çözmeye çalıştığı problem. Üstteki tabloda modelin parametrelerinin yarısına yakını hiç kullanılmıyor; MoE’nin bütün mantığı çöküyor.

Bu problemi çözmek için geliştirilen yöntemler, MoE literatürünün belki de en kalabalık bölümü. Ana hatlarıyla:

Noisy top-k gating (2017)

Shazeer’in çözümü şirin: router’ın ürettiği skorlara eğitim sırasında ayarlanabilir miktarda Gaussian gürültü ekle^[3]. Kontrollü bir rastgelelik, sıralamayı ara ara karıştırıyor ve arka sıradaki expert’lere de token düşüyor. Böylece hiçbir expert baştan devre dışı kalmıyor.

Auxiliary loss (yardımcı kayıp)

Daha doğrudan bir yaklaşım: eğitim hedefine bir ceza terimi ekle. Klasik formülasyonda her expert’e düşen token oranı f_e ile o expert’in ortalama router olasılığı P_e çarpılıp toplanıyor; dağılım dengesizleştikçe bu toplam büyüyor ve model cezalandırılıyor^[10]. ST-MoE ayrıca router z-loss‘u ekledi: logit’ler çok büyürse eğitim sayısal olarak dengesizleşiyor, bu terim onları makul aralıkta tutuyor^[10].

Capacity factor ve düşen token’lar

Pratik bir kısıt daha var: GPU’da her expert’e sabit boyutlu bir buffer ayrılıyor. Kapasite şu formülle belirleniyor: (batch'teki token / expert sayısı) × capacity factor^[5]. Bir expert’e kapasitesinin üstünde token gelirse fazlası ne oluyor? İşlenmiyor — token dropping. O token expert katmanını atlayıp residual bağlantı üzerinden geçiyor, yani o katmanda hiç işlem görmemiş oluyor^[22]^[23]. Switch Transformer 1–1.25 gibi düşük capacity factor’larla en iyi sonucu veriyordu^[5]; günümüz sistemlerinin çoğu ise block-sparse kernel’lerle “dropless” çalışmayı tercih ediyor^[10].

Auxiliary loss’suz denge (2024–)

Aux loss’un bir maliyeti var: dengelemeyi zorlarken modelin asıl hedefiyle çelişiyor ve kaliteyi düşürüyor. DeepSeek-V3 bunu şöyle aştı: her expert’e bir bias değeri verildi ve bu bias eğitim boyunca gradient’le değil, elle güncellendi — yükü fazla olan expert’in bias’ı biraz düşürülüyor, boşta kalanınki biraz yükseltiliyor^[8]^[10]. Denge sağlanıyor ama loss fonksiyonuna dokunulmadığı için model kalitesi bundan zarar görmüyor. 2026’nın yeni modellerinin çoğu bu yaklaşımın bir türevini kullanıyor.

Alternatif bir yol daha var, adı expert choice routing: kararı tersine çevirip “her token kendi expert’ini seçsin” yerine “her expert kendi token’larını seçsin” diyorsunuz. Denge problemi tanım gereği ortadan kalkıyor, çünkü her expert tam olarak kapasitesi kadar token alıyor^[26]. Router’ın kendisini yönlendirme kalitesine göre düzenleyen daha yeni yaklaşımlar da var^[21].

6. Peki Expert’ler Gerçekten “Uzman” mı?

MoE anlatılırken çok sevilen bir kurgu var: “bir expert deyimleri anlar, bir expert karmaşık gramer yapılarını çözer, bir expert matematik yapar.” Hoş bir hikâye. Ölçümler bunu desteklemiyor.

Mixtral’ın makalesinde yazarlar tam olarak bunu test etti. Farklı alanlardan metinler verip router’ın seçimlerine baktılar ve konuya göre uzmanlaşma bulamadılar: ArXiv makaleleri (LaTeX), PubMed biyoloji özetleri ve PhilPapers felsefe metinleri neredeyse aynı expert dağılımını üretti^[7].

Buldukları şey başkaydı: sözdizimsel bir düzen. Python kodundaki self kelimesi ya da İngilizce metindeki Question kelimesi, geçtiği her yerde aynı expert’e gidiyordu. Bir de belirgin bir konum etkisi var — ardışık token’ların aynı expert’e düşme oranı 15. katmanda %27.9’a çıkıyor; rastgele olsaydı %12.5 olacaktı^[7]. Router’lar sözcük türüne (part-of-speech) de hatırı sayılır biçimde duyarlı çıkıyor^[18].

2026’da yayımlanan bir çalışma bunun üstüne gitti ve daha da rahatsız edici bir sonuç buldu: expert seçimi büyük ölçüde hidden state’lerin geometrisini yansıtıyor, alan bilgisini değil. Farklı MoE modelleri aynı matematik problemini çözerken en çok kullandıkları expert’lerin sadece ~%60’ı ortaktı — ki bu, tamamen farklı problemler çözerken çıkan orana yakın^[17].

Doğru zihinsel model şu: Router, token’ları “biyoloji / matematik / şiir” gibi insan-okunur kategorilere ayırmıyor. Hidden state uzayında işine yarayan bir bölme buluyor ve bu bölme işe yarıyor — ama neye göre böldüğünü bizim kelimelerimizle açıklamak çoğu zaman mümkün değil. “Expert” ismi, 1991’deki niyetten kalma bir isim; bugünkü davranışın tam karşılığı değil.

7. Faturanın Geldiği Yer: VRAM

Şimdi işin sevimsiz tarafına gelelim. MoE hesabı azaltıyor — belleği azaltmıyor.

Router hangi expert’i seçeceğini token geldiğinde öğreniyor. Yani hangi expert’e ihtiyaç duyulacağı önceden belli değil, dolayısıyla hepsi bellekte hazır durmak zorunda. Mixtral 13 milyarlık bir modelin hızında koşar ama 47 milyarlık bir modelin VRAM’ini ister^[5]. DeepSeek-V3’ü çalıştırmak için 671 milyar parametrelik yer ayırmanız gerekir; token başına 37 milyarını kullanacak olmanız bunu değiştirmez.

İkinci incelik daha da önemli, çünkü “MoE her zaman hızlıdır” sanısını bozuyor. GPU’da iki farklı darboğaz var:

Durum	Darboğaz	MoE’nin durumu
Prefill / büyük batch	Aritmetik (FLOP)	Kazanıyor. Az hesap = az iş.
Decode / küçük batch	Memory bandwidth (bellek bant genişliği)	Avantajı eriyor. Ağırlıkları okumak, çarpmaktan uzun sürüyor.

Epoch AI’ın analizine göre H100’de kritik batch büyüklüğü ~300 token civarında; bunun altında matris çarpımı için yapılan bellek okumaları (memory read) aritmetikten daha uzun sürüyor ve aktif parametre avantajı büyük ölçüde kayboluyor^[13]. Aynı çalışma pratik bir kural da veriyor: kısa context’li hızlı decode’da 4 yönlü ve 8 yönlü seyrek modeller, kabaca toplam parametrelerinin %65’i ve %50’si kadar dense modele denk düşüyor^[13]. Yani “37 milyar aktif” demek “37 milyarlık dense model hızı” demek değil.

Üçüncüsü de dağıtık kurulumda çıkıyor. Bütün expert’ler tek GPU’ya sığmadığı için expert parallelism (EP) kullanılıyor: expert’ler farklı GPU’lara dağıtılıyor ve token’lar her MoE katmanında kendi expert’lerinin bulunduğu GPU’ya gönderilip sonuç geri toplanıyor — buna all-to-all iletişim deniyor^[19][20]. Dense modellerde olmayan, tamamen MoE’ye özgü bir maliyet kalemi bu; üstelik yük dengesizse bazı GPU’lar boş beklerken bazıları tıkanıyor^[28][29]. Referans bir ölçüm için: Qwen3-235B’nin 8×H200 üzerindeki bir kurulumunda GPU başına ~55 GiB bellek kullanımı raporlanıyor^[20].

Şekil 5 — MoE’nin takası tek cümlede: bol miktarda VRAM verip GPU hesabından tasarruf ediyorsunuz. Tek kullanıcılı, küçük kurulumlarda bu takas genelde kârlı değil; yüksek trafikli servislerde çok kârlı.

8. 2026’nın Tasarım Tercihi: Çok Sayıda, Küçük Expert

Mixtral’ın 8 iri expert’i bugün eski moda sayılıyor. Yönü değiştiren çalışma DeepSeekMoE oldu; iki fikir getirdi^[9]:

Fine-grained experts (ince taneli expert’ler). Expert’leri daha küçük parçalara bölüp daha fazlasını seç. 8 expert’ten 2 seçerken 28 farklı kombinasyon kurabilirsiniz; 64 expert’ten 8 seçerken 4 milyardan fazla. Aynı hesap bütçesiyle çok daha esnek bir uzmanlaşma alanı açılıyor.

Shared expert (paylaşılan expert). Her token’ın mutlaka geçtiği, hiç yönlendirilmeyen bir expert ayır. Dilin her yerinde lazım olan genel bilgi orada birikiyor; böylece routed expert’ler aynı temel bilgiyi tekrar tekrar öğrenmek zorunda kalmıyor. DeepSeekMoE bu ikisiyle 16 milyar parametrelik modelini LLaMA2 7B seviyesine, o modelin hesabının yaklaşık %40’ıyla ulaştırdı^[9].

DeepSeek-V3 bu tasarımın ölçeklenmiş hali: katman başına 256 routed expert + 1 shared expert, token başına 8 routed expert seçiliyor^[8]. Kimi K3’te ise 896 expert ve top-16 yönlendirme raporlanıyor^[24]. Eğilim net: expert sayısı artıyor, expert boyu küçülüyor, aktif oran düşüyor.

Model	Toplam	Aktif / token	Expert düzeni
Mixtral 8x7B (2023)^[6]	46,7 Mrd	~12,9 Mrd	8 expert, top-2
DeepSeek-V3 (2024)^[8]	671 Mrd	37 Mrd	256 routed + 1 shared, top-8
gpt-oss-120b (2025)^[11]	117 Mrd	5,1 Mrd^[12]	top-4, 36 katman, MXFP4
gpt-oss-20b (2025)^[11]	20,9 Mrd	3,6 Mrd	top-4, 24 katman
Qwen3-235B-A22B^[20]	235 Mrd	22 Mrd	adındaki A22B = aktif 22 milyar
Kimi K3 (2026)^[24]	2,8 Trl	~50 Mrd	896 expert, top-16

9. Ne Zaman MoE, Ne Zaman Dense?

Bir model seçerken ya da kendi kurulumunuzu planlarken işinize yarayacak kısa bir karar tablosu:

Durum	Tercih	Neden
Elinizde bol VRAM var, yüksek istek trafiği bekliyorsunuz	MoE	Batch büyüdükçe aktif parametre avantajı tam olarak geri döner^[13]
Tek GPU, sınırlı VRAM, tek kullanıcı	Dense	MoE’nin bütün parametreleri belleğe girmek zorunda; küçük batch’te hız avantajı da erir^[5]^[13]
Aynı hesap bütçesiyle daha yüksek kalite istiyorsunuz	MoE	Kapasiteyi hesaptan ayırmanın tek pratik yolu^[4]
Küçük veri setiyle fine-tuning yapacaksınız	Dikkat	MoE’ler küçük görevlerde dense modellerden daha kolay overfit oluyor; expert dışı ağırlıkları dondurmak işe yarayan bir yaklaşım^[5]

Kapanış

Mixture of Experts’i tek cümleye indirmek gerekirse: modelin kapasitesini, o kapasiteyi kullanmanın maliyetinden ayırmanın yolu. Dense bir modelde bu ikisi birbirine yapışıktır — parametre eklemek, her token’ı pahalılaştırır. MoE bu bağı koparıyor; bedeli de bellek olarak ödeniyor.

Mimarinin kendisi 1991’den beri ortada duruyordu. 2026’da her yerde olmasının sebebi yeni bir fikir değil, yeni bir denge: GPU belleği artık büyük modelleri tutabiliyor, ve asıl kıt kaynak hesap gücü hâline geldi. Load balancing’in çözülmesi de bunu mümkün kıldı — 2017’nin gürültü ekleme numarasından 2024’ün bias güncellemesine kadar giden bütün o uğraş, aslında tek bir amaca hizmet ediyor: ödediğiniz VRAM’in tamamının gerçekten çalışıyor olması.

Bir de dürüst bir kapanış notu: “expert” kelimesi bize hoş bir hikâye anlattırıyor ama ölçümler o hikâyeyi doğrulamıyor. Router’ın neye göre böldüğünü hâlâ tam olarak bilmiyoruz^[17]. Çalışıyor, ölçülebiliyor, ölçekleniyor — ama neden çalıştığı, bu alanın hâlâ açık sorularından biri.

Devam etmek isterseniz üç yol var: bir MoE modelinin router çıktılarını kendi metninizle yazdırıp hangi expert’lerin seçildiğine bakmak (en öğretici olanı bu), vLLM’de expert parallelism’i açıp GPU’lar arası all-to-all trafiğini ölçmek^[19], ve DeepSeek-V3 teknik raporunu load balancing bölümünden okumaya başlamak^[8]. Kolay gelsin!

Kaynaklar

Bir yanıt yazın Yanıtı iptal et

Yorum yapabilmek için oturum açmalısınız.