Optimasi Biaya: Caching Cepat — API, Biaya dan Integrasi

Keuntungan:

Jelaskan logika pencocokan awalan dari cache cepat
Meningkatkan cache hit dengan mengutamakan konteks tetap dan konteks variabel setelahnya
Dapat menghitung ekonomi tulis/baca cache dan titik impas

Produk LLM terlihat murah dalam prototipe; Saat Anda meningkatkan skalanya, tagihannya akan mengejutkan. Di sebagian besar beban kerja, sebagian besar tagihan berasal dari konteks tetap yang sama yang dikirim berulang kali dengan setiap permintaan: perintah sistem yang panjang, buku aturan, dokumentasi referensi. Caching yang cepat menghilangkan pemborosan ini. Dalam unit ini, Anda akan mempelajari cara kerja cache, cara mengatur prompt untuk mencapai, dan cara menghitung titik impas dari ekonomi cache. Jika dipasang dengan benar, itu saja dapat memotong tagihan Anda setengah atau bahkan lebih rendah.

Bagaimana Cara Kerja Cache? Satu-satunya Aturan yang Tidak Dapat Diubah

Caching cepat adalah pencocokan awalan. Penyedia menyimpan sementara token yang telah diproses sejak awal permintaan Anda. Jika prompt dimulai dengan awalan yang sama pada permintaan berikutnya, bagian umum ini tidak dihitung ulang; Jauh lebih murah untuk membaca daripada cache.

Satu aturan yang tidak dapat diubah mengikuti dari ini: Jika satu byte berubah di mana saja di awalan, seluruh cache menjadi tidak valid sejak saat itu dan seterusnya. Artinya, konten tetap harus berada di awal dan konten variabel harus berada di akhir. Jika Anda meletakkan baris di awal perintah sistem yang berubah setiap kali permintaan, seperti "Tanggal hari ini: 18.07.2026", semua yang ada di belakangnya tidak akan bisa masuk ke cache.

Urutan pemrosesan biasanya: alat → prompt sistem → pesan. Anda meletakkan titik cache (breakpoint) di akhir bagian yang diperbaiki.

Ekonomi Cache

Cache memiliki tiga tingkatan harga:

Tulis cache: Menyimpan untuk pertama kalinya. ~1,25x harga input normal (untuk penyimpanan 5 menit).
Bacaan cache: Membaca permintaan berikutnya. ~0,1 kali harga input normal — yaitu sepersepuluh.
Input normal: Bagian yang tidak masuk ke cache dan diproses dengan biaya penuh setiap saat.

Titik impas: Permintaan pertama membayar premi tulis (1,25×). Dari permintaan kedua, pembacaan (0,1×) mulai berlaku. Secara kasar, Anda akan bersaing ketat dalam dua permintaan; Setelah itu menjadi tabungan bersih. Semakin besar konteks tetapnya dan semakin banyak permintaan yang digunakan kembali, semakin besar keuntungannya.

Skenario

Apakah cache berfungsi?

Prompt sistem tetap yang besar, ribuan permintaan

Ya — penghasilan tertinggi

Banyak pertanyaan pada dokumen referensi yang sama

Teks pendek yang sangat berbeda untuk setiap permintaan

Tidak — bonus menulis terbuang percuma

Permintaan satu kali

Tidak - tidak ada bacaan sama sekali

Tanggal/ID berubah dengan setiap permintaan pada prompt sistem

Tidak — awalan rusak, hitnya nol

Langkah demi Langkah: Bagaimana Cara Mengatur Hit Prompt?

Pisahkan konstanta dan variabel. Konten apa yang tidak pernah berubah (perintah sistem, buku peraturan, dokumentasi)? Apa yang berubah pada setiap permintaan (pertanyaan pengguna, tanggal, ID)?
Letakkan konstanta di awal. Selama pemrosesan, bagian yang didahulukan (alat, sistem) harus stabil.
Letakkan variabel di akhir. Pertanyaan pengguna saat ini, terakhir.
Tempatkan tanda di ujung perbatasan. Letakkan titik cache di blok terakhir dari bagian yang diperbaiki.
Verifikasi pukulan. Periksa apakah cache_read_input_tokens lebih besar dari nol di bidang penggunaan sebagai respons. Jika nol, ada pengganggu tersembunyi di awalan.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

