Kimi K3 yerel sunucuda nasıl çalıştırılır?

Kimi K3 self-hosting gereksinimleri

Kimi K3 modelini kendi sunucunuzda barındırmak, 2,8 trilyon parametre için alan ayırmak anlamına gelir. Moonshot, açık ağırlıkları MXFP4 formatında yayımladı; bu da ağırlık başına yaklaşık yarım bayt demektir. Dolayısıyla, tek bir token önbelleği bile ayırmadan önce ağırlıklar tek başına yaklaşık 1.4 TB yer kaplar. Günümüzde satışta olan hiçbir hızlandırıcı (accelerator) bunu tek başına barındıramaz. K3 çok düğümlü (multi-node) bir modeldir ve tek bir sunucu için cevap olumsuzdur.

Karar budur. Aşağıdaki her şey bunun arkasındaki aritmetiktir, çünkü bu aritmetik bir sonraki sürümde tekrar kullanacağınız kısımdır. 17 Temmuz 2026 tarihindeki duyurudan sonraki haftalarda çeşitli altyapı sağlayıcıları K3 dağıtım kılavuzları yayımladı ve her biri zaten bir kümeye (cluster) sahip olduğunuzu varsaydı. Bu sayfa diğer uçtan başlar: maliyeti nedir, bunun yerine ne çalıştırabilirsiniz ve bu iki durumdan hangisinde olduğunuzu nasıl anlarsınız.

Toplam parametreler ile aktif parametreler aynı sayıda değildir

K3, bir mixture of experts (MoE) modelidir. MoE, ağı birçok alt ağa böler ve bir yönlendiricinin (router) her token için bunlardan birkaçını seçmesine olanak tanır. Model kartı, 93 katman boyunca dağıtılmış 896 yönlendirilmiş uzmandan (expert) 2.8T toplam parametre ve her token için 104B aktif parametre olduğunu belirtir; her token için bu uzmanlardan 16 tanesi çalışır.

Bu iki parametre sayısı farklı soruları yanıtlar ve bunları birbirinin yerine kullanmak, "bunu çalıştırabilir miyim" konulu her tartışmada yapılan en yaygın hatadır.

Aktif parametreler hesaplama maliyetini belirler. Bir token yaklaşık 104B parametre üzerinden çarpılır, bu nedenle beklemeniz gereken iş hacmi 2.8T'lik bir modelden ziyade 104B'lik yoğun (dense) bir modele benzer. MoE mimarisinin oluşturulmasının tüm nedeni budur.

Toplam parametreler bellek maliyetini belirler. Yönlendirici, herhangi bir token için herhangi bir uzmanı seçebilir, bu nedenle ilk istek gelmeden önce her uzmanın bellekte yerleşik olması gerekir. 104B parametreyi VRAM'de tutup geri kalanını talep üzerine getiremezsiniz; çünkü bu getirme işleminin mikrosaniye mertebesinde tamamlanması gerekir, oysa bir PCIe bağlantısı saniyede onlarca gigabayt veri taşıyabilir. Bunu deneyenler olmaktadır. Uzmanları NVMe üzerinden akışla (streaming) yüklemek, saniyede onlarca token üretmesi gereken bir modeli, birkaç saniyede bir token üreten bir modele dönüştürür.

Özetle, hesaplaması ucuz, depolaması pahalıdır. Donanım boyutlandırmasını 2.8T değerine göre, hız beklentilerinizi ise 104B değerine göre yapın.

Ağırlık başına bayt ve terabaytların kaynağı

Parametre sayısı çarpı ağırlık başına bayt. Ağırlıklar için formülün tamamı budur.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3, kuantizasyon farkındalığı ile eğitilmiş ve MXFP4 ağırlıkları ile MXFP8 aktivasyonları ile yayınlanmıştır; bu nedenle 4-bit satırı gerçek değerdir. Üstteki satırlar ölçeklendirme amacıyla eklenmiştir: bf16 formatında aynı model 5.6 TB boyutuna ihtiyaç duyardı. MXFP4 ayrıca her 32 ağırlık bloğu için 8-bitlik paylaşılan bir ölçek saklar; bu da yaklaşık yüzde 6 oranında ek yük getirir. Dolayısıyla yayınlanan depo, net 1.4 TB değerinden ziyade 1.5 TB civarındadır.

