Keperluan untuk self-host Kimi K3

Keperluan untuk self-hosting Kimi K3

Self-hosting Kimi K3 bermaksud mencari ruang untuk 2.8 trilion parameter. Moonshot menerbitkan open weights dalam format MXFP4, iaitu kira-kira separuh bait bagi setiap parameter, jadi berat model sahaja mencecah kira-kira 1.4 TB sebelum anda memperuntukkan satu token cache pun. Tiada pemecut (accelerator) yang dijual hari ini mampu menampung jumlah tersebut secara sendirian. Untuk satu GPU, jawapannya adalah tidak. Untuk satu pelayan, jawapannya adalah ya hanya jika pelayan tersebut merupakan nod 8-GPU dengan pemecut 288 GB, iaitu spesifikasi yang digunakan oleh resipi penyajian (serving recipes) terkecil yang diterbitkan.

Itulah keputusannya. Segala maklumat di bawah adalah pengiraan di sebaliknya, kerana pengiraan ini merupakan bahagian yang akan anda gunakan semula pada keluaran seterusnya. Beberapa vendor infrastruktur menerbitkan panduan penggunaan K3 dalam tempoh beberapa minggu selepas pengumuman pada 17 Julai 2026, dan setiap satunya mengandaikan anda sudah pun memiliki sebuah kluster. Halaman ini bermula dari sudut yang berbeza: apakah kosnya, apakah alternatif yang boleh anda jalankan, dan bagaimana untuk menentukan kategori mana yang anda hadapi.

Jumlah parameter dan parameter aktif tidak mempunyai angka yang sama

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

Dua kiraan parameter tersebut menjawab soalan yang berbeza, dan tertukar antara keduanya merupakan kesilapan paling lazim dalam setiap perbincangan "bolehkah saya menjalankan ini".

Parameter aktif menetapkan kos pengiraan. Satu token didarabkan melalui kira-kira 104B parameter, jadi throughput yang anda patut jangkakan menyerupai model padat 104B dan bukannya 2.8T. Itulah sebab utama MoE dibina.

Jumlah parameter menetapkan kos memori. Penghala mungkin memilih mana-mana pakar untuk mana-mana token, jadi setiap pakar perlu disimpan di suatu tempat yang pantas sebelum permintaan pertama tiba. Menyimpan hanya pakar yang kerap digunakan (hot experts) dalam VRAM dan mengambil yang selebihnya atas permintaan memang wujud: --moe-cache-mib dalam llama.cpp mengekalkan cache GPU bagi pakar yang sebaliknya berada dalam RAM sistem dan memuat naik pakar yang tiada apabila penghala memilihnya. Walau bagaimanapun, ia tidak mengecilkan jumlah keseluruhan. Pakar yang selebihnya masih perlu berada dalam RAM, dan pautan PCIe memindahkan puluhan gigabait sesaat berbanding terabait sesaat bagi HBM, jadi setiap cache miss akan memakan masa. Menstrim pakar daripada NVMe kerana model tersebut tidak muat dalam RAM adalah lebih perlahan, dan panduan K3 daripada Unsloth memberi amaran bahawa offloading cakera berjalan dengan jauh lebih perlahan.

Oleh itu, ia murah untuk dikira tetapi mahal untuk disimpan. Tentukan saiz perkakasan anda berdasarkan 2.8T. Tentukan jangkaan kelajuan anda berdasarkan 104B.

Bait per pemberat, dan dari mana datangnya terabait

Kiraan parameter didarab dengan bait per pemberat. Bagi pemberat, itulah formula keseluruhannya.

