KV Cache vs Prompt Cache: Ano ang Pagkakaiba?

KV cache kumpara sa prompt cache: ang maikling sagot

Magkapareho lamang ng isang salita ang KV cache at prompt cache ng provider, at halos wala nang iba. Ang KV cache ay working memory para sa bawat request. Nasa RAM o VRAM ito ng server sa buong tagal ng isang request. Lumalaki ito batay sa context length at sa dami ng sabay-sabay na request. Ang prompt caching ng provider ay feature para sa billing at latency. Iniimbak sa mga server ng provider ang stable prefix ng prompt mo. Kapag ipinadala mo itong muli, sisingilin ito sa mas mababang rate.

Ang isa ay memory na binibili mo bilang hardware. Ang isa naman ay memory na hinahawakan ng ibang partido at sinisingil ka para sa paggamit nito.

Mas mahalaga sa praktikal na paggamit ang pagkakaiba kaysa sa depinisyon. Maaaring maubusan ka ng KV cache. Kapag nangyari ito, hindi maglo-load ang model o tatanggihan ang request. Hindi ka maaaring maubusan ng prompt cache. Maaari lamang itong hindi ma-hit. Kapag nangyari iyon, tahimik kang sisingilin sa buong presyo.

Ano ang nilalaman ng KV cache, at bakit ito umiiral

Kapag bumubuo ang isang transformer ng token number 500, kailangan nitong mag-attend sa lahat ng 499 token bago nito. Para sa bawat token na iyon, kailangan ng bawat layer ang key vector at value vector. Kung muling kukuwentahin ang lahat ng ito sa bawat bagong token, lalago ang tagal ng generation kasabay ng square ng haba. Kaya naman iniimbak na lamang ito ng runtime. Ang imbakan na iyon ang KV cache (key/value cache).

Per-request state ito dahil binubuo ito mula sa eksaktong token sequence ng request na iyon. Hindi maaaring mag-share nito ang dalawang user na nagpapadala ng magkaibang prompt, maliban kung gumagamit ang runtime ng prefix caching. Hiwalay na feature ito na ilalarawan sa susunod.

May dalawang phase ang serving. Binabasa ng prefill ang buong prompt at pinupuno ang cache. Limitado ito ng compute. Gumagawa ang decode ng tig-isang token at idinadagdag ito sa cache. Limitado naman ito ng memory bandwidth. Dahil sa paghahating ito, magkaiba ang speed na iniuulat para sa prompt processing at token generation kapag sinukat mo ang tokens per second sa sarili mong box.

Gaano karaming memory ang ginagamit ng KV cache?

Huwag maghanap ng vendor table. Arithmetic ang tumutukoy sa laki nito at maaari mo itong kalkulahin para sa anumang model:

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

Ang 2 ay para sa key at value. Ang lahat ng iba pang numero ay mula sa config.json ng model, na naka-publish sa Hugging Face page ng model.

Gamitin ang Llama 3.1 8B bilang halimbawa. Nakalista sa config nito ang num_hidden_layers na 32 at num_key_value_heads na 8. Ang hidden_size na 4096 na hinati sa 32 attention heads ay nagbibigay ng head dimension na 128. Sa f16, 2 bytes ang bawat element:

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

I-multiply ito sa context na hinihingi mo, pagkatapos ay i-multiply sa bilang ng requests na sabay-sabay mong pinapatakbo.

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

Sa 8k na context, 1 GiB ang cache para sa isang request. Sa 32k, 4 GiB ito, na nasa kaparehong range ng mismong 4-bit weights. Sa buong 128k context ng model, 16 GiB ito para sa isang request, at 64 GiB kung apat na request ang bawat isa ay pumupuno rito. Hindi nagbago ang weights. Cache lamang ang nagbago.

Malaki ang epekto ng grouped query attention (GQA) sa numerong ito. May 8 key/value heads ang Llama 3.1 8B na nagsisilbi sa 32 query heads, kaya apat na query head ang nagbabahagi ng isang naka-store na key/value pair. Ang model na ang num_key_value_heads ay katumbas ng num_attention_heads ay gumagamit ng apat na beses na mas malaking cache sa parehong parameter count. Suriin ang field na iyon bago ipagpalagay na pareho ang serving cost ng dalawang 8B model.

Bakit tumatakbo ang isang model sa 2k pero ayaw mag-load sa 32k

