Cache KV vs Cache Prompt: Perbedaan dan Risikonya

Cache KV vs cache prompt: jawaban singkat

Cache KV dan cache prompt milik provider memiliki satu kata yang sama, tetapi hampir tidak memiliki kesamaan lain. Cache KV adalah memori kerja per permintaan. Cache ini berada di RAM atau VRAM server Anda selama masa aktif satu permintaan, dan ukurannya bertambah seiring panjang konteks serta jumlah permintaan yang dijalankan secara bersamaan. Caching prompt oleh provider adalah fitur penagihan dan latensi. Prefix prompt yang stabil disimpan di server provider, lalu dikenai biaya dengan tarif diskon saat Anda mengirimkannya kembali.

Yang satu adalah memori yang Anda beli sebagai perangkat keras. Yang lain adalah memori yang disimpan pihak lain dan disewakan kepada Anda.

Perbedaan praktisnya lebih penting daripada definisinya. Kapasitas cache KV dapat habis. Jika itu terjadi, model gagal dimuat atau permintaan ditolak. Cache prompt tidak dapat habis. Anda hanya dapat gagal memanfaatkannya, lalu tanpa disadari membayar harga penuh.

Isi cache KV dan alasan keberadaannya

Transformer yang menghasilkan token nomor 500 harus melakukan attention terhadap semua 499 token sebelumnya. Untuk setiap token tersebut, setiap layer memerlukan vektor key dan vektor value. Menghitung ulang semuanya untuk setiap token baru akan membuat waktu pembuatan meningkat secara kuadrat terhadap panjang urutan. Karena itu, runtime menyimpannya. Penyimpanan tersebut disebut cache KV (cache key/value).

Cache ini merupakan state per-request karena dibangun dari urutan token persis milik request tersebut. Dua pengguna yang mengirim prompt berbeda tidak dapat berbagi cache ini, kecuali runtime menggunakan prefix caching, yang merupakan fitur terpisah dan dijelaskan nanti.

Serving berlangsung dalam dua fase. Prefill membaca seluruh prompt dan mengisi cache. Proses ini dibatasi oleh compute. Decode menghasilkan satu token setiap kali dan menambahkannya ke cache. Proses ini dibatasi oleh bandwidth memori. Pembagian ini menyebabkan kecepatan pemrosesan prompt dan pembuatan token yang dilaporkan berbeda ketika Anda mengukur token per detik pada server Anda sendiri.

Berapa banyak memori yang digunakan cache KV?

Jangan mencari tabel dari vendor. Ukurannya dapat dihitung ulang secara aritmetis untuk model apa pun:

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

Angka 2 mewakili key dan value. Semua angka lainnya berasal dari config.json model, yang dipublikasikan pada halaman Hugging Face model tersebut.

Gunakan Llama 3.1 8B sebagai contoh. Konfigurasinya mencantumkan num_hidden_layers sebesar 32 dan num_key_value_heads sebesar 8. hidden_size sebesar 4096 yang dibagi ke dalam 32 attention head menghasilkan dimensi head sebesar 128. Pada f16, setiap elemen berukuran 2 byte:

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

Kalikan nilai tersebut dengan context yang diminta, lalu kalikan lagi dengan jumlah request yang dijalankan secara bersamaan.

[
  {
    "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
  }
]

Dengan context sebesar 8k, cache berukuran 1 GiB untuk satu request. Pada 32k, ukurannya 4 GiB, yang berada dalam kisaran yang sama dengan bobot 4-bit itu sendiri. Pada context penuh model sebesar 128k, ukurannya 16 GiB untuk satu request, dan 64 GiB jika empat request masing-masing mengisinya. Bobotnya tidak berubah. Hanya cache yang berubah.

Grouped query attention (GQA) sangat memengaruhi angka tersebut. Llama 3.1 8B memiliki 8 key/value head yang melayani 32 query head, sehingga setiap empat query head berbagi satu pasangan key/value yang disimpan. Model yang num_key_value_heads-nya sama dengan num_attention_heads menggunakan cache empat kali lebih besar pada jumlah parameter yang sama. Periksa field tersebut sebelum menganggap biaya serving dua model 8B sama.

Mengapa model yang berjalan pada 2k menolak dimuat pada 32k