Bu durum, alışılagelmiş kaçış yolunu kapatmaktadır. "Sadece kuantize et" yaklaşımı burada işe yaramaz, çünkü yayınlanan kontrol noktası (checkpoint) halihazırda 4-bit formatındadır. 2-bit seviyesine inmek ağırlıkları 0.7 TB seviyesine getirir ve bu kontrol noktasında kimsenin ölçmediği bir doğruluk kaybına yol açar. Yine de tek bir kartın kapasitesinin çok ötesinde kalırsınız.

Kimi K3 kaç adet GPU gerektirir

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Bu değerleri hedef olarak değil, alt sınır olarak kabul edin. Bu sayılar yalnızca ağırlıkları kapsar; KV önbelleği, aktivasyon tamponları, ayırıcı parçalanması ve eşzamanlı ikinci bir istek için yer içermez. Ayrıca, 93 katman ve 896 uzman tarafından her zaman tam olarak bölünemeyen paralel bir ayrıştırma varsayarlar.

Yayınlanan kılavuzlar, bu alt sınırın oldukça üzerindedir. Ağustos 2026 itibarıyla Moonshot, 64 veya daha fazla hızlandırıcıdan oluşan bir süper düğüm önermektedir. SGLang yemek kitabı, 18 kartlık bir alt sınıra karşılık; dört adet 8-GPU düğümü, 32 GPU ve 2.560 GB toplam bellekten oluşan bir H100 yapılandırması sunmaktadır. Bu fark bir israf değildir. Bu alan; KV önbelleği, aktivasyon belleği ve sunucunun aynı anda birçok isteği işlemesine olanak tanıyan kapasite payıdır. En uygun satır olan 5 GB300 sınıfı kartlar bile, çoğu sağlayıcının tek bir SKU olarak kiralamadığı bir makineyi tanımlamaktadır.

KV önbelleği insanları şaşırtan kısımdır

Ağırlıklar sabit bir maliyettir. KV (key value) önbelleği ise sabit değildir: bağlam uzunluğuyla ve her eşzamanlı kullanıcıyla birlikte büyür. Standart dikkat (attention) mekanizması için formül bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element şeklindedir; ardından bunu bağlam uzunluğu ve eşzamanlılık ile çarparsınız.

İşte bir örnek hesaplama (bu sadece bir örnektir): 64 katman, 8 KV başlığı, 128 başlık boyutu, fp8. Bu, token başına 2 64 8 128 1 = 131.072 bayt, yani 128 KiB eder.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

128k bağlamdaki bir kullanıcı 16 GiB maliyet oluşturur. Tam bir milyon bağlamdaki bir kullanıcı ise 128 GiB maliyet oluşturur ki bu, tek bir konuşma için tek bir kartın kapasitesinden fazladır.

K3 standart dikkat mekanizmasını kullanmaz ve son rakamın nedeni de budur. 93 katmanının 69'u KDA (Kimi Delta Attention) katmanı, 24'ü ise Gated MLA (multi-head latent attention) katmanıdır. KDA, her token ile büyüyen bir önbellek yerine sabit boyutlu bir yinelemeli durum tutar; MLA ise anahtar ve değeri tek bir düşük dereceli gizli vektöre sıkıştırır. Bu sayede gerçek token başına maliyet, örnekteki hesaplamanın çok altına düşer. Moonshot, gizli boyutları yayınlamadığı için K3'ün kendisine dair kullanıcı başına bir rakam vermeyeceğim. Bunun yerine kendi ölçümünüzü yapın: sunucuyu küçük bir --max-model-len ile başlatın, nvidia-smi ile bellek kullanımını izleyin ve ardından ayırma işlemi başarısız olana kadar limiti artırın.

Akıl yürütme biçimi bir sonraki sürümde de varlığını korur. Eğer bir model bir milyon token bağlam sunduğunu iddia ediyor ancak dikkat tasarımı hakkında hiçbir şey söylemiyorsa, aksini kanıtlayan biri çıkana kadar önbelleğin kısıtlayıcı faktör olduğunu varsayın.

Katman 1: kümeyi saatlik kiralama

K3'ü bizzat çalıştıran tek katman budur. Donanımı satın almazsınız. İhtiyacınız olan saatler boyunca kiralarsınız ve sonrasında durdurursunuz.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Belirtilen oran bir teklif değil, varsayımdır. Veri merkezi hızlandırıcıları için talep üzerine liste fiyatları 2026 yılı boyunca GPU saati başına yaklaşık 2 ile 5 USD arasında seyretmiştir; rezerve kapasite ise daha ucuzdur. Sağlayıcınızın güncel rakamını alın ve hesaplamayı tekrarlayın: GPU sayısı çarpı saat çarpı oran. Tablonun amacı oranı göstermektir. Günde dört saat boyunca 8 GPU'lu bir düğümü ölçeklendirmek aylık 2,400 USD maliyet oluştururken, 32 GPU'luk SGLang yapılandırmasını sürekli çalışır durumda bırakmak 57,600 USD maliyet oluşturur.

