Kimi K3 self-host etmek için ne gerekir?

Kimi K3'ü self-host etmek için gerekenler

Kimi K3'ü self-host etmek için 2.8 trilyon parametreyi barındıracak alan gerekir. Moonshot, açık ağırlıkları MXFP4 biçiminde yayımladı. Bu biçimde ağırlık başına yaklaşık yarım byte kullanılır. Bu nedenle yalnızca ağırlıklar, tek bir cache token'ı için alan ayırmadan önce yaklaşık 1.4 TB yer kaplar. Günümüzde satışta olan hiçbir accelerator bu veriyi tek başına barındıramaz. K3, birden fazla node gerektiren bir modeldir. Tek sunucu için yanıt olumsuzdur.

Sonuç budur. Aşağıda bu sonuca götüren hesaplama açıklanmaktadır. Çünkü sonraki release için yeniden kullanacağınız bölüm hesaplamadır. Birkaç infrastructure vendor, 17 July 2026 tarihinde yapılan duyurudan sonraki haftalarda K3 deployment guide yayımladı. Bu kılavuzların her biri, zaten bir cluster sahibi olduğunuzu varsayıyordu. Bu sayfa konuya diğer uçtan yaklaşır: bunun maliyeti nedir, bunun yerine ne çalıştırılabilir ve bu iki durumdan hangisinde olduğunuz nasıl anlaşılır?

Toplam parametre sayısı ile etkin parametre sayısı aynı değildir

K3, mixture of experts modelidir. MoE (mixture of experts), ağı birçok alt ağa böler ve bir router'ın her token için bunlardan birkaçını seçmesini sağlar. Model kartında 2.8T toplam parametre ve token başına etkinleştirilen 104B parametre listelenir. Bu yapı, 93 katmana dağılmış 896 routed expert içinden her token için 16 tanesinin çalıştırılmasıyla oluşturulur.

Bu iki parametre sayısı farklı sorulara yanıt verir. Bunları birbirinin yerine kullanmak, her "bunu çalıştırabilir miyim" başlığında yapılan en yaygın hatadır.

Etkin parametreler hesaplama maliyetini belirler. Bir token yaklaşık 104B parametre üzerinden hesaplanır. Bu nedenle beklenmesi gereken throughput, 2.8T parametreli dense modelden çok 104B parametreli bir modele benzer. MoE model oluşturulmasının temel nedeni budur.

Toplam parametreler bellek maliyetini belirler. Router herhangi bir token için herhangi bir expert'i seçebilir. Bu nedenle ilk istek gelmeden önce tüm expert'lerin bellekte hazır bulunması gerekir. VRAM üzerinde 104B parametreyi tutup geri kalanını gerektiğinde getirmek mümkün değildir. Çünkü bu aktarımın mikrosaniyeler içinde tamamlanması gerekir ve bir PCIe bağlantısı saniyede yalnızca onlarca gigabayt aktarabilir. Bu yöntem yine de denenmektedir. Expert'leri NVMe üzerinden stream etmek, saniyede onlarca token üretmesi gereken bir modeli birkaç saniyede bir token üreten bir modele dönüştürür.

Sonuç olarak hesaplama maliyeti düşüktür, depolama maliyeti ise yüksektir. Donanımı 2.8T parametreye göre boyutlandırın. Hız beklentilerinizi ise 104B parametreye göre belirleyin.

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

Parametre sayısı ile ağırlık başına bayt sayısının çarpımı kullanılır. 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, quantisation-aware olarak eğitildi ve MXFP4 ağırlıkları ile MXFP8 aktivasyonları kullanılarak yayımlandı. Bu nedenle gerçek satır 4 bitlik satırdır. Üstündeki satırlar karşılaştırma amacıyla verilmiştir: aynı model bf16 kullanılarak çalıştırılsaydı 5.6 TB alan gerektirirdi. MXFP4 ayrıca her 32 ağırlıktan oluşan blok için ortak bir 8 bitlik ölçek değeri saklar. Bu, yaklaşık yüzde 6 ek yük oluşturur. Bu nedenle yayımlanan repository, tam olarak 1.4 TB yerine 1.5 TB değerine daha yakındır.

