Cara Menjalankan Kimi K3 Secara Mandiri

Kebutuhan untuk self-host Kimi K3

Self-hosting Kimi K3 berarti menyediakan ruang untuk 2.8 triliun parameter. Moonshot merilis bobot terbuka dalam format MXFP4, dengan ukuran sekitar setengah byte per bobot. Karena itu, bobotnya saja berukuran sekitar 1.4 TB sebelum Anda mengalokasikan satu token pun untuk cache. Tidak ada akselerator yang dijual saat ini yang dapat menampung ukuran tersebut sendirian. K3 adalah model multi-node, jadi satu server tidak memadai.

Itulah kesimpulannya. Bagian berikut menjelaskan perhitungannya, karena perhitungan inilah yang dapat Anda gunakan kembali pada rilis berikutnya. Beberapa vendor infrastruktur menerbitkan panduan deployment K3 dalam beberapa minggu setelah pengumuman pada 17 July 2026. Semua panduan tersebut mengasumsikan bahwa Anda sudah memiliki cluster. Halaman ini memulai dari sisi sebaliknya: berapa biayanya, apa yang dapat Anda jalankan sebagai gantinya, dan cara menentukan posisi Anda di antara kedua opsi tersebut.

Jumlah parameter total dan parameter aktif bukan angka yang sama

K3 adalah model mixture of experts. MoE (mixture of experts) membagi jaringan menjadi banyak subjaringan, lalu membiarkan router memilih beberapa di antaranya untuk setiap token. Kartu model mencantumkan 2.8T parameter total dan 104B parameter yang diaktifkan untuk setiap token, dari 896 routed experts, dengan 16 expert yang aktif untuk setiap token, di 93 layer.

Kedua jumlah parameter tersebut menjawab pertanyaan yang berbeda. Menukar keduanya adalah kesalahan yang paling umum dalam setiap diskusi "bisakah model ini dijalankan".

Parameter aktif menentukan biaya komputasi. Sebuah token diproses melalui sekitar 104B parameter. Jadi, throughput yang dapat diharapkan lebih menyerupai model dense 104B daripada model 2.8T. Itulah alasan utama MoE dibuat.

Parameter total menentukan kebutuhan memori. Router dapat memilih expert mana pun untuk setiap token. Karena itu, semua expert harus sudah berada di memori sebelum request pertama tiba. Anda tidak dapat menyimpan 104B parameter di VRAM lalu mengambil sisanya sesuai permintaan. Proses pengambilan harus selesai dalam hitungan mikrodetik, sedangkan koneksi PCIe hanya mampu memindahkan puluhan gigabyte per detik. Banyak orang tetap mencobanya. Streaming expert dari NVMe mengubah model yang seharusnya menghasilkan puluhan token per detik menjadi model yang hanya menghasilkan satu token setiap beberapa detik.

Jadi, biaya komputasinya rendah, tetapi biaya penyimpanannya tinggi. Sesuaikan hardware dengan 2.8T. Sesuaikan ekspektasi kecepatan dengan 104B.

Byte per bobot, dan asal terabita

Jumlah parameter dikalikan byte per bobot. Untuk bobot, itulah seluruh rumusnya.

