Mixture of Experts (MoE) Nedir? 2026 LLM Mimari Rehberi

Llama 4 Scout, 109 milyar parametreden oluşuyor ama bir cümle üretirken bunların yalnızca 17 milyarını kullanıyor. Mixtral 8x7B’de 45 milyar parametre saklı; her token için hesaba katılan kısım sadece 12.9 milyar. Bu sayıların tutarsız görünmesi anlaşılır, çünkü bu modeller klasik yapıyla çalışmıyor. Mixture of Experts (MoE), bu çelişkiyi çözen mimari tasarım. Ve bu tasarım, son iki yılda neredeyse tüm büyük dil modellerinin içine girdi.

Dense model: her şeyi kullanan mimari

GPT-2’den Llama 3’e uzanan klasik Transformer mimarisi dense (yoğun) bir yapıya dayanır. Her token, her katmandan geçer; her katmanda da tüm Feed-Forward Network (FFN) ağırlıkları devreye girer. Dikkat mekanizması, normalizasyon katmanları, FFN bloğu; bunların hepsi her token için tam kapasite çalışır.

Pratik sonucu şu: 70 milyar parametreli bir dense model, bir kelime üretmek için 70 milyar parametreyi hesaplamaya dahil eder. Model büyüdükçe hesaplama maliyeti doğrusal artar, VRAM gereksinimleri de öyle. Llama 3.1 70B veya Gemma 3 27B bu kategoriye girer; güçlü modeller, ama her çıkarım için kaynak kullanımları sabit ve yüksek.

Dense modelde bilgiyi genişletmenin tek yolu daha fazla parametre eklemek. Daha fazla parametre, hem eğitim hem de çıkarım maliyetini orantılı biçimde yükseltir. 2022’ye kadar bu denklem kabul gördü. Ama ölçek büyüdükçe maliyet artık katlanarak yükseliyordu: eğitim için daha fazla GPU, çıkarım için daha fazla VRAM, erişim için daha yüksek maliyet. 100B parametrenin üzerine çıkmak büyük çoğunluk için pratik olmaktan çıkıyordu. Araştırmacılar farklı bir yol aradı.

Mixture of Experts: seçici aktivasyon

MoE fikri yeni değil. 1990’larda Jordan ve Jacobs’un çalışmalarına dayanır. Büyük dil modelleriyle birleşimi ise Mistral AI’nin 2023 sonunda Mixtral’ı duyurmasıyla ana akıma girdi. Ama mimarinin kendisi daha erken tarihli; Google’ın 2021’deki Switch Transformer makalesi ve 2022’deki GLaM çalışması, MoE’nin dil modellerinde ölçeklenebileceğini kapsamlı biçimde kanıtladı.

Temel prensip şu: her Transformer bloğundaki FFN katmanı, birden fazla uzman (expert) ağ ile değiştiriliyor. Her token için bu uzmanların tamamı değil, yalnızca bir alt kümesi aktive ediliyor. Hangi uzmanların çalışacağını bir router (yönlendirici) belirliyor. Geri kalan uzmanlar o token için hiçbir hesaplama yapmıyor; bellekte var olmaya devam ediyorlar ama FLOP bütçesine dahil değiller. Bu yaklaşımın literatürdeki adı sparse aktivasyon (seyrek aktivasyon).

Gündelik bir benzetme işleyişi netleştirir: büyük bir hastanede her hasta her doktora gitmez. Triyaj hemşiresi belirtilere bakarak hangi uzman bölümün devreye gireceğine karar verir. MoE’deki router da aynı işi yapar; gelen token’ın içeriğine göre hangi uzmanların çalışacağını belirler, seçilmeyenler o hesaplama döngüsünde hiçbir iş yapmaz. Önemli bir ayrım: MoE, birden fazla modeli paralelde çalıştırmak değildir. Tek bir modelin içinde, her token için dinamik olarak seçilen uzman alt-ağlar vardır; fark küçük görünse de mimari ve hesaplama açısından her şeyi değiştirir.

Router nasıl karar veriyor?

Router, basit bir lineer katman ve softmax fonksiyonundan oluşur. Her token için tüm uzmanlara bir skor verir, ardından en yüksek K skora sahip uzmanları seçer. Mixtral’da K=2; yani her token her blokta iki uzmanı kullanır.

