Panduan Konteks Panjang Kimi K3: Memuat Seluruh Buku dan Repository dalam 1 Juta Token
Panduan Konteks Panjang Kimi K3: Memuat Seluruh Buku dan Repository dalam 1 Juta Token
Konteks panjang adalah kemampuan khas lini produk Kimi, dan kimi-k3 mendorong jendela ke 1,000,000 token yang dibagi antara input dan output. Untuk merasakan skalanya: satu request dapat memuat satu buku teknis lengkap, semua file inti sebuah repository kecil, atau catatan rapat setahun penuh. Tapi "muat" dan "bekerja dengan baik" adalah dua hal berbeda β semakin besar jendela, semakin tertib Anda harus mengelola kualitas input dan biaya.
Versi 30 detik
Konteks kimi-k3 = 1,000,000 token, dibagi antara input dan output. Konversi kasar: bahasa Inggris ~750,000 kata; bahasa Tionghoa ~550,000β700,000 karakter (verifikasi dengan tokenizer). Buku utuh, repository, dan riwayat percakapan panjang muat dalam satu request. Memberi lebih banyak tidak berarti menjawab lebih baik β saring sebelum menuang.
Apa yang benar-benar dimuat 1 juta token
| Jenis konten | Konversi kasar | 1M token memuat |
|---|---|---|
| Teks Inggris | 1 token β 0.75 kata | ~750,000 kata |
| Teks Tionghoa | 1.4β1.8 token/karakter | 550,000β700,000 karakter |
| Kode | Bergantung bahasa dan kepadatan simbol | Puluhan ribu baris |
| Dokumen campuran | Gambar dikonversi per resolusi | Ratusan halaman |
Rujukan: buku teknis 500 halaman berjalan 250,000β400,000 kata Inggris; kode inti proyek web menengah biasanya puluhan ribu baris; catatan rapat setahun jarang melebihi 300,000 karakter. Semuanya berada di dalam jendela 1 juta token β itulah makna praktis "konteks sekelas buku".
Jenis pekerjaan yang layak memakai jendela penuh
Pemahaman menyeluruh dengan dependensi antar-bagian. Kontrak, prospektus, laporan riset panjang β kesimpulan tersebar antar-bab, klausul saling merujuk. Chunking kehilangan referensi silang; satu pembacaan penuh membangun gambaran utuh.
Tanya-jawab level repository. Masukkan semua file inti proyek kecilβmenengah ke konteks dan model menjawab pertanyaan lintas-file seperti "siapa yang memanggil fungsi ini" atau "module mana yang rusak bila interface ini berubah" tanpa pipeline retrieval. Untuk repo lebih besar dari jendela, lakukan satu putaran pemilihan file β simpan modul inti, entry point, dan definisi tipe β lalu masukkan hasilnya secara utuh.
Konteks percakapan atau pipeline yang menumpuk. Dalam proyek jangka panjang, keputusan dan kesimpulan sebelumnya perlu tetap hadir. Jendela 1 juta token menampung rantai keputusan berbulan-bulan, menghilangkan kebutuhan mesin ringkasan yang sering.
Jendela besar tidak menggantikan retrieval
RAG dan konteks panjang menyelesaikan masalah berbeda: RAG menemukan fragmen relevan di korpus raksasa; konteks panjang memahami mendalam sekumpulan materi yang sudah diketahui. Dengan basis pengetahuan seratus ribu dokumen Anda tetap mencari dulu, lalu memberikan teks lengkap yang cocok. Keduanya saling melengkapi, bukan alternatif.
Pola dua tahap: cari posisi, lalu baca mendalam
Menuangkan semuanya ke jendela mahal dan berisik. Pola produksi yang lebih murah punya dua tahap:
Tahap satu: persempit. Gunakan model kecil atau pencarian kata kunci untuk memilih bagian relevan dari korpus. Tujuannya bukan menjawab pertanyaan β melainkan menyusutkan materi dari "semua" ke "relevan".
Tahap dua: baca mendalam. Berikan materi terpilih secara utuh ke kimi-k3 agar bekerja dengan konteks penuh untuk analisis, penalaran, dan generasi.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["EXAIV_API_KEY"],
base_url="https://exaiv.com/api/ai/v1",
)
# Stage two: hand the filtered full text to kimi-k3
resp = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "system", "content": "You are a contract review assistant. Answer only from the given text."},
{"role": "user", "content": "Below is the full agreement. List every clause unfavorable to party B:\n\n" + contract_text},
],
)
print(resp.choices[0].message.content)
Keuntungan pola ini adalah presisi: tahap baca mendalam tidak memuat materi tidak relevan, sehingga atensi model tidak terencer β jawaban lebih mantap dibanding pendekatan tuang-semuanya.
Pengendalian biaya
Struktur biaya konteks panjang jelas: input token mendominasi. Empat tuas menjaga tagihan tetap rendah:
Beri sesuai kebutuhan. Menanyakan fungsi tertentu tidak butuh seluruh repository β kirim file terkait. Konteks panjang adalah plafon kemampuan, bukan pengaturan default.
Pakai ulang prefix stabil. Letakkan system prompt dan bagian tetap dokumen di depan messages tanpa perubahan, agar prefix caching mengenai. kimi-k3 mendukung prefix caching otomatis; request berulang atas dokumen panjang yang sama jauh lebih murah saat hit.
Pangkas derau. Log, tag HTML, gambar base64 padat-token dan tipis-informasi β bersihkan sebelum memberi. Jika 30% dari 1 juta token adalah derau log, Anda membakar 30% anggaran tanpa hasil.
Batasi panjang output. Output memakai jendela yang sama. Tetapkan plafon max_tokens yang masuk akal agar model yang melenceng tidak menulis esai yang Anda bayar.
Output panjang juga menghabiskan capacity input
Jendela dibagi antara input dan output. Jika output mungkin panjang β terjemahan penuh misalnya β sisihkan capacity dan pendekkan input sesuai. Rencanakan dengan input plus output yang diharapkan, tidak pernah input saja.
Jebakan yang sering terjadi
Hilang di tengah. Dalam konteks sangat panjang, informasi di tengah jendela kadang dimanfaatkan lebih lemah daripada yang di awal dan akhir. Kurangi dengan menaruh instruksi terpenting di system prompt dan di akhir pesan pengguna, serta materi kritis di dekat tepi.
Menyimpan seluruh riwayat percakapan. Pesan yang menumpuk akan memakan jendela. Ringkas secara berkala β pertahankan kesimpulan dan keputusan, pensiunkan detail proses.
Menganggap konteks sebagai memori. Model tidak punya memori lintas request β setiap request mulai baru. Untuk memori persisten, lampirkan materi latar yang diperlukan setiap kali, atau kelola file ringkasan yang Anda suntikkan per request.
Mengabaikan perbedaan tokenizer. Teks campuran Tionghoa-Inggris, kode, dan simbol khusus bervariasi lebar dalam kepadatan token; memperkirakan dari jumlah karakter tidak andal. Ukur sekali dengan data nyata sebelum menetapkan anggaran.
Demonstrasi tanya-jawab repository
Tanya-jawab level repository memperlihatkan pola ini berjalan dari ujung ke ujung. Pilih file inti terlebih dahulu, lalu bertanya dengan konteks penuh:
core_files = ["src/app.ts", "src/routes.ts", "src/services/payment.ts"]
repo_text = "\n\n".join(
f"// ===== {p} =====\n{open(p).read()}" for p in core_files
)
resp = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "system", "content": "You answer questions about this repository. Cite file names."},
{"role": "user", "content": f"{repo_text}\n\nQuestion: where is the refund policy enforced, and what breaks if we change it?"},
],
)
Dua kebiasaan membuat cara ini andal. Pertama, jaga inventaris file tetap stabil antar-pertanyaan agar prefix cache mengenai β pertanyaan kedua hanya berbiaya sebagian kecil dibanding pertanyaan pertama. Kedua, minta model mengutip nama file dalam jawaban; kutipan mempercepat peninjauan dan langsung mengungkap halusinasi.
Memantau penggunaan token
Beban kerja konteks panjang layak mendapat pemantauan eksplisit. Setiap respons membawa objek usage:
print(resp.usage.prompt_tokens) # biaya bagian input
print(resp.usage.completion_tokens) # biaya bagian output
print(resp.usage.total_tokens)
Catat ini per request dan agregasikan per beban kerja. Tiga sinyal penting: rasio prompt-terhadap-completion (menunjukkan apakah pemangkasan input adalah tuas yang tepat), token per pertanyaan (menunjukkan apakah tahap seleksi Anda terlalu murah hati), dan perilaku cache-hit antar pertanyaan berulang (menunjukkan apakah prefix Anda benar-benar stabil). Panduan pemantauan lengkap ada di panduan pelacakan token.
Menyusun percakapan panjang untuk jendela yang tahan lama
Untuk asisten multi-putaran yang harus bertahan berbulan-bulan, tiga kebiasaan menjaga jendela tetap terpakai dengan baik:
Ringkas per bab, bukan per giliran. Alih-alih meringkas setiap pesan, ringkas menurut unit pekerjaan β satu fitur yang diselesaikan, satu insiden yang diselesaikan. Ringkasan tersebut mempertahankan konteks yang model perlukan sambil membuang detail tingkat token.
Pisahkan arsip dari konteks aktif. Simpan riwayat lengkap di sisi aplikasi Anda sendiri; masukkan hanya ringkasan plus beberapa giliran terkini ke dalam permintaan. Jika model perlu detail lama, request khusus untuk mengambilnya dari arsip dengan kimi-k3 berbiaya beberapa detik sekali pakai β jauh lebih murah daripada mengalirkan semuanya sepanjang waktu.
Gunakan tanda batas yang eksplisit. Saat menggabungkan ringkasan dengan percakapan terkini, tandai bagian tersebut secara jelas (RINGKASAN SEBELUMNYA, PERCAKAPAN TERKINI) sehingga model mengetahui bobot relatifnya dan tidak mengobati ringkasan sebagai fakta baru.
messages = [
{"role": "system", "content": system_prompt},
{"role": "user", "content": f"PREVIOUS SUMMARY:\n{summary}\n\nRECENT TURNS:\n{recent}"},
]
Dengan tiga kebiasaan ini, jendela 1 juta token melayani proyek yang berjalan berbulan-bulan tanpa pernah memulai dari nol β dan tanpa biaya arsip yang terus membengkak.
Membandingkan kapasitas jendela antar model
Kimi-k3 tidak sendirian dalam lini 1 juta token; beberapa keluarga model lain di EXAIV juga menawarkan jendela besar. Perbedaannya terletak pada apa yang mengapitnya:
- kimi-k3 memasangkan 1 juta token dengan multimodal native β dokumen panjang dan tangkapan layar berbagi konteks yang sama
- DeepSeek V4.1 Flash menawarkan ~1 juta token di tingkat hemat biaya β cocok untuk volume tinggi yang peka biaya
- Model GPT memuat jendela besar pada sisi tertutup β kuat namun tanpa opsi self-hosting
Jika alur kerja Anda menggabungkan analisis dokumen panjang dengan gambar atau video, kombinasi konteks-panjang-multimodal dari kimi-k3 adalah satu-satunya yang mencakup keduanya dalam satu request. Untuk pemrosesan teks murni bervolume tinggi, tingkat hemat DeepSeek sering kali menjadi pilihan yang lebih murah. Spesifikasi live ada di halaman model.
Tiga kebiasaan kecil menutup panduan ini: ukur dahulu dengan tokenizer sebelum menetapkan anggaran, guna nama fail dalam jawaban model agar senang disemak, dan tetapkan satu hari dalam bulan untuk meninjau token per fitur. Konteks panjang bukan sekadar fitur β ia mengubah cara anda mendesain pipeline dokumen sepenuhnya, dan tim yang menguasai pola dua tahap di atas akan membangun produk yang mustahil dibangun di jendela kecil.
FAQ
Seberapa besar jendela konteks kimi-k3
Bisakah memuat seluruh buku
Masih perlu RAG dengan konteks panjang
Bagaimana mengendalikan biaya konteks panjang
Apakah model mengabaikan informasi di tengah jendela
Apakah riwayat percakapan meluapkan jendela
Artikel ini menjawab apa
- apa yang benar-benar dimuat 1 juta token konteks
- menganalisis dokumen panjang
- mengendalikan biaya konteks panjang
Peta skenario cepat
| Jika Anda perlu | Buka bagian |
|---|---|
| analisis dokumen panjang | Pola dua tahap |
| Q&A tingkat repository | Q&A tingkat repository |
| menekan tagihan | Pengendalian biaya |
Pandang ke depan
Katalog dan bobot terus berubah; konvensi integrasi dan pemanggilan di sini mengikuti dokumen resmi saat publikasi.
Sumber dan verifikasi
Fakta kunci dalam artikel ini berasal dari model card resmi Kimi K3 (spesifikasi konteks) dan pengukuran tokenizer platform dan diverifikasi pada 2026-11-09. ID model, harga, dan ketersediaan mengikuti katalog langsung platform β sengaja tidak menulis angka tetap yang cepat usang. Contoh kode mengikuti kontrak API saat publikasi; periksa dokumen resmi sebelum menghubungkan ke produksi.
Ruang lingkup dan audiens
Audiens: developer yang menangani dokumen panjang atau repository besar. Cakupan: pola penggunaan konteks panjang, pengendalian biaya, dan batas-batasnya. Tidak mencakup: desain arsitektur RAG atau pemilihan vector store.
Catatan editorial dan koreksi
Ditulis oleh tim konten EXAIV dari fakta yang dapat diverifikasi, dengan sumber dan kode diperiksa sebelum publikasi. Jika ada yang usang atau keliru, halaman rilis resmi dan katalog langsung yang berlaku β beri tahu lewat kanal masukan halaman agar kami memperbaikinya.
Bacaan terkait
- Panduan koneksi Kimi K3
- Panduan RAG Knowledge Base
- Qwen KV Cache dan konteks panjang
- Pelacakan token dan biaya
- Panduan structured output