Her iki ana sunucu da model kartı üzerinde bir başlatma komutu yayınlar.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Bu ham komutların hiçbiri gerçek bir kümede çalıştırılacak komutlar değildir. Donanımınıza uygun paralellik bayraklarını ekleyin: SGLang, tensör paralelliği için --tp-size ve uzman paralelliği için --ep-size kullanır; bunların çarpımı sahip olduğunuz gerçek GPU sayısına eşit olmalıdır.

Gerçek trafik göndermeden önce sunucunun ayağa kalktığını doğrulayın:

curl http://127.0.0.1:30000/v1/models

Sağlıklı bir sunucu, model kimliğini listeleyen bir JSON nesnesi ile yanıt verir. Connection refused, sürecin hala ağırlıkları yüklediği veya zaten sonlandığı anlamına gelir; bu nedenle yeniden denemeden önce sunucu günlüğünü okuyun.

İlk gün karşılaşılan yaygın hata, çalışma zamanının modelden daha eski olmasıdır. K3, kararlı vLLM ve SGLang sürümlerinin lansman sırasında içermediği KDA ve yeni bir MoE katmanı ile piyasaya sürülmüştür; belirtisi ise sunucunun başlatma sırasında Model architectures [...] are not supported for now biçiminde bir satırla kapanmasıdır. Bu katmanları çalıştıracak kod derlemenizde bulunmadığından, hiçbir yapılandırma değişikliği bunu düzeltmez. Model kartında belirtilen nightly sürümünü yükleyin veya ilgili katmanı içeren sürümü bekleyin.

İnsanları yanıltan bir maliyet notu: Sayaç, model hazır olduğunda değil, örnek (instance) başladığında çalışmaya başlar. 1 GB/s hızında 1.5 TB'lık bir indirme, ilk token üretilmeden önce yaklaşık 25 dakikalık küme süresi demektir. Ağırlıkları örneğin ömründen daha uzun süre kalan bir birimde (volume) saklayın; böylece ikinci çalıştırma dakikalar içinde başlar.

Katman 2: Tek bir hızlandırıcı üzerinde daha küçük bir model çalıştırma

Bu katmanda K3 çalıştırmıyorsunuz. Başlamadan önce bunu açıkça belirtin, çünkü "K3'ü yerel olarak çalıştır" konulu çoğu tartışma, bunu itiraf etmeden burada sona erer.

Sığdırma kuralı, minyatür ölçekte aynı formüle dayanır: parametre sayısı çarpı ağırlık başına bayt, artı KV önbelleği, artı yaklaşık 2 GB çalışma zamanı yükü, VRAM kapasitenizin altında kalmalıdır. 4-bit nicemlemede bu, parametre başına yaklaşık yarım bayta denk gelir ve şu rahat eşleşmeleri sağlar:

• 16 GB kart: 4-bit seviyesinde 7B model, uzun bağlam (context) için yeterli alanla
• 24 GB kart: 4-bit seviyesinde 14B model
• 48 GB kart: 4-bit seviyesinde 32B model
• 80 GB kart: 4-bit seviyesinde 70B model veya 8-bit seviyesinde 30B sınıfı MoE

Yukarıdaki her eşleşme, aynı anda tek bir istek yapıldığını varsayar. İkinci bir kişi komut gönderdiği anda her eşzamanlı yuva kendi KV önbelleğini ister; bu da Ollama'nın NUM_PARALLEL ve MAX_QUEUE ayarları ile paralel yuvalar, kuyruğa alınan istekler ve kalan VRAM arasında yaptığınız dengedir.

Ollama, GPU takılı bir VPS üzerinde çalışan bir sunucuya ulaşmanın en kısa yoludur:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run, modeli ilk kullanımda indirir ve ardından sizi bir komut satırına düşürür. Mevcut olmayan bir etiket Error: model "..." not found hatası döndürür, bu nedenle etiketleri ezberden yazmak yerine kütüphane sayfasından kopyalayın. systemd birimi ve uzak erişim dahil olmak üzere tam kılavuz VPS üzerinde Ollama çalıştırma bölümündedir.

