Bagaimana cara melakukan deployment Kimi K3 secara lokal?

TL;DR

Kimi K3 adalah open-weight namun bukan berskala workstation: menyajikan model native memerlukan GPU kelas pusat data dan memori terdistribusi. Gunakan vLLM untuk jalur produksi paling langsung, atau SGLang ketika topologi, expert parallelism, dan kontrol cache menjadi penting. Build GGUF komunitas menurunkan ambang perangkat keras, tetapi tetap memerlukan kira-kira 500 GB hingga jauh di atas 1 TB memori yang dapat dialamatkan dan menukar kecepatan atau kualitas demi keterlaksanaan. Untuk PC dan Mac biasa, ujilah terlebih dahulu melalui API hosted dan lakukan self-hosting hanya bila privasi, utilisasi berkelanjutan, atau kontrol infrastruktur membenarkan biayanya.

What Is Kimi K3?

Kimi K3 adalah model flagship multimodal native open-weight dari Moonshot AI untuk pengkodean jangka panjang, pekerjaan berbasis agen, penalaran, dan pemahaman visual.

Moonshot menggambarkannya sebagai model 3T-class open pertama di dunia. Arsitekturnya mengombinasikan Kimi Delta Attention dan Attention Residuals dengan desain MoE sparse yang memilih hanya subset expert untuk setiap token.

Skalanya tidak biasa bahkan menurut standar frontier model. Alih-alih mengaktifkan semua 2,8T parameter untuk setiap token, K3 memilih 16 dari 896 routed expert, plus shared expert. Ini mengurangi komputasi per token secara signifikan, meski semua bobot model tetap harus tersedia di suatu tempat dalam sistem inferensi.

K3 juga menerapkan quantization-aware training sejak tahap SFT, alih-alih memperlakukan serving presisi rendah semata sebagai langkah kompresi pascapelatihan.

Karenanya, arsitekturnya dioptimalkan untuk serving skala sangat besar—namun “sparse compute” jangan disamakan dengan “jejak memori kecil.” Hanya sebagian jaringan yang menghitung setiap token, tetapi kumpulan expert lengkap tetap harus dapat diakses.

How Does Kimi K3 Perform?

Benchmark resmi Kimi K3 dari Moonshot menempatkan model ini dekat dengan model frontier proprietary terdepan, khususnya pada rekayasa perangkat lunak jangka panjang dan beban kerja agen.

Pilihan berikut mencakup penalaran, coding, agen, dan visi. Lebih tinggi lebih baik untuk semua skor yang ditampilkan.

Skor resmi menempatkan Kimi K3 dekat GPT-5.6 Sol, Claude Fable 5, dan Claude Opus 4.8 di berbagai tugas penalaran, coding, agen, dan visi. Perlakukan hasil yang dilaporkan penyedia sebagai konteks kapabilitas alih-alih peringkat universal; analisis benchmark terperinci dibahas terpisah. Untuk panduan ini, poin operasionalnya adalah bahwa self-hosting menawarkan kapabilitas kelas frontier dan kontrol infrastruktur, namun bukan jalan pintas desktop berbiaya rendah.

Can You Actually Run Kimi K3 Locally?

Ya, tetapi ada dua definisi “lokal” yang sangat berbeda.

Server lokal / pusat data privat: realistis.

Desktop atau laptop normal: secara teknis dapat dieksperimenkan dengan build komunitas yang sangat dikuantisasi, tetapi umumnya tidak praktis untuk penggunaan interaktif.

Resep vLLM Kimi K3 saat ini menetapkan baseline yang sangat tinggi:

• NVIDIA: setidaknya 8× GB300
• AMD ROCm: setidaknya 8× MI355X atau MI350X
• Driver NVIDIA: R580+ untuk image K3 CUDA 13 saat ini
• Infrastruktur multi-node direkomendasikan untuk trafik produksi nyata

Panduan vLLM day-0 asli juga menunjukkan jalur cepat 8-GPU B300 atau 8-GPU MI355X. Untuk deployment produksi baru, ikuti resep yang lebih baru karena mencerminkan stack serving setelah optimasi hari peluncuran.

Ini poin kuncinya: K3 open-weight, namun bukan model open berskala konsumen.

Official Weights vs Community GGUF Quantizations

Ada cara lain untuk menurunkan ambang perangkat keras: kuantisasi komunitas.

