Pengoptimuman Kos: Caching Segera

Keuntungan:

• Terangkan logik pemadanan awalan caching segera
• Meningkatkan cache hit dengan meletakkan konteks tetap dahulu dan konteks berubah selepas
• Boleh mengira cache tulis/baca ekonomi dan titik pulang modal

Produk LLM kelihatan murah dalam prototaip; Apabila anda melangkah ke skala, bil mengejutkan. Dalam kebanyakan beban kerja, kebanyakan bil datang daripada konteks tetap yang sama yang dihantar berulang kali dengan setiap permintaan: gesaan sistem yang panjang, buku peraturan, dokumentasi rujukan. Caching segera menghapuskan pembaziran ini. Dalam unit ini, anda akan mempelajari cara cache berfungsi, cara mengatur gesaan untuk memukul dan cara mengira titik pulang modal ekonomi cache. Apabila dipasang dengan betul, ia sahaja boleh mengurangkan bil anda separuh atau lebih rendah.

Bagaimana Cache Berfungsi? Satu Peraturan Yang Tidak Berubah

Caching segera ialah padanan awalan. Pembekal menyimpan sementara token yang telah diproses sejak permulaan gesaan anda. Jika gesaan bermula dengan awalan yang sama pada permintaan seterusnya, bahagian biasa ini tidak dikira semula; Ia jauh lebih murah untuk dibaca daripada cache.

Satu peraturan tidak berubah berikutan daripada ini: Jika satu bait berubah di mana-mana dalam awalan, keseluruhan cache menjadi tidak sah mulai dari itu dan seterusnya. Iaitu, kandungan tetap hendaklah pada permulaan dan kandungan berubah hendaklah pada akhir. Jika anda meletakkan baris pada permulaan gesaan sistem yang berubah dengan setiap permintaan, seperti "Tarikh hari ini: 18.07.2026", semua di belakangnya tidak akan dapat memasuki cache.

Perintah pemprosesan biasanya: alat → gesaan sistem → mesej. Anda meletakkan titik cache (titik putus) pada penghujung bahagian tetap.

Ekonomi Cache

Cache mempunyai tiga peringkat harga:

• Tulis cache: Menyimpan buat kali pertama. ~1.25x harga input biasa (untuk penyimpanan 5 minit).
• Bacaan cache: Membaca pada permintaan seterusnya. ~0.1 kali harga input biasa — iaitu, satu persepuluh.
• Input biasa: Bahagian yang tidak memasuki cache dan diproses pada kos penuh setiap kali.

Titik pulang modal: Permintaan pertama membayar premium tulis (1.25×). Daripada permintaan kedua, bacaan (0.1×) mula dimainkan. Secara kasarnya, anda akan menerima dua permintaan; Selepas itu, ia adalah simpanan bersih. Lebih besar konteks tetap dan lebih banyak permintaan ia digunakan semula, lebih besar keuntungan menjadi.

Senario

Adakah cache berfungsi?

Gesaan sistem tetap yang besar, beribu-ribu permintaan

Ya — pendapatan tertinggi

Banyak soalan mengenai dokumen rujukan yang sama

ya

Teks pendek yang berbeza sama sekali untuk setiap permintaan

Tidak — bonus tulis sia-sia

Permintaan sekali

Tidak - tidak membaca sama sekali

Tarikh/ID berubah dengan setiap permintaan pada gesaan sistem

Tidak — awalan rosak, pukulan sifar

Langkah demi Langkah: Bagaimana untuk Menyediakan Gesaan Hit?

1. Asingkan pemalar dan pembolehubah. Apakah kandungan yang tidak pernah berubah (gesaan sistem, buku peraturan, dokumentasi)? Yang manakah berubah dengan setiap permintaan (soalan pengguna, tarikh, ID)?
2. Letakkan pemalar pada permulaan. Semasa pemprosesan, bahagian yang didahulukan (alat, sistem) mestilah stabil.
3. Letakkan pembolehubah di hujung. Soalan semasa pengguna, terakhir.
4. Letakkan tanda di hujung sempadan. Letakkan titik cache di blok terakhir bahagian tetap.
5. Sahkan pukulan. Semak sama ada cache_read_input_tokens lebih besar daripada sifar dalam medan penggunaan dalam respons. Jika sifar, terdapat pengganggu tersembunyi dalam awalan.

