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 sağlamak anlamına gelir. Moonshot, açık ağırlıkları MXFP4 formatında yayınlamıştır; bu format ağırlık başına yaklaşık yarım baytlık bir yer kaplar. Dolayısıyla, tek bir token önbelleği bile ayırmadan önce ağırlıklar tek başına yaklaşık 1.4 TB yer tutar. Günümüzde satışta olan hiçbir hızlandırıcı, bu veriyi tek başına barındıramaz. Tek bir GPU için cevap hayırdır. Tek bir sunucu için ise cevap iki farklı biçimde evettir. Birincisi, 288 GB hızlandırıcılara sahip 8 GPU'lu bir düğümdür; bu, yayınlanan en küçük çok kullanıcılı servis tariflerinde kullanılan yapıdır. İkincisi ise, Unsloth'un kayıpsız Q8 GGUF formatını llama.cpp üzerinde çalıştıran, GPU olsun veya olmasın, aynı anda tek bir kullanıcıya hizmet veren ve toplamda yaklaşık 1.6 TB RAM ve VRAM birleşimine sahip bir makinedir.

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. 16 Temmuz 2026 tarihindeki duyurudan sonraki haftalarda çeşitli altyapı sağlayıcıları K3 dağıtım kılavuzları yayınladı ve her biri zaten bir kümeye sahip olduğunuzu varsaydı. Bu sayfa ise 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 parametre sayısı ile aktif parametre sayısı aynı 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 896 yönlendirilmiş uzmandan (her token için 16 tanesi çalışır) oluşan, toplam 2.8T parametre ve token başına 104B aktif parametre olduğunu belirtir.

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 yoğun bir modelden ziyade 104B yoğun bir modele benzer. MoE mimarisinin oluşturulmasının temel 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 hızlı bir yerde depolanması gerekir. Yalnızca aktif uzmanları VRAM'de tutup geri kalanını talep üzerine getirme yöntemi mevcuttur: llama.cpp'nin --moe-cache-mib özelliği, aksi takdirde sistem RAM'inde bulunan uzmanların bir GPU önbelleğini tutar ve yönlendirici seçtikçe eksik olanları yükler. Ancak bu, toplam boyutu küçültmez. Uzmanların geri kalanı hala RAM'de bulunmak zorundadır ve bir PCIe bağlantısı, HBM'nin terabayt/saniye hızına kıyasla saniyede onlarca gigabayt veri taşır; bu nedenle her önbellek ıskalaması (cache miss) zaman kaybettirir. Model RAM'e de sığmadığı için uzmanları NVMe üzerinden akıtmak daha da yavaştır ve Unsloth'un K3 kılavuzu, diskten yükleme (offloading) işleminin çok daha yavaş çalıştığı konusunda uyarıda bulunur.

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

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, nicemleme (quantisation) 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 verilmiştir: bf16 formatında aynı model 5.6 TB gerektirirdi. MXFP4 ayrıca her 32 ağırlık bloğu için paylaşılan 8-bitlik bir ölçek saklar; bu da yaklaşık yüzde 6'lık bir ek yük getirir. Moonshot yapılandırması; dikkat (attention), paylaşılan uzmanlar (shared experts) ve görüntü kulesini (vision tower) 4-bit formatının dışında tutar. Bu nedenle tam kontrol noktası (checkpoint), temiz bir 1.4 TB yerine Unsloth hesaplamasına göre yaklaşık 1.56 TB boyutundadır.