Repositori Unsloth K3 saat ini menyediakan beberapa varian GGUF yang dapat berjalan melalui perangkat lunak kompatibel llama.cpp.

Perbandingan konsolidasi. Angka memori yang dapat dialamatkan adalah estimasi perencanaan (ukuran unduhan plus sekitar 10–15% headroom runtime), bukan jaminan; pengaturan konteks, cache, visi, dan offload dapat memerlukan lebih banyak.

Pembedaan ini juga menjelaskan mengapa beberapa artikel deployment lokal awal mengutip 594 GB: 594 GB kini merujuk pada build GGUF komunitas UD-IQ1_S, bukan deskripsi berguna dari checkpoint native lengkap saat ini.

Model 466–649 GB jauh lebih kecil dibanding jejak deployment asli, tetapi masih sangat besar menurut standar workstation. Anda juga harus menyisihkan memori untuk state runtime, konteks, cache, vision projector, proses sistem operasi, dan overhead lainnya.

Kapasitas disk bukanlah memori inferensi. Memiliki SSD 1 TB tidak berarti model 600 GB akan berjalan cepat di mesin dengan RAM 64 GB. Offloading ke SSD dapat membuat eksperimen ekstrem menjadi mungkin, tetapi generasi token bisa menjadi sangat lambat.

How to Deploy Kimi K3 with vLLM

Untuk self-hosting serius, vLLM adalah titik awal yang paling lugas.

Moonshot saat ini mencantumkan vLLM sebagai salah satu engine inferensi K3 yang direkomendasikan, dan vLLM menyediakan dukungan khusus model untuk KDA, MXFP4 MoE, parsing reasoning, tool calling, prefix caching, dan deployment terdistribusi.

Periksa prasyarat

Untuk deployment produksi NVIDIA, resep teruji saat ini menggunakan container vllm/vllm-openai:kimi-k3.

Periksa GPU:

nvidia-smi

Konfirmasi Docker:

docker --version

Konfirmasi NVIDIA Container Toolkit dapat melihat akselerator:

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Jika perintah terakhir tidak dapat melihat semua GPU, perbaiki runtime GPU host/container sebelum mengunduh model multi-terabyte.

Setel token Hugging Face Anda

Jika autentikasi diperlukan untuk repositori model, simpan token dalam variabel lingkungan alih-alih menulisnya langsung ke skrip.

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Tarik container K3 vLLM

docker pull vllm/vllm-openai:kimi-k3

Resep saat ini menetapkan build CUDA 13 dan driver NVIDIA R580 atau lebih baru.

Luncurkan Kimi K3

Template awal Blackwell TP8 saat ini (resep vLLM diperbarui 2026-09-10): gunakan ini sebagai baseline, lalu regenerasi atau benchmark profil untuk perangkat keras dan trafik Anda.

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

Resep saat ini memerlukan image K3 CUDA 13 dan driver NVIDIA R580 atau lebih baru. KV cache FP8 harus dipasangkan dengan backend MLA prefill/decode yang kompatibel; lakukan benchmark alternatif sebelum mengubah konfigurasi attention.

Sumber: resep vLLM Kimi K3. Ini menggantikan perintah day-0 sebelumnya alih-alih menyajikannya sebagai resep produksi saat ini.

Untuk run validasi pertama, pertimbangkan membatasi panjang model maksimum alih-alih langsung mengalokasikan capability 1.048.576 token penuh. Resep vLLM saat ini secara eksplisit merekomendasikan menyesuaikan max-model-len sesuai beban kerja.

Sebagai contoh:

--max-model-len 131072

Ini tidak mengubah batas konteks arsitektural K3. Ini hanya memberikan engine serving envelope operasional yang lebih mudah dikelola untuk pengujian awal Anda.

Uji endpoint lokal

vLLM mengekspos API kompatibel OpenAI pada port 8000.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

Atau gunakan OpenAI Python SDK:

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

Resep vLLM resmi menggunakan pola localhost kompatibel OpenAI yang sama, sehingga relatif mudah mengganti aplikasi antara inferensi lokal dan hosted.

How to Deploy Kimi K3 with SGLang

SGLang adalah rute deployment besar lainnya yang resmi direkomendasikan oleh Moonshot.

Ini sangat relevan ketika Anda menginginkan kontrol lebih dalam atas serving terdistribusi, expert parallelism, kernel spesifik hardware, atau topologi produksi yang kompleks.

