Cache Prompt LLM: Hitung Penghematan Tanpa Menghitung Token Dua Kali
Oleh Nicho
Prompt caching bisa menekan biaya saat kamu berulang kali mengirim instruksi atau konteks yang sama ke LLM. Penghematannya tergantung pada cache hit yang benar-benar terjadi, kategori penagihan dari penyedia, dan seberapa sering materi yang di-cache dipakai ulang sebelum kedaluwarsa.
Harga baca cache yang murah hanya sebagian dari hitungan. Penulisan bisa punya harga terpisah, token output tetap berbiaya, dan total input yang dilaporkan mungkin sudah termasuk token yang di-cache. Panduan ini menjelaskan cara menyusun estimasi yang berguna dan memeriksanya terhadap catatan pemakaian. Contoh perhitungannya memakai harga yang jelas-jelas hipotetis, bukan hasil aplikasi yang terukur atau penawaran dari penyedia.
Kenali apa yang sebenarnya di-cache oleh penyedia
Prompt caching umumnya berkaitan dengan konteks input yang bisa dipakai ulang. Jangan sampai tertukar dengan aplikasi yang mengembalikan jawaban tersimpan tanpa memanggil model.
Dokumentasi context caching DeepSeek menjelaskan pencocokan unit prompt-prefix yang disimpan. Fitur ini aktif secara default, tapi berjalan dengan upaya terbaik. Permintaan yang terlihat mirip tidak menjamin cache hit, dan input yang di-cache bukan berarti jawaban sebelumnya akan langsung dikembalikan.
Untuk aplikasimu, bedakan tiga mekanisme:
- Prompt caching dari penyedia: layanan inferensi memakai ulang pemrosesan input yang memenuhi syarat dan melaporkan kategori pemakaiannya sendiri.
- Response caching di aplikasi: aplikasimu menyajikan hasil tersimpan, sehingga bisa sama sekali menghindari panggilan model.
- Caching retrieval atau dokumen: aplikasimu menghindari pengulangan kerja ekstraksi atau retrieval, tapi tetap bisa mengirim teks hasilnya ke model.
Ukur masing-masing secara terpisah. Kalau tidak, perubahan di retrieval dokumen bisa disalahartikan sebagai diskon inferensi, atau cache hit pada respons bisa dihitung sebagai cache hit dari penyedia.
Bagi input ke kategori yang tidak tumpang tindih
Mulai dari skema pemakaian endpoint yang kamu pilih, bukan rumus tebakan. DeepSeek melaporkan prompt_cache_hit_tokens dan prompt_cache_miss_tokens. API lain mungkin menampilkan field berbeda atau rincian bersarang.
Kalau sebuah respons melaporkan 10,000 total token input, termasuk 8,000 token yang di-cache, sisa input yang tidak di-cache adalah 2,000. Menagih semua 10,000 dengan tarif non-cache lalu menambahkan 8,000 dengan tarif cache berarti menghitung sebagian permintaan dua kali.
Untuk layanan dengan tarif hit dan miss terpisah, estimasi dasar token model adalah:
cost = miss_tokens / 1M × miss_rate + hit_tokens / 1M × hit_rate + output_tokens / 1M × output_rate
Pakai rumus itu hanya kalau cocok dengan definisi penyedia. Kalau layanan melaporkan pembuatan atau penyimpanan cache secara terpisah, cocokkan dulu kategori-kategori itu sebelum menjumlahkan biayanya. Harga tulis cache bisa menggantikan kategori lain atau menjadi biaya tambahan; kartu tarif yang menentukan perbedaannya.
Simpan mata uang, satuan, model ID, penyedia, dan tanggal di samping perhitunganmu. Angka yang dikutip per seribu token tidak bisa dimasukkan begitu saja ke rumus per juta token.
Sertakan penulisan pertama dan masa pakainya
Panduan penagihan inferensi Kimi membedakan penulisan cache K3 berdasarkan masa berlakunya, dengan kategori lima menit dan satu jam. Input yang kena cache dihitung dengan harga hit tanpa biaya penulisan cache tambahan. Itu aturan platform langsung, bukan bukti bahwa gateway memakai perhitungan yang sama.
Pertanyaan yang berguna: berapa kali sebuah prefix akan dipakai ulang selama entri cache-nya masih berlaku? Coba skema penagihan hipotetis untuk prefix satu juta token ini:
| Biaya | Perkiraan harga |
|---|---|
| Proses prefix tanpa cache | $1.00 per pemakaian |
| Penulisan cache pertama, menggantikan penagihan input biasa | $1.25 |
| Setiap pembacaan cache berikutnya | $0.10 |
Lima pemakaian tanpa cache biayanya $5.00. Satu penulisan lalu empat pembacaan biayanya $1.65, hemat 67% untuk prefix itu. Kalau cuma sekali pakai, jalur cache justru lebih mahal: $1.25 bukan $1.00.
Asumsi bahwa penulisan menggantikan penagihan input biasa itu penting. Kalau penyedia nyata menagih penulisan secara tambahan, rumusnya berubah. Harga ini cuma ilustrasi metode; bukan kutipan Kimi atau cheapaimodel saat ini.
Untuk skema gaya penggantian ini, bandingkan write_cost + (uses − 1) × read_cost dengan uses × ordinary_cost. Lalu ulangi perhitungannya untuk perkiraan jumlah pemakaian dalam masa berlaku yang sebenarnya. Pembacaan murah tidak berguna kalau setiap permintaan datang setelah entri kedaluwarsa.
Hitung penghematan untuk seluruh permintaan
Diskon input tidak sama dengan diskon persentase pada tagihan akhir. Misalnya beban kerja tanpa cache punya $10 biaya input dan $20 biaya output. Anggap 80% dari input itu jadi cache hit, biaya baca 10% dari tarif input biasa, dan tidak ada biaya penulisan tambahan.
Biaya input baru jadi $2 untuk miss plus $0.80 untuk hit, atau $2.80. Totalnya jadi $22.80 bukan $30: hemat 24% secara keseluruhan, meski ada diskon 90% pada tarif bagian yang kena cache.
Jawaban panjang, output reasoning, tool call, percobaan ulang, dan penyimpanan bisa mengubah totalnya lebih jauh. Pakai pemakaian yang ditagih yang dilaporkan endpoint, bukan cuma menghitung jawaban akhir yang terlihat. Untuk harga model saat ini, mulai dari perbandingan harga, lalu terapkan campuran pemakaianmu sendiri.
Rancang pengukuran yang berguna
Kumpulkan cukup informasi supaya bisa membandingkan hal yang setara:
- Model dan rute penyedia, waktu permintaan, dan konfigurasi terkait.
- Total input, cache hit, cache miss, pembuatan cache, dan output kalau dilaporkan.
- Layanan yang ditagih terpisah dan biaya yang tercatat di akun.
- Apakah hasilnya memenuhi kriteria penerimaan aplikasi.
Hitung porsi hit berbobot token: total token hit dibagi total token input yang memenuhi syarat. Merata-ratakan persentase per permintaan bisa menyesatkan kalau permintaan kecil dan permintaan besar dapat bobot yang sama.
Simpan instruksi tetap dan konteks yang bisa dipakai ulang sebelum mengubah materi khusus tugas kalau susunan itu cocok dengan aturan prefix yang didokumentasikan penyedia. Jangan susun ulang instruksi keamanan atau hapus konteks yang diperlukan hanya demi mengejar tingkat hit yang lebih tinggi. Validasi kualitas output setelah mengubah struktur prompt.
Cocokkan dulu sebelum melakukan scaling
Bandingkan sampel kecil catatan pemakaian dengan tampilan tagihan penyedia. Selidiki kategori yang hilang, pembulatan, jendela harga yang berbeda, serta biaya penulisan atau tool sebelum menganggap tagihannya salah.
cheapaimodel mempublikasikan tarif input, output, dan cache-read di halaman harga. Pastikan aturan penulisan dan aturan pengenaan biaya lain untuk model yang berlaku sebelum menganggap subtotal tiga kolom sebagai tagihan lengkap. Untuk perbedaan khusus K3, lihat panduan Kimi API.
Hasil yang berguna adalah biaya per hasil yang diterima jadi lebih rendah. Jumlah token yang di-cache lebih besar saja tidak membuktikan bahwa aplikasimu jadi lebih murah atau lebih efektif.