{ "sistem": [ { "jenis": "teks", "teks": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "message": [ { "role": "user", "content": "{{user_current_}soalan]

Petua: Jangan meneka hits cache, ukur mereka. Jika usage.cache_read_input_tokens masih sifar pada permintaan berturut-turut, pemutus senyap (datetime.now() pada gesaan sistem, JSON tidak tertib, senarai alatan yang berubah dengan setiap permintaan) sedang dijalankan. Bandingkan gesaan mentah bagi kedua-dua permintaan bait demi bait dan cari perbezaannya.

Pengganggu Senyap

Corak biasa yang merosakkan cache tanpa disedari:

# BREAKER: membenamkan maklumat dalam gesaan sistem yang berubah dengan setiap permintaan "Tarikh hari ini: {{now}}. Anda ialah pembantu..." ← perubahan awalan dengan setiap permintaan, tekan adalah sifar# BENAR: alihkan pembolehubah ke sistem mesej: "Anda adalah pembantu..." ← pemalar memasuki mesej cache: [{peranan: pengguna, kandungan: "Hari ini ialah {:{now}}.

Pemutus lain: JSON diisih secara berbeza pada setiap permintaan (simpan kunci dalam susunan tetap), senarai alatan yang berbeza-beza mengikut pengguna (alat diproses terlebih dahulu; tiada apa yang masuk ke dalam cache jika ia berubah), menukar model pertengahan perbualan (cache adalah khusus model).

Gesaan lemah / Gesaan kuat (struktur mesra cache)

# Sistem LEMAH (binaan penghapusan cache): "Tarikh: 18.07.2026 14:32. Pengguna: Ahmet (id 8842). Anda ialah bot sokongan. Peraturan: ...(2000 token)..."

# Sistem KUAT (struktur mesra cache): "Anda ialah bot sokongan. Peraturan: ...(2000 token, tidak pernah berubah)..." [tanda cache]mesej: [ { peranan: pengguna, kandungan: "Tarikh: 18.07.2026 14:32. ID pengguna: 8842. Soalan: bagaimana cara saya memulakan bayaran balik saya?" }]

Dalam versi lemah, blok peraturan 2000 token diproses pada kos penuh pada setiap permintaan. Dalam versi yang kukuh, blok yang sama ditulis sekali dan dibaca pada semua permintaan berikutnya untuk sepersepuluh daripada harga.

Tiga Kes Mini

Kes 1 — Cache buku peraturan. Automasi perakaunan sedang menambah buku peraturan 12,000 token pada setiap invois; 5,000 permintaan setiap hari. Kos input tanpa cache ~$180 sehari. Mereka mengekalkan buku peraturan tetap dan menyimpannya di cache: permintaan pertama membayar premium tulis, bacaan seterusnya 0.1×. Kos input menurun ~90% kepada ~$18 sehari.

Kes 2 — Kos baris tarikh tersembunyi. Satu pasukan menyediakan cache tetapi tidak mendapat pukulan; cache_read_input_tokens sentiasa sifar. Sebab: Terdapat datetime.now() dalam baris pertama gesaan sistem, awalan berubah dengan setiap permintaan. Apabila kami mengalihkan tarikh ke mesej pengguna, kadar hit tiba-tiba meningkat daripada 0% kepada 94%.

Kes 3 — Cache salah letak. Aplikasi carian menghantar pertanyaan pendek yang berbeza dengan setiap permintaan; Mereka tidak sabar-sabar menambah tanda cache. Tanpa awalan biasa, setiap permintaan hanya membayar premium tulis, tiada bacaan — meningkatkan kos. Mereka mengeluarkan tanda itu. Pelajaran: cache membayar hanya jika terdapat awalan yang besar dan tetap yang digunakan semula.

Kesilapan biasa

• Mencampurkan pemalar dan pembolehubah: Apabila kandungan pembolehubah berada dalam awalan, pukulan ditetapkan semula.
• Membenamkan tarikh/ID dalam gesaan sistem: Pengganggu senyap yang paling biasa.
• Tidak mengukur pukulan: Jika cache_read_input_tokens tidak disemak, pembaziran tidak akan disedari.
• Menambah cache apabila tiada awalan awam: Anda hanya membayar premium tulis, kos meningkat.
• Menukar senarai atau model kenderaan: Awalan dipecahkan dari awal; semuanya ditulis semula.
• Melupakan saiz cache minimum: Cache yang sangat pendek (di bawah ~1–4k token bergantung pada model) tidak akan memasuki cache secara senyap.

Lebih Dalam: Merekabentuk Cache mengikut Jenis Beban Kerja

Hasil sebenar caching berbeza-beza bergantung pada sifat beban kerja anda; jadi kenali trafik anda dahulu. Tiga corak biasa dan pemasangan yang betul:

Gesaan sistem biasa, soalan berbeza. Corak perusahaan yang paling biasa: gesaan sistem yang besar (peranan, peraturan, mungkin dokumen rujukan) dengan beratus-ratus soalan pengguna yang berbeza. Di sini bahagian tetap (sistem) dicache pada mulanya; setiap soalan baharu membayar harga penuh hanya untuk bahagian kecilnya sendiri. Keuntungannya sangat tinggi kerana bahagian yang besar dibaca berulang kali pada sepersepuluh daripada harga.

Monolog berbilang pusingan. Apabila perbualan berlarutan, setiap pusingan baharu dibina di atas semua sejarah sebelumnya. Jika anda meletakkan bendera cache pada penghujung pusingan terakhir, setiap permintaan menggunakan semula awalan perbualan sebelumnya; hits terkumpul apabila perbualan berkembang. Ini secara mendadak mengekang kos sesi pembantu yang panjang.

Awalan yang dikongsi ialah bit terakhir untuk ditukar. Permintaan berbilang berkongsi set prior tetap yang besar (set sampel, arahan) tetapi dipisahkan oleh satu soalan pada penghujungnya. Anda meletakkan penuding cache di hujung bahagian yang dikongsi; Jika tidak, setiap permintaan akan menulis cache berasingannya sendiri dan tiada satu pun daripadanya akan dibaca.

Satu kaveat: cache bergantung pada model dan saiz minimum tertentu. Awalan yang sangat kecil (di bawah beberapa ribu token, bergantung pada model) tidak akan memasuki cache secara senyap walaupun anda membenderakannya — cache_creation_input_tokens kekal sifar. Selain itu, menukar model pertengahan perbualan akan membatalkan keseluruhan cache; Jika tugasan berbeza memerlukan model murah, simpan aliran utama dalam satu model dan letakkan tugas sampingan dalam panggilan berasingan.

Secara ringkasnya

Caching segera ialah padanan awalan: kandungan tetap harus berada di awal, kandungan berubah harus berada di akhir. Untuk konteks yang besar dan digunakan semula, kos baca ialah sepersepuluh daripada harga penuh, kira-kira pulang modal dalam dua permintaan. Kesilapan yang paling biasa ialah merosakkan awalan dengan membenamkan data pembolehubah dalam gesaan sistem; Anda mengesahkan pukulan dengan mengukurnya dalam medan penggunaan.

Tugasan permohonan

Pilih beban kerja. (1) Bahagikan kandungan kepada dua lajur: "tidak pernah berubah" dan "berubah dengan setiap permintaan". (2) Lukis semula struktur segera, meletakkan bahagian tetap pada permulaan dan bahagian berubah pada akhir. (3) Anggarkan saiz token bahagian tetap dan bandingkan kos bulanan dengan/tanpa cache. (4) Perhatikan medan (cache_read_input_tokens) yang anda akan sahkan daripada hit.

senarai semak

• [ ] Saya boleh menerangkan bahawa cache ialah padanan awalan dan satu-satunya peraturan yang tidak boleh diubah.
• [ ] Saya boleh meningkatkan ketepatan dengan meletakkan kandungan tetap pada permulaan dan pembolehubah pada akhir.
• [ ] Saya tahu menulis/membaca ekonomi dan titik pulang modal dua permintaan.
• [ ] Saya dapat mengenali pengganggu senyap (tarikh, JSON tidak teratur, menukar senarai kenderaan).
• [ ] Saya boleh mengesahkan hit dengan usage.cache_read_input_tokens.