Apa itu prompt caching? Bagaimana prompt yang berulang digunakan kembali

Prompt caching berarti API mengingat awal permintaan Anda dan menggunakannya kembali saat Anda mengirim awal yang sama di lain waktu. Anda tetap mengirim teks lengkap setiap panggilan, tetapi penyedia dapat melewati proses membaca ulang bagian yang berulang, dan sebagian penyedia menagih bagian itu dengan tarif lebih rendah. Ini hanya bekerja pada awal permintaan, dan hanya jika awal tersebut identik.

Bot dukungan yang terus membaca ulang halaman yang sama#

Misalkan Anda menjalankan bot dukungan dengan 2.000 tiket sehari. Setiap permintaan dimulai dengan 3.000 token yang sama: gaya bahasa, aturan pengembalian dana, kebijakan pengiriman. Setelah itu datang pesan pelanggan satu baris, seperti "Di mana pesanan saya?" (Jika token masih samar, mulailah dengan apa itu token.)

Tanpa caching, penyedia membaca lagi semua 3.000 token aturan untuk tiket nomor 1, tiket nomor 2, dan tiket nomor 2.000. Halaman yang sama, dibaca 2.000 kali. Dengan caching, permintaan pertama membayar harga penuh untuk membacanya, dan permintaan berikutnya yang dimulai dengan teks yang sama dapat menggunakan kembali hasil kerjanya.

Panduan API DeepSeek (diperiksa 24 Oktober 2026) menjelaskan persis hal ini: context caching aktif secara default, tidak perlu perubahan kode, dan permintaan berikutnya dengan awalan yang tumpang tindih dihitung sebagai "cache hit". Hanya input yang di-cache. Jawaban dihasilkan baru setiap kali.

Apa yang dianggap "sama": aturan awalan#

Cache mencocokkan dari karakter pertama dan seterusnya. Begitu permintaan Anda berbeda dari yang di-cache, semua setelah titik itu dianggap baru. Itulah sebabnya urutan permintaan Anda lebih penting daripada panjangnya.

Inilah kesalahan yang diam-diam mematikan caching. Seorang developer ingin bot mengetahui waktu dan meletakkannya di paling atas:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

Waktu berubah setiap detik, jadi baris pertama berbeda pada setiap permintaan, dan tidak ada yang setelahnya dapat cocok. Solusinya adalah memindahkan apa pun yang berubah ke bagian akhir:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Sekarang 3.000 token aturan berada di depan dan tetap identik. Logika yang sama berlaku untuk dua kasus umum lainnya: percakapan panjang mengirim ulang seluruh riwayatnya pada setiap giliran, sehingga pesan lama menjadi awal berulang yang siap pakai (lebih lanjut di mengapa percakapan panjang lebih mahal), dan agen mengulang definisi alat serta instruksinya pada setiap langkah.

Caching juga bersifat best-effort. DeepSeek menyatakan cache membutuhkan beberapa detik untuk dibangun, sebuah hit memerlukan kecocokan penuh dengan unit awalan cache yang ada, tidak ada jaminan tingkat hit, dan cache yang tidak terpakai dihapus, biasanya dalam hitungan jam hingga hari. Jadi permintaan kedua yang dikirim setengah detik setelah yang pertama mungkin belum hit, dan hit tersebut mungkin mencakup kurang dari seluruh awalan Anda.

Cara melihatnya: field cache di usage#

Anda tidak perlu menebak apakah berhasil. Setiap penyedia melaporkannya di bagian usage respons, dengan nama field masing-masing.

DeepSeek menggunakan dua field:

• prompt_cache_hit_tokens — token input yang ditemukan di cache
• prompt_cache_miss_tokens — token input yang tidak ditemukan

Misalkan tiket dukungan pertama Anda kembali dengan prompt_cache_hit_tokens: 0 dan prompt_cache_miss_tokens: 3200, dan tiket satu menit kemudian menunjukkan prompt_cache_hit_tokens: 3000 dan prompt_cache_miss_tokens: 200. 3.000 token aturan digunakan kembali; hanya pesan pelanggan baru dan beberapa token yang dibaca dari awal. Jika angka hit tetap nol pada setiap panggilan, periksa awal permintaan Anda: ada sesuatu di sana yang berubah.

Anthropic bekerja berbeda, karena Anda menandai apa yang di-cache. Anda menambahkan cache_control dengan tipe ephemeral ke permintaan atau ke blok konten:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Menurut dokumentasi prompt caching Anthropic (diperiksa 24 Oktober 2026), jawaban melaporkan tiga angka: cache_creation_input_tokens (ditulis ke cache sekarang), cache_read_input_tokens (dibaca dari cache), dan input_tokens (apa yang datang setelah breakpoint cache terakhir). Misalkan panggilan pertama menunjukkan cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; yang kedua menunjukkan 0 dan 10000. Itu adalah penulisan cache diikuti pembacaan cache.