Nagre-reserve ang runtime ng KV cache kapag naglo-load ang model. Ang laki nito ay batay sa context length na iyong na-configure, hindi sa prompt na aktuwal mong ipinapadala. Ang default context window ng Ollama ay 4096 tokens. Kapag itinaas mo ito sa 32k, humihingi ka ng 4 GiB na karagdagang allocation bago dumating ang kahit isang token.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Pareho ang setting para sa bawat session mula sa interactive prompt:

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

Magkakaiba ang anyo ng failure sa bawat stack. Kinakalkula ng vLLM ang mga value sa startup at tumatangging tumakbo:

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.

Sa CPU-only VPS, walang ganitong check dahil ordinaryong system RAM ang ginagamit sa allocation. Sa halip, kinukuha ng kernel's out-of-memory killer ang process, at iniiwan nito ang ebidensiya sa kernel ring buffer:

dmesg -T | grep -i "killed process"

Kapag binanggit sa isang linya ang serving process mo, nangangahulugan itong nangako ang server ng mas maraming memory kaysa sa mayroon ito. Ang tamang ayos ay mas maliit na context, hindi mas malaking swap file: binabasa ang KV cache na naka-page sa disk sa bawat generated token, kaya bumabagal ang generation hanggang sa maging hindi na praktikal gamitin. Tinalakay sa aming gabay sa num_ctx at context length sa Ollama kung paano pumili ng makatwirang value.

Ano ang epekto ng concurrency sa bilang

May sariling KV cache ang bawat kasalukuyang request. Ito ang madalas na hindi nasasama sa capacity plan. Ang apat na user na bawat isa ay may 32k na context ay nangangailangan ng 16 GiB sa kabuuan, bukod pa sa weights.

Nagkakaiba ang mga runtime sa kung gaano kahigpit ang requirement na ito. Inilalaan ng Ollama at llama.cpp ang context na itinakda mo kapag nag-load ang model, kaya committed ang memory kahit walang gumagamit nito. Hinahati naman ng vLLM ang pool sa mga block na may fixed size at ipinapamahagi ang mga ito habang lumalaki ang bawat request, kaya ang request na may 500 token ay 500 token lang ang ginagamit na katumbas na espasyo. Sa alinmang paraan, may limitasyon ang pool. Kapag puno na ito, pumipila ang mga bagong request sa halip na tumakbo. Ipinaliliwanag sa kung ilang sabay-sabay na user ang kayang i-serve ng self-hosted LLM kung paano naaapektuhan ng pag-pila ang response time.

Apat na paraan para paliitin ang KV cache

1. Bawasan ang context length. Ito ang pinakamalaking lever at kadalasan ang pinakamurang hakbang. Karamihan sa chat workload ay hindi umaabot sa 32k.
2. I-quantise mismo ang cache. Ang OLLAMA_KV_CACHE_TYPE ng Ollama ay naka-default sa f16 at tumatanggap ng q8_0, na gumagamit ng humigit-kumulang kalahati ng memory, at q4_0, na gumagamit ng humigit-kumulang isang-kapat. Ang katumbas sa llama.cpp ay -ctk q8_0 at -ctv q8_0.
3. Pumili ng model na may mas kaunting key/value head o mas kaunting layer. Basahin ang config.json bago mag-download ng 40 GB na weights.
4. Mas kaunting request ang i-serve nang sabay at i-queue ang iba.

Sa q4_0, bumababa ang figure para sa Llama 3.1 8B mula 128 KiB bawat token tungo sa humigit-kumulang 32 KiB. Dahil dito, ang 32k na context ay kumokonsumo ng humigit-kumulang 1 GiB sa halip na 4 GiB. Hindi libre ang pagtitipid na ito. Mas mababa ang precision ng pagkaka-store ng keys at values, kaya ikumpara muna ang output sa sarili mong prompts bago mo ito gamitin nang permanente.

Ano talaga ang napapala sa provider prompt caching

Ibang product ang provider prompt caching, at iba rin ang unit of account nito. Minamarkahan mo ang isang stable prefix, iniimbak ito ng provider, at ang mga susunod na call na eksaktong umuulit sa parehong prefix ay sinisingil sa mas mababang rate sa halip na sa buong input price.

Ang mga multiplier na inilathala ng Anthropic, noong August 2026: ang 5-minute cache write ay nagkakahalaga ng 1.25 times ng base input token price. Ang 1-hour write ay nagkakahalaga ng 2 times, at ang cache read ay nagkakahalaga ng 0.1 times. Kapag inilagay mo sa mga numerong ito ang 20,000-token system prompt, malinaw agad ang pakinabang.

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

