Perbezaan KV Cache dan Prompt Cache dalam AI

KV cache berbanding prompt cache: jawapan ringkas

KV cache dan prompt cache penyedia hanya berkongsi satu perkataan yang sama, namun fungsinya hampir tiada kaitan. KV cache ialah memori kerja bagi setiap permintaan. Ia berada dalam RAM atau VRAM pelayan anda sepanjang hayat satu permintaan, dan ia berkembang mengikut panjang konteks serta bilangan permintaan yang anda jalankan serentak. Prompt caching penyedia pula merupakan ciri pengebilan dan kependaman. Awalan (prefix) yang stabil bagi prompt anda disimpan pada pelayan penyedia, kemudian dikenakan caj pada kadar diskaun apabila anda menghantarnya semula.

Satu adalah memori yang anda beli sebagai perkakasan. Satu lagi adalah memori yang dipegang oleh pihak lain dan anda dikenakan sewa untuknya.

Perbezaan praktikal lebih penting daripada definisinya. Anda boleh kehabisan KV cache, dan apabila itu berlaku, model enggan dimuatkan atau permintaan anda ditolak. Anda tidak boleh kehabisan prompt cache. Anda hanya boleh gagal untuk mencapainya, dan kemudian anda perlu membayar harga penuh secara senyap.

Kandungan KV cache dan sebab ia wujud

Transformer yang menjana token nombor 500 perlu memberikan perhatian kepada semua 499 token sebelumnya. Bagi setiap token tersebut, setiap lapisan memerlukan vektor kunci (key vector) dan vektor nilai (value vector). Mengira semula kesemuanya bagi setiap token baharu akan menyebabkan masa penjanaan meningkat mengikut kuasa dua panjang jujukan, jadi runtime menyimpannya sebagai ganti. Storan tersebut ialah KV cache (key/value cache).

Ia merupakan state bagi setiap permintaan kerana ia dibina daripada jujukan token yang tepat bagi permintaan tersebut. Dua pengguna yang menghantar prompt berbeza tidak boleh berkongsi cache ini, melainkan runtime melakukan prefix caching, iaitu ciri berasingan yang diterangkan kemudian.

Penyediaan servis berlaku dalam dua fasa. Prefill membaca keseluruhan prompt anda dan mengisi cache, dan ia dihadkan oleh kuasa pengkomputeran. Decode menghasilkan satu token pada satu masa dan menambahkannya ke dalam cache, dan ia dihadkan oleh lebar jalur memori. Pemisahan ini adalah sebab pemprosesan prompt dan penjanaan token melaporkan kelajuan yang berbeza apabila anda mengukur token sesaat pada pelayan anda sendiri.

Berapakah memori yang digunakan oleh KV cache?

Jangan mencari jadual vendor. Saiznya adalah hasil pengiraan aritmetik yang boleh anda lakukan semula untuk mana-mana model:

bytes per token = 2 * layers * kv_heads * head_dim * bytes per element

Angka 2 mewakili key dan value. Setiap nombor lain diperoleh daripada config.json model tersebut, yang diterbitkan pada halaman Hugging Face model berkenaan.

Ambil Llama 3.1 8B sebagai contoh. Konfigurasinya menyenaraikan num_hidden_layers 32 dan num_key_value_heads 8. hidden_size sebanyak 4096 yang dibahagikan merentasi 32 attention heads memberikan dimensi head sebanyak 128. Pada f16, setiap elemen adalah 2 bait:

2 * 32 * 8 * 128 * 2 = 131072 bytes = 128 KiB per token

Darabkan nilai tersebut dengan konteks yang anda minta, kemudian darabkan dengan jumlah permintaan yang dijalankan serentak.

[
  {
    "label": "2k context",
    "one_request_gib": 0.25,
    "four_requests_gib": 1
  },
  {
    "label": "8k context",
    "one_request_gib": 1,
    "four_requests_gib": 4
  },
  {
    "label": "32k context",
    "one_request_gib": 4,
    "four_requests_gib": 16
  },
  {
    "label": "128k context",
    "one_request_gib": 16,
    "four_requests_gib": 64
  }
]