Ada satu jebakan di layar. Prompt yang lebih pendek dari minimum model (512, 1.024, atau 4.096 token, tergantung model) diproses tanpa caching dan tanpa error. Anda akan melihat nol di kedua field cache dan tanpa peringatan. Masa hidup default adalah 5 menit, diperbarui gratis pada setiap penggunaan; ttl opsional sebesar 1h membuatnya bertahan lebih lama.

Apa dampaknya pada tagihan Anda#

Caching mengubah harga bagian yang berulang, jadi ada baiknya menghitungnya sekali. Anthropic mencantumkan pengali pada harga input dasar: penulisan cache dengan masa hidup 5 menit berbiaya 1,25×, pembacaan berbiaya 0,1× (0,05× untuk Opus 5.5 dan Sonnet 5.5). Ambil awalan 10.000 token yang digunakan kembali dalam 20 permintaan di dalam jendela 5 menit, menggunakan pembacaan standar 0,1×:

10.000 × 20 = 200.000 token dengan harga dasar tanpa caching

10.000 × 1,25 = 12.500 untuk permintaan pertama yang menulis cache

19 × 10.000 × 0,1 = 19.000 untuk 19 permintaan yang membacanya

12.500 + 19.000 = 31.500 setara token dengan caching

Jadi bagian yang berulang berbiaya jauh di bawah seperlima dari jumlah tanpa cache. Jebakannya: jika 5 menit berlalu antar permintaan, permintaan berikutnya menulis cache lagi dengan 1,25×, dan awalan yang jarang digunakan bisa jadi lebih mahal daripada tanpa caching sama sekali.

Sekarang bot dari awal, sebagai baseline harga penuh biasa. 2.000 permintaan sehari, 3.000 token input dan sekitar 300 token output masing-masing:

2.000 × 3.000 = 6.000.000 token input sehari

2.000 × 300 = 600.000 token output sehari

Tabel ini memberi harga beban kerja hari itu pada setiap model CheapTokens yang tersedia di samping OpenRouter:

DeepSeek-V4-Flash lebih murah daripada OpenRouter secara total, dengan input dan output dihitung bersama, dan beban kerjanya mudah masuk: konteks 380K dan hingga 32.768 token output per jawaban. Ini adalah biaya harga penuh dari beban kerja: token input × harga per token. Awalan panjang yang stabil adalah tempat porsi input itu paling besar.

Coba sendiri dalam lima menit#

Rencananya: kirim system prompt panjang yang sama dua kali dengan pertanyaan berbeda dan lihat usage. Letakkan teks aturan Anda sendiri di support_rules.txt (satu atau dua halaman teks sudah cukup). Endpoint-nya adalah CheapTokens API yang kompatibel dengan OpenAI, dan Anda dapat mengambil kunci dari akun Anda.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Yang perlu diperiksa pada hasil cetak: prompt_tokens memberi tahu Anda seberapa besar permintaan Anda. Kedua permintaan membawa teks SYSTEM yang sama, jadi sebagian besar angka itu berulang dari satu permintaan ke permintaan berikutnya — kira-kira seukuran file aturan Anda. Awal yang berulang itulah bagian yang dapat digunakan kembali oleh penyedia dengan caching, seperti DeepSeek API atau Anthropic di atas. Sekarang latihan tentang urutan: tambahkan baris dengan waktu saat ini (datetime.now()) di bagian atas SYSTEM dan jalankan lagi. Kedua permintaan tidak lagi berbagi awal, karena keduanya berbeda sejak baris pertama. Letakkan baris yang sama di akhir prompt dan awal yang sama kembali.

Daftar periksa singkat untuk prompt Anda sendiri:

1. Teks stabil lebih dulu: instruksi, aturan, definisi alat, contoh.
2. Teks yang berubah terakhir: tanggal, nama pengguna, pesan terbaru.
3. Jaga awalan identik byte demi byte — bahkan spasi ekstra pun dihitung.
4. Periksa ukuran minimum penyedia sebelum bertanya-tanya mengapa tidak ada yang di-cache.
5. Lihat field usage setelah perubahan, bukan sebelumnya.

Untuk memberi harga beban kerja Anda sendiri, buka halaman harga dan masukkan ukuran input serta output Anda, atau mulai dari halaman DeepSeek. Setelah permintaan pertama berhasil, estimasi yang sama hanya butuh satu menit untuk prompt apa pun yang Anda tulis. Untuk biaya kedua sisi permintaan, lihat token input vs output.