Tip: Jangan menebak cache yang ditemukan, ukurlah. Jika usage.cache_read_input_tokens masih nol pada permintaan berturut-turut, pemutus senyap (datetime.now() pada prompt sistem, JSON tidak berurutan, daftar alat berubah setiap permintaan) sedang berjalan. Bandingkan prompt mentah dari dua permintaan byte demi byte dan temukan perbedaannya.

Pengganggu Senyap

Pola umum yang tanpa disadari merusak cache:

# BREAKER: menyematkan informasi di prompt sistem yang berubah dengan setiap permintaan "Tanggal hari ini: {{sekarang}}. Anda adalah asisten..." ← awalan berubah dengan setiap permintaan, hit adalah nol# BENAR: pindahkan variabel ke sistem pesan: "Anda adalah asisten..." ← konstanta memasuki pesan cache: [{peran: pengguna, konten: "Hari ini adalah {{sekarang}}. Pertanyaan: ..."}] ← variabel di akhir

Pemutus lainnya: JSON diurutkan secara berbeda pada setiap permintaan (simpan kunci dalam urutan tetap), daftar alat bervariasi menurut pengguna (alat diproses terlebih dahulu; tidak ada yang masuk ke cache jika diubah), mengubah model di tengah percakapan (cache khusus untuk model).

Prompt lemah / Prompt kuat (struktur ramah cache)

# LEMAH (pembangunan penghilang cache)sistem: "Tanggal: 18.07.2026 14:32. Pengguna: Ahmet (id 8842). Anda adalah bot pendukung. Aturan: ...(2000 token)..."

# STRONG (struktur ramah-cache)sistem: "Anda adalah bot pendukung. Aturan: ...(2000 token, tidak pernah berubah)..." [tanda cache]pesan: [ { peran: pengguna, konten: "Tanggal: 18.07.2026 14:32. ID pengguna: 8842. Pertanyaan: bagaimana cara memulai pengembalian dana?" }]

Dalam versi lemah, blok aturan 2000 token diproses dengan biaya penuh pada setiap permintaan. Dalam versi kuat, blok yang sama ditulis satu kali dan dibaca pada semua permintaan berikutnya dengan sepersepuluh harga.

Tiga Kasus Mini

Kasus 1 — Menyimpan buku aturan dalam cache. Otomatisasi akuntansi menambahkan 12.000 buku peraturan token ke setiap faktur; 5.000 permintaan per hari. Biaya masukan tanpa cache ~$180 per hari. Mereka menjaga buku peraturan tetap konstan dan menyimpannya dalam cache: permintaan pertama membayar premi tulis, selanjutnya dibaca 0,1×. Biaya input turun ~90% menjadi ~$18 per hari.

Kasus 2 — Biaya garis tanggal tersembunyi. Satu tim menyiapkan cache tetapi tidak mendapatkan hasil; cache_read_input_tokens selalu nol. Alasan: Ada datetime.now() di baris pertama prompt sistem, awalan berubah dengan setiap permintaan. Saat kami memindahkan tanggal ke pesan pengguna, hit rate tiba-tiba meningkat dari 0% menjadi 94%.

Kasus 3 — Cache salah tempat. Aplikasi pencarian mengirimkan pertanyaan singkat yang sangat berbeda dengan setiap permintaan; Mereka dengan bersemangat menambahkan tanda cache. Tanpa awalan umum, setiap permintaan hanya membayar premi tulis, tidak ada pembayaran baca — sehingga meningkatkan biaya. Mereka menghapus tanda itu. Pelajaran: cache hanya membayar jika ada awalan yang besar dan konstan yang digunakan kembali.

Kesalahan umum

