Keperluan untuk self-host Kimi K3

Keperluan untuk self-host Kimi K3

Self-hosting Kimi K3 memerlukan ruang untuk 2.8 trilion parameter. Moonshot menerbitkan open weights dalam MXFP4, iaitu kira-kira setengah bait bagi setiap weight. Oleh itu, weight sahaja memerlukan kira-kira 1.4 TB sebelum anda memperuntukkan satu token pun untuk cache. Tiada accelerator yang dijual hari ini dapat menampung jumlah itu secara bersendirian. K3 ialah model berbilang nod, jadi satu pelayan tidak memadai.

Itulah kesimpulannya. Semua perkara di bawah ialah pengiraan yang mendasarinya kerana pengiraan ini boleh digunakan semula untuk keluaran seterusnya. Beberapa vendor infrastruktur menerbitkan panduan deployment K3 dalam beberapa minggu selepas pengumuman pada 17 July 2026, dan setiap panduan mengandaikan anda sudah memiliki cluster. Halaman ini bermula dari arah yang berbeza: kosnya, perkara yang boleh anda jalankan sebagai ganti, dan cara menentukan keadaan yang anda hadapi.

Jumlah parameter dan parameter aktif bukan nombor yang sama

K3 ialah model mixture of experts. MoE (mixture of experts) membahagikan rangkaian kepada banyak subrangkaian dan membolehkan router memilih beberapa daripadanya bagi setiap token. Kad model menyenaraikan 2.8T jumlah parameter dan 104B parameter yang diaktifkan bagi setiap token, daripada 896 routed experts, dengan 16 daripadanya diaktifkan untuk mana-mana token tertentu, merentasi 93 lapisan.

Kedua-dua jumlah parameter itu menjawab soalan yang berbeza. Menukar penggunaannya ialah kesilapan yang paling biasa dalam setiap perbincangan "bolehkah saya menjalankannya".

Parameter aktif menentukan kos pengiraan. Sesuatu token melalui kira-kira 104B parameter dalam pengiraan, jadi throughput yang patut dijangkakan lebih menyerupai model dense 104B berbanding model 2.8T. Itulah sebab utama MoE dibina.

Jumlah parameter menentukan kos memori. Router boleh memilih mana-mana expert bagi mana-mana token, jadi setiap expert perlu berada dalam memori sebelum permintaan pertama tiba. Anda tidak boleh menyimpan 104B dalam VRAM dan mengambil parameter yang selebihnya apabila diperlukan, kerana proses pengambilan itu perlu selesai dalam masa mikrodetik, sedangkan pautan PCIe hanya memindahkan puluhan gigabait sesaat. Ada yang tetap mencubanya. Streaming expert daripada NVMe menukar model yang sepatutnya menghasilkan berpuluh-puluh token sesaat menjadi model yang menghasilkan satu token setiap beberapa saat.

Jadi, kos pengiraannya rendah tetapi kos penyimpanannya tinggi. Tentukan saiz perkakasan berdasarkan 2.8T. Tetapkan jangkaan kelajuan berdasarkan 104B.

Bait per berat, dan dari mana terabait itu datang

Bilangan parameter didarab dengan bait bagi setiap berat. Untuk berat, itulah keseluruhan formulanya.

[
  {
    "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 kesedaran kuantisasi dan dikeluarkan dengan berat MXFP4 serta pengaktifan MXFP8, jadi baris 4-bit ialah angka sebenar. Baris di atasnya menunjukkan skala: pada bf16, model yang sama memerlukan 5.6 TB. MXFP4 juga menyimpan satu skala 8-bit yang dikongsi bagi setiap blok 32 berat, yang menambah kira-kira 6 peratus. Oleh itu, repositori yang diterbitkan berukuran hampir 1.5 TB, bukannya 1.4 TB yang dikira tanpa tambahan tersebut.

Ini menutup jalan keluar yang lazim. "Kuantisasikan sahaja" tidak membantu di sini kerana checkpoint yang dikeluarkan sudah 4-bit. Menurunkannya kepada 2-bit akan menjadikan berat berukuran 0.7 TB dan menjejaskan ketepatan, yang belum diukur pada checkpoint ini. Saiznya masih jauh melebihi kapasiti mana-mana satu kad.

Berapa GPU yang diperlukan oleh 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
  }
]