Runtime mengalokasikan KV cache saat model dimuat. Ukurannya mengikuti panjang konteks yang Anda konfigurasi, bukan prompt yang benar-benar dikirim. Ukuran jendela konteks default Ollama adalah 4096 token. Jika Anda menaikkannya menjadi 32k, Anda meminta alokasi tambahan sebesar 4 GiB sebelum satu token pun diterima.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Untuk menerapkan pengaturan yang sama pada setiap sesi, gunakan prompt interaktif berikut:

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

Kegagalan ini terlihat berbeda pada setiap stack. vLLM menghitung kebutuhan memori saat startup lalu menolak 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, pemeriksaan seperti itu tidak ada karena alokasinya menggunakan RAM sistem biasa. Kernel kemudian menjalankan out-of-memory killer terhadap proses tersebut dan meninggalkan buktinya di ring buffer kernel:

dmesg -T | grep -i "killed process"

Baris yang mencantumkan proses serving Anda berarti server meminta memori lebih besar daripada yang tersedia. Solusinya adalah menggunakan konteks yang lebih kecil, bukan file swap yang lebih besar. KV cache yang dipaginasi ke disk harus dibaca pada setiap token yang dihasilkan, sehingga proses generasi melambat hingga tidak berguna. Panduan kami tentang num_ctx dan panjang konteks di Ollama menjelaskan cara memilih nilai yang sesuai: panduan kami tentang num_ctx dan panjang konteks di Ollama.

Dampak konkurensi terhadap jumlah pengguna

Setiap request yang sedang diproses membawa KV cache-nya sendiri. Inilah faktor yang sering terlewat dalam perencanaan kapasitas. Empat pengguna yang masing-masing mempertahankan konteks 32k membutuhkan 16 GiB secara total, di luar bobot model.

Setiap runtime menerapkan aturan yang berbeda. Ollama dan llama.cpp mencadangkan konteks yang Anda minta saat model dimuat. Jadi, memori tersebut tetap dialokasikan meskipun tidak ada yang menggunakannya. vLLM membagi pool menjadi blok berukuran tetap dan membagikannya saat setiap request bertambah besar. Karena itu, request berisi 500 token hanya menahan ruang untuk 500 token. Bagaimanapun, ukuran pool tetap terbatas. Setelah penuh, request baru masuk antrean dan tidak langsung diproses. Dampak antrean tersebut terhadap waktu respons dibahas dalam berapa banyak pengguna konkuren yang dapat dilayani LLM yang di-host sendiri.

Empat cara mengurangi ukuran cache KV

1. Kurangi panjang konteks. Ini adalah pengungkit terbesar dan biasanya paling murah. Sebagian besar beban kerja chat tidak pernah mendekati 32k.
2. Kuantisasi cache itu sendiri. OLLAMA_KV_CACHE_TYPE milik Ollama secara default menggunakan f16 dan menerima q8_0, yang menggunakan sekitar setengah memori, serta q4_0, yang menggunakan sekitar seperempatnya. Padanan di llama.cpp adalah -ctk q8_0 dan -ctv q8_0.
3. Pilih model dengan jumlah key/value head atau layer yang lebih sedikit. Baca config.json sebelum mengunduh weight berukuran 40 GB.
4. Layani lebih sedikit request sekaligus dan antrekan sisanya.

Pada q4_0, angka untuk Llama 3.1 8B turun dari 128 KiB per token menjadi sekitar 32 KiB. Dengan demikian, konteks 32k memerlukan sekitar 1 GiB, bukan 4 GiB. Penghematan ini tidak gratis. Key dan value disimpan dengan presisi yang lebih rendah. Karena itu, bandingkan output menggunakan prompt Anda sendiri sebelum mempertahankan pengaturan tersebut.

Manfaat nyata caching prompt dari provider

Caching prompt dari provider adalah produk yang berbeda dengan satuan biaya yang berbeda. Anda menandai prefix yang stabil, provider menyimpannya, lalu panggilan berikutnya yang mengulang prefix tersebut secara persis ditagihkan dengan tarif lebih rendah, bukan dengan harga input penuh.

Pengali yang dipublikasikan Anthropic, per Agustus 2026: penulisan cache 5 menit dikenai biaya 1.25 kali harga token input dasar. Penulisan cache 1 jam dikenai biaya 2 kali, sedangkan pembacaan cache dikenai biaya 0.1 kali. Jika system prompt 20,000 token menggunakan skema tersebut, pola biayanya 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 perhitungannya sebagai aritmetika. Premium penulisan 5 menit setara dengan 5,000 token pada panggilan pertama: 25,000 dibandingkan dengan 20,000 jika dikirim tanpa cache. Setiap panggilan berikutnya dalam periode tersebut ditagihkan 2,000, bukan 20,000, sehingga menghemat 18,000. Jadi, cache 5 menit sudah lebih hemat mulai panggilan kedua.