Bu seçim süreci Top-K gating olarak bilinir. Aktive edilen uzmanların çıktıları, router’ın belirlediği ağırlıklarla ağırlıklı ortalama alınarak birleştirilir ve sonraki katmana aktarılır. Hangi uzmanın ne kadar ağırlık alacağı da yine router’ın softmax çıktısından geliyor. İşleyişi sözde kodla göstermek gerekirse:

scores = softmax(W_g · x)
selected = argtopk(scores, k=2)
output = Σ (scores[i] · Expert_i(x)) for i in selected

K değeri mimarinin en kritik hiperparametrelerinden biri. Switch Transformer K=1 ile maksimum seyrekliği hedeflerken, Mixtral K=2 seçerek kalite ile verimlilik arasında bir denge kurdu. K arttıkça model kapasitesi yükselir ama hesaplama maliyeti de artar; açık kaynak modellerin büyük çoğunluğu bu yüzden K=2’de karar kıldı.

İkinci önemli hiperparametre capacity factor: bir uzmanın tek işlem adımında kaç token kabul edebileceğini sınırlar. Değer düşük tutulursa hesaplama maliyeti azalır ama kapasitesi dolan bir uzmanı isteyen fazla tokenler işlemsiz kalabilir; buna token dropping denir ve buffer token yaklaşımı bu kaybı hafifletmek için geliştirildi. Değer yüksek tutulursa token kaybı önlenir ama aktarım yükü büyür. Capacity factor ile K’nin birlikte ayarlanması, MoE eğitiminin en kritik mühendislik kararlarından biri.

Eğitim sırasında kritik bir sorun çıkar: tüm tokenler aynı birkaç uzmanı tercih ederse, geri kalanlar hiç güncellenmez ve zamanla işlevsiz hale gelir. Buna expert collapse (uzman çökmesi) denir. Bunu önlemek için eğitim hedefine bir load balancing loss eklenir; bu ek kayıp terimi, tüm uzmanların yaklaşık eşit kullanılmasını teşvik eder. Uygulamada bazı uzmanlar yine de diğerlerinden daha fazla “tercih edilen” hale gelebilir, ama bu eğitim boyunca kontrol altında tutulur.

İlginç bir detay: router’ın kararları token bazlı. Aynı kelimenin farklı bağlamlardaki iki örneği farklı uzmanlara yönlendirilebilir. “Java” kelimesi bir programlama sorusunda farklı, bir coğrafya sorusunda farklı uzmanları tetikleyebilir. Bu dinamik, mimarinin iç işleyişini anlamayı da zorlaştırıyor.

Sayılarla MoE

Llama 4 Maverick’in rakamları özellikle çarpıcı: 400 milyar parametre barındırıyor, her token için yalnızca 17 milyarı kullanılıyor. Aynı hesaplama bütçesiyle dense bir modelden çok daha geniş bir bilgi kapasitesi sunuyor. Başka bir şekilde söylersek: dense bir 17B modelle aynı çıkarım maliyetinde, 400B’lik bir model eğitebiliyorsunuz.

MoE modellerini değerlendirirken iki sayıyı ayırt etmek gerekiyor. Toplam parametre, tüm uzmanların ağırlık sayısıdır; modeli belleğe yüklemek için bu kadar VRAM gerekir. Aktif parametre ise her forward pass’te hesaba katılan kısımdır; çıkarım hızı ve FLOP bütçesi buna göre şekillenir. Toplam/aktif oranı Mixtral 8x7B’de yaklaşık 3.6:1 iken DeepSeek-V3’te 18:1’e ulaşıyor; mimarinin yıllar içinde ne kadar seyrekleştiğini bu oran özetliyor.

MoE neden daha verimli?

Verimlilik iki katmanda geliyor.

Eğitim tarafında: sabit bir hesaplama bütçesiyle MoE, dense modele kıyasla çok daha fazla parametre barındırabilir. Google’ın 2022 tarihli GLaM makalesinde bunu gösterdiler; aynı FLOP bütçesiyle eğitilen MoE, dense modeli MMLU ve diğer kıyaslamalarda geride bırakıyordu. Daha büyük kapasite, daha az hesaplama ile. Bu ilişki, sonraki yıllarda birçok çalışmayla tekrar tekrar doğrulandı.