Anggap angka ini sebagai had minimum, bukan sasaran. Angka tersebut hanya mengira berat model: tiada cache KV, penimbal pengaktifan, fragmentasi allocator atau ruang untuk permintaan serentak kedua. Angka ini juga mengandaikan pembahagian selari yang sama rata, sedangkan 93 lapisan dan 896 pakar tidak semestinya membenarkannya.

Panduan yang diterbitkan menetapkan keperluan yang jauh lebih tinggi daripada had minimum ini. Setakat Ogos 2026, Moonshot mengesyorkan supernode dengan 64 atau lebih accelerator. Cookbook SGLang pula menyediakan konfigurasi H100 yang dibina daripada empat nod 8-GPU, iaitu 32 GPU dan 2,560 GB memori agregat, berbanding had minimum 18 kad. Perbezaan itu bukan pembaziran. Ia menyediakan ruang untuk cache KV, memori pengaktifan dan kapasiti tambahan supaya server boleh memproses banyak permintaan secara berkumpulan pada satu masa. Malah baris yang paling menjimatkan, 5 kad kelas GB300, merujuk kepada mesin yang kebanyakan penyedia tidak menyewakannya sebagai satu SKU.

Cache KV ialah bahagian yang sering mengejutkan pengguna

Berat model ialah kos tetap. Cache KV (key value) bukan kos tetap: saiznya meningkat mengikut panjang konteks dan meningkat lagi bagi setiap pengguna serentak. Bagi attention biasa, formulanya ialah bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, kemudian darabkan dengan panjang konteks dan bilangan pengguna serentak.

Berikut ialah contoh pengiraan, dan ini hanya contoh: 64 lapisan, 8 kepala KV, dimensi kepala 128 dan fp8. Hasilnya ialah 2 64 8 128 1 = 131,072 bait, iaitu 128 KiB bagi setiap 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
  }
]

Seorang pengguna dengan konteks 128k menggunakan 16 GiB. Seorang pengguna dengan konteks penuh sejuta token menggunakan 128 GiB, iaitu lebih besar daripada kapasiti mana-mana kad tunggal, untuk satu perbualan.

K3 tidak menggunakan attention biasa, dan angka terakhir itu menjelaskan sebabnya. K3 mempunyai 93 lapisan, iaitu 69 lapisan KDA (Kimi Delta Attention) dan 24 lapisan Gated MLA (multi-head latent attention). KDA mengekalkan keadaan berulang bersaiz tetap dan bukannya cache yang berkembang dengan setiap token. MLA memampatkan key dan value menjadi satu vektor laten berpangkat rendah. Oleh itu, kos sebenar bagi setiap token jauh lebih rendah daripada contoh pengiraan tadi. Moonshot belum menerbitkan dimensi laten, jadi saya tidak akan memberikan angka bagi setiap pengguna untuk K3. Ukur sendiri: mulakan pelayan dengan --max-model-len yang kecil, pantau memori menggunakan nvidia-smi, kemudian tingkatkan had itu sehingga peruntukan memori gagal.

Bentuk penaakulan ini masih terpakai untuk keluaran seterusnya. Jika model mengiklankan konteks sejuta token tetapi tidak menjelaskan reka bentuk attentionnya, anggap cache sebagai kekangan utama sehingga ada pihak membuktikan sebaliknya.

Tier 1: sewa kluster mengikut jam

Ini satu-satunya tier yang menjalankan K3 sendiri. Anda tidak membeli perkakasan tersebut. Anda menyewanya untuk tempoh yang diperlukan dan menghentikannya selepas itu.

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