Bu durum, alışılagelmiş kaçış yolunu kapatmasa da daraltır. Yayınlanan kontrol noktası halihazırda 4-bit olduğundan, kolay tasarruf zaten yapılmıştır; ancak daha düşük seviyelere inmek rakamı değiştirmeye devam eder. 27 Ekim 2026 itibarıyla, Unsloth tarafından ölçülen dinamik GGUF K3 nicemlemeleri, 2-bit UD-Q2_K_XL için 861.3 GB'tan başlayıp 1-bit UD-IQ1_S için 594 GB'a kadar inmektedir. Unsloth bunların maliyetini de yayınlamaktadır: tam model ile ilk token uyumu UD-Q2_K_XL'de yüzde 90.390, 711.1 GB'lık UD-IQ2_XXS'de yüzde 84.127 ve UD-IQ1_S'de yüzde 78.875'tir. Hugging Face deposunda ayrıca, yanında herhangi bir uyum verisi yayınlanmamış olan, UD-Q1_0 için 466 GB'a kadar inen daha küçük 1-bit dosyalar da bulunmaktadır. Bu, ölçülebilir bir doğruluk kaybıdır ve en küçük dosya bile hala en büyük tek kartın yaklaşık 1.6 katı büyüklüğündedir.

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 ayrılan alanı içermez. Bölünme işleminin eşit olması gerekmez: vLLM'in pipeline paralelliği modeli katmanlar boyunca böler ve eşit olmayan bölünmeleri destekler; SGLang'in K3 prefill tarifleri ise 93 katman üzerinde 8 ve 16 pipeline aşaması çalıştırır.

Yayınlanan kılavuzlar bu alt sınırın üzerindedir. Moonshot'ın lansman kılavuzu, 64 veya daha fazla hızlandırıcıdan oluşan bir süper düğüm önermiştir. 27 Ekim 2026 itibarıyla SGLang yemek kitabı, 18 kartlık alt sınıra karşılık, dört adet 8-GPU düğümünden oluşan, toplam 32 GPU ve 2.560 GB toplam belleğe sahip bir H100 yapılandırması sunmaktadır. Ayrıca, kart başına 288 GB ile 2.304 GB kapasiteli, tek bir 8-GPU B300 düğümü ve bir 8-GPU MI350X veya MI355X düğümü üzerinde çalışan tek düğümlü tarifleri de listelemektedir. Alt sınırın üzerindeki 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 seçenek olan 5 GB300 sınıfı kartlar, pratikte tam olarak bu tür 8-GPU'lu düğümlere yuvarlanır; bu da çok kullanıcılı K3 sunum tarifi yayınlanan en küçük makine boyutudur.

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 mekanizması için formül bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element şeklindedir; bu değeri 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 değerler 2 64 8 128 1 = 131,072 bayt, yani token başına 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 ağırlık bile yüklenmeden önce tek bir sohbet için 288 GB'lık bir kartın neredeyse yarısıdır.

K3 standart dikkat mekanizmasını kullanmaz; son rakamın nedeni 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 düşük dereceli tek bir gizli vektörde sıkıştırır. Bu nedenle gerçek token başına maliyet, örnek hesaplamanın çok altına düşer. Moonshot tarafından yayınlanan config.json dosyası bu gizli vektörün boyutunu verir: 512'lik bir kv_lora_rank ve 64 genişliğinde döner anahtar (qk_rope_head_dim), yani MLA katmanı başına token başına 576 değer. Her biri 2 bayt olan 24 katman boyunca bu değer 27,648 bayt, yani token başına yaklaşık 27 KiB veya sabit KDA durumu hariç, 1,048,576 tokenlık tam bir sohbet için yaklaşık 27 GiB eder. Bunu bir ölçümden ziyade bir tahmin olarak değerlendirin: motorlar önbelleği kendi yöntemleriyle doldurur ve düzenler; 8-bitlik bir önbellek bu boyutu kabaca yarıya indirir.

Kendi dağıtımınızın ne kadar bellek tuttuğunu görmek için --max-model-len değerini artırırken nvidia-smi değerini izlemeyin. vLLM, KV önbellek havuzunu önceden ayırır; bu havuzun boyutu --gpu-memory-utilization (mevcut belgelerde varsayılan olarak 0.92) veya GPU başına açık bir önbellek bütçesi ile belirlenir. Bu nedenle toplam GPU belleği, tek bir sohbeti değil, havuzun tamamını gösterir. Bunun yerine, vLLM'in KV önbellek boyutunu token cinsinden ve bağlam uzunluğunuzdaki maksimum eşzamanlılığı rapor ettiği başlangıç loglarını okuyun.

Akıl yürütme biçimi bir sonraki sürümde de varlığını korur. Bir model bir milyon tokenlık bağlam sunuyor ve dikkat tasarımı hakkında hiçbir şey belirtmiyorsa, aksi kanıtlanana kadar önbelleğin kısıtlayıcı faktör olduğunu varsayın.

Katman 1: kümeyi saatlik olarak kiralama

