Tofauti kati ya KV cache na prompt cache

KV cache dhidi ya prompt cache: jibu fupi

KV cache na prompt cache ya mtoa huduma hushirikiana neno moja tu, lakini kimsingi ni vitu tofauti. KV cache ni kumbukumbu ya kazi kwa kila ombi (request). Hukaa kwenye RAM au VRAM ya seva yako kwa muda wote wa ombi moja, na hukua kulingana na urefu wa muktadha (context length) na idadi ya maombi unayoendesha kwa wakati mmoja. Prompt caching ya mtoa huduma ni kipengele cha malipo na latency. Kiambishi awali (prefix) kisichobadilika cha prompt yako huhifadhiwa kwenye seva za mtoa huduma, kisha hutozwa kwa punguzo unapoituma tena.

Moja ni kumbukumbu unayonunua kama maunzi (hardware). Nyingine ni kumbukumbu inayoshikiliwa na mtu mwingine na unalipia kodi.

Tofauti ya kivitendo ni muhimu zaidi kuliko ufafanuzi. Unaweza kuishiwa na KV cache, na ikitokea hivyo, modeli inakataa kupakia au ombi linakataliwa. Huwezi kuishiwa na prompt cache. Unachoweza kufanya ni kushindwa kuitumia (miss), na hapo utalipia bei kamili kimya kimya.

Yaliyomo kwenye KV cache na sababu ya kuwepo kwake

Transformer inayozalisha token namba 500 inapaswa kufanya attention kwa token zote 499 zilizotangulia. Kwa kila moja ya token hizo, kila layer inahitaji key vector na value vector. Kuhesabu upya vector zote hizo kwa kila token mpya kungeifanya kasi ya uzalishaji ikue kwa mraba wa urefu wa mlolongo, hivyo runtime huzihifadhi badala ya kuzihesabu upya. Hifadhi hiyo ndiyo KV cache (key/value cache).

Hali hii ni ya kila ombi (per-request state) kwa sababu inajengwa kutokana na mlolongo kamili wa token za ombi husika. Watumiaji wawili wanaotuma prompt tofauti hawawezi kushiriki cache hiyo, isipokuwa kama runtime inatumia prefix caching, ambayo ni kipengele tofauti kitakachoelezwa baadaye.

Utoaji huduma hufanyika katika hatua mbili. Prefill inasoma prompt yako yote na kujaza cache, na hatua hii inategemea uwezo wa kompyuta (compute-bound). Decode inazalisha token moja kwa wakati mmoja na kuiongeza kwenye cache, na hatua hii inategemea kasi ya memory bandwidth (memory-bound). Mgawanyo huu ndio sababu ya uchakataji wa prompt na uzalishaji wa token kuripoti kasi tofauti unapofanya kupima token kwa sekunde kwenye seva yako.

Kumbukumbu kiasi gani hutumiwa na KV cache?

Usitafute jedwali la muuzaji. Ukubwa huu ni hesabu unayoweza kuifanya upya kwa modeli yoyote:

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

Namba 2 inawakilisha key na value. Namba nyingine zote zinatokana na config.json ya modeli, iliyochapishwa kwenye ukurasa wa Hugging Face wa modeli hiyo.

Chukua Llama 3.1 8B. Usanidi wake unaonyesha num_hidden_layers 32 na num_key_value_heads 8. hidden_size ya 4096 iliyogawanywa katika attention heads 32 inatoa head dimension ya 128. Kwa f16, kila kipengele ni baiti 2:

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

Zidisha hiyo kwa context unayoomba, kisha kwa maombi unayoyafanya kwa wakati mmoja.

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

Katika context ya 8k, cache ni 1 GiB. Katika 32k ni 4 GiB, ambayo iko katika kiwango sawa na uzito wa 4-bit wenyewe. Katika context kamili ya 128k ya modeli, ni 16 GiB kwa ombi moja, na 64 GiB ikiwa maombi manne yataijaza yote. Uzito haukubadilika kamwe. Cache pekee ndiyo iliyobadilika.

Grouped query attention (GQA) inafanya kazi kubwa katika namba hiyo. Llama 3.1 8B ina 8 key/value heads zinazohudumia 32 query heads, kwa hivyo query heads nne zinashiriki jozi moja ya key/value iliyohifadhiwa. Modeli ambayo num_key_value_heads yake ni sawa na num_attention_heads yake hutumia cache mara nne zaidi kwa idadi sawa ya vigezo (parameters). Hakiki sehemu hiyo moja kabla ya kudhani kuwa modeli mbili za 8B zina gharama sawa ya kuhudumia.

Kwa nini modeli iliyofanya kazi kwa 2k inakataa kupakia kwa 32k