Pada konteks 8k, cache tersebut adalah 1 GiB. Pada 32k, ia adalah 4 GiB, iaitu dalam julat yang sama dengan berat 4-bit itu sendiri. Pada konteks penuh 128k model tersebut, ia adalah 16 GiB untuk satu permintaan, dan 64 GiB jika empat permintaan masing-masing mengisinya. Berat model tidak pernah berubah. Hanya cache yang berubah.

Grouped query attention (GQA) memainkan peranan besar dalam angka tersebut. Llama 3.1 8B mempunyai 8 key/value heads yang melayani 32 query heads, jadi empat query heads berkongsi satu pasangan key/value yang disimpan. Model yang mempunyai num_key_value_heads sama dengan num_attention_heads menggunakan cache empat kali ganda pada jumlah parameter yang sama. Semak medan tersebut sebelum anda menganggap dua model 8B mempunyai kos penyediaan yang sama.

Mengapa model yang berjalan pada 2k enggan dimuatkan pada 32k

Ini kerana runtime menempah KV cache semasa model dimuatkan, dengan saiz mengikut panjang konteks yang anda konfigurasikan, bukan mengikut prompt yang anda hantar. Tetingkap konteks lalai Ollama ialah 4096 token. Tingkatkan kepada 32k dan anda telah meminta 4 GiB peruntukan tambahan sebelum satu token pun tiba.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Tetapan yang sama bagi setiap sesi, daripada prompt interaktif:

ollama run llama3.1:8b
/set parameter num_ctx 32768

Kegagalan kelihatan berbeza pada setiap stack. vLLM menyemak pengiraan pada permulaan dan enggan berjalan:

ValueError: The model's max seq len (131072) is larger than the maximum number of tokens that can be stored in KV cache (78336). Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine.

Pada VPS yang hanya menggunakan CPU, tiada semakan sedemikian kerana peruntukan tersebut adalah RAM sistem biasa. Out-of-memory killer kernel akan menamatkan proses tersebut, dan ia meninggalkan bukti dalam kernel ring buffer:

dmesg -T | grep -i "killed process"

Baris yang menamakan proses penyajian anda bermakna pelayan menjanjikan lebih banyak memori daripada yang tersedia. Penyelesaiannya ialah konteks yang lebih kecil, bukan fail swap yang lebih besar: KV cache yang di-page ke cakera dibaca pada setiap token yang dijana, jadi penjanaan menjadi perlahan sehingga tidak berguna. Memilih nombor yang munasabah diterangkan dalam panduan kami tentang num_ctx dan panjang konteks dalam Ollama.

Kesan konkurensi terhadap angka

Setiap permintaan yang sedang diproses membawa KV cache miliknya sendiri. Ini adalah perkara yang sering terlepas pandang dalam perancangan kapasiti. Empat pengguna yang masing-masing memegang 32k konteks memerlukan 16 GiB secara keseluruhan, sebagai tambahan kepada berat model (weights).

Runtime berbeza dari segi tahap ketat pengurusan memori ini. Ollama dan llama.cpp menempah konteks yang diminta semasa model dimuatkan, jadi memori tersebut dikomitkan sama ada ia digunakan atau tidak. vLLM membahagikan pool kepada blok bersaiz tetap dan mengagihkannya mengikut pertumbuhan setiap permintaan, jadi permintaan 500-token hanya menggunakan memori untuk 500 token. Walau apa pun kaedahnya, pool tersebut adalah terhad, dan apabila ia penuh, permintaan baharu akan diletakkan dalam baris gilir dan bukannya dijalankan. Kesan baris gilir tersebut terhadap masa respons dihuraikan dalam berapa ramai pengguna serentak yang boleh disokong oleh LLM yang dihoskan sendiri.

Empat cara untuk mengecilkan KV cache