Bu durum, yaygın kaçış yolunu ortadan kaldırır. "Sadece quantise edin" yaklaşımı burada işe yaramaz, çünkü yayımlanan checkpoint zaten 4 bittir. 2 bite düşürülürse ağırlıklar 0.7 TB boyutuna iner, ancak bu checkpoint üzerinde doğruluk kaybını ölçen bir çalışma bulunmamaktadır. Yine de tek bir kartın kapasitesinin çok üzerinde kalır.

Kimi K3 için kaç GPU gerekir

[
  {
    "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ğerler hedef değil, alt sınır olarak değerlendirilmelidir. Yalnızca ağırlıkları hesaba katar. KV cache, aktivasyon arabellekleri, allocator parçalanması ve aynı anda ikinci bir isteği işlemek için gereken kapasiteyi kapsamaz. Ayrıca 93 katmanın ve 896 uzmanın her zaman eşit şekilde bölünmesine olanak veren bir paralel bölme varsayar.

Yayımlanan öneriler 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 supernode önerir. SGLang cookbook ise dört adet 8-GPU düğümden, toplam 32 GPU ve 2,560 GB bellektan oluşan bir H100 yapılandırması sunar. Bu yapılandırma, 18 kartlık alt sınırın üzerindedir. Aradaki fark israf değildir. Bu kapasite KV cache, aktivasyon belleği ve sunucunun aynı anda çok sayıda isteği batch işlemesine olanak veren payı karşılar. En avantajlı satır olan 5 GB300 sınıfı kartlar bile çoğu sağlayıcının tek bir SKU olarak kiralamadığı bir makineyi ifade eder.

KV önbelleği, kullanıcıları şaşırtan bölümdür

Ağırlıklar sabit bir maliyettir. KV (key value) önbelleği ise sabit değildir: bağlam uzunluğuyla ve eşzamanlı her kullanıcıyla birlikte büyür. Standart attention için formül bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element şeklindedir. Ardından bu değer bağlam uzunluğuyla ve eşzamanlı kullanıcı sayısıyla çarpılır.

Aşağıda hesaplanmış bir örnek yer alır; bu yalnızca bir örnektir: 64 katman, 8 KV head, 128 head dimension ve fp8. Sonuç 2 64 8 128 1 = 131,072 byte, yani token başına 128 KiB olur.

[
  {
    "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ğlam uzunluğunda tek kullanıcı 16 GiB tüketir. Tam bir milyon token bağlam kullanan tek kullanıcı ise 128 GiB tüketir. Bu miktar, tek bir kartın kapasitesinden fazladır ve bu değer yalnızca tek bir konuşma içindir.

K3, standart attention kullanmaz. Son sayının nedeni budur. K3'ün 93 katmanı, 69 KDA (Kimi Delta Attention) katmanı ve 24 Gated MLA (multi-head latent attention) katmanından oluşur. KDA, her token ile büyüyen bir önbellek yerine sabit boyutlu bir recurrent state tutar. MLA ise key ve value değerlerini tek bir düşük rank latent vector içinde sıkıştırır. Bu nedenle gerçek token başına maliyet, hesaplanan örneğin oldukça altındadır. Moonshot, latent dimension değerlerini yayımlamamıştır. Bu nedenle K3 için kullanıcı başına bir değer vermeyeceğim. Bunun yerine kendi sisteminizde ölçüm yapın: sunucuyu küçük bir --max-model-len ile başlatın, belleği nvidia-smi ile izleyin ve allocation başarısız olana kadar limiti yükseltin.

Akıl yürütmenin temel yapısı bir sonraki sürümde de geçerliliğini korur. Bir model bir milyon token bağlamı desteklediğini belirtiyor ancak attention tasarımı hakkında bilgi vermiyorsa, aksi kanıtlanana kadar bağlam önbelleğinin sınırlayıcı kaynak olduğunu varsayın.

Tier 1: cluster'ı saatlik kiralama

K3'ün kendisini çalıştıran tek katman budur. Donanımı satın alınmaz. Gereken saatler boyunca kiralanır ve ardından durdurulur.

[
  {
    "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. Veri merkezi accelerator'ları için isteğe bağlı kullanım liste fiyatları 2026 boyunca GPU saati başına yaklaşık 2-5 USD arasında değişti ve rezerve kapasite daha ucuzdur. Sağlayıcınızın gerçek ücretini alın ve çarpımı yeniden yapın: GPU sayısı x saat sayısı x ücret. Grafiğin amacı oranı göstermektir. Günde dört saat boyunca 8 GPU'lu bir node'u çalıştırmak ayda 2,400 USD tutarken SGLang için boyutlandırılmış 32 GPU'lu yapılandırmayı sürekli çalıştırmak 57,600 USD tutar.

Her iki yaygın server da model card üzerinde bir başlatma komutu yayımlar.

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

Gerçek bir cluster'da yalnızca bu komutlar çalıştırılmaz. Donanımınıza uygun parallelism flag'lerini ekleyin: SGLang, tensor parallel için --tp-size ve expert parallel için --ep-size kullanır; bunların çarpımı, gerçekten sahip olduğunuz GPU sayısına eşit olmalıdır.

Gerçek network traffic göndermeden önce server'ın çalıştığını doğrulayın:

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

Sağlıklı bir server, model id'sini listeleyen bir JSON nesnesiyle yanıt verir. Connection refused, sürecin hâlâ weight'leri yüklediği veya zaten sonlandığı anlamına gelir; yeniden denemeden önce server log'unu okuyun.

İlk gün karşılaşılan yaygın hata, modelden daha eski bir runtime kullanılmasıdır. K3, KDA ve stable vLLM ile SGLang release'lerinde ilk yayımlandıkları sırada bulunmayan yeni bir MoE katmanıyla birlikte yayımlandı. Belirti, server'ın başlatma sırasında Model architectures [...] are not supported for now biçiminde bir satırla sonlanmasıdır. Build'inizde bu katmanları çalıştıracak kod bulunmadığından hiçbir config değişikliği sorunu çözmez. Model card'da belirtilen nightly sürümünü kurun veya bu desteği içeren release'i bekleyin.

Gözden kaçan bir maliyet ayrıntısı vardır. Sayaç, model hazır olduğunda değil, instance başlatıldığında çalışmaya başlar. 1 GB/s hızında 1.5 TB indirmek, ilk token alınmadan önce yaklaşık 25 dakikalık cluster süresi gerektirir. Weight'leri instance ömründen bağımsız bir volume üzerinde stage edin; böylece ikinci çalıştırma birkaç dakika içinde başlar.

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

Bu katmanda K3 çalıştırılmamaktadır. Başlamadan önce bunu açıkça belirtin. Çünkü “K3'ü yerel olarak çalıştırma” başlıklarının çoğu, bunu kabul etmeden bu noktada sona erer.

Sığma kuralı aynı formülün daha küçük ölçekte uygulanmasıdır: parametre sayısı ile ağırlık başına byte değerinin çarpımına KV cache ve yaklaşık 2 GB çalışma zamanı ek yükü eklenir. Sonuç VRAM kapasitesinin altında kalmalıdır. 4-bit kullanımda bu değer parametre başına yaklaşık yarım byte olur. Bu da aşağıdaki eşleşmeleri rahatça mümkün kılar:

• 16 GB kart: Uzun context için yeterli boşlukla 4-bit bir 7B model
• 24 GB kart: 4-bit bir 14B model
• 48 GB kart: 4-bit bir 32B model
• 80 GB kart: 4-bit bir 70B model veya 8-bit bir 30B sınıfı MoE modeli

Ollama, GPU bağ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 bir prompt görüntüler. Mevcut olmayan bir tag için Error: model "..." not found döndürülür. Bu nedenle tag değerlerini bellekten yazmak yerine library sayfasından kopyalayın. systemd unit dosyası ve uzak erişim dahil tüm uygulama adımları VPS üzerinde Ollama çalıştırma bölümünde açıklanmaktadır.

llama.cpp, quantisation ve offload işlemleri üzerinde daha fazla denetim 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 GPU üzerinde her layer'ın çalıştırılmasını ister. Load log kaydını okuyun. Bu kayıt, kaç layer'ın offload edildiğini gösterir. Sistem RAM'ine taşan layer'lar HBM bant genişliği yerine RAM bant genişliğinde çalışır. Bu nedenle model sığmadığı anda üretim hızı bir büyüklük mertebesi düşer. İki aracın farkları ve ödünleşimleri Ollama ve llama.cpp karşılaştırması bölümünde ele alınmaktadır.

Katman 3: barındırılan API, self-hosted 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"
  }
]

Endpoint OpenAI ile uyumludur. Base 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."}]}'

Geçerli bir key, choices dizisini içeren bir JSON nesnesi döndürür. 401, key'in hatalı olduğu veya Bearer ön ekinin eksik olduğu anlamına gelir. Model bulunamadı hatası genellikle id'nin değiştiğini gösterir. Bunun nedeni, sağlayıcıların checkpoint'ler arasında id'leri kullanımdan kaldırmasıdır.

Şimdi, yukarıda varsayılan kiralama ücretini kullanarak başa baş noktasını hesaplayalım. Sürekli açık bir 8 GPU node'un aylık maliyeti 14,400 USD'dir. Aynı para, milyon output token başına 15.00 USD ücret üzerinden API'den yaklaşık 960 milyon output token satın alır. Maliyet açısından avantaj sağlamak için ayda yaklaşık 1 milyar output token üretmeniz, yani günde yaklaşık 30 milyon token üretmeniz ve cluster'ı bu süre boyunca sürekli meşgul tutmanız gerekir. Bunun nedeni, boşta olan GPU'ların da çalışan GPU'larla aynı ücret üzerinden faturalandırılmasıdır. Prompt ağırlıklı agent iş yüklerinde eşik daha da uzaklaşır. Tekrarlanan context, cache-miss oranı olan milyon başına 3.00 USD yerine cache-hit oranı olan milyon başına 0.30 USD üzerinden ücretlendirilir.

Bu katmanda self-host edilen bileşenler modelin çevresindeki tüm bileşenlerdir: API key'i tutarak istemciye ulaşmasını engelleyen bir gateway, request ve response logları, retry işlemleri, rate limit'ler ve kullanıcı başına bütçeler. Bunların tümü GPU içermeyen küçük bir VPS üzerinde çalışır. Aynı ayrım closed weights için de geçerlidir. Bu durumda Claude'u self-host etmek model düzeyinde mümkün değildir ve sahip olduğunuz tek bölüm orkestrasyondur.

Hangi serving stack hangi katmana aittir

vLLM ve SGLang sınıfındaki sunucular tier 1 kapsamındadır. Bu sunucular, continuous batching ve paged KV cache ile aynı anda çok sayıda isteğe hizmet vermek üzere tasarlanmıştır. Ayrıca tensor parallelism ve expert parallelism kullanarak yükü birden fazla node arasında dağıtırlar. Datacenter accelerator'ları ve bu accelerator'lar arasında hızlı bir interconnect varsayarlar. Tek bir consumer card üzerinde kurulmaları daha zahmetlidir ve fark edilir bir kazanım sağlamazlar.

llama.cpp ve Ollama tier 2 kapsamındadır. Bunlar tek bir makineyi, GGUF quantisation kullanımını, model sığmadığında CPU offload yapılmasını ve düşük concurrency düzeyini hedefler. llama.cpp, katmanların çoğunu system RAM'de tutarak çok büyük bir MoE modelini teknik olarak yükleyebilir. Ancak 2.8T model için bu yöntem token başına saniyelerle ölçülen bir hız sunar. Dosyanın ayrıştırılabildiğini gösterir. Kullanıcıların erişimine açılabilecek bir servis değildir. Tam karşılaştırma Ollama ve vLLM karşılaştırması bölümündedir. Model değişse de sonuç değişmez: belirleyici soru, paylaşılan donanımda çok sayıda kullanıcıya mı hizmet verdiğiniz, yoksa kendi donanımınızda tek bir kullanıcıya mı hizmet verdiğinizdir.

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

1. Toplam parametre sayısının ağırlık başına bayt değeriyle çarpımı, belleğin alt sınırını verir. Bunun altında hiçbir şey çalışmaz. Sürüm zaten 4-bit olduğunda herhangi bir quantisation yöntemi bu sınırı önemli ölçüde değiştiremez.
2. Etkin parametre sayısı, throughput sınıfını belirler. 104B etkin parametreye sahip 2.8T MoE, hesaplama açısından 104B model gibi davranır.
3. Token başına KV cache, context length ile ve eşzamanlılıkla çarpıldığında, ağırlıkların bellekte kapladığı alan ayrıldıktan sonra büyümeye devam eden maliyeti verir.
4. Dolar başına saniyedeki token sayısı, hangi katmanın seçileceğini belirleyen tek sayıdır. Yukarıdaki her şey bu sayının girdisidir.

Bu dört ölçütü herhangi bir sürüme uygulandığında, vendor guide açılmadan önce doğru sonuca ulaşılır. Ardından yazılan her rakama tarih eklenmelidir. K3 yayımlandıktan sonraki iki hafta içinde fiyatlar ve desteklenen mimari listeleri değişti. Bu sayfadaki tüm rakamlar July 2026'da yayımlanan değerlerdir.

FAQ

Kimi K3 tek bir GPU üzerinde çalıştırılabilir mi?

Hayır. Ağırlıklar, Moonshot tarafından sunulan MXFP4 hassasiyetinde yaklaşık 1.4 TB boyutundadır ve satışta olan en büyük tek hızlandırıcı 288 GB kapasiteye sahiptir. Bir MoE modelinde etkin olmayan uzmanlar kullanılabilir bir hızda diskten akışla okunamaz. Bunun nedeni, router'ın herhangi bir token için herhangi bir uzmanı seçebilmesi ve PCIe üzerinden veri getirme işleminin token bütçesinin izin verdiğinden çok daha uzun sürmesidir. K3 için makul en küçük dağıtım, birden fazla GPU içeren bir node'dur. Yayımlanan tariflerde 32 veya daha fazla hızlandırıcı kullanılır.

Kimi K3 ne kadar VRAM gerektirir?

Yalnızca ağırlıklar için 1.4 TB ile başlanmalıdır. Bu miktar, 18 adet H100 80GB kartına veya 5 adet GB300 sınıfı karta karşılık gelir. Bunun üzerine KV cache ve activation memory eklenmelidir. Ağustos 2026 itibarıyla Moonshot 64 veya daha fazla hızlandırıcı önermektedir. SGLang cookbook ise toplam 2,560 GB belleğe sahip 32 GPU'lu bir H100 yapılandırması yayımlar. Bu nedenle ağırlık miktarı bir gereksinim değil, alt sınır olarak değerlendirilmelidir.

Quantisation, Kimi K3'ün tek bir node'a sığmasını sağlar mı?

Kullanışlı bir sonuç sağlamaz. Yayımlanan checkpoint, quantisation-aware training kullanılarak zaten 4-bit olarak hazırlanmıştır. Bu nedenle kolay bellek tasarrufu zaten uygulanmıştır. Ağırlıkları yeniden 2-bit'e düşürmek miktarı 0.7 TB'ye indirir. Ancak bu değer yine de en büyük kartın kapasitesinin iki katından fazladır. Ayrıca 2-bit kullanımının bu model üzerindeki doğruluk maliyeti ölçülmemiştir.

GPU kiralamak Kimi K3 API'sinden daha ucuz mudur?

Yalnızca yüksek ve istikrarlı kullanım hacminde. GPU saat ücretinin 2.50 USD olduğu varsayılırsa, sürekli çalışan 8 GPU'lu bir node'un aylık maliyeti 14,400 USD olur. Aynı tutarla, yayımlanan milyon token başına 15.00 USD ücret üzerinden yaklaşık 960 milyon output token satın alınabilir. Ayrıca boşta geçen saatler, ağırlık indirmeleri ve cluster'ın çalışır durumda kalmasını sağlayan personel için de ödeme yapılır. Kısa süreli yoğunluklar için saatlik kiralama tercih edilmelidir. Karşılaştırma, tahmine değil, ölçülen token hacmine göre yapılmalıdır.

104B active parameter hız açısından ne ifade eder?

Her token için yapılan aritmetik işlemin 104B model düzeyinde olduğu anlamına gelir. Bu nedenle throughput, 2.8T model sınıfında değil, 104B model sınıfında olur. Bu bilgi bellek kullanımını göstermez. Router herhangi bir token için herhangi bir uzmanı çağırabildiğinden 2.8T parametrenin tamamı bellekte tutulur. Tokens per second tahmini için active parameter sayısı kullanılmalıdır. VRAM kapasitesini belirlemek için ise toplam parameter sayısı esas alınmalıdır.