Kadar ini ialah andaian, bukan sebut harga. Harga senarai atas permintaan untuk pemecut pusat data berada kira-kira antara 2 hingga 5 USD bagi setiap jam GPU sehingga 2026, manakala kapasiti terpelihara lebih murah. Gunakan angka sebenar daripada penyedia anda dan buat semula pengiraan: GPU didarab dengan jam dan kadar. Tujuan carta ini adalah untuk menunjukkan nisbah. Menjalankan nod 8 GPU selama empat jam sehari menelan kos 2,400 USD sebulan, manakala membiarkan konfigurasi 32 GPU yang dilaraskan untuk SGLang terus berjalan menelan kos 57,600 USD.

Kedua-dua pelayan utama menerbitkan perintah pelancaran pada kad model.

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

Tiada satu pun perintah asas itu boleh digunakan secara terus pada kluster sebenar. Tambahkan flag parallelism yang sepadan dengan perkakasan anda: SGLang menggunakan --tp-size untuk tensor parallel dan --ep-size untuk expert parallel, dan hasil darab kedua-duanya mesti sama dengan jumlah GPU yang benar-benar anda miliki.

Pastikan pelayan telah bermula sebelum anda menghantar trafik sebenar:

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

Pelayan yang sihat memberikan respons dalam bentuk objek JSON yang menyenaraikan ID model. Connection refused bermaksud proses masih memuatkan weight atau telah berhenti, jadi baca log pelayan sebelum mencuba lagi.

Kegagalan yang lazim berlaku pada hari pertama ialah runtime yang lebih lama daripada model. K3 dikeluarkan bersama KDA dan lapisan MoE baharu yang belum disertakan dalam release stabil vLLM dan SGLang semasa pelancaran, dan gejalanya ialah pelayan berhenti semasa permulaan dengan baris dalam bentuk Model architectures [...] are not supported for now. Tiada perubahan konfigurasi yang dapat membaikinya kerana kod untuk menjalankan lapisan tersebut tiada dalam build anda. Pasang nightly yang dinamakan pada kad model, atau tunggu release yang menyertakannya.

Satu perkara tentang kos yang sering terlepas pandang. Meter bermula apabila instance bermula, bukan apabila model sudah sedia. Muat turun 1.5 TB pada kelajuan 1 GB/s mengambil kira-kira 25 minit masa kluster sebelum token pertama. Letakkan weight pada volume yang kekal selepas instance dihentikan, supaya proses kedua bermula dalam beberapa minit.

Tahap 2: jalankan model yang lebih kecil pada satu pemecut

Anda tidak menjalankan K3 pada tahap ini. Nyatakan perkara itu dengan jelas sebelum bermula, kerana kebanyakan perbincangan tentang "menjalankan K3 secara setempat" berakhir pada tahap ini tanpa mengakuinya.

Peraturan kesesuaian masih menggunakan formula yang sama dalam skala lebih kecil: parameter didarab dengan bait bagi setiap weight, kemudian ditambah dengan cache KV dan kira-kira 2 GB overhed masa jalan, mesti berada dalam kapasiti VRAM anda. Pada 4-bit, nilainya kira-kira setengah bait bagi setiap parameter, lalu menghasilkan padanan yang selesa:

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

Setiap padanan di atas mengandaikan satu permintaan pada satu-satu masa. Apabila orang kedua menghantar prompt, setiap slot serentak memerlukan cache KV sendiri. Inilah pertukaran yang tetapan NUM_PARALLEL dan MAX_QUEUE Ollama sediakan antara slot selari, permintaan dalam baris gilir dan VRAM yang masih tersedia.

Ollama ialah cara paling ringkas untuk menyediakan server yang berfungsi pada VPS dengan GPU yang dipasang:

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

ollama run memuat turun model pada penggunaan pertama, kemudian memaparkan prompt. Tag yang tidak wujud mengembalikan Error: model "..." not found. Oleh itu, salin tag daripada halaman library dan jangan taip berdasarkan ingatan. Panduan lengkap, termasuk unit systemd dan akses jauh, terdapat dalam menjalankan Ollama pada VPS.