Hii ni kwa sababu runtime hutenga KV cache wakati modeli inapopakia, ikiwa na ukubwa wa context length uliyosanidi, si kwa ajili ya prompt unayotuma. Dirisha la context chaguo-msingi la Ollama ni 4096 tokens. Ukiliongeza hadi 32k, utakuwa umeomba 4 GiB ya nafasi ya ziada kabla ya token yoyote kufika.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Mpangilio uleule kwa kila session, kutoka kwenye interactive prompt:

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

Kushindwa huku kunaonekana kwa namna tofauti kwenye kila stack. vLLM hukagua hesabu wakati wa kuanza na kukataa kufanya kazi:

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.

Kwenye VPS inayotumia CPU pekee, hakuna ukaguzi wa aina hiyo, kwa sababu utengaji huo ni wa RAM ya kawaida ya mfumo. Utaratibu wa kernel wa out-of-memory killer huiondoa process hiyo, na huacha ushahidi kwenye kernel ring buffer:

dmesg -T | grep -i "killed process"

Mstari unaotaja process yako ya kuhudumia unamaanisha kuwa seva iliahidi kumbukumbu zaidi ya ile iliyokuwa nayo. Suluhisho ni context ndogo, si faili kubwa ya swap: KV cache inayohamishiwa kwenye diski husomwa kila token inayozalishwa, hivyo uzalishaji hupungua kasi hadi kufikia hatua ya kutokuwa na manufaa. Kuchagua namba inayofaa kunaelezwa katika mwongozo wetu kuhusu num_ctx na context length katika Ollama.

Athari za concurrency kwenye namba

Kila ombi linalochakatwa hubeba KV cache yake yenyewe. Hiyo ndiyo hoja ambayo mipango mingi ya uwezo wa seva huikosa. Watumiaji wanne, kila mmoja akiwa na 32k ya context, wanahitaji 16 GiB kwa pamoja, juu ya uzito wa model (weights).

Runtime hutofautiana katika jinsi zinavyotekeleza hili. Ollama na llama.cpp hutenga context uliyoomba wakati model inapopakiwa, hivyo kumbukumbu hutengwa iwe inatumiwa au la. vLLM hugawa pool katika vitalu vya ukubwa maalum na kuvitoa kadiri ombi linavyokua, hivyo ombi la token 500 hushikilia nafasi ya token 500 pekee. Kwa vyovyote vile, pool ina ukomo, na ikijaa, maombi mapya huingia kwenye foleni badala ya kuchakatwa. Athari za foleni hiyo kwenye muda wa majibu zimefafanuliwa katika idadi ya watumiaji wa wakati mmoja ambayo LLM inayojiendesha inaweza kuhudumia.

Njia nne za kupunguza ukubwa wa KV cache

1. Punguza urefu wa context (context length). Hii ndiyo njia kuu na kwa kawaida ndiyo ya gharama nafuu zaidi. Mizigo mingi ya kazi ya chat haifikii hata 32k.
2. Fanya quantisation ya cache yenyewe. OLLAMA_KV_CACHE_TYPE ya Ollama hutumia f16 kama chaguo-msingi na inakubali q8_0, ambayo hutumia takriban nusu ya kumbukumbu, na q4_0, ambayo hutumia robo moja. Vifaa sawa vya llama.cpp ni -ctk q8_0 na -ctv q8_0.
3. Chagua model yenye vichwa (heads) vichache vya key/value au tabaka (layers) chache. Soma config.json kabla ya kupakua GB 40 za weights.
4. Hudumia maombi machache kwa wakati mmoja na uweke mengine kwenye foleni.

Katika q4_0, takwimu ya Llama 3.1 8B inashuka kutoka 128 KiB kwa kila token hadi takriban 32 KiB, kwa hivyo 32k ya context inagharimu takriban 1 GiB badala ya 4 GiB. Akiba hiyo haiji bure. Keys na values huhifadhiwa kwa usahihi mdogo, kwa hivyo linganisha matokeo (output) kwa kutumia prompts zako mwenyewe kabla ya kuamua kuitumia.

Faida halisi ya prompt caching ya mtoa huduma

Prompt caching ya mtoa huduma ni bidhaa tofauti yenye kipimo tofauti cha gharama. Unaweka alama kwenye prefix thabiti, mtoa huduma anaihifadhi, na maombi ya baadaye yanayorudia prefix hiyo hiyo kikamilifu yanatozwa kwa bei iliyopunguzwa badala ya bei kamili ya input.

Viwanda vya Anthropic vilivyochapishwa, kufikia Agosti 2026: uandishi wa cache wa dakika 5 unagharimu mara 1.25 ya bei ya msingi ya input token. Uandishi wa saa 1 unagharimu mara 2, na usomaji wa cache unagharimu mara 0.1. Weka system prompt ya token 20,000 nyuma ya namba hizo na muundo wa dili utakuwa wazi.

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