Mencampur konstanta dan variabel: Ketika konten variabel ada di awalan, hit akan diatur ulang.
Menyematkan tanggal/ID di prompt sistem: Pengganggu diam yang paling umum.
Tidak mengukur hit: Jika cache_read_input_tokens tidak dicentang, pemborosan tidak akan diketahui.
Menambahkan cache ketika tidak ada awalan publik: Anda hanya membayar premi tulis, biayanya meningkat.
Mengubah daftar atau model kendaraan: Awalannya rusak dari awal; semuanya ditulis ulang.
Melupakan ukuran cache minimum: Cache yang sangat pendek (di bawah ~1–4 ribu token tergantung modelnya) tidak akan masuk ke cache secara diam-diam.

Lebih Dalam: Mendesain Cache Berdasarkan Jenis Beban Kerja

Imbalan sebenarnya dari caching bervariasi tergantung pada sifat beban kerja Anda; jadi kenali lalu lintas Anda terlebih dahulu. Tiga pola khas dan pemasangan yang benar:

Prompt sistem umum, pertanyaan berbeda. Pola perusahaan yang paling umum: prompt sistem yang besar (peran, aturan, mungkin dokumen referensi) dengan ratusan pertanyaan pengguna yang berbeda. Di sini bagian tetap (sistem) di-cache pada awalnya; setiap pertanyaan baru membayar harga penuh hanya untuk porsi kecilnya. Keuntungannya sangat tinggi karena porsinya yang besar dibacakan berulang-ulang dengan sepersepuluh harga.

Monolog multi-putaran. Saat percakapan berlanjut, setiap babak baru dibangun di atas semua sejarah sebelumnya. Jika Anda memasang tanda cache di akhir putaran terakhir, setiap permintaan akan menggunakan kembali awalan percakapan sebelumnya; hit terakumulasi seiring berkembangnya percakapan. Hal ini secara signifikan mengurangi biaya sesi asisten yang panjang.

Awalan bersama adalah bit terakhir yang diubah. Beberapa permintaan berbagi sejumlah besar prioritas tetap (kumpulan sampel, instruksi) tetapi dipisahkan oleh satu pertanyaan di akhir. Anda meletakkan penunjuk cache di akhir bagian yang dibagikan; Jika tidak, setiap permintaan akan menulis cache tersendiri dan tidak ada satupun yang akan dibaca.

Satu peringatan: cache bergantung pada model dan ukuran minimum tertentu. Awalan yang sangat kecil (di bawah beberapa ribu token, bergantung pada modelnya) tidak akan masuk ke cache secara diam-diam meskipun Anda menandainya — cache_creation_input_tokens tetap nol. Selain itu, mengubah model di tengah percakapan akan membatalkan seluruh cache; Jika tugas yang berbeda memerlukan model yang murah, pertahankan aliran utama dalam satu model dan tempatkan pekerjaan sampingan dalam panggilan terpisah.

Singkatnya

Caching cepat adalah pencocokan awalan: konten tetap harus di awal, konten variabel harus di akhir. Untuk konteks penggunaan ulang yang besar, biaya baca adalah sepersepuluh dari harga penuh, kira-kira mencapai titik impas dalam dua permintaan. Kesalahan paling umum adalah merusak awalan dengan menyematkan data variabel di prompt sistem; Anda memverifikasi hit dengan mengukurnya di bidang penggunaan.

Tugas aplikasi

Pilih beban kerja. (1) Bagi konten menjadi dua kolom: "tidak pernah berubah" dan "berubah setiap kali ada permintaan". (2) Gambar ulang struktur prompt, letakkan bagian konstan di awal dan bagian variabel di akhir. (3) Perkirakan ukuran token bagian tetap dan bandingkan biaya bulanan dengan/tanpa cache. (4) Catat dari bidang mana (cache_read_input_tokens) Anda akan memverifikasi hitnya.

daftar periksa

[] Saya dapat menjelaskan bahwa cache adalah pencocokan awalan dan satu-satunya aturan yang tidak dapat diubah.
[ ] Saya dapat meningkatkan akurasi dengan menempatkan konten tetap di awal dan variabel di akhir.
[ ] Saya mengetahui ilmu ekonomi tulis/baca dan titik impas dua permintaan.
[ ] Saya dapat mengenali pengganggu senyap (tanggal, JSON tidak berurutan, daftar kendaraan berubah).
[] Saya dapat memverifikasi hit dengan usage.cache_read_input_tokens.