Çıkarım tarafında: her token için yalnızca aktif uzmanlar hesaplanır. 45 milyar parametreli Mixtral 8x7B, çıkarım sürecinde 12.9 milyar parametre kullanır. Dense 13B modelle neredeyse aynı işlem yükünde, 45B model kapasitesiyle çalışır. Aynı donanım üzerinde çok daha güçlü bir model çalıştırabilirsiniz. Bu fark özellikle çıkarım altyapısı üzerine hesaplama yapanlar için önemli; tokenmale başına maliyet, toplam parametreden değil aktif parametreden oluşuyor.

Uzmanlık boyutu da var. Araştırmacılar, MoE modellerinde bazı uzmanların belirli token türleri için uzmanlaşma eğilimi gösterdiğini gözlemledi. Bir uzman İngilizce metne, diğeri Python koduna, bir başkası sayısal ifadelere daha sık tepki veriyor. Bu uzmanlaşma denetimli değil; eğitim sürecinde kendiliğinden oluşuyor. Modelin farklı görevler için farklı bilgi havuzları geliştirdiğini söylemek mümkün, ama bu yorumu aşırı kesinleştirmemek gerekiyor; araştırmacılar hâlâ bu dinamiği inceliyor ve uzmanlaşmanın tam olarak nasıl çalıştığı tartışmalı. Yine de router aktivasyonlarını analiz ederek hangi uzmanın hangi içerikte daha sık seçildiğini gözlemlemek mümkün; bu yorumlanabilirlik çalışmaları, modelin davranışını anlamak için değerli bir pencere açıyor.

Dezavantajlar ve zorluklar

MoE bir bedel ödetir. Bu bedel çıkarım sürecinde değil, donanım gereksiniminde gizli.

Bellek sorunu birinci sırada. MoE’de tüm uzmanlar bellekte tutulmak zorunda. Token başına sadece 2 uzman çalışsa da kalan 6 uzman VRAM’de varlığını korur. Mixtral 8x7B, fp16 formatında yaklaşık 90GB VRAM ister. Bu, tek bir tüketici GPU’sunun çok üzerinde; iki veya dört GPU’ya ihtiyaç duyarsınız, ya da kuantizasyon zorunlu hale gelir.

İnce ayar da daha karmaşık. Dense modelde tüm parametreler her örnekten öğrenir. MoE’de router hangi uzmanı seçerse yalnızca o güncellenir. Az veriyle yapılan ince ayarda bazı uzmanlar hiç güncellenmeyebilir; bu, özellikle domain-specific fine-tuning senaryolarında öngörülemeyen sonuçlara yol açabilir. Bu yüzden MoE modellerine ince ayar uygularken daha büyük veri setleri, dikkatli load balancing ve bazen farklı öğrenme hızı planlaması gerekiyor. Pratikte yaygın iki strateji var: router ağırlıklarını eğitim sırasında dondurup yalnızca FFN ağırlıklarını güncellemek ve LoRA gibi parametre-verimli yöntemlerde uzman başına ayrı adaptör yerine paylaşımlı tek bir adaptör kullanmak. Paylaşımlı adaptör bellek açısından daha ekonomik ama kalite kaybı yaşanabiliyor; hangi stratejinin işe yaradığı göreve ve veri miktarına bağlı. Üçüncü bir yol da MoE’nin geniş kapasitesini daha küçük bir dense modele aktarmak: knowledge distillation bu amaçla kullanılıyor ve DeepSeek-R1 ailesi bunu somutlaştırdı; 671B’lik MoE modelinden Llama 8B ve Qwen 32B gibi dense modellere damıtma yapıldı.

Dağıtık hesaplamada da koordinasyon maliyeti var. Birden fazla GPU veya sunucuya yayılan MoE modellerinde, hangi uzmanın hangi cihazdaki hesabı yapacağını düzenlemek için iletişim ek yükü oluşur. Bu “all-to-all” iletişim, bazı senaryolarda performans darboğazı yaratabilir. Pratik olarak: Mixtral 8x7B’yi 4 GPU’ya böldüğünüzde, GPU’lar arasındaki iletişim her forward pass’te gerçekleşmek zorunda. Token ve uzman sayısı arttıkça bu iletişim maliyeti orantılı büyür; yüksek uzman sayılı modellerde NVLink veya InfiniBand gibi hızlı bağlantılar bu yüzden kritik hale geliyor. Tensor parallelism ile model parallelism arasındaki denge, MoE dağıtımının en karmaşık kısımlarından biri.

