TL;DR
Pada 2026, Kimi K3 dapat di-host sendiri (self-hosted), namun repositori bobot publik sekitar 1.56 TB dan resep resmi vLLM dimulai dari 8 GPU NVIDIA GB300 atau 8 GPU AMD MI355X/MI350X. Moonshot merekomendasikan 64 akselerator atau lebih dalam konfigurasi supernode untuk inferensi produksi yang efisien. Bagi sebagian besar tim, API terkelola tetap menjadi titik awal dengan risiko lebih rendah.
Kimi K3 Self-Hosting vs API secara Singkat
Self-hosting Kimi K3 berarti mengunduh bobot model terbuka dari Moonshot dan menjalankannya di infrastruktur yang dikelola oleh tim Anda sendiri atau akun cloud Anda. Organisasi Anda bertanggung jawab atas kapasitas GPU, penyajian model, penskalaan, keamanan, peningkatan, pemantauan, dan keandalan.
Akses API Kimi K3 berarti mengirim permintaan ke endpoint yang dikelola penyedia tanpa mengoperasikan klaster GPU yang mendasarinya. Penyedia mengelola penyajian model dan kapasitas, sementara tim Anda membayar berdasarkan penggunaan dan terutama berfokus pada integrasi aplikasi.
Moonshot memperkenalkan Kimi K3 dalam blog teknis resmi pada 16 Juli 2026 dan merilis bobot lengkapnya pada 27 Juli. Model ini kini tersedia sebagai checkpoint bobot terbuka, namun “open weights” tidak boleh disamakan dengan “mudah dijalankan secara lokal.” Untuk gambaran kemampuan dan tolok ukur yang lebih luas, lihat panduan akses Kimi K3 dari CometAPI.
Perbedaan praktisnya bukan sekadar akses ke model. Ini tentang siapa yang memiliki infrastruktur, perencanaan kapasitas, peningkatan, dan risiko operasional.
| Faktor keputusan | Kimi K3 self-hosted | Kimi K3 API terkelola |
|---|---|---|
| Akses model | Akses penuh ke bobot dan konfigurasi penyajian yang dirilis | Akses melalui endpoint yang dikelola penyedia |
| Jejak bobot | Sekitar 1.56 TB di repositori model publik | Tidak perlu mengunduh atau menyimpan model |
| Minimum resmi | 8x NVIDIA GB300, atau 8x AMD MI355X/MI350X | Tidak perlu pengadaan GPU |
| Panduan produksi | Multi-node dengan domain komunikasi bandwidth tinggi | Penyedia mengelola kapasitas dan penskalaan |
| Struktur biaya | Infrastruktur tetap ditambah rekayasa dan operasi | Penagihan variabel berbasis penggunaan |
| Risiko utilisasi | Kapasitas menganggur tetap menimbulkan biaya | Pengeluaran umumnya mengikuti penggunaan aktual |
| Tanggung jawab upgrade | Tim Anda memvalidasi runtime, bobot, dan perubahan penyajian | Penyedia mengelola pembaruan stack penyajian |
| Kontrol jalur data | Kontrol lebih besar atas deployment, logging, dan retensi | Bergantung pada arsitektur dan ketentuan penyedia |
| Tinjauan lisensi | Kimi K3 License langsung mengatur penggunaan bobot | Ketentuan penyedia mengatur akses terkelola |
| Kecocokan terbaik | Beban kerja berkelanjutan, keahlian inferensi terdistribusi, persyaratan kontrol ketat | Evaluasi, permintaan variabel, deploy lebih cepat, staf infrastruktur terbatas |
Pertanyaan sentralnya bukan apakah self-hosting secara teknis memungkinkan. Pertanyaannya adalah apakah tim Anda dapat menjaga infrastruktur yang dibutuhkan tetap cukup sibuk—dan mengoperasikannya dengan cukup andal—untuk mengungguli akses terkelola dalam biaya total per tugas yang diterima.
Bisakah Anda Self-Host Kimi K3?
Bisa. Moonshot telah memublikasikan bobot lengkap di repositori resmi Kimi K3 di bawah Kimi K3 License khusus. Jalur deployment publik mencakup vLLM, SGLang, dan TokenSpeed.
Namun, Kimi K3 bukan model kelas workstation. Ini adalah model Mixture-of-Experts berukuran 2.8 triliun parameter dengan 104 miliar parameter teraktivasi per token, 896 expert terouting, kemampuan multimodal native, bobot MXFP4, aktivasi MXFP8, dan jendela konteks hingga 1,048,576 token.
Angka 104B parameter teraktivasi menggambarkan kapasitas model yang digunakan selama tiap langkah token. Ini bukan berarti hanya 104B parameter yang perlu disimpan. Router dapat memilih expert berbeda selama generasi, sehingga seluruh himpunan expert tetap menjadi bagian dari model yang dideploy.
Kimi K3 Self-Hosting vs API: Persyaratan Infrastruktur
Self-hosting Kimi K3 memerlukan lingkungan GPU terdistribusi besar, sementara akses API terkelola menghilangkan kebutuhan mengoperasikan klaster penyajian model. Pada 2026, baseline self-hosting resmi dimulai dari delapan GPU NVIDIA GB300 atau AMD MI355X/MI350X, sedangkan pengguna API hanya membutuhkan infrastruktur aplikasi standar.
Perbedaannya bukan sekadar siapa yang memiliki GPU. Self-hosting juga membuat tim Anda bertanggung jawab atas penyimpanan model, jaringan multi-node, perencanaan kapasitas, deployment, penskalaan, pemantauan, peningkatan, dan pemulihan kegagalan. Dengan akses API terkelola, sebagian besar tanggung jawab itu beralih ke penyedia.
Persyaratan Perangkat Keras untuk Self-Hosting
Resep vLLM resmi saat ini mencantumkan prasyarat berikut untuk menjalankan checkpoint Kimi K3 penuh:
- NVIDIA: minimal 8x GPU GB300
- AMD ROCm: minimal 8x GPU MI355X atau MI350X
- Lalu lintas produksi: disarankan deployment multi-node
- vLLM: versi 0.27.0 atau lebih baru, menggunakan image Kimi K3 dan profil deployment yang didokumentasikan
Persyaratan ini mewakili lantai penyajian yang terdokumentasi, bukan jaminan bahwa sistem delapan GPU akan memenuhi setiap beban kerja produksi.
Dokumentasi peluncuran Moonshot melangkah lebih jauh. Untuk efisiensi inferensi yang lebih tinggi, disarankan men-deploy Kimi K3 pada konfigurasi supernode dengan 64 akselerator atau lebih. Rekomendasi tersebut sangat relevan bagi tim yang menargetkan konkruensi tinggi, beban kerja konteks panjang, atau latensi yang dapat diprediksi di bawah beban.
Bottleneck bukan hanya memori GPU agregat. Kimi K3 mengaktifkan 16 dari 896 expert terouting per token, sehingga deployment expert-parallel menghasilkan komunikasi all-to-all yang substansial antar akselerator.
Resep vLLM resmi merekomendasikan backend komunikasi seperti deepep_v2 untuk lingkungan RDMA dan flashinfer_nvlink_one_sided untuk komunikasi lintas-node berbasis NVLink. Akibatnya, delapan GPU yang terhubung melalui jaringan lebih lambat tidak setara secara operasional dengan delapan GPU di dalam sistem ber-bandwidth tinggi dan terhubung erat.
Berapa Banyak Penyimpanan dan Memori Runtime yang Dibutuhkan Self-Hosting?
Checkpoint Kimi K3 publik sekitar 1.56 TB, menurut repositori resmi Hugging Face.
Perhitungan batas bawah teoretis untuk 2.8 triliun parameter yang disimpan pada empat bit per parameter adalah:
2.8 trillion parameters × 4 bits ÷ 8
= 1.4 trillion bytes
= about 1.4 TB, or 1.27 TiB
Mengapa Kimi K3 Lebih Sulit Disajikan daripada Model Standar?
Kimi K3 lebih sulit disajikan karena arsitektur MoE terdistribusinya menggabungkan lalu lintas expert all-to-all, perencanaan cache konteks panjang, riwayat penalaran spesifik model, dan validasi tool-call. Tim harus menguji kinerja interkoneksi, paralelisme, perilaku prefill dan decode, konkruensi, serta penanganan retry alih-alih memperlakukannya seperti endpoint model single-node konvensional.
Resep vLLM resmi menyoroti beberapa pertimbangan produksi:
- Lalu lintas lintas-node memerlukan backend all-to-all yang sesuai dan fabric komunikasi ber-bandwidth tinggi.
- Backend MoE berubah sesuai strategi paralelisme dan topologi perangkat keras.
- Tensor parallelism, expert parallelism, dan profil prefill/decode terdisagregasi yang didokumentasikan harus diuji terhadap beban kerja nyata.
max-model-len, konkruensi, dan pemanfaatan memori perlu penalaan eksplisit, bukan nilai default.- K3 kadang dapat memancarkan format tool-call yang tidak diharapkan oleh parser-nya sendiri; resep merekomendasikan validasi skema dan penanganan retry.
Apakah konteks 1M token bebas digunakan?
Tidak. Moonshot tidak menerapkan tingkat per-token yang lebih tinggi hanya karena sebuah permintaan menggunakan konteks yang lebih panjang, namun prompt panjang tetap mengonsumsi token input dan meningkatkan kerja prefill, permintaan KV-cache, latensi, dan tekanan konkruensi. Konfigurasikan max-model-len sesuai beban kerja yang benar-benar ingin Anda layani, bukan mengaktifkan maksimum secara default.
Kompatibilitas aplikasi juga penting. Menurut quickstart Kimi K3 API dari Moonshot, K3 selalu melakukan penalaran dan mendukung nilai reasoning_effort low, high, dan max, dengan max sebagai default. Ini dapat meningkatkan volume token yang dihasilkan, tetapi overhead bervariasi menurut tugas dan pengaturan effort. Ukur token penalaran dan output pada himpunan evaluasi Anda sendiri alih-alih mengasumsikan pengali tetap. Untuk percakapan multi-giliran dan tool call, kirim kembali pesan asisten lengkap, termasuk reasoning_content dan tool_calls, alih-alih hanya menyimpan jawaban yang terlihat.
Endpoint terkelola menghapus sebagian besar pekerjaan tingkat klaster, tetapi tidak menghapus validasi tingkat aplikasi, logika retry, pengukuran latensi, atau penanganan status multi-giliran.
Berapa Biaya Kimi K3 API?
Per Juli 2026, Moonshot mengenakan biaya $0.30 per 1M token input cache-hit, $3.00 per 1M token input cache-miss, dan $15.00 per 1M token output. Biaya efektif sangat bergantung pada pemanfaatan prefix cache dan panjang output, jadi tim harus mengukur penggunaan yang ditagih dengan permintaan berbentuk produksi alih-alih hanya membandingkan tarif input utama.
Halaman harga resmi Kimi K3 dari Moonshot mencantumkan:
| Penggunaan API | Harga resmi per 1M token |
|---|---|
| Input cache-hit | $0.30 |
| Input cache-miss | $3.00 |
| Output | $15.00 |
Rumus biaya permintaan langsung adalah:
Biaya API =
(cache-hit input tokens ÷ 1M × $0.30)
- (cache-miss input tokens ÷ 1M × $3.00)
- (output tokens ÷ 1M × $15.00)
Sebagai contoh, sebuah permintaan dengan 300,000 token input dan 30,000 token output berbiaya:
- $1.35 jika semua input ditagih sebagai input cache-miss
- $0.54 jika semua input menerima harga cache-hit
Beban kerja nyata biasanya berada di antara dua kasus tersebut. Performa cache bergantung pada seberapa konsisten aplikasi menggunakan prefix yang tidak berubah dan bagaimana penyedia mengimplementasikan caching.
Harga terkelola juga bervariasi menurut penyedia. Per Juli 2026, CometAPI mencantumkan Kimi K3 dengan $2.40 per 1M token input dan $12.00 per 1M token output—20% di bawah tarif cache-miss standar Moonshot sebesar $3.00 untuk input dan $15.00 untuk output. Namun, ini bukan penghematan 20% yang universal. Moonshot hanya mengenakan $0.30 per 1M token input cache-hit, sehingga beban kerja dengan tingkat cache-hit tinggi mungkin lebih murah melalui API resmi.
Gunakan halaman model CometAPI yang live sebagai sumber harga terkini, dan lihat panduan harga Kimi K3 API untuk contoh biaya. Bandingkan kedua rute menggunakan penggunaan yang benar-benar ditagih dari himpunan evaluasi yang sama, termasuk cache hit, token penalaran, retry, dan tingkat tugas yang diterima.
Berapa Biaya Self-Hosting Kimi K3?
Kimi K3 tidak memiliki harga self-hosting yang universal. Biaya lengkap bergantung pada ukuran klaster, ketentuan kontrak, utilisasi produktif, jaringan, penyimpanan, rekayasa, dan target keandalan. Skenario perencanaan delapan GPU saja dapat melebihi $58,000 per bulan untuk infrastruktur, sementara topologi produksi 64+ akselerator yang direkomendasikan Moonshot memerlukan model biaya terpisah yang jauh lebih besar.
Gunakan model bulanan lengkap:
Biaya bulanan self-hosted =
biaya akselerator atau klaster
- rekayasa platform
- operasi inferensi
- jaringan dan penyimpanan
- observabilitas dan keamanan
- redundansi dan ruang idle
Skenario infrastruktur delapan GPU ilustratif
Tabel berikut menggunakan 730 jam per bulan dan tiga tarif hipotetis untuk klaster ukuran minimum yang selalu tersedia. Angka-angka ini adalah input perencanaan, bukan penawaran. Angka-angka ini juga tidak mewakili rekomendasi produksi 64+ akselerator dari Moonshot.
| Tarif klaster asumsi | Biaya infrastruktur bulanan | Permintaan setara dengan pengeluaran pada $1.35 tiap permintaan | Permintaan setara dengan pengeluaran pada $0.54 tiap permintaan |
|---|---|---|---|
| $80/hour | $58,400 | 43,300 | 108,100 |
| $120/hour | $87,600 | 64,900 | 162,200 |
| $160/hour | $116,800 | 86,500 | 216,300 |
Penambahan rekayasa, pemantauan, redundansi, jaringan, dan kapasitas idle meningkatkan ambang self-hosting. Topologi produksi yang lebih besar meningkatkan ambang tersebut lebih jauh.
Utilisasi itu penting, namun tidak ada ambang universal
Tidak ada persentase utilisasi GPU universal di mana self-hosting menjadi lebih murah. Level yang dibutuhkan bergantung pada throughput terukur, biaya perangkat keras, target latensi, redundansi, dan apakah perangkat keras merupakan biaya baru atau sudah dimiliki.
Sebagai gantinya, lacak utilisasi produktif:
Utilisasi produktif =
jam-klaster yang dihabiskan untuk beban kerja yang diterima
÷ total jam-klaster yang diprovisikan
Angka utilisasi yang tinggi tidak cukup jika permintaan gagal memenuhi target latensi atau kualitas. Demikian pula, angka yang lebih rendah mungkin masih dapat diterima ketika perangkat keras sudah dikomit untuk beban kerja lain. Gunakan utilisasi sebagai input ke model TCO, bukan aturan keputusan yang berdiri sendiri.
Penyebut yang paling berguna bukan jumlah permintaan mentah. Melainkan pekerjaan ekuivalen yang diterima:
Titik impas tugas yang diterima =
total biaya bulanan self-hosted
÷ biaya API terkelola per tugas ekuivalen yang diterima
Sertakan kegagalan, retry, pelanggaran latensi, peninjauan manusia, dan output yang menurun pada kedua sisi. Dua endpoint yang menggunakan bobot yang sama tidak setara secara ekonomis jika salah satunya gagal memenuhi target keandalan atau kualitas aplikasi.
Apa yang Diizinkan oleh Kimi K3 License?
Kimi K3 License khusus memberikan hak luas untuk menggunakan, menyalin, memodifikasi, fine-tuning, men-deploy, mendistribusikan, mensublisensikan, dan menjual perangkat lunak serta bobot model. Lisensi ini juga mencakup ketentuan yang penting bagi bisnis Model-as-a-Service berskala besar dan produk komersial berskala tinggi.
| Pertanyaan lisensi | Ketentuan yang dipublikasikan |
|---|---|
| Bisakah perusahaan menggunakan dan memodifikasi bobot? | Ya, tunduk pada ketentuan lisensi dan hukum yang berlaku |
| Apa itu “Model as a Service”? | Akses pihak ketiga ke inferensi atau fine-tuning yang memberikan kontrol bermakna atas input, parameter, atau data pelatihan |
| Apa yang dikecualikan dari definisi tersebut? | Fitur produk tertanam dan sekadar meneruskan ke model yang di-host pihak lain |
| Apa yang memicu persyaratan perjanjian MaaS? | Lebih dari $20 juta pendapatan agregat selama 12 bulan berturut-turut untuk pemegang lisensi dan afiliasinya yang mengoperasikan bisnis MaaS |
| Apa yang terjadi di atas ambang tersebut? | Perjanjian terpisah dengan Moonshot diperlukan sebelum penggunaan komersial perangkat lunak atau turunannya |
| Kapan atribusi terlihat diperlukan? | Produk atau layanan komersial dengan lebih dari 100 juta MAU atau lebih dari $20 juta pendapatan bulanan harus menampilkan “Kimi K3” secara mencolok |
| Penggunaan mana yang dikecualikan dari Bagian 2 dan 3? | Penggunaan internal dan akses melalui produk resmi Moonshot atau mitra inferensi tersertifikasi |
Untuk sebagian besar deployment internal dan aplikasi komersial biasa, lisensi tidak melarang penggunaan secara default. Tim yang menjual akses model langsung, mengoperasikan API model, atau mendekati ambang yang dinyatakan sebaiknya meminta penasihat hukum meninjau desain produk dan struktur perusahaan yang tepat.
“Open-weight” adalah deskripsi yang lebih akurat daripada “sepenuhnya open source” karena penggunaan diatur oleh lisensi khusus ini, bukan hanya lisensi perangkat lunak permisif standar.
API vs Self-Hosted Kimi K3: Mana yang Harus Anda Pilih?
Bagi sebagian besar tim pada 2026, akses API terkelola adalah langkah pertama yang lebih baik karena permintaan, perilaku cache, dan biaya per tugas yang diterima masih belum pasti. Pilih self-hosting hanya ketika utilisasi berkelanjutan, persyaratan kontrol data, atau kustomisasi runtime telah diukur terhadap biaya lengkap dari deployment produksi andal yang ekuivalen.
Pilih API terkelola ketika:
- Trafik baru, variabel, atau sulit diprediksi.
- Anda membutuhkan akses produksi tanpa siklus pengadaan GPU.
- Tim Anda belum mengoperasikan inferensi MoE terdistribusi.
- Penggunaan jauh di bawah ambang titik impas yang Anda hitung.
- Scaling, pembaruan, dan kapasitas terkelola lebih bernilai daripada kontrol runtime.
- Penanganan data dan ketentuan layanan penyedia memenuhi persyaratan Anda.
Pilih self-hosting ketika:
- Permintaan cukup berkelanjutan dan dapat diprediksi untuk menjaga klaster sangat terutilisasi.
- Organisasi Anda sudah memiliki infrastruktur GPU terdistribusi dan engineer inferensi.
- Jalur data terkontrol, lingkungan khusus, atau kebijakan retensi khusus adalah persyaratan keras.
- Anda memerlukan kontrol langsung atas versi model, penjadwalan, pengaturan runtime, atau bobot yang di-fine-tune.
- Pengeluaran terkelola yang terukur mendekati biaya internal lengkap dari deployment andal yang ekuivalen.
- Tinjauan legal mengonfirmasi bahwa penggunaan yang dimaksud sesuai dengan Kimi K3 License.
Pertimbangkan deployment hibrida ketika:
- Permintaan baseline dapat diprediksi tetapi trafik memiliki lonjakan besar.
- Kapasitas self-hosted dapat melayani beban stabil sementara API menangani limpahan.
- Anda memerlukan fallback terkelola untuk pemeliharaan atau kegagalan regional.
- Prompt, skema tool, uji penerimaan, dan perilaku model tetap portabel di kedua rute.
Strategi hibrida menambah kompleksitas routing dan observabilitas, jadi sebaiknya menyelesaikan masalah kapasitas atau ketahanan yang terukur alih-alih hanya preferensi arsitektur.
Bagaimana Menguji Titik Impas API vs Self-Hosting?
Jalankan himpunan evaluasi berbentuk produksi yang sama melalui rute terkelola dan dikelola sendiri, lalu bandingkan biaya per tugas yang diterima—bukan sekadar harga token mentah atau biaya sewa GPU. Uji yang kredibel harus mengukur cache hit, token output, latensi, retry, kualitas, konkruensi, waktu rekayasa, kapasitas idle, dan pemulihan kegagalan setidaknya selama satu periode operasi yang representatif.
- Buat himpunan evaluasi yang representatif. Sertakan 30 hingga 50 tugas yang mencakup campuran permintaan coding, konteks panjang, visi, dan tool-calling yang sebenarnya.
- Ukur penggunaan terkelola selama setidaknya satu minggu. Catat token input, token cache-hit, token output, latensi, retry, error, dan tingkat tugas yang diterima.
- Uji topologi self-hosted yang diusulkan. Gunakan batas konteks, konkruensi, paralelisme, dan pengaturan keandalan yang dimaksud—bukan demonstrasi pengguna tunggal.
- Hitung biaya bulanan lengkap. Sertakan waktu klaster, rekayasa, observabilitas, redundansi, penyimpanan, jaringan, keamanan, dan ruang idle.
- Bandingkan ekonomi tugas yang diterima. Pastikan kualitas, latensi, dan keandalan setara sebelum membandingkan biaya.
- Jalankan skenario kegagalan. Uji kehilangan node, rollback deployment, pertumbuhan antrian, lonjakan konteks panjang, dan tool call yang salah format.
- Setujui self-hosting hanya ketika kasus operasionalnya terukur. Kontrol strategis dapat membenarkan biaya lebih tinggi, tetapi trade-off harus eksplisit.
Untuk baseline terkelola, CometAPI quickstart menyediakan rute kompatibel OpenAI. Pertahankan prompt, tool, dan kriteria penerimaan tidak berubah saat menguji penyedia lain atau endpoint self-hosted.
FAQ
Bisakah Kimi K3 berjalan di satu GPU?
Tidak di bawah panduan penyajian model penuh resmi. Resep vLLM dimulai dari delapan GPU NVIDIA GB300 atau delapan GPU AMD MI355X/MI350X dan merekomendasikan infrastruktur multi-node untuk trafik produksi nyata. Topologi final bergantung pada panjang konteks, konkruensi, latensi, dan target redundansi.
Berapa banyak penyimpanan yang dibutuhkan self-hosting Kimi K3?
Repositori Hugging Face publik sekitar 1.56 TB. Persyaratan memori runtime lebih tinggi karena penyajian juga membutuhkan metadata kuantisasi, aktivasi, KV cache, buffer komunikasi, dan ruang kepala untuk konkruensi.
Apakah Kimi K3 open source?
Kimi K3 paling tepat dideskripsikan sebagai bobot terbuka di bawah Kimi K3 License khusus. Bobot tersedia publik dan dapat dimodifikasi serta dideploy, tetapi operator MaaS besar dan produk komersial yang sangat besar menghadapi ketentuan tambahan.
Apakah self-hosting Kimi K3 lebih murah daripada akses API?
Bisa lebih murah pada utilisasi yang tinggi dan berkelanjutan, tetapi tidak ada titik impas universal. Bandingkan biaya bulanan lengkap dari deployment andal yang ekuivalen dengan biaya API terkelola per tugas yang diterima, termasuk perilaku cache, retry, latensi, dan kapasitas idle.
Engine inferensi mana yang mendukung Kimi K3?
Moonshot saat ini merekomendasikan vLLM, SGLang, dan TokenSpeed. Resep vLLM memberikan baseline perangkat keras publik yang paling jelas, sementara setiap engine tetap membutuhkan validasi spesifik beban kerja.
Uji Rute Terkelola Sebelum Membeli Infrastruktur
Bobot terbuka Kimi K3 menciptakan opsi self-hosting yang nyata, tetapi ukuran checkpoint dan persyaratan penyajian terdistribusi menjadikannya proyek infrastruktur alih-alih deployment model rutin.
Mulailah dengan himpunan evaluasi tetap. Ukur penggunaan token, perilaku cache, latensi, retry, dan kualitas tugas yang diterima melalui endpoint terkelola. Lalu bandingkan hasil tersebut dengan topologi self-hosted yang diuji beban menggunakan biaya bulanan lengkap—bukan hanya tagihan GPU.
CometAPI menyediakan rute yang kompatibel OpenAI untuk menetapkan baseline tersebut. Gunakan How to Use Kimi K3 API guide untuk detail implementasi, CometAPI quickstart untuk langkah migrasi, serta halaman model Kimi K3 dan halaman harga yang live untuk ketersediaan dan tarif saat ini.