Cache 1 jam adalah pilihan yang berbeda. Penulisannya ditagihkan 40,000, dengan premium sebesar 20,000 token. Karena itu, cache tersebut memerlukan dua hit dalam satu jam agar mulai lebih hemat. Ini bergantung pada pola trafik Anda, bukan pada model. Perhitungan lengkap, termasuk cara memilih durasi cache, tersedia di perhitungan titik impas caching prompt Claude.

Dua hal menentukan apakah cache dapat digunakan. Pertama, prefix yang lebih pendek dari panjang minimum model tidak akan disimpan di cache secara diam-diam. Per Agustus 2026, panjang minimum yang didokumentasikan adalah 512 token untuk Claude Opus 5 dan 1,024 token untuk Claude Sonnet 5. Request yang lebih pendek diproses secara normal tanpa mengembalikan error. Kedua, masa berlaku dihitung sejak awal request yang menulis atau membaca entri tersebut, dan setiap pembacaan memperbarui masa berlaku tanpa biaya tambahan. Karena itu, endpoint yang sibuk dapat mempertahankan cache 5 menit tanpa batas waktu. Endpoint yang dipanggil sekali setiap sepuluh menit membayar premium penulisan setiap kali dan tidak pernah memperoleh manfaat dari cache.

Periksa responsnya, jangan hanya berasumsi. Objek usage melaporkan cache_creation_input_tokens dan cache_read_input_tokens. Jumlah pembacaan yang selalu nol pada setiap panggilan berarti Anda membayar penulisan cache tetapi tidak memperoleh hasilnya.

Tempat kedua cache bersinggungan

System prompt yang panjang adalah titik pertemuannya, dan biayanya dibebankan pada kedua sisi sekaligus.

Di lokal, system prompt sepanjang 20,000 token menggunakan sekitar 2.4 GiB KV cache pada server Llama 3.1 8B dengan f16. Penggunaan ini terjadi secara terpisah untuk setiap request bersamaan yang menyertakannya. Di sisi remote, prefix yang sama memerlukan satu penulisan cache, lalu biayanya menjadi 0.1 kali input pada setiap pemanggilan berikutnya. Biaya lokal bertambah seiring jumlah pengguna. Biaya remote bertambah seiring trafik dan direset selama periode tidak aktif.

Ada fitur lokal yang terlihat seperti provider prompt caching dan sering tertukar dengannya: prefix caching. Dokumentasi vLLM menjelaskan automatic prefix caching sebagai caching “KV cache dari query yang sudah ada, sehingga query baru dapat langsung menggunakan kembali KV cache jika memiliki prefix yang sama dengan salah satu query yang sudah ada”. Server llama.cpp secara default menyimpan prompt cache untuk setiap slot, dan --cache-reuse N menetapkan ukuran chunk terkecil yang akan dicoba untuk digunakan kembali.

Prefix caching menghemat komputasi prefill. System prompt sepanjang 20,000 token diproses satu kali, bukan pada setiap request, sehingga time to first token berkurang secara signifikan. Di vLLM, block yang digunakan bersama dipakai kembali, bukan diduplikasi, sehingga penggunaan memori juga membaik. Namun, fitur ini tidak pernah mengurangi cache yang harus Anda pertahankan untuk token yang sedang aktif. Mempertahankan weights di memori antara request adalah mekanisme terkait, tetapi terpisah, yang dibahas dalam mempertahankan model Ollama tetap dimuat di antara request.

Apa yang perlu diukur pada server Anda sendiri

Muat model dengan context target, lalu baca angka aktual alih-alih mengandalkan estimasi.

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

ollama ps menampilkan model yang dimuat beserta ukurannya dan informasi apakah model berjalan pada GPU atau CPU. Jika model yang seharusnya sepenuhnya berada di GPU melaporkan pembagian ke CPU, berarti KV cache mendorong sebagian model keluar dari GPU, sehingga kecepatan generasi akan menurun. nvidia-smi memberikan angka VRAM yang sebenarnya, sedangkan free -g menjalankan fungsi yang sama pada VPS yang hanya menggunakan CPU. Tingkatkan context secara bertahap, muat ulang model, lalu pantau perubahan angkanya. Hasil perhitungan Anda dan angka yang dilaporkan seharusnya hampir sama. Jika tidak, selisih tersebut biasanya berasal dari buffer komputasi milik runtime, bukan kesalahan dalam rumus.