Bellek konusunda bir ayrıntı daha: MoE’de dikkat katmanlarının KV cache yükü, uzun bağlamlarda toplam bellek denklemine ayrıca ekleniyor. DeepSeek-V3 bu sorunu Multi-head Latent Attention (MLA) tekniğiyle ele aldı; MLA, KV cache boyutunu belirgin biçimde küçülterek uzun bağlamda bellek kullanımını düşürüyor. Ayrıntısı MLA yazısında var.

Gerçek dünya modelleri

MoE artık niş bir araştırma konusu değil. Bugün aktif olarak kullanılan güçlü modellerin büyük kısmı bu mimariyi temel alıyor.

Mistral AI’nin 2023 sonunda duyurduğu Mixtral 8x7B ve 8x22B, açık ağırlık olarak yayınlandı. 8x7B versiyonu çıkarımda 12.9B aktif parametre kullanırken GPT-3.5’e yakın performans gösterdi. O dönem için bu rakam önemliydi; daha az hesaplamayla daha büyük modelin kapasitesini elde etmek mümkün olduğunu somut biçimde kanıtladı ve açık kaynak topluluğunda MoE mimarisine olan ilgiyi hızla artırdı.

Meta’nın 2026’da duyurduğu Llama 4 Scout ve Maverick açık ağırlıkla erişilebilir durumda. Scout 109B toplam / 17B aktif, Maverick 400B toplam / 17B aktif parametre kullanıyor; her iki modelde 16 uzman bulunuyor ve Top-1 yönlendirme tercih edilmiş. Maverick’in rakamları özellikle ilginç: 400 milyar parametrelik model kapasitesi, 17 milyar aktif parametre bütçesiyle çalışıyor. Her ikisi de çok uzun bağlam penceresi (1M token) destekliyor.

Google, Gemini 1.5 Pro ve Flash konusunda resmi bir açıklama yapmadı. Araştırmacılar MoE tabanlı olduğuna dair güçlü kanıtlar sundu; 1 milyon token bağlam penceresi bu mimariyle çok daha tutarlı ve makul bir hal alıyor. Dense bir yapıyla bu ölçekte bağlam tutmak hem maliyet hem performans açısından çok daha zor olurdu.

xAI’nin Grok-1’i 314 milyar parametreli MoE mimarisiyle açık ağırlık olarak yayınlandı. GPT-4’ün de MoE kullandığı yaygın biçimde iddia ediliyor, ama OpenAI bu konuda hiçbir resmi açıklama yapmadı.

DeepSeek-V3, 671 milyar toplam ve yaklaşık 37 milyar aktif parametre ile çalışıyor. DeepSeek bu modelde özel bir varyant geliştirdi: “fine-grained MoE” ve “shared experts” kombinasyonu. Yük dengelemeyi de farklı ele aldılar; klasik auxiliary loss yerine her batch’te uzmanlara dengeli token dağılımını zorlayan bir kısıt mekanizması kullanıldı. Çoklu GPU dağıtımındaki all-to-all iletişim darboğazı için de özel optimizasyonlar geliştirildi. Her iki tekniği bir arada kullanmak hem maliyet hem performans açısından dikkat çekici sonuçlar verdi ve bu modelin eğitim maliyetinin, benzer büyüklükteki rakiplerine kıyasla çok daha düşük olduğunu raporladılar. DeepSeek serisinin akıl yürütme tarafını o3 ve DeepSeek-R1 üzerine yazımızda inceleyebilirsiniz.

Nasıl çalıştırırsın?

MoE modellerini yerel ortamda çalıştırmanın en pratik yolu Ollama ve llama.cpp. Her iki araç da GGUF formatında kuantize MoE modellerini destekliyor. Önemli bir ayrıntı: llama.cpp, çok büyük MoE modellerinde otomatik olarak belirli katmanları GPU’ya, kalanları CPU’ya offload edebilir; bu da GPU VRAM sınırını kısmen aşmanızı mümkün kılar.

# Mixtral 8x7B çekme
ollama pull mixtral:8x7b

# Çalıştırma
ollama run mixtral:8x7b

Kuantizasyon seçenekleri ve yaklaşık boyutlar:

