Berapa GPU untuk Menjalankan Kimi K3 Sendiri?
Kimi K3 memiliki 2,8 triliun parameter dalam MXFP4. Pahami hitungan VRAM, KV cache, dan tiga cara realistis menjalankannya tanpa cluster 32 GPU.
Yang diperlukan untuk menjalankan Kimi K3 secara mandiri
Menjalankan Kimi K3 secara mandiri berarti menyediakan ruang untuk 2.8 triliun parameter. Moonshot merilis bobot terbuka dalam MXFP4, yang menggunakan sekitar setengah byte per bobot. Dengan demikian, bobotnya saja berukuran sekitar 1.4 TB sebelum Anda mengalokasikan satu token pun untuk cache. Tidak ada akselerator yang dijual saat ini yang dapat menampungnya sendiri. K3 adalah model multi-node, sehingga jawabannya adalah tidak jika hanya menggunakan satu server.
Itulah kesimpulannya. Bagian berikut menjelaskan perhitungannya karena perhitungan tersebut dapat Anda gunakan kembali pada rilis berikutnya. Beberapa vendor infrastruktur menerbitkan panduan deployment K3 dalam beberapa minggu setelah pengumuman pada 17 July 2026, dan setiap panduan mengasumsikan bahwa Anda sudah memiliki cluster. Halaman ini membahasnya dari sisi sebaliknya: berapa biayanya, apa yang dapat Anda jalankan sebagai gantinya, dan cara menentukan kondisi yang sesuai untuk Anda.
Jumlah parameter total dan parameter aktif tidak sama
K3 adalah model mixture of experts. MoE (mixture of experts) membagi jaringan menjadi banyak subjaringan dan memungkinkan router memilih beberapa di antaranya untuk setiap token. Model card mencantumkan 2.8T parameter total dan 104B parameter yang diaktifkan untuk setiap token, dari 896 routed experts; 16 di antaranya aktif untuk setiap token pada 93 layer.
Kedua jumlah parameter tersebut menjawab pertanyaan yang berbeda. Menukar keduanya adalah kesalahan paling umum dalam setiap diskusi “apakah model ini dapat saya jalankan”.
Parameter aktif menentukan biaya komputasi. Sebuah token diproses melalui sekitar 104B parameter. Karena itu, throughput yang dapat Anda harapkan lebih menyerupai model dense 104B daripada model 2.8T. Inilah alasan utama MoE dibuat.
Parameter total menentukan biaya memori. Router dapat memilih expert mana pun untuk token mana pun. Karena itu, semua expert harus sudah berada di memori sebelum request pertama diterima. Anda tidak dapat menyimpan 104B parameter di VRAM lalu mengambil sisanya sesuai kebutuhan, karena proses pengambilan harus selesai dalam hitungan mikrodetik, sedangkan koneksi PCIe hanya mampu mentransfer puluhan gigabyte per detik. Sebagian 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. Tentukan spesifikasi hardware berdasarkan 2.8T. Tentukan ekspektasi kecepatannya berdasarkan 104B.
Byte per bobot dan asal terabyte tersebut
Jumlah parameter dikalikan byte per bobot. Untuk bobot, itulah keseluruhan rumusnya.
The data behind this chart
[
{
"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 memperhitungkan kuantisasi dan dirilis dengan bobot MXFP4 serta aktivasi MXFP8, sehingga baris 4-bit adalah konfigurasi yang 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 berukuran lebih mendekati 1.5 TB daripada 1.4 TB secara teoritis.
Hal ini menutup celah yang biasanya digunakan. "Cukup lakukan kuantisasi" tidak membantu di sini karena checkpoint yang dirilis sudah menggunakan 4-bit. Jika diturunkan menjadi 2-bit, ukuran bobot akan menjadi 0.7 TB, dengan biaya akurasi yang belum pernah diukur pada checkpoint ini. Ukurannya tetap jauh melebihi kapasitas satu kartu grafis.
Berapa GPU yang dibutuhkan Kimi K3
The data behind this chart
[
{
"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
}
]Anggap angka tersebut sebagai batas minimum, bukan target. Angka itu hanya menghitung bobot model: tidak mencakup KV cache, buffer aktivasi, fragmentasi allocator, atau ruang untuk permintaan konkuren kedua. Angka itu juga mengasumsikan pembagian paralel yang merata, sedangkan 93 layer dan 896 expert tidak selalu dapat dibagi secara merata.
Panduan yang dipublikasikan menunjukkan kebutuhan yang jauh di atas batas minimum tersebut. Per Agustus 2026, Moonshot merekomendasikan supernode dengan 64 akselerator atau lebih. Cookbook SGLang menyediakan konfigurasi H100 yang terdiri atas empat node 8-GPU, dengan total 32 GPU dan memori agregat 2,560 GB, dibandingkan dengan batas minimum 18 kartu. Selisih tersebut bukan pemborosan. Selisih itu digunakan untuk KV cache, memori aktivasi, dan ruang cadangan agar server dapat memproses banyak permintaan secara batch secara bersamaan. Bahkan baris yang paling menguntungkan, yaitu 5 kartu kelas GB300, menggambarkan mesin yang biasanya tidak disewakan oleh sebagian besar penyedia 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 yang terhubung secara bersamaan. Untuk attention biasa, rumusnya adalah bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, kemudian hasilnya dikalikan dengan panjang konteks dan konkurensi.
Berikut contoh perhitungannya, 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.
The data behind this chart
[
{
"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 satu juta token memerlukan 128 GiB, yang melebihi kapasitas kartu tunggal mana pun, hanya untuk satu percakapan.
K3 tidak menggunakan attention biasa, dan angka terakhir itulah alasannya. Dari 93 layer yang dimilikinya, 69 adalah layer KDA (Kimi Delta Attention) dan 24 adalah layer Gated MLA (multi-head latent attention). KDA mempertahankan state rekuren berukuran tetap, bukan cache yang bertambah pada setiap token, sedangkan MLA memadatkan key dan value menjadi satu vektor latent berperingkat rendah. Dengan demikian, biaya nyata per token jauh lebih rendah daripada contoh perhitungan tersebut. Moonshot belum memublikasikan dimensi latent, jadi saya tidak akan mencantumkan angka per pengguna untuk K3. Ukur sendiri: jalankan server dengan --max-model-len yang kecil, pantau penggunaan memori dengan nvidia-smi, lalu naikkan batas tersebut hingga 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 yang membuktikan sebaliknya.
Tingkat 1: sewa cluster per jam
Ini satu-satunya tingkat yang menjalankan K3 secara langsung. Anda tidak membeli perangkat kerasnya. Anda menyewanya selama diperlukan, lalu menghentikannya setelah selesai.
The data behind this chart
[
{
"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 sesuai permintaan untuk accelerator pusat data 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 dikalikan tarif. Inti grafik tersebut adalah perbandingannya. Menjalankan node 8 GPU selama empat jam per hari membutuhkan biaya 2,400 USD per bulan, sedangkan menjalankan konfigurasi 32 GPU yang sesuai untuk SGLang membutuhkan biaya 57,600 USD.
Kedua server utama 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 30000Tidak satu pun dari kedua perintah dasar tersebut dapat langsung digunakan pada cluster nyata. Tambahkan flag paralelisme yang sesuai dengan perangkat keras 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 tersedia.
Pastikan server telah berjalan sebelum Anda mengirim trafik nyata:
curl http://127.0.0.1:30000/v1/modelsServer yang sehat merespons dengan objek JSON yang mencantumkan model id. Connection refused berarti proses masih memuat weight atau sudah berhenti, jadi baca log server sebelum mencoba lagi.
Kegagalan yang umum terjadi pada hari pertama adalah runtime yang lebih lama daripada modelnya. K3 dirilis bersama KDA dan layer MoE baru yang belum tersedia dalam rilis stabil vLLM dan SGLang saat peluncuran. Gejalanya adalah server berhenti saat startup dengan baris berbentuk 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. Instal nightly yang disebutkan pada model card, atau tunggu rilis yang sudah menyertakannya.
Ada satu catatan biaya yang sering terlewat. Meter mulai berjalan saat instance dimulai, bukan saat model sudah siap. Download sebesar 1.5 TB dengan kecepatan 1 GB/s membutuhkan sekitar 25 menit waktu cluster sebelum token pertama tersedia. Simpan weight pada volume yang tetap ada setelah instance dihentikan, agar 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 formula yang sama dalam skala lebih kecil: 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, kombinasi berikut biasanya memiliki ruang yang cukup:
- 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
Setiap kombinasi di atas mengasumsikan satu request pada satu waktu. Saat orang kedua mengirim prompt, setiap slot konkuren memerlukan KV cache sendiri. Inilah trade-off yang pengaturan NUM_PARALLEL dan MAX_QUEUE Ollama berikan antara slot paralel, request yang diantrekan, dan VRAM yang masih tersedia.
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:14bollama 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 kuantisasi 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. Baca log pemuatan karena log tersebut menampilkan jumlah layer yang di-offload. Layer yang melimpah ke RAM sistem berjalan pada bandwidth RAM, bukan bandwidth HBM. Akibatnya, kecepatan generasi turun hingga satu orde besarnya saat model tidak lagi sepenuhnya termuat. Trade-off antara kedua tool tersebut dibahas di Ollama dan llama.cpp secara berdampingan.
Tingkat 3: API terkelola, orkestrasi yang di-host sendiri
The data behind this chart
[
{
"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 valid 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.
Berikut perhitungan titik impas menggunakan tarif sewa yang diasumsikan di atas. Node 8 GPU yang selalu aktif berbiaya 14,400 USD per bulan. Dengan tarif 15.00 USD per juta token output, biaya yang sama membeli sekitar 960 juta token output dari API. Agar lebih hemat, Anda harus menghasilkan hampir 1 miliar token output per bulan, atau sekitar 30 juta per hari, dan menjaga cluster tetap sibuk sepanjang waktu. GPU yang idle tetap ditagihkan dengan tarif yang sama seperti GPU yang sibuk. Workload agent yang banyak menggunakan prompt membuat titik ini semakin jauh. Context yang berulang ditagihkan dengan tarif cache hit sebesar 0.30 USD per 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 berjalan pada VPS kecil tanpa GPU. Pembagian yang sama berlaku untuk bobot tertutup. self-hosting Claude tidak dimungkinkan pada tingkat model, sehingga orkestrasi menjadi satu-satunya bagian yang Anda miliki.
Stack serving untuk tier mana
Server kelas vLLM dan SGLang termasuk tier 1. Server ini dirancang untuk melayani banyak permintaan secara bersamaan dengan continuous batching dan paged KV cache, serta tensor parallelism dan expert parallelism yang tersebar di beberapa node. Server ini mengasumsikan penggunaan akselerator di pusat data dan interkoneksi berkecepatan tinggi di antaranya. Pada satu kartu konsumen, instalasinya lebih rumit dan manfaatnya hampir tidak terlihat.
llama.cpp dan Ollama termasuk tier 2. Keduanya ditujukan untuk satu mesin, kuantisasi GGUF, CPU offload saat model tidak muat, dan concurrency rendah. Secara teknis, llama.cpp dapat memuat MoE berukuran sangat besar dengan menyimpan sebagian besar layer di RAM sistem. Namun, untuk model 2.8T, proses tersebut membutuhkan waktu dalam hitungan detik per token. Ini hanya membuktikan bahwa file dapat di-parse. Ini bukan service yang dapat digunakan oleh pengguna. Perbandingan lengkapnya tersedia di Ollama dibandingkan dengan vLLM, dan perbandingan tersebut 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 tahap ini
- Total parameter dikalikan byte per bobot menentukan batas minimum memori. Tidak ada model yang dapat berjalan di bawah batas ini, dan trik kuantisasi tidak banyak mengubahnya jika rilis tersebut sudah 4-bit.
- Parameter aktif menentukan kelas throughput. MoE 2.8T dengan 104B parameter aktif memiliki beban komputasi seperti model 104B.
- Cache KV per token, dikalikan panjang konteks dan konkurensi, adalah biaya yang terus bertambah setelah memori untuk bobot terpenuhi.
- Token per detik per dolar adalah satu-satunya angka yang menentukan tier. Semua hal di atas menjadi input untuk angka tersebut.
Terapkan keempat angka tersebut pada rilis apa pun untuk mendapatkan jawaban yang tepat sebelum membuka panduan vendor. Selanjutnya, cantumkan tanggal pada setiap angka yang Anda catat. Harga dan daftar arsitektur yang didukung sama-sama berubah dalam dua minggu setelah K3 diluncurkan, dan setiap angka di 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 oleh Moonshot, sedangkan akselerator tunggal terbesar yang dijual hanya memiliki kapasitas 288 GB. Model MoE tidak dapat memuat expert yang tidak aktif dari disk secara cukup cepat untuk digunakan, karena router dapat memilih expert mana pun pada token mana pun dan pengambilan data 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 akselerator 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 akselerator atau lebih, sedangkan SGLang cookbook memublikasikan konfigurasi H100 32 GPU dengan total kapasitas 2,560 GB. Jadi, anggap ukuran bobot tersebut sebagai batas minimum, bukan sebagai kebutuhan keseluruhan.
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. Selain itu, dampak 2-bit terhadap akurasi model ini belum diukur.
Apakah menyewa GPU lebih murah daripada API Kimi K3?
Hanya jika volumenya tinggi dan stabil. Dengan asumsi biaya 2.50 USD per jam GPU, node dengan 8 GPU yang selalu aktif berharga 14,400 USD per bulan. Jumlah yang sama membeli sekitar 960 juta token output dengan tarif yang dipublikasikan, yaitu 15.00 USD per juta token. Anda juga membayar jam idle, pengunduhan bobot, dan tenaga orang yang menjaga cluster tetap berjalan. Sewa GPU per jam untuk beban kerja yang meningkat sesaat, lalu bandingkan biayanya dengan volume token yang benar-benar Anda ukur, bukan dengan perkiraan.
Apa arti 104B parameter aktif bagi kecepatan?
Artinya, operasi komputasi per token setara dengan model 104B. Karena itu, throughput berada pada kelas tersebut, bukan kelas 2.8T. Hal ini tidak menjelaskan kebutuhan memori: seluruh 2.8T parameter tetap berada di memori karena router dapat memanggil expert mana pun pada token mana pun. Gunakan jumlah parameter aktif untuk memperkirakan token per detik, dan jumlah parameter total untuk menentukan kebutuhan VRAM.