llama.cpp memberikan lebih banyak kawalan terhadap 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 dimuatkan pada GPU. Baca log pemuatan: log tersebut memaparkan bilangan layer yang telah di-offload. Layer yang melimpah ke RAM sistem berjalan pada jalur lebar RAM, bukan jalur lebar HBM. Oleh itu, kelajuan penjanaan menurun dengan ketara sebaik sahaja model tidak lagi muat sepenuhnya. Pertukaran antara kedua-dua alat ini diterangkan dalam Ollama dan llama.cpp secara bersebelahan.

Tahap 3: API dihoskan, penyelarasan layan diri

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

Titik akhir ini serasi dengan OpenAI, jadi klien sedia ada boleh digunakan selepas anda menukar URL asas.

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

Kunci yang berfungsi mengembalikan objek JSON dengan tatasusunan choices. 401 bermaksud kunci itu salah atau awalan Bearer tiada. Ralat model tidak ditemui biasanya bermaksud id tersebut telah berubah kerana penyedia menamatkan penggunaan id antara checkpoint.

Kini, kira titik pulang modal menggunakan kadar sewaan yang diandaikan di atas. Nod 8 GPU yang sentiasa aktif berharga 14,400 USD sebulan, manakala pada harga 15.00 USD bagi setiap juta token output, jumlah yang sama membeli kira-kira 960 juta token output daripada API. Untuk menjimatkan kos, anda perlu menjana hampir satu bilion token output sebulan, iaitu kira-kira 30 juta sehari, dan memastikan kluster sibuk sepanjang masa kerana GPU yang tidak digunakan dibilkan pada kadar yang sama seperti GPU yang sedang digunakan. Beban kerja ejen yang banyak menggunakan prompt menjauhkan titik ini lagi: konteks berulang dibilkan pada kadar cache-hit 0.30 USD bagi setiap juta, bukannya kadar cache-miss 3.00 USD.

Perkara yang anda hos sendiri pada tahap ini ialah segala-galanya di sekeliling model: gateway yang menyimpan kunci API supaya kunci itu tidak pernah sampai kepada klien, log permintaan dan respons, percubaan semula, had kadar serta belanjawan bagi setiap pengguna. Semua ini berjalan pada VPS kecil tanpa GPU. Pembahagian yang sama terpakai pada weight tertutup. Claude tidak boleh dihos sendiri pada tahap model, dan penyelarasan ialah satu-satunya bahagian yang anda miliki.

Pelayan stack penyajian yang sesuai untuk setiap peringkat

Pelayan dalam kelas vLLM dan SGLang tergolong dalam peringkat 1. Pelayan ini direka untuk mengendalikan banyak permintaan serentak, dengan continuous batching dan cache KV berhalaman, serta tensor parallelism dan expert parallelism yang diagihkan merentasi beberapa nod. Pelayan ini mengandaikan penggunaan accelerator di pusat data dan interconnect berkelajuan tinggi antara accelerator tersebut. Pada satu kad pengguna, pelayan ini lebih sukar dipasang dan hanya memberikan sedikit manfaat yang dapat anda lihat.

llama.cpp dan Ollama tergolong dalam peringkat 2. Kedua-duanya menyasarkan satu mesin, quantisation GGUF, CPU offload apabila model tidak muat dalam memori, serta concurrency yang rendah. llama.cpp secara teknikal boleh memuatkan MoE yang sangat besar dengan mengekalkan kebanyakan layer dalam RAM sistem, tetapi bagi model 2.8T, kaedah itu mengambil masa beberapa saat bagi setiap token. Ini hanya membuktikan bahawa fail tersebut boleh dihuraikan. Ia bukan servis yang sesuai untuk digunakan oleh pengguna. Perbandingan penuh terdapat dalam Ollama berbanding vLLM, dan perbandingan ini tidak berubah mengikut model: persoalannya sentiasa sama ada anda menyediakan servis kepada ramai pengguna pada hardware yang dikongsi atau kepada seorang pengguna pada hardware milik anda sendiri.

Empat nombor yang kekal relevan selepas titik semakan ini