Yalnızca CPU ile de çalışabilirsiniz ama hız beklentinizi düşürmelisiniz: Q4_K_M formatında 20-50 token/sn yerine 1-3 token/sn civarında değerler görürsünüz. Büyük RAM’i olan bir makine (64GB+) genellikle Q4_K_M’yi makul hızda kaldırabilir; GPU olmak zorunda değil.

Üretim ortamında ise MoE-farkındalıklı çıkarım motorları devrede. vLLM, TensorRT-LLM ve llama.cpp expert parallelism destekliyor: her GPU belirli uzmanları barındırıyor, bir token hangi uzmanları gerektiriyorsa ilgili GPU’lardan çıktılar toplanıp birleştiriliyor. Koordinasyonu karmaşık, ama büyük MoE modellerini kullanılabilir kılmanın pratik yolu bu. Mixtral’ı vLLM ile çok GPU’lu çalıştırmak tek satır:

vllm serve mistralai/Mixtral-8x7B-Instruct-v0.1 \
  --tensor-parallel-size 4 \
  --dtype bfloat16

Tek GPU senaryosunda GGUF, GPTQ veya AWQ gibi formatlarla sıkıştırma şart; ayrıntılar model kuantizasyonu rehberinde.

Büyük MoE modellerini çalıştırmak istiyorsanız Llama 4 Maverick (400B) gerçekten büyük bir makine gerektiriyor. Q4_K_M formatında dahi yaklaşık 200GB bellek istiyor; bu noktada ya çok büyük bir sunucu ya da birden fazla GPU ile distributed çalıştırma gerekiyor. Daha erişilebilir bir başlangıç noktası Mixtral 8x7B Q4_K_M.

MoE mu, dense mi? Pratik karar rehberi

Bulut tarafında önemli bir not: birçok büyük API sağlayıcı arka planda MoE modeli çalıştırıyor. Toplam parametre sayısı değil aktif parametre sayısı hesaplama maliyetini belirlediği için, aynı kalite seviyesindeki MoE tabanlı bir API, dense bir modele kıyasla daha düşük maliyet sunabiliyor.

Bundan sonrası

MoE olgunlaşmış bir mimari ama evrim sürüyor.

“Fine-grained MoE” yaklaşımında uzman başına parametre sayısı düşürülüyor, karşılığında çok daha fazla uzman kullanılıyor. DeepSeek-V3 bunu 256 uzmanla denedi (her token için 8’i aktif). Mixtral’ın 8 uzmanı vardı ve her token 2 tanesini kullandı. 256 uzman ve 8 aktif uzman kombinasyonu çok daha ince bir uzmanlaşma olanağı tanıyor; her uzman daha dar bir alana odaklanabiliyor.

“Shared experts” başka bir yön: bazı uzmanlar her token için her zaman aktive edilirken routing yalnızca geriye kalan uzmanlar üzerinde çalışıyor. Ortak temel bilgiyi korurken uzmanlaşmayı da mümkün kılıyor. DeepSeek bu tekniği özellikle başarıyla uyguladı.

MoE ve uzun bağlam (long context) kombinasyonu da aktif araştırma alanı. 1 milyon token bağlam için dense mimaride devasa bir dikkat mekanizması gerekiyor; MoE bu yükü katmanlar arasında dağıtmak için doğal bir zemin sunuyor.

Üç fikir daha ufukta. Conditional compute, seyrekliği katman eksenine taşıyor: her token yalnızca hangi uzmanları değil, kaç katmandan geçeceğini de dinamik olarak belirleyebiliyor. Soft MoE, discrete Top-K seçimi yerine sürekli (continuous) routing kullanıyor; her token tüm uzmanlara farklı ağırlıklarla katkıda bulunuyor, eğitim stabilitesi açısından umut vaat ederken çıkarım karmaşıklığını artırıyor. Mixture of Agents ise aynı prensibi bir soyutlama düzeyi yukarı çıkarıyor: “uzman” rolünü tek modelin alt-ağları değil, router ile orkestra edilen ayrı modeller üstleniyor.

Büyük modellerin neden bu kadar hızlı ilerlediğini merak ediyorsanız, bir parçası burada. Parametre sayısı değil, ne kadarının ne zaman aktive edildiği belirleyici hale geldi. Bu soruya verilen yanıt, önümüzdeki nesil modellerin biçimini şekillendirmeyi sürdürüyor.