Gunakan Cookbook Kimi K3 SGLang khusus dan pilih topologi spesifik hardware. Berikut adalah profil Unified/Balanced 8×B300 single-node terverifikasi dari cookbook; ini diukur dengan SGLang v0.5.18 pada commit 71de97b2.

Pasang build yang mendukung K3:

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Luncurkan profil B300 TP8/DCP8 terverifikasi:

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio bergantung beban kerja: hitung dari rata-rata panjang input plus output di cookbook resmi. Jangan menyalin topologi B300 ini ke H100/H200, GB200/GB300, AMD, atau deployment multi-node; profil tersebut menggunakan layout TP/PP/DCP/EP yang berbeda.

Uji server:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

Untuk deployment nyata, validasi kapasitas, kualitas output, dan pemulihan kegagalan pada versi SGLang, topologi, panjang konteks, dan campuran trafik yang akan Anda jalankan.

vLLM vs SGLang vs llama.cpp

Memilih engine inferensi terutama bergantung pada perangkat keras Anda dan tujuan deployment.

Jika Anda memiliki server 8-GPU kelas Blackwell/MI35x, mulailah dengan vLLM.

Jika Anda merancang klaster inferensi terdistribusi khusus dan menginginkan kontrol serving tingkat rendah yang lebih banyak, evaluasi SGLang juga.assistant_message

Jika tujuan Anda sederhana “Saya ingin membuktikan bahwa K3 bisa berjalan pada hardware milik saya,” GGUF plus llama.cpp jauh lebih terjangkau—dengan catatan mesin Anda memiliki jumlah memori yang benar-benar luar biasa.

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

Repositori Kimi K3 GGUF komunitas kini menyediakan varian kompatibel llama.cpp.

Rute ini menurunkan hambatan masuk secara dramatis dibanding deployment bobot native kelas pusat data, tetapi “dramatis” bersifat relatif: bahkan build yang lebih kecil pun berukuran ratusan gigabita.

Pasang llama.cpp di macOS atau Linux

Model card GGUF saat ini menyediakan:

curl -LsSf https://llama.app/install.sh | sh

Di Windows:

winget install llama.cpp

Mulai server kompatibel OpenAI

Repositori saat ini mendokumentasikan UD-Q4_K_XL sebagai contoh:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Anda juga dapat menjalankan CLI langsung:

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Perintah tersebut berasal langsung dari model card Kimi K3 GGUF saat ini.

Namun, UD-Q4_K_XL berukuran sekitar 1,51 TB, sehingga bukan varian yang akan dipilih sebagian besar pengguna workstation. Jika prioritas Anda adalah mengurangi kebutuhan memori alih-alih mempertahankan kualitas sebanyak mungkin, pertimbangkan varian 1-bit dan 2-bit yang lebih kecil terlebih dahulu.

Sebagai contoh:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

Direktori UD-IQ1_M saat ini kira-kira 649 GB.

Model 649 GB tetap bukan model untuk laptop normal. Idealnya, state model yang sering diakses harus berada di memori cepat. Offloading berat ke SSD mungkin membuat eksperimen ekstrem menjadi mungkin tanpa membuatnya berguna untuk pekerjaan interaktif.

Run the Same GGUF Build with Ollama

Ollama adalah lapisan kemudahan untuk rute deployment GGUF yang sama, bukan metode self-hosting keempat yang independen.

Repositori K3 GGUF juga mengekspos rute Ollama.

Sebagai contoh:

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama menyederhanakan manajemen model dan pengalaman API, tetapi tidak menghapus kebutuhan memori K3.

Mengubah peluncur dari llama.cpp ke Ollama tidak dapat mengubah kuantisasi beberapa ratus gigabita menjadi model GPU 24 GB. Data model yang mendasari tetap harus disimpan dan diakses.

Karena alasan ini, Ollama sebaiknya dipandang sebagai pembungkus runtime yang nyaman, bukan sebagai solusi pengganti perangkat keras.

Which Kimi K3 Quantization Should You Choose?

Untuk eksperimen, pilihan utamanya adalah trade-off antara ukuran model dan fidelitas.

Important Kimi K3 Serving Behavior

Ada satu detail implementasi spesifik K3 yang mudah terlewat.