[
  {
    "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 pemberat MXFP4 serta pengaktifan MXFP8, jadi baris 4-bit adalah yang sebenar. Baris di atasnya disediakan sebagai skala: pada bf16, model yang sama memerlukan 5.6 TB. MXFP4 juga menyimpan satu skala 8-bit yang dikongsi bagi setiap blok 32 pemberat, yang menambah kira-kira 6 peratus, dan konfigurasi Moonshot mengecualikan attention, pakar yang dikongsi (shared experts) dan vision tower daripada format 4-bit, jadi pusat pemeriksaan (checkpoint) penuh berjumlah kira-kira 1.56 TB mengikut kiraan Unsloth dan bukannya 1.4 TB yang tepat.

Ini mengecilkan ruang alternatif biasa tanpa menutupnya sepenuhnya. Pusat pemeriksaan yang dikeluarkan sudah pun dalam format 4-bit, jadi penjimatan mudah telah pun diambil, tetapi pengurangan lanjut masih mengubah angka tersebut. Setakat 11 Oktober 2026, kuantisasi GGUF dinamik Unsloth bagi K3 berjulat daripada 861.3 GB untuk UD-Q2_K_XL 2-bit sehingga 594 GB untuk UD-IQ1_S 1-bit, dan Unsloth menerbitkan kosnya: persetujuan token top-1 dengan model penuh adalah 90.390 peratus pada UD-Q2_K_XL, 84.127 peratus pada UD-IQ2_XXS 711.1 GB dan 78.875 peratus pada UD-IQ1_S. Itu adalah kehilangan ketepatan yang diukur, dan binaan paling kecil pun masih kira-kira dua kali ganda saiz kad tunggal terbesar.

Berapakah bilangan 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 tersebut sebagai lantai, bukan sasaran. Angka itu hanya mengira berat model: tiada KV cache, tiada penimbal pengaktifan, tiada fragmentasi pengumpuk (allocator), dan tiada ruang untuk permintaan serentak kedua. Ia juga mengandaikan pembahagian selari yang sekata, yang tidak selalu dapat dicapai oleh 93 lapisan dan 896 pakar.

Panduan yang diterbitkan berada di atas lantai tersebut. Pada Ogos 2026, Moonshot mengesyorkan supernode dengan 64 atau lebih pemecut. Setakat 11 Oktober 2026, buku resipi SGLang mengeluarkan konfigurasi H100 yang dibina daripada empat nod 8-GPU, 32 GPU dan 2,560 GB memori agregat, berbanding lantai 18 kad. Ia juga menyenaraikan resipi nod tunggal pada satu nod 8-GPU B300 dan satu nod 8-GPU MI350X atau MI355X, dengan 2,304 GB pada 288 GB setiap kad. Jurang di atas lantai itu bukanlah pembaziran. Ia adalah untuk KV cache, memori pengaktifan, dan ruang kepala yang membolehkan pelayan memproses banyak permintaan secara serentak. Baris yang paling mesra, kad kelas 5 GB300, dalam praktiknya dibundarkan kepada tepat jenis nod 8-GPU tersebut, iaitu mesin terkecil yang diterbitkan oleh sesiapa untuk resipi penyajian K3.

KV cache ialah bahagian yang mengejutkan ramai orang

Weight merupakan kos tetap. KV (key value) cache pula tidak: ia berkembang mengikut panjang konteks dan bertambah dengan setiap pengguna serentak. Bagi attention biasa, formulanya ialah bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, kemudian anda darabkan dengan panjang konteks dan keserentakan.

Berikut ialah contoh pengiraan, dan ini hanyalah satu contoh: 64 layer, 8 KV head, dimensi head 128, fp8. Ini memberikan 2 64 8 128 1 = 131,072 bait, jadi 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 pada konteks 128k menelan kos 16 GiB. Seorang pengguna pada kapasiti penuh sejuta token menelan kos 128 GiB, iaitu hampir separuh daripada kad 288 GB untuk satu perbualan, sebelum satu pun weight dimuatkan.

K3 tidak menggunakan attention biasa, dan angka terakhir itulah sebabnya. 93 layer miliknya terdiri daripada 69 layer KDA (Kimi Delta Attention) dan 24 layer Gated MLA (multi-head latent attention). KDA mengekalkan state berulang bersaiz tetap dan bukannya cache yang berkembang dengan setiap token, manakala MLA memampatkan key dan value ke dalam satu vektor latent berpangkat rendah (low rank), jadi kos sebenar bagi setiap token jauh lebih rendah daripada contoh pengiraan tadi. Fail config.json yang diterbitkan oleh Moonshot memberikan saiz latent tersebut: kv_lora_rank sebanyak 512 ditambah dengan rotary key selebar 64 (qk_rope_head_dim), jadi 576 nilai bagi setiap token untuk setiap layer MLA. Merentasi 24 layer pada 2 bait setiap satu, jumlahnya ialah 27,648 bait, kira-kira 27 KiB bagi setiap token, atau sekitar 27 GiB untuk perbualan penuh 1,048,576 token, ditambah dengan state KDA yang tetap. Anggap ini sebagai anggaran dan bukannya ukuran tepat: enjin menyusun dan meletakkan cache mengikut cara tersendiri, dan cache 8-bit secara kasarnya mengurangkan saiz tersebut kepada separuh.

Untuk melihat apa yang disimpan oleh deployment anda sendiri, jangan pantau nvidia-smi semasa meningkatkan --max-model-len. vLLM melakukan pra-peruntukan (preallocate) pool KV cache-nya, yang disaizkan daripada --gpu-memory-utilization (0.92 secara lalai dalam dokumentasi semasa) atau daripada bajet cache per-GPU yang eksplisit, jadi jumlah memori GPU akan menunjukkan pool tersebut dan bukannya satu perbualan sahaja. Sebaliknya, baca log permulaan, di mana vLLM melaporkan saiz KV cache dalam unit token dan keserentakan maksimum pada panjang konteks anda.

Bentuk penaakulan ini akan kekal dalam keluaran seterusnya. Jika sesuatu model mengiklankan konteks sejuta token dan tidak menyatakan apa-apa tentang reka bentuk attention-nya, anggap cache sebagai kekangan utama sehingga dibuktikan sebaliknya.

Tahap 1: sewa kluster mengikut jam

Ini adalah satu-satunya tahap yang menjalankan K3 pada ketepatan yang dibekalkan (shipped precision). Anda tidak membeli perkakasan tersebut. Anda menyewanya untuk jam 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 tersebut adalah anggaran, bukan sebut harga. Kadar atas permintaan (on-demand) berbeza-beza mengikut penyedia dan generasi GPU; komponen 288 GB yang diperlukan oleh resipi nod tunggal menelan kos lebih tinggi sejam berbanding H100, dan kapasiti yang ditempah (reserved capacity) adalah lebih murah. Ambil angka sebenar daripada penyedia anda dan lakukan semula pendaraban: bilangan GPU didarab dengan jam didarab dengan kadar. Tujuan carta ini adalah untuk menunjukkan nisbah. Melakukan bursting pada nod 8 GPU selama empat jam sehari menelan kos 2,400 USD sebulan, manakala membiarkan konfigurasi 32 GPU H100 bersaiz SGLang berjalan menelan kos 57,600 USD.

Kedua-dua pelayan arus perdana menerbitkan arahan 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 arahan asas tersebut yang anda jalankan pada kluster sebenar. Tambahkan flag selari (parallelism flags) yang sepadan dengan perkakasan anda: SGLang menggunakan --tp-size untuk tensor parallel, --pp-size untuk pipeline parallel dan --ep-size untuk expert parallel. Hasil darab tensor parallel dan pipeline parallel mestilah sama dengan bilangan GPU yang anda miliki, dan expert parallel memecahkan pakar dalam kumpulan tersebut, itulah sebabnya resipi 32 GPU H100 menetapkan kedua-dua --tp-size 32 dan --ep-size 32.

Pastikan pelayan telah naik sebelum anda menghantar trafik sebenar:

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

Pelayan yang sihat akan menjawab dengan objek JSON yang menyenaraikan id model. Connection refused bermaksud proses tersebut masih memuatkan pemberat (weights) atau telah pun keluar, jadi baca log pelayan sebelum anda mencuba semula.

Kegagalan biasa pada minggu-minggu awal ialah runtime yang lebih lama daripada model. K3 dibekalkan dengan KDA dan lapisan MoE baharu yang tidak disertakan dalam keluaran stabil vLLM dan SGLang semasa pelancaran, dan simptomnya ialah pelayan keluar semasa permulaan dengan baris berbentuk Model architectures [...] are not supported for now. Tiada perubahan konfigurasi yang dapat membetulkannya, kerana kod untuk menjalankan lapisan tersebut tiada dalam binaan anda. Perkara itu telah berubah: sejak 11 Oktober 2026, SGLang telah menyertakan sokongan K3 dalam keluarannya sejak v0.5.17, dengan v0.5.21 sebagai versi terkini, dan nota keluaran vLLM v0.29.0 hingga v0.31.0 semuanya merangkumi kerja K3. Pasang keluaran semasa. Sesetengah laluan khusus perkakasan masih menamakan imej khusus, contohnya binaan NVFP4 SGLang pada Blackwell, jadi semak resipi untuk kad anda.

Satu nota kos yang sering memerangkap pengguna. Meter bermula apabila instans bermula, bukan apabila model sedia. Muat turun 1.56 TB pada kelajuan 1 GB/s mengambil masa kira-kira 26 minit masa kluster sebelum token pertama. Letakkan pemberat pada volum yang kekal selepas instans ditamatkan, supaya larian kedua bermula dalam beberapa minit sahaja.

Tahap 2: menjalankan model yang lebih kecil pada satu pemecut

Anda tidak menjalankan K3 pada tahap ini. Nyatakan perkara ini dengan jelas sebelum bermula, kerana kebanyakan perbincangan mengenai "menjalankan K3 secara setempat" berakhir di sini tanpa mengakui hakikat tersebut.

Peraturan kesesuaian menggunakan formula yang sama dalam skala kecil: parameter didarab dengan bait bagi setiap pemberat, ditambah dengan KV cache, serta kira-kira 2 GB overhead masa jalan, mestilah berada di bawah kapasiti VRAM anda. Pada 4-bit, ini adalah kira-kira setengah bait bagi setiap parameter, yang memberikan gandingan 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 gandingan di atas mengandaikan satu permintaan pada satu masa. Sebaik sahaja orang kedua menghantar prompt, setiap slot serentak memerlukan KV cache sendiri. Inilah pertukaran yang dilakukan oleh tetapan NUM_PARALLEL dan MAX_QUEUE Ollama untuk anda antara slot selari, permintaan dalam baris gilir dan baki VRAM yang anda miliki.

Terdapat satu cara untuk menjalankan K3 itu sendiri pada satu mesin besar, dan ia terletak di antara tahap ini dengan tahap sebelumnya. Unsloth mendokumentasikan binaan GGUF 1-bit dan 2-bit bagi K3 dalam llama.cpp dan menamakan NVIDIA DGX Station sebagai perkakasan yang mampu menjalankannya. Peraturan praktikalnya ialah RAM ditambah VRAM mestilah lebih kurang sama dengan saiz kuantisasi, iaitu kira-kira 610 GB untuk binaan terkecil. Jika kurang daripada itu, model akan beralih ke cakera dan kelajuannya akan merosot dengan mendadak. Itu adalah K3 yang dikuantisasi secara berat, pada kos ketepatan yang diukur di atas, bukannya model yang lebih kecil.

Ollama ialah laluan terpantas untuk mendapatkan pelayan yang berfungsi pada VPS dengan GPU terpasang:

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

ollama run memuat turun model pada penggunaan pertama, kemudian membawa anda ke prompt. Tag yang tidak wujud akan memaparkan Error: model "..." not found, jadi salin tag daripada halaman pustaka dan bukannya menaipnya berdasarkan ingatan. Panduan lengkap, termasuk unit systemd dan akses jauh, terdapat dalam menjalankan Ollama pada VPS.

llama.cpp memberikan anda lebih kawalan ke 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 lapisan dimuatkan pada GPU. Baca log muatan: ia mencetak berapa banyak lapisan yang telah di-offload. Lapisan yang melimpah ke dalam RAM sistem akan berjalan pada lebar jalur RAM dan bukannya lebar jalur HBM, jadi kelajuan penjanaan akan merosot sebanyak satu magnitud sebaik sahaja model tidak lagi muat sepenuhnya. Pertukaran antara kedua-dua alat ini dibincangkan dalam perbandingan Ollama dan llama.cpp.

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.

Tingkatan tindanan penyajian (serving stack)

Pelayan kelas vLLM dan SGLang tergolong dalam tingkatan 1. Ia wujud untuk menyajikan banyak permintaan serentak, dengan ciri continuous batching dan paged KV cache, serta tensor dan expert parallelism yang tersebar merentasi beberapa nod. Ia mengandaikan penggunaan pemecut pusat data dan sambungan pantas antara nod tersebut. Pada satu kad pengguna (consumer card), ia lebih berat untuk dipasang dan tidak memberikan kelebihan yang ketara.

llama.cpp dan Ollama tergolong dalam tingkatan 2. Ia disasarkan untuk satu mesin, kuantisasi GGUF, offload CPU apabila model tidak muat, dan konkurensi rendah. llama.cpp akan memuatkan MoE yang besar dengan menyimpan pemberat pakar (expert weights) dalam RAM sistem (--cpu-moe atau --n-cpu-moe) dan, dengan --moe-cache-mib, menyimpan pakar yang digunakan dalam GPU; begitulah cara binaan K3 terkuantisasi Unsloth berjalan pada satu mesin. Kelajuan kemudiannya bergantung pada lebar jalur RAM dan kekerapan router terlepas cache, dan jika fail lebih besar daripada jumlah RAM dan VRAM, ia akan beralih ke cakera. Ini adalah persediaan yang boleh digunakan untuk seorang pengguna. Ia bukanlah servis yang boleh menampung ramai pengguna. Perbandingan penuh ada dalam Ollama berbanding vLLM, dan ia tidak berubah mengikut model: persoalannya sentiasa sama ada anda menyajikan ramai pengguna pada perkakasan kongsi atau seorang pengguna pada perkakasan sendiri.

Empat angka yang mengatasi titik semakan ini

1. Jumlah parameter didarab dengan bait bagi setiap pemberat memberikan lantai memori. Tiada apa-apa yang berjalan di bawahnya pada ketepatan yang dikeluarkan, dan melakukan kuantisasi di bawah keluaran 4-bit memberikan anda sehingga kira-kira 60 peratus pada kos ketepatan yang diukur, bukan satu magnitud.
2. Parameter aktif memberikan kelas pemprosesan. MoE 2.8T dengan 104B aktif mengira seperti model 104B.
3. KV cache bagi setiap token, didarab dengan panjang konteks, didarab dengan konkurensi, ialah kos yang terus meningkat selepas anda membayar untuk pemberat tersebut.
4. Token sesaat bagi setiap dolar ialah satu-satunya angka yang menentukan tahap. Semua perkara di atas adalah input kepadanya.

Gunakan empat perkara tersebut pada mana-mana keluaran dan anda akan mendapat jawapan yang betul sebelum anda membuka panduan vendor. Kemudian, letakkan tarikh pada setiap angka yang anda tulis. Harga dan senarai seni bina yang disokong kedua-duanya berubah dalam tempoh dua minggu selepas K3 dilancarkan. Angka pelancaran pada halaman ini diterbitkan pada Julai 2026, dan resipi penyajian, keluaran masa jalanan serta angka kuantisasi telah disemak semula pada 11 Oktober 2026.

FAQ

Bolehkah saya menjalankan Kimi K3 pada satu GPU?

Tidak. Berat model adalah sekitar 1.4 TB pada ketepatan MXFP4 yang dibekalkan oleh Moonshot, dan kuantisasi terkecil K3 yang diterbitkan, iaitu binaan 1-bit 594 GB daripada Unsloth, adalah kira-kira dua kali ganda daripada 288 GB yang terdapat pada pemecut (accelerator) paling berkuasa yang tersedia secara meluas. llama.cpp boleh menyimpan pakar (experts) dalam RAM sistem dan menyimpan pakar yang aktif dalam cache GPU, tetapi ini masih memerlukan saiz kuantisasi dalam RAM ditambah VRAM. Jika kurang daripada itu, model akan menggunakan cakera dan berjalan dengan jauh lebih perlahan. Resipi penyajian (serving) terkecil yang diterbitkan menggunakan satu nod 8-GPU kad B300 atau MI350X/MI355X, manakala resipi H100 menggunakan 32 kad.

Berapakah VRAM yang diperlukan oleh Kimi K3?

Mulakan dengan 1.4 TB untuk berat model sahaja, iaitu 18 kad H100 80GB atau 5 kad kelas GB300. Kemudian, tambahkan memori untuk KV cache dan pengaktifan (activation memory). Pada Ogos 2026, Moonshot mengesyorkan 64 atau lebih pemecut. Setakat 11 Oktober 2026, buku panduan SGLang menerbitkan resipi nod tunggal pada 8 kad B300 atau 8 kad MI350X/MI355X, dengan jumlah 2,304 GB, dan konfigurasi 32 GPU H100 dengan jumlah 2,560 GB. Oleh itu, anggap angka berat tersebut sebagai nilai minimum dan bukannya keperluan mutlak.

Adakah kuantisasi membolehkan Kimi K3 dimuatkan pada satu nod?

Checkpoint 4-bit yang dibekalkan sudah boleh dimuatkan pada satu nod jika nod tersebut mempunyai lapan kad 288 GB, iaitu apa yang digunakan oleh resipi B300 dan MI355X daripada SGLang. Mengurangkan kuantisasi membantu mesin yang lebih kecil: binaan GGUF dinamik Unsloth berjulat daripada 861.3 GB pada 2-bit hingga 594 GB pada 1-bit, berbanding kira-kira 1.56 TB tanpa kehilangan data (lossless). Kos ketepatan telah diukur: persetujuan top-1 dengan model penuh jatuh kepada 90.390 peratus pada UD-Q2_K_XL dan 78.875 peratus pada UD-IQ1_S. Tiada satu pun daripada binaan ini yang boleh dimuatkan pada satu kad sahaja.

Adakah menyewa GPU lebih murah daripada API Kimi K3?

Hanya pada volum yang tinggi dan stabil. Dengan andaian kos 2.50 USD sejam bagi setiap GPU, satu nod 8 GPU yang sentiasa aktif menelan kos 14,400 USD sebulan. Jumlah wang yang sama boleh membeli kira-kira 960 juta token output pada kadar yang diterbitkan iaitu 15.00 USD bagi setiap juta token. Anda juga perlu membayar untuk jam melahu, muat turun berat model, dan kos tenaga kerja untuk menyelenggara kluster tersebut. Sewa mengikut jam untuk penggunaan secara lonjakan (bursts), dan bandingkan dengan volum token sebenar anda dan bukannya anggaran.

Apakah maksud 104B parameter aktif terhadap kelajuan?

Ini bermakna aritmetik bagi setiap token adalah setara dengan model 104B, jadi throughput berada dalam kelas tersebut dan bukannya kelas 2.8T. Ini tidak menyatakan apa-apa tentang memori: kesemua 2.8T parameter kekal residen, kerana penghala (router) boleh memanggil mana-mana pakar untuk mana-mana token. Gunakan kiraan aktif untuk meramal token sesaat, dan gunakan jumlah kiraan parameter untuk menentukan saiz VRAM.