Jika angka-angka tersebut membuat Anda mempertimbangkan hardware yang tidak ingin Anda sewa, perbandingan dengan biaya pembayaran per token dibahas dalam GPU VPS dibandingkan dengan token API.

FAQ

Apakah KV cache sama dengan prompt caching?

Tidak. KV cache adalah memori per permintaan di dalam proses serving yang menyimpan vektor key dan value untuk setiap token dalam konteks saat ini. Cache ini berada di RAM atau VRAM dan dilepaskan ketika permintaan berakhir. Prompt caching dari provider adalah fitur penagihan yang menyimpan prefix prompt yang stabil pada infrastruktur provider dan mengenakan tarif lebih rendah saat Anda mengirimkannya lagi. Kehabisan KV cache membuat model gagal dimuat. Cache prompt yang tidak tersedia hanya meningkatkan tagihan dan waktu hingga token pertama.

Mengapa model saya dapat dimuat pada konteks 2k, tetapi gagal pada 32k?

Karena runtime mengalokasikan seluruh KV cache saat memuat model. Ukurannya ditentukan oleh panjang konteks yang Anda konfigurasi, bukan oleh prompt yang Anda kirim. Untuk Llama 3.1 8B pada f16, cache membutuhkan 128 KiB per token. Dengan demikian, konteks 2k membutuhkan 0.25 GiB dan 32k membutuhkan 4 GiB. Bobot model muat dalam kedua kasus tersebut. Reservasi cache yang gagal. vLLM melaporkannya sebagai ValueError yang mencantumkan jumlah maksimum token yang dapat disimpan, serta menyarankan Anda menaikkan gpu_memory_utilization atau menurunkan max_model_len. Pada mesin yang hanya menggunakan CPU, kernel out-of-memory killer justru menghentikan proses. Anda dapat mengonfirmasinya dengan dmesg -T | grep -i "killed process".

Bagaimana cara menghitung ukuran KV cache untuk model saya?

Kalikan 2 dengan jumlah layer, jumlah head key/value, dimensi head, dan jumlah byte per elemen. Hasilnya adalah jumlah byte per token. Selanjutnya, kalikan hasil tersebut dengan panjang konteks dan jumlah permintaan yang berjalan secara bersamaan. Baca jumlah layer dan head dari config.json milik model. Gunakan 2 byte per elemen untuk f16 atau bf16. Cache q8_0 berukuran kira-kira setengahnya, sedangkan q4_0 berukuran kira-kira seperempatnya.

Apakah prompt caching mengurangi memori yang dibutuhkan server saya?

Prompt caching dari provider tidak memengaruhi hardware Anda karena penyimpanannya berada di sisi provider. Padanan lokalnya adalah prefix caching, yang tersedia pada vLLM dan server llama.cpp. Fitur ini menggunakan kembali vektor key dan value yang telah dihitung untuk prefix bersama. Dengan demikian, kebutuhan komputasi prefill berkurang dan waktu hingga token pertama menjadi lebih singkat. Pada vLLM, blok yang sama digunakan kembali, bukan diduplikasi, sehingga penggunaan memori juga membaik. Namun, kedua fitur tersebut tidak mengurangi cache yang diperlukan untuk token yang sedang diproses. Karena itu, perhitungan konteks dan konkurensi tetap menentukan kebutuhan minimum.

Apakah layak melakukan caching pada prompt yang hanya saya kirim sekali?

Tidak. Penulisan cache lebih mahal daripada input biasa. Untuk opsi 5-minute, tarifnya adalah 1.25 kali tarif dasar per August 2026. Jadi, prefix yang tidak pernah Anda kirim ulang dalam periode tersebut hanya menambah biaya. Caching bermanfaat ketika prefix yang sama dikirim berulang kali, misalnya system prompt yang panjang atau dokumen yang akan Anda gunakan untuk mengajukan beberapa pertanyaan. Periksa cache_read_input_tokens dalam respons API untuk memastikan cache hit terjadi, bukan biaya penulisan yang terus dikenakan.