Isome kama hesabu. Ziada ya uandishi wa dakika 5 ni sawa na token 5,000 kwenye ombi la kwanza: 25,000 dhidi ya 20,000 kwa kuituma bila cache. Kila ombi la baadaye ndani ya muda huo linatozwa 2,000 badala ya 20,000, ikiwa ni akiba ya 18,000. Kwa hiyo, cache ya dakika 5 inaanza kuleta faida kuanzia ombi la pili na kuendelea.

Cache ya saa 1 ni dau tofauti. Inatoza 40,000 wakati wa uandishi, ziada ya token 20,000, kwa hivyo inahitaji maombi mawili ndani ya saa hiyo ili ianze kuleta faida. Hili ni swali kuhusu mtiririko wako wa traffic, si kuhusu model. Hesabu kamili, ikijumuisha jinsi ya kuchagua muda wa cache, iko kwenye hesabu ya break-even kwa Claude prompt caching.

Maelezo mawili huamua kama utafanikiwa kutumia cache au la. Kwanza, prefix iliyo chini ya urefu wa chini kabisa wa model haihifadhiwi kimyakimya: kufikia Agosti 2026, kiwango cha chini kilichothibitishwa ni token 512 kwa Claude Opus 5 na token 1,024 kwa Claude Sonnet 5, na ombi fupi kuliko hapo huchakatwa kama kawaida bila kutoa error. Pili, muda wa kuishi hupimwa kuanzia mwanzo wa ombi linaloandika au kusoma data hiyo, na kila usomaji huifanya upya bila gharama ya ziada. Kwa hivyo, endpoint yenye shughuli nyingi huifanya cache ya dakika 5 iendelee kuishi bila kikomo. Endpoint inayopigiwa simu kila baada ya dakika kumi hulipa ziada ya uandishi kila wakati na haipati faida yoyote.

Kagua majibu badala ya kudhani. Kitu cha usage huripoti cache_creation_input_tokens na cache_read_input_tokens. Idadi ya usomaji ya sifuri kwenye kila ombi inamaanisha unanunua uandishi lakini hupati chochote.

Mahali ambapo akiba mbili hukutana

System prompt ndefu ndiyo mahali ambapo hivi viwili hukutana, na inakutoza gharama pande zote mbili kwa wakati mmoja.

Kwenye seva ya ndani (locally), system prompt ya token 20,000 inachukua takriban 2.4 GiB ya KV cache kwenye seva ya Llama 3.1 8B kwa f16, na inafanya hivyo kando kwa kila ombi linaloijumuisha. Kwa upande wa mbali (remotely), prefix hiyo hiyo inagharimu uandishi mmoja wa cache na kisha 0.1 ya input kwenye kila ombi linalofuata. Gharama ya ndani huongezeka kulingana na idadi ya watumiaji wako. Gharama ya mbali huongezeka kulingana na trafiki yako na hujirekebisha wakati wa muda wa kutofanya kazi (idle time).

Kuna kipengele cha ndani kinachofanana na prompt caching ya mtoa huduma na mara nyingi huchanganywa nayo: prefix caching. Nyaraka za vLLM zinaelezea automatic prefix caching kama kuhifadhi "KV cache ya queries zilizopo, ili query mpya iweze kutumia tena KV cache moja kwa moja ikiwa inashiriki prefix sawa na moja ya queries zilizopo". Seva ya llama.cpp huhifadhi prompt cache kwa kila slot kwa chaguo-msingi, na --cache-reuse N huweka kipande kidogo zaidi ambacho itajaribu kukitumia tena.

Prefix caching huokoa compute ya prefill. System prompt yako ya token 20,000 huchakatwa mara moja badala ya kila ombi, jambo ambalo hupunguza muda wa kupata token ya kwanza kwa kiasi kikubwa. Katika vLLM, blocks zilizoshirikiwa hutumiwa tena badala ya kurudiwa, hivyo kumbukumbu pia huboreka. Kitu ambacho haifanyi kamwe ni kupunguza cache ambayo lazima uishikilie kwa ajili ya token zinazotumika sasa. Kuweka weights zikiwa hai kati ya maombi ni hatua inayohusiana lakini tofauti, iliyofafanuliwa katika kuweka model ya Ollama ikiwa imepakiwa kati ya maombi.

Nini cha kupima kwenye seva yako mwenyewe

Pakia modeli kwenye context unayolenga, kisha usome namba halisi badala ya kuamini makadirio.

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