K3 menggunakan preserved thinking history. Moonshot menyatakan percakapan multi-turn dan alur kerja tool-call harus mengirim kembali pesan assistant sebelumnya yang lengkap, termasuk reasoning_content dan tool_calls, alih-alih hanya mempertahankan konten yang terlihat.

Pola aplikasi sederhana terlihat seperti ini:

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

Ini menjadi sangat penting untuk agen coding, loop tool, dan sesi otonom yang berjalan lama.

K3 juga menjaga reasoning tetap aktif dan mendukung low, high, dan max reasoning effort. Ketika layer serving Anda mengekspos parameter tersebut, perlakukan reasoning effort sebagai kontrol latensi/kualitas lain daripada selalu memaksimalkannya untuk setiap permintaan.

How to Optimize a Local Kimi K3 Deployment

Jangan langsung mengalokasikan seluruh konteks 1M

K3 mendukung 1.048.576 token, tetapi kapabilitas maksimum model dan konfigurasi server yang masuk akal adalah hal berbeda.

Untuk pengembangan, mulailah dengan sesuatu seperti:

--max-model-len 131072

Kemudian tingkatkan konteks hanya setelah mengukur memori yang tersedia, waktu ke token pertama, throughput, dan perkiraan konkurensi.

Aktifkan prefix caching

Agen coding sering menggunakan ulang instruksi repositori, skema tool, prompt sistem, dan prefix panjang.

Dengan vLLM:

--enable-prefix-caching

Arsitektur attention hibrida K3 memerlukan penanganan khusus untuk prefix caching, dan vLLM telah mengimplementasikan dukungan khusus model untuk ini.

Gunakan parser K3

Untuk beban kerja agen, sertakan:

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

Ini menjaga tool call dan output reasoning selaras dengan format serving K3.

Jaga storage tetap cepat

Model pada skala ini menempatkan tekanan yang tidak biasa pada storage lokal selama unduhan pertama, pemuatan checkpoint, pembaruan, dan pemulihan.

Storage NVMe lebih disukai dibanding disk jaringan yang lambat. Jika beberapa mesin berbagi file model, topologi cache model dan bandwidth jaringan menjadi bagian dari arsitektur inferensi, bukan sekadar detail deployment.

Pantau lebih dari sekadar utilisasi GPU

Lacak:

• Utilisasi HBM/VRAM
• RAM CPU
• tingkat hit cache
• waktu ke token pertama
• token decode per detik
• kedalaman antrean permintaan
• komunikasi antar-GPU
• bandwidth antar-node
• kegagalan parsing tool-call
• waktu pemuatan model

Pada skala K3, angka utilisasi GPU yang tampaknya sehat tidak memberi tahu apakah topologi serving Anda efisien.

Local Kimi K3 vs Hosted Kimi K3

Self-hosting memberi tim kontrol maksimum atas jalur data, runtime, dan bobot model, sekaligus membuat mereka bertanggung jawab atas kapasitas GPU, scaling, upgrade, pemantauan, dan pemulihan. Akses hosted menghapus sebagian besar pekerjaan infrastruktur dan umumnya lebih cepat untuk evaluasi atau permintaan yang berubah-ubah.

Untuk analisis lengkap perangkat keras dan break-even, baca Kimi K3 Self-Hosting vs API. Untuk harga token, caching, dan perbandingan K2.7, gunakan panduan harga Kimi K3. Artikel ini oleh karena itu menjaga perbandingan tetap singkat dan berfokus pada perintah deployment, konfigurasi, dan troubleshooting.

Common Kimi K3 Local Deployment Problems

Model tidak muat di memori GPU

Ini adalah kegagalan yang paling dapat diprediksi.

Jangan menghitung memori dari 104B parameter yang diaktifkan. Angka itu menggambarkan komputasi per token, bukan jumlah data bobot expert yang harus disediakan oleh sistem serving.

Gunakan topologi terdistribusi yang didukung, kuantisasi GGUF yang lebih kecil, atau layanan hosted.

Error CUDA atau driver NVIDIA

Image vLLM K3 saat ini berbasis CUDA 13 dan memerlukan driver host R580+.

Jika host masih pada stack R575/CUDA 12.9, perbarui atau ikuti jalur build-from-source yang dijelaskan oleh vLLM alih-alih mengasumsikan container akan memperbaiki ketidakcocokan driver host.

Permintaan pertama sangat lambat