1. Jumlah parameter didarab dengan bait bagi setiap weight menentukan had minimum memori. Tiada model boleh berjalan di bawah had ini, dan tiada kaedah quantisation dapat mengurangkannya dengan banyak apabila release itu sudah menggunakan 4-bit.
2. Parameter aktif menentukan kelas throughput. MoE 2.8T dengan 104B parameter aktif mempunyai keperluan pengiraan seperti model 104B.
3. KV cache bagi setiap token, didarab dengan panjang context dan concurrency, ialah kos yang terus meningkat selepas kos weight ditanggung.
4. Token sesaat bagi setiap dolar ialah satu-satunya nombor yang menentukan tier. Semua perkara di atas menjadi input kepadanya.

Gunakan keempat-empat perkara ini pada mana-mana release untuk mendapatkan jawapan yang tepat sebelum membuka panduan vendor. Kemudian, nyatakan tarikh bagi setiap angka yang anda catat. Harga dan senarai seni bina yang disokong kedua-duanya berubah dalam tempoh dua minggu selepas K3 dilancarkan, dan setiap angka pada halaman ini diterbitkan pada Julai 2026.

FAQ

Bolehkah saya menjalankan Kimi K3 pada satu GPU?

Tidak. Weights tersebut berukuran kira-kira 1.4 TB pada ketepatan MXFP4 yang dikeluarkan oleh Moonshot, manakala accelerator tunggal terbesar yang dijual mempunyai kapasiti 288 GB. Model MoE tidak boleh menstrim expert yang tidak aktif dari cakera pada kelajuan yang boleh digunakan, kerana router boleh memilih mana-mana expert untuk mana-mana token dan pengambilan melalui PCIe mengambil masa jauh lebih lama daripada belanjawan masa token. Deployment K3 terkecil yang munasabah ialah nod berbilang GPU, dan resipi yang diterbitkan menggunakan 32 accelerator atau lebih.

Berapa banyak VRAM yang diperlukan oleh Kimi K3?

Mulakan dengan 1.4 TB untuk weights sahaja, iaitu 18 kad H100 80GB atau 5 kad kelas GB300. Kemudian tambahkan cache KV dan memori activation. Setakat August 2026, Moonshot mengesyorkan 64 accelerator atau lebih, manakala cookbook SGLang menerbitkan konfigurasi 32 GPU H100 dengan jumlah keseluruhan 2,560 GB. Oleh itu, anggap angka weights sebagai had minimum, bukan keperluan sebenar.

Adakah quantisation membolehkan Kimi K3 dimuatkan pada satu nod?

Tidak secara praktikal. Checkpoint yang dikeluarkan itu sudah menggunakan 4-bit dengan quantisation-aware training, jadi penjimatan mudah telah pun diperoleh. Jika dikurangkan lagi kepada 2-bit, weights menjadi 0.7 TB, yang masih lebih daripada dua kali ganda kapasiti kad terbesar. Kos ketepatan 2-bit pada model ini juga belum diukur.

Adakah menyewa GPU lebih murah daripada API Kimi K3?

Hanya pada volum yang tinggi dan stabil. Dengan andaian kos 2.50 USD bagi setiap jam GPU, nod 8 GPU yang sentiasa aktif berharga 14,400 USD sebulan. Jumlah yang sama membeli kira-kira 960 juta output token pada kadar diterbitkan sebanyak 15.00 USD bagi setiap juta token. Anda juga perlu membayar jam tidak aktif, muat turun weights dan tenaga kerja yang mengekalkan cluster supaya terus beroperasi. Sewa mengikut jam untuk lonjakan penggunaan, dan bandingkan dengan volum token yang diukur sendiri, bukan anggaran.

Apakah maksud 104B active parameters dari segi kelajuan?

Maksudnya, pengiraan bagi setiap token adalah seperti model 104B. Oleh itu, throughput berada dalam kelas tersebut, bukan kelas 2.8T. Angka ini tidak menerangkan keperluan memori: semua parameter 2.8T kekal dalam memori kerana router boleh memanggil mana-mana expert untuk mana-mana token. Gunakan jumlah active parameters untuk menganggarkan token sesaat, dan jumlah keseluruhan parameters untuk menentukan keperluan VRAM.