1. Kurangkan panjang konteks. Ini adalah tuil paling berkesan dan biasanya paling murah. Kebanyakan beban kerja sembang tidak pernah menghampiri 32k.
2. Kuantisasikan cache itu sendiri. OLLAMA_KV_CACHE_TYPE lalai Ollama ialah f16 dan ia menerima q8_0, yang menggunakan kira-kira separuh memori, serta q4_0, yang menggunakan kira-kira satu perempat. Setara llama.cpp bagi tetapan ini ialah -ctk q8_0 dan -ctv q8_0.
3. Pilih model dengan kepala key/value yang lebih sedikit atau lapisan yang lebih sedikit. Baca config.json sebelum anda memuat turun 40 GB pemberat.
4. Kendalikan permintaan yang lebih sedikit pada satu masa dan baris gilirkan selebihnya.

Pada q4_0, angka Llama 3.1 8B menurun daripada 128 KiB setiap token kepada kira-kira 32 KiB, jadi konteks 32k menelan kos kira-kira 1 GiB dan bukannya 4 GiB. Penjimatan itu tidak datang secara percuma. Key dan value disimpan dengan ketepatan yang lebih rendah, jadi bandingkan output pada prompt anda sendiri sebelum mengekalkannya.

Apa yang sebenarnya dibeli oleh prompt caching penyedia

Prompt caching penyedia merupakan produk berbeza dengan unit akaun yang berbeza. Anda menandakan awalan (prefix) yang stabil, penyedia menyimpannya, dan panggilan seterusnya yang mengulangi awalan yang sama dengan tepat akan dibilkan pada kadar yang dikurangkan berbanding harga input penuh.

Pengganda yang diterbitkan oleh Anthropic, setakat Ogos 2026: penulisan cache 5 minit berharga 1.25 kali ganda harga token input asas. Penulisan 1 jam berharga 2 kali ganda, dan bacaan cache berharga 0.1 kali ganda. Letakkan prompt sistem 20,000 token di sebalik angka-angka tersebut dan bentuk tawaran itu menjadi jelas.

[
  {
    "label": "No caching, every call",
    "billed_token_equivalents": "20,000"
  },
  {
    "label": "First call, 5 minute cache write",
    "billed_token_equivalents": "25,000"
  },
  {
    "label": "First call, 1 hour cache write",
    "billed_token_equivalents": "40,000"
  },
  {
    "label": "Every later call, cache hit",
    "billed_token_equivalents": "2,000"
  }
]

Baca ia sebagai aritmetik. Premium penulisan 5 minit adalah bersamaan 5,000 token pada panggilan pertama: 25,000 berbanding 20,000 untuk menghantarnya tanpa cache. Setiap panggilan seterusnya dalam tempoh tersebut dibilkan sebanyak 2,000 dan bukannya 20,000, iaitu penjimatan sebanyak 18,000. Jadi, cache 5 minit memberikan keuntungan bermula dari panggilan kedua dan seterusnya.

Cache 1 jam pula merupakan pertaruhan yang berbeza. Ia dibilkan sebanyak 40,000 semasa penulisan, iaitu premium bersamaan 20,000 token, jadi ia memerlukan dua kali hit dalam tempoh sejam sebelum ia memberikan keuntungan. Ini adalah persoalan tentang corak trafik anda, bukan tentang model tersebut. Pengiraan penuh, termasuk cara memilih tempoh masa, terdapat dalam matematik titik pulang modal untuk Claude prompt caching.

Dua perincian menentukan sama ada anda berjaya mencapai cache atau tidak. Pertama, awalan yang berada di bawah panjang minimum model tidak akan dicache secara senyap: setakat Ogos 2026, minimum yang didokumenkan ialah 512 token untuk Claude Opus 5 dan 1,024 token untuk Claude Sonnet 5, dan permintaan yang lebih pendek akan diproses seperti biasa tanpa ralat dikembalikan. Kedua, jangka hayat diukur dari permulaan permintaan yang menulis atau membaca entri tersebut, dan setiap bacaan akan menyegarkannya tanpa kos tambahan. Oleh itu, endpoint yang sibuk akan memastikan cache 5 minit kekal hidup selama-lamanya. Endpoint yang dipanggil setiap sepuluh minit akan membayar premium penulisan setiap kali dan tidak akan mendapat sebarang penjimatan.