Periksa apakah checkpoint masih dimuat, kernel masih dikompilasi, cache dipanaskan, atau file masih diunduh.

Dengan aset kelas multi-terabyte, “proses server dimulai” dan “model siap untuk trafik produksi” bukan keadaan yang setara.

Panggilan tool gagal sesekali

Resep vLLM saat ini mencatat bahwa K3 kadang menghasilkan bentuk tool-call yang tidak diharapkan oleh parsernya. Sistem produksi karenanya harus memvalidasi skema tool-call dan menerapkan retry alih-alih mempercayai setiap panggilan yang dihasilkan secara buta.

Percakapan panjang menjadi kurang stabil

Pastikan Anda mengembalikan pesan assistant lengkap—termasuk informasi reasoning dan tool—ke putaran K3 berikutnya.

Menghilangkan field state reasoning tersembunyi dapat merusak pola preserved-thinking-history yang dilatih K3.

So, What Is the Best Way to Deploy Kimi K3 Locally?

Bagi sebagian besar organisasi dengan perangkat keras yang sesuai, vLLM adalah jalur deployment pertama terbaik. Ia memiliki dukungan khusus K3, API kompatibel OpenAI, parser khusus model, prefix caching, dukungan speculative decoding, dan resep perangkat keras terkini.

Pilih SGLang ketika rekayasa inferensi terdistribusi dan kontrol serving berbutir halus lebih penting daripada jalur setup terpendek.

Pilih llama.cpp plus kuantisasi GGUF komunitas hanya ketika tujuan Anda adalah eksperimen workstation/server dan Anda memahami bahwa bahkan versi 1-bit tetap berukuran ratusan gigabita.

Untuk workstation developer konvensional, kesimpulan paling praktis berbeda: jangan membeli ratusan gigabita RAM semata-mata untuk memaksa K3 ke desktop. Ujilah Kimi K3 melalui CometAPI terlebih dahulu, kuantifikasikan manfaatnya pada tugas Anda sendiri, dan beralih ke self-hosting hanya ketika privasi, utilisasi berkelanjutan, atau kontrol infrastruktur membuat ekonominya masuk akal.

FAQ

Bisakah Kimi K3 berjalan di satu GPU konsumen?

Tidak realistis. Model ini jauh melampaui kapasitas VRAM GPU konsumen. Kuantisasi GGUF low-bit komunitas mengurangi jejak secara signifikan, tetapi varian terkecil saat ini tetap ratusan gigabita.

Bisakah saya menjalankan Kimi K3 di Mac?

Eksekusi eksperimental CPU/Apple-Silicon dengan GGUF dan offloading storage pada prinsipnya memungkinkan, tetapi kinerja interaktif dan kapasitas memori menjadi faktor pembatas. MacBook tipikal tidak boleh diperlakukan sebagai platform serving K3 yang praktis.

Apakah Kimi K3 mendukung Ollama?

Build GGUF komunitas dapat diluncurkan melalui Ollama. Runtime menyederhanakan setup tetapi tidak mengubah kebutuhan memori yang mendasarinya.

vLLM atau SGLang mana yang lebih baik untuk Kimi K3?

vLLM lebih mudah sebagai default untuk deployment produksi baru. SGLang menarik untuk tim yang membangun topologi serving terdistribusi canggih. Keduanya termasuk engine inferensi K3 yang direkomendasikan Moonshot.

Berapa banyak konteks yang didukung Kimi K3?

Spesifikasi model resmi mendukung 1.048.576 token. Server lokal tidak harus mengekspos seluruh jendela konteks; menetapkan max-model-len yang lebih rendah bisa lebih praktis untuk deployment awal dan konkurensi lebih tinggi.

Apakah Kimi K3 open source?

Deskripsi yang lebih tepat adalah open-weight. Moonshot telah merilis bobot model di bawah Lisensi Kimi K3. Tinjau lisensi tersebut secara langsung sebelum redistribusi komersial atau penggunaan lain di mana ketentuan lisensi penting.

Apa cara termudah menggunakan Kimi K3 tanpa GPU lokal?

API hosted adalah rute termudah. Kimi K3 tersedia melalui CometAPI dengan antarmuka chat-completions kompatibel OpenAI, sehingga kode aplikasi dapat tetap dekat dengan apa yang akan Anda gunakan terhadap server vLLM atau SGLang lokal.