Mengaktifkan caching prompt tidak menjimatkan apa-apa pun—malah, invois OpenAI-API saya melonjak sebanyak kira-kira satu perempat. Punca utamanya adalah satu baris tunggal yang berubah pada setiap permintaan: cap masa (timestamp) yang disematkan dalam prompt sistem.

Penyedia LLM membenarkan pembangun melakukan caching pada fragmen prompt untuk mengurangkan kos pemprosesan token. Pembacaan cache (sebuah “hit”) menelan kos sekecil satu persepuluh daripada kadar biasa, manakala penulisan cache (sebuah “miss”) menelan kos kira-kira 1.25 × harga biasa. Jika penulisan berlaku tetapi fragmen yang di-cache tidak pernah dibaca, caj tambahan 25% itu akan membazir. Itulah yang berlaku apabila cap masa menghalang prompt daripada sepadan dengan mana-mana entri cache yang sedia ada.

Mengapa caching boleh memakan diri

Prompt caching berfungsi dengan memadankan urutan bait yang tepat bagi bahagian yang di-cache. Penyedia akan melakukan hashing pada input; jika hash tersebut sepadan dengan entri yang disimpan, sistem akan menggunakan semula pengiraan sebelumnya dan mengenakan kadar bacaan yang murah. Sebarang variasi—walaupun hanya satu aksara—akan memecahkan padanan tersebut dan memaksa pengiraan baharu, yang akan dicaj pada kadar penulisan yang lebih tinggi.

Dalam kes saya, prompt sistem bermula dengan:

Current session started: 2026-07-14T09:41:07Z

Oleh sebab cap masa dikemas kini bagi setiap panggilan API, beberapa bait pertama permintaan tidak pernah identikal. Penyedia menganggap setiap panggilan sebagai entri cache baharu, mengenakan premium penulisan, dan tidak pernah merekodkan sebarang pembacaan. Hasilnya ialah peningkatan berterusan dalam cache_creation_input_tokens manakala cache_read_input_tokens kekal pada sifar, satu tanda jelas bahawa cache tidak pernah dipadankan (hit).

Cara mengesan cache yang rosak

Log penggunaan yang dibekalkan oleh API memberikan dua kaunter utama:

  • cache_creation_input_tokens – token yang mencetuskan penulisan.
  • cache_read_input_tokens – token yang mendapat manfaat daripada pembacaan.

Apabila nilai pertama meningkat dan nilai kedua kekal mendatar, cache tersebut tidak digunakan semula. Ujian ringkas yang boleh dilakukan adalah dengan mengulangi permintaan yang sama tepat sebanyak dua kali; panggilan kedua sepatutnya menunjukkan lonjakan dalam token bacaan jika cache berfungsi dengan baik.

Cara menyelesaikan masalah

Penyelesaiannya mudah: pastikan bahagian yang di-cache adalah statik merentasi semua panggilan. Ikuti dua peraturan ini:

  1. Letakkan kandungan tidak berubah (immutable) di hadapan. Prompt sistem, definisi alatan (tool definitions), atau sebarang arahan yang tidak pernah berubah harus menduduki bait-bait awal permintaan.
  2. Lampirkan kandungan yang boleh berubah (mutable) di akhir. Cap masa, teks janaaan pengguna, ID permintaan, atau sebarang data yang berubah bagi setiap panggilan mesti diletakkan selepas segmen yang di-cache.

Jika satu aksara pun beralih, hash akan berubah dan kegagalan cache (cache miss) akan berterusan. Menyusun semula prompt supaya cap masa berada di penghujung akan memulihkan kadar padanan cache (cache hit rate) dan menurunkan semula bil ke tahap kos rendah yang dijangkakan.

Bila caching benar-benar membantu

Prompt caching sangat berguna dalam senario di mana set arahan yang sama digunakan berulang kali:

  • Gelung ejen (Agent loops) di mana AI memanggil semula set alatan yang tetap secara berulang kali.
  • Sesi sembang (Chat sessions) yang merujuk kepada dokumen statik yang panjang sementara hanya pertanyaan terbaru pengguna yang berubah.
  • Pengekstrakan data pukal (Bulk data extraction) di mana prompt pemprosesan (parsing) yang sama digunakan pada banyak rekod.

Bagi panggilan tunggal (single-shot) yang menyertakan konteks baharu setiap kali—seperti soalan sekali guna dengan mukadimah yang unik—caching tidak memberikan sebarang manfaat dan mungkin menambah kos jika permintaan tersebut secara tidak sengaja mencetuskan penulisan.

Perangkap tersembunyi

Walaupun prompt itu sendiri adalah statik, permintaan boleh diubah di peringkat hiliran:

  • Proxy atau agregator yang menyusun semula atau menyuntik ruang kosong (whitespace) boleh memecahkan padanan bait-demi-bait.
  • Perkhidmatan gerbang (Gateway services) yang menambah pengepala pengesahan (authentication headers) di hadapan atau mengubah format JSON mungkin secara tidak sengaja mengubah fragmen yang di-cache.

Menguji melalui gerbang dengan menghantar permintaan yang serupa sebanyak dua kali dan menyemak kaunter bacaan dapat membantu mengesahkan bahawa laluan caching kekal utuh.

Gambaran kos yang lebih luas

Caj tambahan 25% untuk penulisan bukanlah penalti kerana menggunakan caching; ia mencerminkan pengiraan tambahan yang diperlukan untuk menyimpan fragmen tersebut bagi kegunaan masa hadapan. Apabila padanan cache (cache hit) berlaku, kos akan turun secara drastik—selalunya kepada sebahagian kecil daripada kadar biasa. Kuncinya adalah untuk membolehkan sistem benar-benar mencapai cache tersebut. Jika tidak, anda membayar premium tanpa sebarang penjimatan.

Hujah balas: caching belum mati

Sesetengah pembangun berpendapat bahawa kerumitan mengurus bahagian prompt yang statik berbanding dinamik melebihi penjimatan yang diperoleh. Pandangan tersebut mengabaikan fakta bahawa banyak saluran paip pengeluaran sudah pun memisahkan konfigurasi (statik) daripada data pengguna (dinamik). Dengan menyusun prompt sewajarnya, mekanisme caching yang sama yang telah membantu pembangun asal API tersebut boleh dimanfaatkan tanpa usaha tambahan. Komprominya hanyalah disiplin yang sederhana dalam reka bentuk prompt, bukannya kecacatan asas dalam teknologi tersebut.

Apa yang perlu diperhatikan seterusnya

  • Pantau kedua-dua kaunter cache dalam papan pemuka penggunaan anda setiap minggu.
  • Audit pembinaan prompt untuk mengesahkan bahawa sebarang elemen pemboleh ubah terletak selepas blok yang dicache.
  • Jalankan ujian A/B dengan dan tanpa caching pada beban kerja yang mewakili untuk mengukur penjimatan sebenar.
  • Sahkan gateway dengan membandingkan payload permintaan mentah sebelum dan selepas sebarang proksi.

Kesimpulan

Caching prompt boleh mengurangkan kos API LLM secara drastik, tetapi hanya jika segmen yang dicache benar-benar identikal merentasi setiap panggilan. Cap masa yang tersasar atau sebarang token dinamik lain pada permulaan prompt akan memaksa penulisan yang mahal setiap kali, sekali gus meningkatkan bil. Dengan meletakkan arahan statik di bahagian hadapan dan meletakkan data yang berubah-ubah di bahagian akhir, anda membiarkan cache menjalankan tugasnya dan memastikan perbelanjaan anda terkawal.