Basahin ito bilang arithmetic. Ang premium ng 5-minute write ay katumbas ng 5,000 token equivalents sa unang call: 25,000 kumpara sa 20,000 kung ipapadala ito nang walang cache. Sa bawat susunod na call sa loob ng window, 2,000 ang sisingilin sa halip na 20,000, kaya 18,000 ang matitipid. Dahil dito, lamang na ang 5-minute cache mula sa ikalawang call.

Ibang trade-off ang 1-hour cache. 40,000 ang sisingilin sa write, na may premium na 20,000 token equivalents, kaya kailangan nito ng dalawang hit sa loob ng isang oras bago ito maging mas sulit. Nakadepende ito sa traffic pattern mo, hindi sa model. Nasa break-even math para sa Claude prompt caching ang buong calculation, pati kung paano piliin ang window.

Dalawang detalye ang nagtatakda kung magagamit mo ang cache. Una, tahimik na hindi kino-cache ang prefix na mas maikli sa minimum length ng model: noong August 2026, ang documented minimum ay 512 tokens para sa Claude Opus 5 at 1,024 tokens para sa Claude Sonnet 5, at normal na pino-process ang mas maikling request nang walang ibinabalik na error. Ikalawa, sinusukat ang lifetime mula sa pagsisimula ng request na nagsusulat o nagbabasa sa entry, at nire-refresh ito ng bawat read nang walang dagdag na cost. Kaya kayang panatilihing buhay ng busy endpoint ang 5-minute cache nang walang takdang katapusan. Ang endpoint na tinatawagan isang beses bawat ten minutes ay nagbabayad ng write premium sa bawat pagkakataon at walang nakokolektang pakinabang.

Suriin ang response sa halip na basta ipagpalagay. Iniuulat ng usage object ang cache_creation_input_tokens at cache_read_input_tokens. Kung zero ang read count sa bawat call, nagbabayad ka para sa writes pero walang nakukuhang resulta.

Kapag nagtagpo ang dalawang cache

Ang mahabang system prompt ang lugar kung saan sila nagtatagpo, at sabay ka nitong sinisingil sa magkabilang panig.

Sa local na setup, ang 20,000-token system prompt ay kumokonsumo ng humigit-kumulang 2.4 GiB ng KV cache sa isang Llama 3.1 8B server na gumagamit ng f16. Ginagawa ito nang hiwalay para sa bawat concurrent request na kasama ang prompt. Sa remote na setup, ang parehong prefix ay nagkakahalaga ng isang cache write, at pagkatapos ay 0.1 beses ng input sa bawat kasunod na call. Ang local na gastos ay lumalaki kasabay ng bilang ng users. Ang remote na gastos ay lumalaki kasabay ng traffic at nagre-reset kapag idle ka.

May isang local feature na kahawig ng provider prompt caching at madalas napagkakamalan dito: prefix caching. Inilalarawan ng vLLM documentation ang automatic prefix caching bilang pag-cache ng “KV cache ng mga dati nang query, upang direktang magamit muli ng isang bagong query ang KV cache kapag pareho ang prefix nito sa isa sa mga dati nang query.” Bilang default, may prompt cache ang llama.cpp server para sa bawat slot, at ang --cache-reuse N ang nagtatakda ng pinakamaliit na chunk na susubukan nitong gamitin muli.

Ang nai-save ng prefix caching ay prefill compute. Pinoproseso nang isang beses ang iyong 20,000-token system prompt sa halip na sa bawat request, kaya malaki ang ibinababa nito sa time to first token. Sa vLLM, ginagamit muli ang mga shared block sa halip na gumawa ng duplicate, kaya gumaganda rin ang memory usage. Ngunit hindi nito kailanman binabawasan ang cache na kailangan mong panatilihin para sa mga token na kasalukuyang live. Ang pagpapanatiling naka-resident ng weights sa pagitan ng mga request ay kaugnay ngunit hiwalay na paraan, na saklaw sa pananatiling naka-load ng Ollama model sa pagitan ng mga request.

Ano ang susukatin sa sarili mong box

I-load ang model sa target context mo, pagkatapos ay basahin ang aktuwal na mga numero sa halip na umasa sa estimate.

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