[
  {
    "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 dilatih dengan quantisation-aware training dan dirilis dengan bobot MXFP4 serta aktivasi MXFP8, jadi baris 4-bit adalah kondisi sebenarnya. Baris di atasnya digunakan sebagai pembanding: pada bf16, model yang sama akan membutuhkan 5.6 TB. MXFP4 juga menyimpan satu skala 8-bit bersama untuk setiap blok yang terdiri dari 32 bobot. Hal ini menambah sekitar 6 persen, sehingga repositori yang dipublikasikan lebih mendekati 1.5 TB daripada 1.4 TB secara teoritis.

Dengan demikian, celah yang biasanya digunakan tidak berlaku. "Cukup lakukan kuantisasi" tidak membantu di sini karena checkpoint yang dirilis sudah 4-bit. Jika diturunkan menjadi 2-bit, ukuran bobot akan menjadi 0.7 TB dan akurasinya akan berkurang, tetapi belum ada yang mengukurnya pada checkpoint ini. Ukurannya tetap jauh melampaui kapasitas satu kartu grafis.

Berapa banyak GPU yang dibutuhkan Kimi K3

[
  {
    "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
  }
]

Angka tersebut harus dianggap sebagai batas minimum, bukan target. Angka itu hanya menghitung bobot model: tidak mencakup KV cache, buffer aktivasi, fragmentasi allocator, maupun kapasitas untuk permintaan konkuren kedua. Perhitungan tersebut juga mengasumsikan pembagian paralel yang merata, sedangkan 93 layer dan 896 expert tidak selalu dapat dibagi secara merata.

Panduan yang dipublikasikan menetapkan kebutuhan yang jauh lebih tinggi daripada batas minimum tersebut. Per Agustus 2026, Moonshot merekomendasikan supernode dengan 64 accelerator atau lebih, sedangkan SGLang cookbook menyediakan konfigurasi H100 yang terdiri atas empat node 8-GPU, yaitu 32 GPU dan total memori 2,560 GB, dibandingkan dengan batas minimum 18 kartu. Selisih tersebut bukan pemborosan. Selisih itu digunakan untuk KV cache, memori aktivasi, dan headroom agar server dapat melakukan batch terhadap banyak permintaan sekaligus. Bahkan baris yang paling menguntungkan, yaitu 5 kartu kelas GB300, menggambarkan mesin yang umumnya tidak disewakan oleh sebagian besar provider sebagai satu SKU.

Cache KV adalah bagian yang sering mengejutkan pengguna

Bobot merupakan biaya tetap. Cache KV (key value) tidak demikian: ukurannya bertambah seiring panjang konteks dan bertambah lagi untuk setiap pengguna secara bersamaan. Untuk attention biasa, rumusnya adalah bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, lalu hasilnya dikalikan dengan panjang konteks dan konkurensi.

Berikut contoh perhitungan, dan ini hanya contoh: 64 layer, 8 head KV, dimensi head 128, fp8. Hasilnya adalah 2 64 8 128 1 = 131,072 byte, atau 128 KiB per token.

[
  {
    "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
  }
]

Satu pengguna dengan konteks 128k memerlukan 16 GiB. Satu pengguna dengan konteks penuh sebesar satu juta memerlukan 128 GiB. Jumlah ini melebihi kapasitas kartu mana pun, hanya untuk satu percakapan.

K3 tidak menggunakan attention biasa, dan angka terakhir itulah alasannya. K3 memiliki 93 layer, yang terdiri atas 69 layer KDA (Kimi Delta Attention) dan 24 layer Gated MLA (multi-head latent attention). KDA mempertahankan state rekuren berukuran tetap, bukan cache yang bertambah pada setiap token. MLA memampatkan key dan value menjadi satu vektor laten berperingkat rendah. Karena itu, biaya nyata per token jauh lebih rendah daripada contoh perhitungan tersebut. Moonshot belum memublikasikan dimensi laten, jadi saya tidak akan mencantumkan angka per pengguna untuk K3. Ukur sendiri: jalankan server dengan --max-model-len yang kecil, pantau memori menggunakan nvidia-smi, lalu naikkan batas tersebut sampai alokasi gagal.

Pola penalarannya tetap berlaku pada rilis berikutnya. Jika sebuah model mengiklankan konteks satu juta token tetapi tidak menjelaskan desain attention-nya, anggap cache sebagai batasan utama sampai ada bukti sebaliknya.

Tingkat 1: sewa cluster per jam

Ini satu-satunya tingkat yang menjalankan K3 itu sendiri. Anda tidak membeli hardware. Anda menyewanya selama diperlukan, lalu menghentikannya.

[
  {
    "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"
  }
]

Tarif tersebut adalah asumsi, bukan penawaran harga. Harga publik on-demand untuk accelerator datacenter berada sekitar 2 hingga 5 USD per jam GPU hingga 2026, sedangkan kapasitas reserved lebih murah. Gunakan angka aktual dari provider Anda dan hitung ulang: jumlah GPU dikalikan jumlah jam, lalu dikalikan tarif. Tujuan chart ini adalah menunjukkan perbandingan. Menjalankan node 8 GPU selama empat jam per hari memerlukan biaya 2,400 USD per bulan, sedangkan konfigurasi 32 GPU yang sesuai untuk SGLang dan terus berjalan memerlukan biaya 57,600 USD.

Kedua server mainstream tersebut menyediakan perintah peluncuran pada model card.

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

Kedua perintah dasar tersebut bukan perintah yang Anda jalankan pada cluster nyata. Tambahkan flag paralelisme yang sesuai dengan hardware Anda: SGLang menggunakan --tp-size untuk tensor parallel dan --ep-size untuk expert parallel. Hasil perkalian keduanya harus sama dengan jumlah GPU yang benar-benar Anda miliki.

Pastikan server sudah aktif sebelum mengirim trafik nyata:

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

Server yang sehat merespons dengan objek JSON yang mencantumkan model id. Connection refused berarti proses masih memuat weights atau sudah keluar, jadi baca log server sebelum mencoba lagi.

Kegagalan yang umum terjadi pada hari pertama adalah runtime yang lebih lama daripada model. K3 dirilis bersama KDA dan layer MoE baru yang belum tersedia dalam rilis vLLM dan SGLang stable saat peluncuran. Gejalanya adalah server keluar saat startup dengan baris dalam bentuk Model architectures [...] are not supported for now. Tidak ada perubahan konfigurasi yang dapat memperbaikinya, karena kode untuk menjalankan layer tersebut tidak ada dalam build Anda. Install nightly yang disebutkan pada model card, atau tunggu rilis yang sudah menyertakannya.

Ada satu catatan biaya yang sering terlewatkan. Meter mulai berjalan saat instance dimulai, bukan saat model siap. Download berukuran 1.5 TB dengan kecepatan 1 GB/s memerlukan sekitar 25 menit waktu cluster sebelum token pertama tersedia. Stage weights pada volume yang tetap tersedia setelah instance dihentikan, sehingga proses kedua dapat dimulai dalam hitungan menit.

Tier 2: jalankan model yang lebih kecil pada satu akselerator

Pada tier ini, Anda tidak menjalankan K3. Nyatakan hal itu dengan jelas sebelum memulai, karena sebagian besar thread tentang “menjalankan K3 secara lokal” berakhir di sini tanpa mengakuinya.

Aturan kecocokannya menggunakan rumus yang sama dalam skala lebih kecil: jumlah parameter dikalikan byte per bobot, ditambah KV cache dan sekitar 2 GB overhead runtime, harus berada di bawah kapasitas VRAM Anda. Pada 4-bit, nilainya kira-kira setengah byte per parameter. Dengan demikian, pasangan berikut cukup leluasa:

• Kartu 16 GB: model 7B pada 4-bit dengan ruang untuk context yang panjang
• Kartu 24 GB: model 14B pada 4-bit
• Kartu 48 GB: model 32B pada 4-bit
• Kartu 80 GB: model 70B pada 4-bit, atau MoE kelas 30B pada 8-bit

Ollama adalah cara tercepat untuk menjalankan server yang berfungsi pada VPS dengan GPU terpasang:

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

ollama run mengunduh model saat pertama kali digunakan, lalu menampilkan prompt. Tag yang tidak ada akan menghasilkan Error: model "..." not found. Karena itu, salin tag dari halaman library, bukan mengetiknya berdasarkan ingatan. Panduan lengkap, termasuk unit systemd dan akses jarak jauh, tersedia di menjalankan Ollama pada VPS.

llama.cpp memberi Anda kontrol yang lebih besar atas quantisation dan offload:

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 meminta setiap layer dijalankan pada GPU. Periksa log pemuatan: log tersebut menampilkan jumlah layer yang berhasil di-offload. Layer yang meluber ke RAM sistem berjalan pada bandwidth RAM, bukan bandwidth HBM. Akibatnya, kecepatan pembuatan teks turun hingga satu tingkat besaran saat model tidak lagi sepenuhnya termuat. Perbandingan kompromi kedua tool tersebut dibahas dalam Ollama dan llama.cpp secara berdampingan.

Tingkat 3: API terkelola, orkestrasi yang di-host sendiri

[
  {
    "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 ini kompatibel dengan OpenAI, sehingga client yang sudah ada dapat digunakan setelah Anda mengubah base URL.

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."}]}'

Key yang berfungsi mengembalikan objek JSON dengan array choices. 401 berarti key salah atau prefix Bearer tidak ada. Error model-not-found biasanya berarti id telah berubah, karena provider menghentikan penggunaan id di antara checkpoint.

Sekarang, hitung titik impas menggunakan tarif sewa yang diasumsikan di atas. Node 8 GPU yang selalu aktif berharga 14,400 USD per bulan. Dengan harga 15.00 USD per satu juta output token, biaya yang sama membeli sekitar 960 juta output token dari API. Agar lebih hemat, Anda harus menghasilkan hampir satu miliar output token per bulan, atau sekitar 30 juta per hari. Cluster juga harus tetap sibuk sepanjang waktu karena GPU yang idle ditagihkan dengan tarif yang sama seperti GPU yang sibuk. Workload agent yang banyak menggunakan prompt membuat titik ini semakin jauh. Context yang diulang ditagihkan dengan tarif cache-hit sebesar 0.30 USD per satu juta, bukan tarif cache-miss sebesar 3.00 USD.

Dalam tingkat ini, yang Anda host sendiri adalah semua komponen di sekitar model: gateway yang menyimpan API key agar tidak pernah sampai ke client, log request dan response, retry, rate limit, serta anggaran per pengguna. Semua komponen tersebut dapat dijalankan pada VPS kecil tanpa GPU. Pembagian yang sama berlaku untuk weight tertutup. self-hosting Claude tidak mungkin dilakukan pada tingkat model, sehingga orkestrasi adalah satu-satunya bagian yang Anda kelola sendiri.

Stack serving untuk tier mana

Server kelas vLLM dan SGLang termasuk tier 1. Keduanya dirancang untuk menangani banyak permintaan secara bersamaan, dengan continuous batching dan paged KV cache, serta tensor parallelism dan expert parallelism yang tersebar di beberapa node. Keduanya mengasumsikan penggunaan akselerator datacenter dan interkoneksi berkecepatan tinggi. Pada satu consumer card, keduanya lebih sulit diinstal dan hanya memberikan sedikit manfaat yang dapat Anda rasakan.

llama.cpp dan Ollama termasuk tier 2. Keduanya ditujukan untuk satu mesin, quantisation GGUF, CPU offload saat model tidak dapat dimuat sepenuhnya, serta concurrency rendah. Secara teknis, llama.cpp dapat memuat MoE berukuran sangat besar dengan menyimpan sebagian besar layer di system RAM. Namun, untuk model 2.8T, metode ini memerlukan waktu dalam hitungan detik per token. Ini hanya membuktikan bahwa file dapat diproses. Ini bukan service yang layak digunakan untuk melayani pengguna. Perbandingan lengkap tersedia di Ollama dibandingkan dengan vLLM, dan hasilnya tidak berubah berdasarkan model: pertanyaannya selalu apakah Anda melayani banyak pengguna pada hardware bersama atau satu pengguna pada perangkat Anda sendiri.

Empat angka yang tetap relevan setelah melewati checkpoint ini

1. Total parameter dikalikan byte per bobot menentukan batas minimum memori. Tidak ada yang dapat berjalan di bawah batas ini, dan trik kuantisasi tidak banyak mengubahnya jika rilis tersebut sudah menggunakan 4-bit.
2. Parameter aktif menentukan kelas throughput. MoE 2.8T dengan 104B parameter aktif memiliki kebutuhan komputasi seperti model 104B.
3. Cache KV per token, dikalikan panjang konteks dan konkurensi, adalah biaya yang terus bertambah setelah bobot tersedia di memori.
4. Token per detik per dolar adalah satu-satunya angka yang menentukan tier. Semua angka di atas menjadi input untuk menghitungnya.

Terapkan keempat angka tersebut pada rilis apa pun untuk mendapatkan jawaban yang tepat sebelum membuka panduan vendor. Selalu cantumkan tanggal pada setiap angka yang Anda catat. Harga dan daftar arsitektur yang didukung sama-sama berubah dalam dua minggu setelah K3 diluncurkan, dan semua angka pada halaman ini berasal dari publikasi pada Juli 2026.

FAQ

Apakah Kimi K3 dapat dijalankan pada satu GPU?

Tidak. Bobotnya berukuran sekitar 1.4 TB pada presisi MXFP4 yang dirilis Moonshot, sedangkan accelerator tunggal terbesar yang dijual berkapasitas 288 GB. Model MoE tidak dapat memuat expert yang tidak aktif dari disk pada kecepatan yang dapat digunakan, karena router dapat memilih expert mana pun untuk setiap token dan pengambilan melalui PCIe memerlukan waktu jauh lebih lama daripada anggaran waktu per token. Deployment K3 terkecil yang masuk akal adalah node dengan beberapa GPU, dan resep yang dipublikasikan menggunakan 32 accelerator atau lebih.

Berapa VRAM yang dibutuhkan Kimi K3?

Mulailah dari 1.4 TB hanya untuk bobot, yang setara dengan 18 kartu H100 80GB atau 5 kartu kelas GB300. Setelah itu, tambahkan KV cache dan memori aktivasi. Per Agustus 2026, Moonshot merekomendasikan 64 accelerator atau lebih, sedangkan cookbook SGLang memublikasikan konfigurasi 32 GPU H100 dengan total kapasitas 2,560 GB. Karena itu, anggap angka bobot sebagai batas minimum, bukan sebagai kebutuhan pasti.

Apakah quantisation membuat Kimi K3 dapat dimuat pada satu node?

Tidak secara praktis. Checkpoint yang dirilis sudah menggunakan 4-bit dengan quantisation-aware training, sehingga penghematan yang mudah sudah diperoleh. Jika dikurangi lagi menjadi 2-bit, ukuran bobot menjadi 0.7 TB, yang masih lebih dari dua kali kapasitas kartu terbesar. Dampak akurasi 2-bit pada model ini juga belum diukur.

Apakah menyewa GPU lebih murah daripada menggunakan API Kimi K3?

Hanya jika volumenya tinggi dan stabil. Dengan asumsi biaya 2.50 USD per jam GPU, node 8 GPU yang selalu aktif berbiaya 14,400 USD per bulan. Jumlah yang sama dapat membeli sekitar 960 juta token output dengan tarif yang dipublikasikan, yaitu 15.00 USD per juta token. Anda juga harus membayar jam tidak aktif, pengunduhan bobot, dan orang yang menjaga cluster tetap berjalan. Sewa GPU per jam untuk lonjakan beban, lalu bandingkan dengan volume token yang benar-benar Anda ukur, bukan dengan perkiraan.

Apa arti 104B parameter aktif bagi kecepatan?

Artinya, perhitungan untuk setiap token setara dengan model 104B. Karena itu, throughput berada pada kelas tersebut, bukan kelas 2.8T. Angka ini tidak menjelaskan kebutuhan memori: seluruh 2.8T parameter tetap berada di memori karena router dapat memanggil expert mana pun untuk setiap token. Gunakan jumlah parameter aktif untuk memperkirakan token per detik, dan jumlah total parameter untuk menentukan kebutuhan VRAM.