ollama ps huorodhesha modeli iliyopakiwa pamoja na ukubwa wake na kama inaendeshwa kwenye GPU au CPU. Modeli uliyotarajia ikae yote kwenye GPU lakini ikionyesha mgawanyo wa CPU inamaanisha kuwa KV cache imesukuma sehemu yake nje, na kasi ya uzalishaji itashuka ipasavyo. nvidia-smi hutoa takwimu sahihi ya VRAM, na free -g hufanya kazi hiyo hiyo kwenye VPS ya CPU pekee. Ongeza context kwa hatua, pakia upya, na uangalie namba ikibadilika. Hesabu zako na takwimu iliyoripotiwa zinapaswa kuwa karibu. Zisipolingana, pengo hilo kwa kawaida ni buffers za kompyuta za runtime yenyewe badala ya kosa katika fomula.

Ikiwa namba hizo zinakusukuma kuelekea vifaa ambavyo ungependelea kutokuvikodisha, ulinganisho dhidi ya kulipia kwa kila token umeelezwa katika GPU VPS dhidi ya API tokens.

FAQ

Je, KV cache ni kitu kimoja na prompt caching?

Hapana. KV cache ni kumbukumbu ya kila ombi (per-request) ndani ya mchakato wa huduma, inayohifadhi vekta za key na value kwa kila token katika muktadha wa sasa. Inakaa kwenye RAM au VRAM yako na huachiliwa ombi linapokamilika. Prompt caching ya mtoa huduma ni kipengele cha malipo kinachohifadhi kiambishi awali (prefix) cha prompt kwenye miundombinu ya mtoa huduma na kutoza ada iliyopunguzwa unapoituma tena. Kuishiwa na KV cache husababisha modeli kushindwa kupakia. Kukosa prompt cache huongeza tu gharama ya ankara yako na muda wa kupata token ya kwanza.

Kwa nini modeli yangu hupakia kwenye muktadha wa 2k lakini inafeli kwenye 32k?

Kwa sababu runtime hutenga KV cache nzima wakati wa kupakia, kwa ukubwa wa urefu wa muktadha uliosanidi badala ya prompt unayotuma. Kwa Llama 3.1 8B katika f16, cache ni 128 KiB kwa kila token, kwa hivyo muktadha wa 2k unagharimu 0.25 GiB na 32k inagharimu 4 GiB. Uzito (weights) hutoshea katika visa vyote viwili. Uhifadhi (reservation) ndio unaofeli. vLLM huripoti hili kama ValueError ikitaja idadi ya juu ya token inayoweza kuhifadhi, na kupendekeza kuongeza gpu_memory_utilization au kupunguza max_model_len. Kwenye mashine ya CPU pekee, kernel out-of-memory killer huua mchakato huo, jambo unaloweza kuthibitisha kwa dmesg -T | grep -i "killed process".

Ninawezaje kukokotoa ukubwa wa KV cache kwa modeli yangu?

Zidisha 2 kwa idadi ya tabaka (layer count), idadi ya key/value heads, ukubwa wa head, na baiti kwa kila element. Hiyo inatoa baiti kwa kila token. Kisha zidisha kwa urefu wa muktadha wako na kwa idadi ya maombi yanayofanyika kwa wakati mmoja (concurrent requests). Soma idadi ya tabaka na heads kutoka kwenye config.json ya modeli. Tumia baiti 2 kwa kila element kwa f16 au bf16. Cache ya q8_0 ni takriban nusu ya hiyo, na q4_0 ni takriban robo.

Je, prompt caching hupunguza kumbukumbu inayohitajika na seva yangu?

Prompt caching ya mtoa huduma haisaidii maunzi yako, kwa sababu hifadhi iko upande wa mtoa huduma. Mbadala wa ndani ni prefix caching, inayotolewa na vLLM na llama.cpp server. Inatumia tena vekta za key na value zilizokwisha kokotolewa kwa prefix inayoshirikiwa, jambo linalookoa nguvu ya kokotoo ya prefill na kupunguza muda wa kupata token ya kwanza. Katika vLLM, blocks zinazoshirikiwa hutumiwa tena badala ya kurudiwa, hivyo kumbukumbu pia huimarika. Hakuna kipengele kinachopunguza cache inayohitajika kwa token zinazochakatwa kwa sasa, kwa hivyo hesabu yako ya muktadha na concurrency bado huweka kiwango cha chini.

Je, inafaa kuhifadhi (cache) prompt ninayotuma mara moja tu?

Hapana. Uandishi wa cache unagharimu zaidi ya input ya kawaida, mara 1.25 ya ada ya msingi kwa chaguo la dakika 5 kuanzia Agosti 2026, kwa hivyo prefix ambayo huitarudishi ndani ya muda huo ni hasara ya moja kwa moja. Caching hulipa pale prefix ileile inapojirudia, kama vile system prompt ndefu au hati ambayo utauliza maswali kadhaa kuihusu. Angalia cache_read_input_tokens katika majibu ya API ili kuthibitisha kuwa unapata hits badala ya kulipia uandishi.