llama.cpp, nicemleme ve offload (yük aktarımı) üzerinde size daha fazla kontrol sağlar:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99, her katmanın GPU üzerinde çalıştırılmasını ister. Yükleme günlüğünü okuyun: kaç katmanın offload edildiğini yazdırır. Sistem RAM'ine taşan katmanlar, HBM bant genişliği yerine RAM bant genişliğinde çalışır; bu nedenle model sığmadığı anda üretim hızı on kat düşer. İki araç arasındaki ödünleşimler Ollama ve llama.cpp karşılaştırması bölümünde ele alınmıştır.

Tier 3: barındırılan API, öz-barındırılan orkestrasyon

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Uç nokta OpenAI ile uyumludur; bu nedenle mevcut bir istemci, base URL değiştirildikten sonra çalışır.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Geçerli bir anahtar, choices dizisini içeren bir JSON nesnesi döndürür. 401 hatası, anahtarın yanlış olduğunu veya Bearer önekinin eksik olduğunu belirtir. Model bulunamadı hatası genellikle kimliğin değiştiği anlamına gelir; çünkü sağlayıcılar kontrol noktaları arasında kimlikleri kullanımdan kaldırır.

Şimdi yukarıda varsayılan kiralama oranını kullanarak başa baş noktasına bakalım. Sürekli çalışan 8 GPU'lu bir düğüm ayda 14,400 USD maliyetindedir. Milyon çıktı token'ı başına 15.00 USD fiyatla, aynı parayla API'den yaklaşık 960 milyon çıktı token'ı alınabilir. Maliyet avantajı sağlamak için ayda bir milyara yakın, yani günde yaklaşık 30 milyon çıktı token'ı üretmeniz ve kümeyi sürekli meşgul tutmanız gerekir; çünkü boşta kalan GPU'lar da meşgul olanlarla aynı oranda ücretlendirilir. İstem ağırlıklı aracı iş yükleri bu sınırı daha da ileri taşır: tekrarlanan bağlam, 3.00 USD olan önbellek ıskalama oranı yerine 0.30 USD olan önbellek isabet oranı üzerinden ücretlendirilir.

Bu katmanda öz-barındırdığınız şey, modelin etrafındaki her şeydir: API anahtarını tutan ve istemciye asla ulaşmamasını sağlayan bir ağ geçidi, istek ve yanıt günlükleri, yeniden denemeler, hız sınırları ve kullanıcı başına bütçeler. Bu yapı, GPU'su olmayan küçük bir VPS üzerinde çalışır. Aynı ayrım, Claude'u öz-barındırmanın model düzeyinde mümkün olmadığı ve yalnızca orkestrasyon kısmının size ait olduğu kapalı ağırlıklı modeller için de geçerlidir.

Hangi sunum yığını hangi katmana aittir

vLLM ve SGLang sınıfı sunucular 1. katmana aittir. Bu sunucular; sürekli toplu işleme (continuous batching), sayfalandırılmış KV önbelleği ve birden fazla düğüme yayılan tensör ve uzman paralelliği ile aynı anda birçok isteğe hizmet vermek için tasarlanmıştır. Veri merkezi hızlandırıcılarını ve bunlar arasında hızlı bir ara bağlantı yapısını temel alırlar. Tek bir tüketici sınıfı ekran kartında kurulumları daha zahmetlidir ve fark edilebilir bir avantaj sağlamazlar.

llama.cpp ve Ollama 2. katmana aittir. Bu araçlar tek bir makineyi, GGUF nicemlemeyi (quantisation), model sığmadığında CPU üzerinde çalıştırmayı ve düşük eşzamanlılığı hedefler. llama.cpp teknik olarak katmanların çoğunu sistem RAM'inde tutarak devasa bir MoE modelini yükleyebilir; ancak 2.8T boyutundaki bir model için bu yöntemle her bir token üretimi saniyeler sürer. Bu durum dosyanın ayrıştırılabildiğini kanıtlar, ancak kullanıcıların erişimine sunulabilecek bir servis değildir. Tam karşılaştırma Ollama ve vLLM karşılaştırması bölümünde yer almaktadır ve bu durum modelden bağımsızdır: temel soru her zaman paylaşımlı donanım üzerinde birçok kullanıcıya mı yoksa kendi donanımınızda tek bir kullanıcıya mı hizmet verdiğinizdir.

Bu kontrol noktasından sonra geçerliliğini koruyan dört sayı