Semak respons dan jangan sekadar membuat andaian. Objek usage melaporkan cache_creation_input_tokens dan cache_read_input_tokens. Kiraan bacaan sifar pada setiap panggilan bermakna anda sedang membeli penulisan tetapi tidak mendapat apa-apa pulangan.

Tempat pertemuan kedua-dua cache

Prompt sistem yang panjang merupakan titik pertemuan kedua-duanya, dan ia memberikan beban pada kedua-dua pihak secara serentak.

Secara tempatan, prompt sistem 20,000-token menggunakan kira-kira 2.4 GiB cache KV pada pelayan Llama 3.1 8B pada f16, dan ia melakukannya secara berasingan bagi setiap permintaan serentak yang menyertakannya. Secara jauh, awalan yang sama itu menelan kos satu penulisan cache dan kemudian 0.1 kali input pada setiap panggilan seterusnya. Kos tempatan berskala mengikut bilangan pengguna anda. Kos jauh berskala mengikut trafik anda dan ditetapkan semula semasa waktu melahu.

Terdapat satu ciri tempatan yang kelihatan seperti prompt caching pembekal dan sering dikelirukan dengannya: prefix caching. Dokumentasi vLLM menghuraikan prefix caching automatik sebagai caching "cache KV bagi pertanyaan sedia ada, supaya pertanyaan baharu boleh menggunakan semula cache KV secara terus jika ia berkongsi awalan yang sama dengan salah satu pertanyaan sedia ada". Pelayan llama.cpp mengekalkan cache prompt bagi setiap slot secara lalai, dan --cache-reuse N menetapkan ketulan terkecil yang akan cuba digunakan semula.

Apa yang dijimatkan oleh prefix caching ialah pengiraan prefill. Prompt sistem 20,000-token anda diproses sekali dan bukannya pada setiap permintaan, yang mengurangkan masa ke token pertama dengan ketara. Dalam vLLM, blok yang dikongsi digunakan semula dan bukannya diduplikasi, jadi penggunaan memori juga bertambah baik. Apa yang ia tidak pernah lakukan ialah mengecilkan cache yang perlu anda simpan untuk token yang sedang aktif. Mengekalkan pemberat (weights) dalam memori antara permintaan adalah tuil yang berkaitan tetapi berasingan, yang dibincangkan dalam mengekalkan model Ollama dimuatkan antara permintaan.

Perkara yang perlu diukur pada pelayan anda sendiri

Muatkan model pada konteks sasaran anda, kemudian baca angka sebenar dan jangan sekadar mempercayai anggaran.

ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
free -g

ollama ps menyenaraikan model yang dimuatkan berserta saiznya dan sama ada ia berjalan pada GPU atau CPU. Jika model yang anda jangkakan dimuatkan sepenuhnya pada GPU melaporkan pembahagian CPU, ini bermakna KV cache telah menolak sebahagian daripadanya keluar, dan kelajuan penjanaan akan menurun sewajarnya. nvidia-smi memberikan angka VRAM sebenar, dan free -g melakukan tugas yang sama pada VPS yang hanya menggunakan CPU. Tingkatkan konteks secara berperingkat, muat semula, dan perhatikan perubahan angka tersebut. Pengiraan anda dan angka yang dilaporkan sepatutnya hampir sama. Apabila ia tidak sama, jurang tersebut biasanya disebabkan oleh penimbal pengiraan (compute buffers) runtime itu sendiri dan bukannya ralat dalam formula.

Jika angka tersebut mendorong anda ke arah perkakasan yang anda tidak mahu sewa, perbandingan dengan pembayaran mengikut token telah diperincikan dalam VPS GPU berbanding token API.