Bu katman, K3'ü yayınlanan hassasiyetinde aynı anda birçok kullanıcıya sunan katmandır. Yeterli RAM'e sahip tek bir makine, Unsloth'un Q8 GGUF formatı aracılığıyla K3'ü yayınlanan hassasiyetinde barındırabilir; Unsloth bunu tam hassasiyetli kayıpsız olarak tanımlar ancak bu yöntem aynı anda tek bir kullanıcıya hizmet verir ve 2. katmanda ele alınmıştır. Burada 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 ücret bir varsayımdır, teklif değildir. İsteğe bağlı (on-demand) ücretler sağlayıcıya ve GPU nesline göre büyük ölçüde değişir; tek düğümlü tarifelerin gerektirdiği 288 GB'lık parçalar saatlik bazda bir H100'den daha maliyetlidir ve rezerve edilmiş kapasite daha ucuzdur. Sağlayıcınızın güncel rakamını alın ve hesaplamayı yeniden yapın: GPU sayısı çarpı saat çarpı ücret. Tablonun amacı oranı göstermektir. Günde dört saat boyunca 8 GPU'lu bir düğümü çalıştırmanın maliyeti aylık 2,400 USD iken, SGLang boyutundaki 32 GPU'lu H100 yapılandırmasını sürekli çalıştırmanın maliyeti 57,600 USD'dir.