1. Toplam parametre sayısının ağırlık başına bayt değeriyle çarpımı, bellek tabanını verir. Hiçbir şey bu değerin altında çalışmaz ve sürüm halihazırda 4-bit seviyesine indirgendiğinde, hiçbir nicemleme (quantization) hilesi bu sınırı önemli ölçüde değiştirmez.
2. Aktif parametreler, iş hacmi sınıfını belirler. 104B aktif parametreye sahip 2.8T MoE modeli, 104B bir model gibi hesaplama yapar.
3. Token başına KV cache, bağlam uzunluğu ve eşzamanlılık ile çarpıldığında, ağırlıklar için ödeme yaptıktan sonra artmaya devam eden maliyeti oluşturur.
4. Dolar başına saniye bazlı token sayısı, bir katmanı seçmenizi sağlayan tek sayıdır. Yukarıdaki her şey, bu değerin girdisidir.

Bu dört maddeyi herhangi bir sürüme uyguladığınızda, bir tedarikçi kılavuzunu açmadan önce doğru cevaba ulaşırsınız. Ardından, not ettiğiniz her rakama tarih ekleyin. Fiyatlar ve desteklenen mimari listeleri, K3 piyasaya sürüldükten sonraki iki hafta içinde değişti; bu sayfadaki her sayı Temmuz 2026'da yayınlanan verilerdir.

FAQ

Kimi K3 modelini tek bir GPU üzerinde çalıştırabilir miyim?

Hayır. Moonshot tarafından sunulan MXFP4 hassasiyetindeki ağırlıklar yaklaşık 1.4 TB boyutundadır ve piyasadaki en büyük tekil hızlandırıcı 288 GB kapasiteye sahiptir. Bir MoE modeli, aktif olmayan uzmanlarını diskten kullanılabilir bir hızda yükleyemez; çünkü yönlendirici (router) her bir token için herhangi bir uzmanı seçebilir ve PCIe üzerinden veri çekme süresi, token bütçesinin izin verdiğinden çok daha uzundur. En küçük mantıklı K3 kurulumu çoklu GPU içeren bir düğümdür ve yayınlanan tarifler 32 veya daha fazla hızlandırıcı kullanılmasını önermektedir.

Kimi K3 ne kadar VRAM gerektirir?

Sadece ağırlıklar için 1.4 TB ile başlayın; bu da 18 adet H100 80GB kart veya 5 adet GB300 sınıfı karta denk gelir. Bunun üzerine KV cache ve aktivasyon belleğini eklemeniz gerekir. Ağustos 2026 itibarıyla Moonshot 64 veya daha fazla hızlandırıcı önermektedir. SGLang yemek kitabı, 2.560 GB toplam kapasiteye sahip 32 adet H100 GPU yapılandırması yayınlamıştır; bu nedenle ağırlık değerini bir gereksinimden ziyade alt sınır olarak kabul edin.

Kuantizasyon, Kimi K3 modelini tek bir düğüme sığdırır mı?

Verimli bir şekilde hayır. Yayınlanan kontrol noktası (checkpoint), kuantizasyon farkındalıklı eğitim ile zaten 4-bit halindedir, yani kolay tasarruf zaten yapılmıştır. 2-bit seviyesine düşürmek ağırlıkları 0.7 TB seviyesine getirir ki bu hala en büyük kartın iki katından fazladır; ayrıca 2-bit seviyesindeki doğruluk kaybı bu model üzerinde ölçülmemiştir.

GPU kiralamak Kimi K3 API kullanmaktan daha mı ucuzdur?

Sadece yüksek ve istikrarlı bir hacimde. GPU saati başına 2.50 USD varsayıldığında, sürekli çalışan 8 GPU'lu bir düğüm ayda 14,400 USD maliyet oluşturur. Aynı tutar ile, milyon token başına 15.00 USD olan yayınlanmış fiyat üzerinden yaklaşık 960 milyon çıktı tokenı satın alınabilir. Ayrıca boşta geçen saatler, ağırlık indirmeleri ve kümeyi ayakta tutan personel için de ödeme yaparsınız. Ani yükler için saatlik kiralama yapın ve tahmini bir değer yerine kendi ölçtüğünüz token hacminizle karşılaştırma yapın.

104B aktif parametre hız açısından ne anlama gelir?

Bu, token başına yapılan aritmetik işlemin 104B'lik bir modelin işlemi olduğu anlamına gelir; dolayısıyla verim (throughput) 2.8T sınıfında değil, bu sınıfta gerçekleşir. Bellek hakkında ise bir şey ifade etmez: 2.8T parametrenin tamamı bellekte kalmalıdır, çünkü yönlendirici her token için herhangi bir uzmanı çağırabilir. Saniye başına token sayısını tahmin etmek için aktif parametre sayısını, VRAM boyutlandırması için ise toplam parametre sayısını kullanın.