FAQ

Adakah KV cache sama dengan prompt caching?

Tidak. KV cache ialah memori bagi setiap permintaan di dalam proses penyediaan, yang menyimpan vektor kunci dan nilai untuk setiap token dalam konteks semasa. Ia berada dalam RAM atau VRAM anda dan akan dilepaskan apabila permintaan tamat. Prompt caching pembekal ialah ciri pengebilan yang menyimpan awalan prompt yang stabil pada infrastruktur pembekal dan mengenakan kadar yang lebih rendah apabila anda menghantarnya semula. Kehabisan KV cache akan menyebabkan model gagal dimuatkan. Ketiadaan prompt cache hanya meningkatkan invois anda dan masa untuk token pertama.

Mengapa model saya dimuatkan pada konteks 2k tetapi gagal pada 32k?

Ini kerana runtime memperuntukkan keseluruhan KV cache semasa waktu pemuatan, mengikut saiz panjang konteks yang anda konfigurasikan dan bukannya prompt yang anda hantar. Bagi Llama 3.1 8B pada f16, cache tersebut ialah 128 KiB bagi setiap token, jadi konteks 2k memerlukan 0.25 GiB dan 32k memerlukan 4 GiB. Berat model (weights) muat dalam kedua-dua kes. Tempahan memori itulah yang gagal. vLLM melaporkannya sebagai ValueError yang menamakan bilangan maksimum token yang boleh disimpan, dan mencadangkan untuk meningkatkan gpu_memory_utilization atau merendahkan max_model_len. Pada mesin yang hanya menggunakan CPU, kernel out-of-memory killer akan menamatkan proses tersebut, yang boleh anda sahkan dengan dmesg -T | grep -i "killed process".

Bagaimanakah cara saya mengira saiz KV cache untuk model saya?

Darabkan 2 dengan bilangan lapisan (layer count), bilangan kepala kunci/nilai, dimensi kepala, dan bait bagi setiap elemen. Itu memberikan nilai bait bagi setiap token. Kemudian darabkan dengan panjang konteks anda dan bilangan permintaan serentak. Baca kiraan lapisan dan kepala daripada config.json model tersebut. Gunakan 2 bait bagi setiap elemen untuk f16 atau bf16. Cache q8_0 adalah kira-kira separuh daripada itu, dan q4_0 kira-kira satu perempat.

Adakah prompt caching mengurangkan memori yang diperlukan oleh pelayan saya sendiri?

Prompt caching pembekal tidak memberi kesan kepada perkakasan anda, kerana storan tersebut berada di pihak pembekal. Padanan tempatan bagi ciri ini ialah prefix caching, yang ditawarkan oleh vLLM dan pelayan llama.cpp. Ia menggunakan semula vektor kunci dan nilai yang telah dikira untuk awalan yang dikongsi, yang menjimatkan pengiraan prefill dan mengurangkan masa untuk token pertama. Dalam vLLM, blok yang dikongsi digunakan semula dan bukannya diduplikasi, jadi penggunaan memori turut bertambah baik. Tiada satu pun daripada ciri ini mengecilkan cache yang diperlukan untuk token yang sedang diproses, jadi pengiraan konteks dan konkurensi anda masih menentukan had minimum.

Adakah berbaloi untuk menyimpan prompt yang saya hanya hantar sekali?

Tidak. Penulisan cache menelan kos lebih tinggi daripada input biasa, iaitu 1.25 kali ganda kadar asas untuk pilihan 5 minit setakat Ogos 2026, jadi awalan yang tidak pernah anda hantar semula dalam tempoh tersebut adalah satu kerugian. Caching berbaloi apabila awalan yang sama berulang, seperti prompt sistem yang panjang atau dokumen yang akan anda ajukan beberapa soalan mengenainya. Semak cache_read_input_tokens dalam respons API untuk mengesahkan bahawa anda mendapat hits dan bukannya membayar untuk penulisan.