Inililista ng ollama ps ang naka-load na model, kasama ang laki nito at kung tumatakbo ito sa GPU o CPU. Kung inaasahan mong ganap na nasa GPU ang isang model pero may iniuulat itong CPU split, nangangahulugan itong may bahagi ng model na itinulak palabas ng KV cache. Bumababa dahil dito ang generation speed. Ibinibigay ng nvidia-smi ang aktuwal na VRAM figure, at pareho ang ginagawa ng free -g para sa CPU-only VPS. Itaas ang context nang paunti-unti, i-reload ang model, at obserbahan kung paano nagbabago ang numero. Dapat magkalapit ang resulta ng arithmetic mo at ang iniulat na figure. Kapag hindi sila magkatugma, karaniwang ang agwat ay dahil sa sariling compute buffers ng runtime, hindi dahil may mali sa formula.

Kung itinutulak ka ng mga numerong iyon patungo sa hardware na mas gugustuhin mong huwag rentahan, makikita ang paghahambing sa pagbabayad per token sa GPU VPS kumpara sa API tokens.

FAQ

Ang KV cache ba ay kapareho ng prompt caching?

Hindi. Ang KV cache ay memory na ginagamit ng bawat request sa loob ng serving process. Hawak nito ang key at value vectors para sa bawat token sa kasalukuyang context. Nasa RAM o VRAM ito at nire-release kapag natapos ang request. Ang provider prompt caching ay isang billing feature. Nag-iimbak ito ng stable prompt prefix sa infrastructure ng provider at nagbibigay ng mas mababang singil kapag ipinadala mo itong muli. Kapag naubusan ng KV cache, hindi maglo-load ang model. Kapag walang prompt cache hit, tataas lamang ang invoice at time to first token.

Bakit naglo-load ang model ko sa 2k context pero nagfa-fail sa 32k?

Dahil inilalaan ng runtime ang buong KV cache sa oras ng pag-load. Nakabatay ang laki nito sa context length na iyong na-configure, hindi sa prompt na ipinapadala mo. Para sa Llama 3.1 8B sa f16, 128 KiB ang cache bawat token. Kaya ang 2k context ay nangangailangan ng 0.25 GiB, habang ang 32k ay nangangailangan ng 4 GiB. Kasya ang weights sa parehong configuration. Ang reservation ang nagfa-fail. Iniuulat ito ng vLLM bilang ValueError, na nagsasaad ng maximum na bilang ng token na maiimbak nito. Iminumungkahi rin nitong taasan ang gpu_memory_utilization o ibaba ang max_model_len. Sa CPU-only box, ang kernel out-of-memory killer naman ang kumikitil sa process. Makukumpirma mo ito gamit ang dmesg -T | grep -i "killed process".

Paano ko kakalkulahin ang laki ng KV cache para sa model ko?

I-multiply ang 2 sa bilang ng layers, bilang ng key/value heads, head dimension, at bytes per element. Makukuha nito ang bytes bawat token. Pagkatapos, i-multiply ito sa context length at sa bilang ng sabay-sabay na request. Kunin ang bilang ng layers at heads mula sa config.json ng model. Gumamit ng 2 bytes bawat element para sa f16 o bf16. Ang q8_0 cache ay humigit-kumulang kalahati nito, at ang q4_0 ay humigit-kumulang isang-kapat.

Nakababawas ba ang prompt caching sa memory na kailangan ng sarili kong server?

Walang epekto ang provider prompt caching sa hardware mo dahil nasa panig ng provider ang storage. Ang lokal na katumbas nito ay prefix caching, na iniaalok ng vLLM at ng llama.cpp server. Ginagamit nitong muli ang mga key at value vector na nakalkula na para sa shared prefix. Nakatitipid ito sa prefill compute at nagpapababa ng time to first token. Sa vLLM, ginagamit muli ang shared blocks sa halip na gumawa ng duplicate, kaya gumaganda rin ang memory usage. Hindi binabawasan ng alinmang feature ang cache na kailangan para sa mga token na kasalukuyang pinoproseso. Kaya ang context at concurrency arithmetic pa rin ang nagtatakda ng minimum na kailangan.

Sulit bang i-cache ang prompt na isang beses ko lang ipapadala?

Hindi. Mas mahal ang cache write kaysa sa plain input. 1.25 times ng base rate ang singil para sa 5-minute option noong August 2026. Kaya kung hindi mo na muling ipapadala ang prefix sa loob ng window, tuwirang lugi ito. Sulit ang caching kapag nauulit ang parehong prefix, gaya ng mahabang system prompt o dokumentong pagtatanungan mo ng ilang tanong. Suriin ang cache_read_input_tokens sa API response upang makumpirmang cache hits ang nakukuha mo sa halip na nagbabayad para sa mga write.