Her iki ana akım sunucu da model kartında 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, pipeline paralelliği için --pp-size ve uzman (expert) paralelliği için --ep-size kullanır. Tensör paralelliği ile pipeline paralelliğinin çarpımı sahip olduğunuz GPU sayısına eşit olmalıdır; uzman paralelliği ise uzmanları bu grup içinde böler, bu nedenle 32 GPU'lu H100 tarifi hem --tp-size 32 hem de --ep-size 32 değerlerini ayarlar.

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 haftalardaki yaygın hata, çalışma zamanının (runtime) modelden daha eski olmasıydı. K3, kararlı vLLM ve SGLang sürümlerinin lansman anında içermediği KDA ve yeni bir MoE katmanı ile yayınlandı; bunun belirtisi, sunucunun başlatma sırasında Model architectures [...] are not supported for now biçiminde bir satırla sonlanmasıdır. Hiçbir yapılandırma değişikliği bunu düzeltemez, çünkü bu katmanları çalıştıracak kod derlemenizde mevcut değildir. Bu durum değişti: 27 Ekim 2026 itibarıyla SGLang, v0.5.17 sürümünden bu yana K3 desteğini sürümlerinde barındırmaktadır (en günceli v0.5.22'dir) ve vLLM'in v0.28.0 ile v0.32.0 arasındaki sürüm notlarının tümü K3 çalışmalarını içermektedir. Güncel bir sürüm yükleyin. Bazı donanıma özgü yollar hala özel bir imajı işaret eder, örneğin SGLang'in Blackwell üzerindeki NVFP4 derlemeleri; bu nedenle kartınız için tarifi kontrol edin.

İ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.56 TB'lık bir indirme, ilk token üretilmeden önce yaklaşık 26 dakikalık küme süresi demektir. Ağırlıkları, örnekten daha uzun ömürlü bir birimde (volume) saklayın; böylece ikinci çalıştırma dakikalar içinde başlar.

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

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

Sığdırma kuralı, minyatür ölçekte aynı formüldü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 seviyesinde bu, parametre başına kabaca yarım bayta denk gelir ve şu rahat eşleşmeleri sağlar:

• 16 GB kart: uzun bağlam için yer bırakan 4-bit 7B model
• 24 GB kart: 4-bit 14B model
• 48 GB kart: 4-bit 32B model
• 80 GB kart: 4-bit 70B model veya 8-bit 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, 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.

K3'ün kendisini tek bir büyük makinede çalıştırmanın bir yolu vardır ve bu, bu kademe ile bir sonraki kademe arasında yer alır. Unsloth, llama.cpp içindeki K3'ün GGUF yapılarını; 1-bit ve 2-bit kuantizasyonlardan, tam hassasiyetli kayıpsız olarak etiketlediği UD-Q8_K_XL'e kadar belgeler ve bunları çalıştırabilecek donanım olarak NVIDIA DGX Station'ı işaret eder. Temel kuralı, RAM artı VRAM'in kabaca kuantizasyon boyutuna eşit olmasıdır; 1-bit UD-IQ1_S yapısı için yaklaşık 610 GB'tan Q8 için yaklaşık 1.6 TB'a kadar değişir. Bu değerin altında model diske taşar ve hızı ciddi oranda düşer. GPU isteğe bağlıdır: Unsloth'un derleme talimatları, "GPU'nuz yoksa veya sadece CPU çıkarımı yapmak istiyorsanız" CUDA'yı devre dışı bırakır. 1-bit ve 2-bit yapılar, yukarıda ölçülen doğruluk kaybı pahasına ağır şekilde kuantize edilmiş K3'tür. Q8 yapısı ise K3'ün yayınlanan hassasiyetindeki halidir ve tek bir kullanıcıya RAM hızında sunulur. Bunların hiçbiri daha küçük bir model değildir.

Ollama, GPU'ya sahip bir VPS üzerinde çalışan bir sunucuya giden en kısa yoldur:

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 bırakı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 uzaktan erişimi de içeren tam kılavuz VPS üzerinde Ollama çalıştırma bölümündedir.

llama.cpp, kuantizasyon ve offload ü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ışması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ığmayı bıraktığı anda üretim hızı bir büyüklük derecesinde düşer. İki araç arasındaki farklar Ollama ve llama.cpp karşılaştırması bölümünde ele alınmıştır.

Tier 3: barındırılan API, kendi kendine 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 temel URL değiştirildikten sonra mevcut bir istemci ç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."}]}'

Çalışan bir anahtar, choices dizisine sahip bir JSON nesnesi döndürür. 401 hatası, kimlik doğrulamanın başarısız olduğu anlamına gelir: anahtarın doğru olduğunu, süresinin dolmadığını veya devre dışı bırakılmadığını ve başlığın Authorization: Bearer ifadesini ve ardından anahtarı içerdiğini kontrol edin. 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ıdaki varsayılan kiralama oranını kullanarak başa baş noktasına bakalım. Sürekli açık olan 8 GPU'lu bir düğüm ayda 14,400 USD maliyetindedir ve milyon çıktı token'ı başına 15.00 USD fiyatla, aynı para API'den yaklaşık 960 milyon çıktı token'ı satın alabilir. Maliyet açısından avantaj sağlamak için ayda yaklaşık bir milyar, 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 faturalandırılır. İstem ağırlıklı aracı iş yükleri, bu sınırı daha da uzağa taşır: tekrarlanan bağlam, 3.00 USD olan önbellek ıskalama oranı yerine 0.30 USD olan önbellek isabet oranı üzerinden faturalandırılır.

Bu katmanda kendi kendine barındırdığınız şey, modelin çevresindeki her şeydir: API anahtarını tutan ve böylece anahtarın 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 kendi kendine barındırmanın model düzeyinde mümkün olmadığı ve orkestrasyonun sahip olduğunuz tek parça olduğu kapalı ağırlıklar 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ılmış tensör ve uzman paralelliği ile aynı anda çok sayıda isteği karşılamak için tasarlanmıştır. Veri merkezi sınıfı hızlandırıcılar ve bunlar arasında hızlı bir ara bağlantı gerektirirler. 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, uzman ağırlıklarını sistem RAM'inde (--cpu-moe veya --n-cpu-moe) tutarak devasa bir MoE modelini yükleyebilir ve --moe-cache-mib ile kullandığı uzmanları GPU üzerinde önbelleğe alabilir; Unsloth'un K3 GGUF sürümlerinin tek bir makinede bu şekilde çalışmasının nedeni budur. Hız, RAM bant genişliğine ve yönlendiricinin önbelleği ne sıklıkla ıskaladığına bağlıdır; dosya, RAM ve VRAM toplamından büyükse disk kullanımına düşer. Bu, tek bir kullanıcı için uygulanabilir bir kurulumdur. Birden fazla kullanıcıyı barındırabileceğiniz 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 çok sayıda kullanıcıya mı yoksa kendi donanımınızda tek bir kullanıcıya mı hizmet verdiğinizdir.

Bu kontrol noktasından daha uzun ömürlü dört sayı

1. Toplam parametre sayısı ile ağırlık başına bayt değerinin çarpımı, bellek tabanını verir. Hiçbir şey, piyasaya sürülen hassasiyet değerinin altında çalışmaz; 4-bit sürümün altında nicemleme yapmak, doğruluk kaybı pahasına yaklaşık yüzde 70 kazanç sağlar, büyüklük mertebesinde bir değişim yaratmaz.
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ılavuzu açmadan önce doğru cevaba ulaşırsınız. Bir sonraki sürüm çoktan duyuruldu: Moonshot, 23 Ekim 2026 tarihinde Kimi Code içerisinde, K3 üzerine ek eğitimle inşa edilen K3.1 Pro sürümünü kullanıma sundu ve API hızlı başlangıç kılavuzunda tam ağırlıkların 4 Kasım'a kadar yayınlanacağı belirtiliyor. Bu nedenle, yazdığınız 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 lansman rakamları Temmuz 2026'da yayınlanmış olup, sunum tarifleri, çalışma zamanı sürümleri ve nicemleme sayıları 27 Ekim 2026 tarihinde yeniden kontrol edilmiştir.

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. K3 modelinin yayınlanan en küçük kuantizasyon sürümü olan Unsloth'un 466 GB boyutundaki UD-Q1_0 dosyası bile, piyasadaki en büyük hızlandırıcıların 288 GB kapasitesinin yaklaşık 1,6 katıdır. llama.cpp, uzmanları sistem RAM'inde tutup aktif olanları GPU üzerinde önbelleğe alabilir; ancak bu yöntem yine de RAM ve VRAM üzerinde yaklaşık kuantizasyon boyutu kadar alan gerektirir. Bu sınırın altında model diske taşar ve çalışma hızı ciddi oranda düşer. Yayınlanan en küçük sunum tarifleri, B300 veya MI350X/MI355X kartlarından oluşan 8 GPU'lu bir düğüm kullanır; H100 tarifi ise 32 GPU gerektirir.

Kimi K3 ne kadar VRAM gerektirir?

Yalnızca 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 önbelleği ve aktivasyon belleğini eklemeniz gerekir. Moonshot'ın lansman kılavuzu 64 veya daha fazla hızlandırıcı önermektedir. 27 Ekim 2026 itibarıyla SGLang yemek kitabı, 8 adet B300 veya 8 adet MI350X/MI355X kartı (toplam 2.304 GB) ve 32 GPU'lu H100 yapılandırması (toplam 2.560 GB) üzerinde tek düğümlü tarifler yayınlamaktadı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ı?

Sunulan 4-bit kontrol noktası, eğer düğüm sekiz adet 288 GB karttan oluşuyorsa (SGLang'in B300 ve MI355X tariflerinde olduğu gibi) tek bir düğüme sığar. Ayrıca Unsloth'un kayıpsız Q8 GGUF formatı ile yaklaşık 1,6 TB RAM ve VRAM içeren tek bir makinede de çalışabilir. Daha düşük değerlere inmek küçük makineler için faydalıdır: Unsloth'un ölçülen dinamik GGUF yapıları 2-bit'te 861,3 GB ile 1-bit'te 594 GB arasında değişir ve deposunda kayıpsız 1,56 TB'a kıyasla 466 GB'a kadar inen 1-bit dosyalar listelenir. Doğruluk maliyeti ölçülmüştür: tam model ile top-1 uyumu UD-Q2_K_XL'de yüzde 90,390'a, UD-IQ1_S'de ise yüzde 78,875'e düşmektedir. Bunların hiçbiri tek bir karta sığmaz.

GPU kiralamak Kimi K3 API'sini 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, 15.00 USD/milyon token olan yayınlanmış fiyat üzerinden yaklaşık 960 milyon çıktı token'ı satın alabilir. 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 değerler yerine kendi ölçtüğünüz token hacminizi baz alarak 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 iş hacmi 2,8T sınıfında değil, bu sınıfta gerçekleşir. Bellek hakkında bir şey ifade etmez: 2,8T parametrenin tamamı bellekte kalır, çünkü yönlendirici (router) herhangi bir 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 boyutunu belirlemek için ise toplam parametre sayısını kullanın.