KV cache మరియు prompt cache మధ్య తేడాలు ఏమిటి?

KV cache మరియు prompt cache: క్లుప్త సమాధానం

KV cache మరియు ప్రొవైడర్ యొక్క prompt cache రెండింటిలోనూ 'cache' అనే పదం ఉన్నప్పటికీ, వాటి మధ్య పెద్దగా పోలిక లేదు. KV cache అనేది ప్రతి అభ్యర్థనకు (request) సంబంధించిన వర్కింగ్ మెమరీ. ఇది ఒక అభ్యర్థన జరుగుతున్నంత సేపు మీ సర్వర్ యొక్క RAM లేదా VRAM లో ఉంటుంది. అభ్యర్థన యొక్క context నిడివిని బట్టి మరియు మీరు ఒకేసారి ఎన్ని అభ్యర్థనలను రన్ చేస్తున్నారనే దానిపై ఇది పెరుగుతుంది. ప్రొవైడర్ prompt caching అనేది బిల్లింగ్ మరియు latency కి సంబంధించిన ఫీచర్. మీ ప్రాంప్ట్‌లోని స్థిరమైన ప్రిఫిక్స్‌ను ప్రొవైడర్ సర్వర్లలో భద్రపరుస్తారు, మీరు దానిని మళ్ళీ పంపినప్పుడు తక్కువ ధరకే ఛార్జ్ చేస్తారు.

ఒకటి మీరు హార్డ్‌వేర్‌గా కొనుగోలు చేసే మెమరీ. మరొకటి వేరొకరు నిల్వ చేసి, దాని కోసం మీ నుండి అద్దె వసూలు చేసే మెమరీ.

వీటి నిర్వచనాల కంటే ఆచరణాత్మక వ్యత్యాసం చాలా ముఖ్యం. KV cache అయిపోవచ్చు, అలా జరిగినప్పుడు మోడల్ లోడ్ అవ్వదు లేదా అభ్యర్థన తిరస్కరించబడుతుంది. మీరు prompt cache ను ఎప్పటికీ ఖాళీ చేయలేరు. మీరు దానిని సరిగ్గా ఉపయోగించుకోవడంలో విఫలమైతే, అదనపు ధర చెల్లించాల్సి వస్తుంది అంతే.

KV cache దేనిని కలిగి ఉంటుంది మరియు అది ఎందుకు అవసరం

ఒక transformer మోడల్ 500వ టోకెన్‌ను జనరేట్ చేస్తున్నప్పుడు, దానికి ముందున్న 499 టోకెన్లన్నింటినీ పరిగణనలోకి తీసుకోవాలి. ఆ ప్రతి టోకెన్ కోసం, ప్రతి లేయర్‌కు ఒక key vector మరియు value vector అవసరం. ప్రతి కొత్త టోకెన్ కోసం వీటిని మళ్లీ మళ్లీ లెక్కిస్తే, జనరేషన్ సమయం టోకెన్ల సంఖ్య యొక్క వర్గానికి (square of the length) అనుగుణంగా పెరుగుతుంది. అందుకే runtime వీటిని భద్రపరుస్తుంది. ఈ నిల్వనే KV cache (key/value cache) అంటారు.

ఇది ప్రతి అభ్యర్థనకు (request) ప్రత్యేకమైన స్థితి, ఎందుకంటే ఇది ఆ అభ్యర్థనలోని ఖచ్చితమైన టోకెన్ క్రమం ఆధారంగా నిర్మించబడుతుంది. ఇద్దరు వినియోగదారులు వేర్వేరు ప్రాంప్ట్‌లను పంపినప్పుడు వారు దీనిని పంచుకోలేరు. అయితే, runtime లో prefix caching అనే ప్రత్యేక ఫీచర్ ఉంటే అది వేరు, దీని గురించి తర్వాత వివరిస్తాము.

సర్వింగ్ రెండు దశల్లో జరుగుతుంది. Prefill దశలో మీ పూర్తి ప్రాంప్ట్‌ను చదివి cache ను నింపుతుంది, ఇది కంప్యూటింగ్ సామర్థ్యంపై ఆధారపడి ఉంటుంది. Decode దశలో ఒకసారి ఒక టోకెన్‌ను ఉత్పత్తి చేసి cache కు జోడిస్తుంది, ఇది మెమరీ బ్యాండ్‌విడ్త్‌పై ఆధారపడి ఉంటుంది. ఈ విభజన వల్లే ప్రాంప్ట్ ప్రాసెసింగ్ మరియు టోకెన్ జనరేషన్ వేగాలు భిన్నంగా ఉంటాయి, అందుకే మీరు మీ సొంత సర్వర్‌లో టోకెన్ల వేగాన్ని కొలిచినప్పుడు ఈ తేడా కనిపిస్తుంది.

KV cache ఎంత మెమరీని ఉపయోగిస్తుంది?

వెండర్ టేబుల్ కోసం వెతకాల్సిన అవసరం లేదు. దీని పరిమాణాన్ని ఏ మోడల్‌కైనా మీరు తిరిగి లెక్కించవచ్చు:

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

2 అనేది key మరియు value లను సూచిస్తుంది. మిగిలిన ప్రతి సంఖ్య మోడల్ యొక్క config.json నుండి వస్తుంది, ఇది మోడల్ యొక్క Hugging Face పేజీలో ప్రచురించబడుతుంది.

Llama 3.1 8B ని ఉదాహరణగా తీసుకుందాం. దీని కాన్ఫిగరేషన్‌లో num_hidden_layers 32 మరియు num_key_value_heads 8 అని ఉంటుంది. 4096 యొక్క hidden_size ను 32 attention heads కు పంపిణీ చేస్తే, head dimension 128 వస్తుంది. f16 వద్ద ప్రతి ఎలిమెంట్ 2 bytes ఉంటుంది:

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

దీనిని మీరు అడిగే context తో, ఆపై మీరు ఒకేసారి రన్ చేసే requests తో గుణించండి.

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

8k context వద్ద cache 1 GiB ఉంటుంది. 32k వద్ద ఇది 4 GiB ఉంటుంది, ఇది 4-bit weights పరిమాణంతో సమానంగా ఉంటుంది. మోడల్ యొక్క పూర్తి 128k context వద్ద, ఒక request కోసం ఇది 16 GiB ఉంటుంది, మరియు నాలుగు requests ఒక్కొక్కటిగా దీనిని నింపితే 64 GiB అవుతుంది. Weights మారవు, కేవలం cache మాత్రమే మారుతుంది.

Grouped query attention (GQA) ఈ సంఖ్యలో కీలక పాత్ర పోషిస్తుంది. Llama 3.1 8B లో 32 query heads కు సేవలు అందించడానికి 8 key/value heads ఉన్నాయి, కాబట్టి నాలుగు query heads ఒకే నిల్వ చేయబడిన key/value pair ను పంచుకుంటాయి. ఒక మోడల్ యొక్క num_key_value_heads దాని num_attention_heads కు సమానంగా ఉంటే, అదే పారామీటర్ సంఖ్య వద్ద అది నాలుగు రెట్లు ఎక్కువ cache ను ఉపయోగిస్తుంది. రెండు 8B మోడల్స్ సర్వ్ చేయడానికి ఒకే ఖర్చు అవుతుందని భావించే ముందు ఆ ఒక్క ఫీల్డ్‌ను తప్పకుండా తనిఖీ చేయండి.

2k వద్ద నడిచిన మోడల్ 32k వద్ద ఎందుకు లోడ్ అవ్వదు

మోడల్ లోడ్ అయినప్పుడు, మీరు కాన్ఫిగర్ చేసిన కాంటెక్స్ట్ లెంగ్త్ ఆధారంగా రన్‌టైమ్ KV cache ను రిజర్వ్ చేస్తుంది, మీరు పంపే ప్రాంప్ట్ పరిమాణం ఆధారంగా కాదు. Ollama యొక్క డిఫాల్ట్ కాంటెక్స్ట్ విండో 4096 టోకెన్లు. దీనిని 32k కి పెంచినప్పుడు, ఒక్క టోకెన్ కూడా రాకముందే మీరు 4 GiB అదనపు కేటాయింపును అడిగినట్లు అవుతుంది.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

ఇంటరాక్టివ్ ప్రాంప్ట్ నుండి ప్రతి సెషన్‌కు ఇదే సెట్టింగ్:

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

ఈ వైఫల్యం ప్రతి స్టాక్‌లో భిన్నంగా కనిపిస్తుంది. vLLM ప్రారంభంలోనే లెక్కలను తనిఖీ చేసి, రన్ అవ్వడానికి నిరాకరిస్తుంది:

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.

కేవలం CPU మాత్రమే ఉన్న VPS లో ఇటువంటి తనిఖీ ఉండదు, ఎందుకంటే ఈ కేటాయింపు సాధారణ సిస్టమ్ RAM లో జరుగుతుంది. అప్పుడు కెర్నల్ యొక్క out-of-memory killer ఆ ప్రాసెస్‌ను నిలిపివేస్తుంది, మరియు దానికి సంబంధించిన ఆధారాలను కెర్నల్ రింగ్ బఫర్‌లో వదిలివేస్తుంది:

dmesg -T | grep -i "killed process"

మీ సర్వింగ్ ప్రాసెస్ పేరుతో ఉన్న ఒక లైన్, ఆ సర్వర్ వద్ద ఉన్న దానికంటే ఎక్కువ మెమరీని అడిగినట్లు సూచిస్తుంది. దీనికి పరిష్కారం పెద్ద swap ఫైల్ కాదు, తక్కువ కాంటెక్స్ట్ లెంగ్త్: డిస్క్‌కు పంపబడిన (paged) KV cache ప్రతి టోకెన్ జనరేషన్ సమయంలో చదవబడుతుంది, దీనివల్ల జనరేషన్ వేగం పనికిరాని స్థాయికి పడిపోతుంది. సరైన సంఖ్యను ఎంచుకోవడం గురించి Ollama లో num_ctx మరియు కాంటెక్స్ట్ లెంగ్త్ పై మా గైడ్ లో వివరించబడింది.

కన్కరెన్సీ సంఖ్యపై చూపే ప్రభావం

ప్రతి ఇన్-ఫ్లైట్ అభ్యర్థన (in-flight request) తన సొంత KV cache ను కలిగి ఉంటుంది. కెపాసిటీ ప్లానింగ్‌లో చాలామంది విస్మరించే అంశం ఇదే. 32k కాంటెక్స్ట్‌ను కలిగి ఉన్న నలుగురు వినియోగదారులకు, మోడల్ వెయిట్స్‌తో పాటు అదనంగా 16 GiB మెమరీ అవసరమవుతుంది.

ఈ విషయంలో రన్‌టైమ్‌ల మధ్య వ్యత్యాసాలు ఉన్నాయి. Ollama మరియు llama.cpp మోడల్ లోడ్ అయినప్పుడే మీరు కోరిన కాంటెక్స్ట్‌ను రిజర్వ్ చేస్తాయి, కాబట్టి ఎవరైనా వాడుతున్నా లేకపోయినా ఆ మెమరీ కేటాయించబడుతుంది. vLLM పూల్‌ను స్థిరమైన పరిమాణం గల బ్లాకులుగా విభజించి, ప్రతి అభ్యర్థన పెరిగే కొద్దీ వాటిని కేటాయిస్తుంది; కాబట్టి 500-token అభ్యర్థన కేవలం 500 టోకెన్లకు సరిపడా స్థలాన్ని మాత్రమే తీసుకుంటుంది. ఏది ఏమైనప్పటికీ, ఈ పూల్ పరిమితమైనది. అది నిండిపోయిన తర్వాత, కొత్త అభ్యర్థనలు రన్ అవ్వడానికి బదులుగా క్యూలో (queue) వేచి ఉంటాయి. ఆ క్యూయింగ్ రెస్పాన్స్ టైమ్స్‌పై ఎలాంటి ప్రభావం చూపుతుందో ఒక self-hosted LLM ఎంతమంది ఏకకాల వినియోగదారులకు సేవ అందించగలదు అనే విభాగంలో వివరించబడింది.

KV cache పరిమాణాన్ని తగ్గించడానికి నాలుగు మార్గాలు

1. Context length ను తగ్గించండి. ఇది అత్యంత ప్రభావవంతమైన మార్గం మరియు సాధారణంగా తక్కువ ఖర్చుతో కూడుకున్నది. చాలా వరకు చాట్ వర్క్‌లోడ్‌లు 32k పరిమితికి చేరుకోవు.
2. Cache ను Quantise చేయండి. Ollama యొక్క OLLAMA_KV_CACHE_TYPE డిఫాల్ట్‌గా f16 ని ఉపయోగిస్తుంది మరియు q8_0 ని అనుమతిస్తుంది, ఇది సుమారు సగం మెమరీని మాత్రమే వాడుకుంటుంది. అలాగే q4_0 ని ఉపయోగిస్తే పావు వంతు మెమరీ సరిపోతుంది. llama.cpp లో దీనికి సమానమైనవి -ctk q8_0 మరియు -ctv q8_0.
3. తక్కువ key/value heads లేదా తక్కువ layers ఉన్న మోడల్‌ను ఎంచుకోండి. 40 GB బరువున్న ఫైళ్లను డౌన్‌లోడ్ చేసే ముందు config.json ని చదవండి.
4. ఒకేసారి తక్కువ అభ్యర్థనలను (requests) సర్వ్ చేయండి మరియు మిగిలిన వాటిని క్యూ (queue) లో ఉంచండి.

q4_0 వద్ద Llama 3.1 8B గణాంకం ప్రతి token కు 128 KiB నుండి సుమారు 32 KiB కి పడిపోతుంది. కాబట్టి 32k context కోసం 4 GiB కి బదులుగా సుమారు 1 GiB ఖర్చవుతుంది. ఈ ఆదా ఉచితం కాదు. Key మరియు value లు తక్కువ precision తో నిల్వ చేయబడతాయి, కాబట్టి మీరు దీన్ని ఖాయం చేసుకునే ముందు మీ స్వంత ప్రాంప్ట్‌లపై అవుట్‌పుట్‌ను సరిపోల్చి చూడండి.

Provider prompt caching ద్వారా నిజంగా పొందే ప్రయోజనం ఏమిటి

Provider prompt caching అనేది భిన్నమైన యూనిట్ ఆఫ్ అకౌంట్‌తో కూడిన ఒక ప్రత్యేక ఉత్పత్తి. మీరు ఒక స్థిరమైన ప్రిఫిక్స్‌ను మార్క్ చేసినప్పుడు, ప్రొవైడర్ దానిని స్టోర్ చేస్తుంది. ఆ తర్వాత అదే ప్రిఫిక్స్‌ను పునరావృతం చేసే కాల్స్ పూర్తి ఇన్‌పుట్ ధరతో కాకుండా, తగ్గిన ధరతో బిల్ చేయబడతాయి.

ఆగస్టు 2026 నాటికి Anthropic ప్రచురించిన మల్టిప్లైయర్స్ ఇవి: 5-నిమిషాల కాష్ రైట్ (cache write) బేస్ ఇన్‌పుట్ టోకెన్ ధర కంటే 1.25 రెట్లు ఉంటుంది. 1-గంట రైట్ 2 రెట్లు ఉంటుంది, మరియు కాష్ రీడ్ (cache read) 0.1 రెట్లు ఉంటుంది. ఈ సంఖ్యల వెనుక 20,000-టోకెన్ల సిస్టమ్ ప్రాంప్ట్‌ను ఉంచితే, ఈ డీల్ యొక్క లాభం స్పష్టమవుతుంది.

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

దీనిని అంకగణితంగా చూడండి. మొదటి కాల్‌లో 5-నిమిషాల రైట్ ప్రీమియం 5,000 టోకెన్లకు సమానం: 25,000, ఇది అన్‌కాష్డ్ (uncached) పద్ధతిలో పంపే 20,000 తో పోలిస్తే తక్కువ. విండోలో జరిగే ప్రతి తదుపరి కాల్ 20,000 కు బదులుగా 2,000 గా బిల్ చేయబడుతుంది, అంటే 18,000 టోకెన్ల ఆదా. కాబట్టి, రెండవ కాల్ నుండే 5-నిమిషాల కాష్ లాభదాయకంగా మారుతుంది.

1-గంట కాష్ అనేది భిన్నమైన పందెం. ఇది రైట్ సమయంలో 40,000 బిల్ చేస్తుంది, అంటే 20,000 టోకెన్ల ప్రీమియం. కాబట్టి, ఇది లాభదాయకం కావాలంటే గంటలోపు కనీసం రెండు సార్లు హిట్ అవ్వాలి. ఇది మోడల్‌కు సంబంధించిన విషయం కాదు, మీ ట్రాఫిక్ పద్ధతికి సంబంధించిన ప్రశ్న. విండోను ఎలా ఎంచుకోవాలో సహా పూర్తి గణన Claude prompt caching కోసం బ్రేక్-ఈవెన్ గణితం లో ఉంది.

మీరు కాష్‌ను హిట్ చేస్తున్నారా లేదా అనేది రెండు అంశాలపై ఆధారపడి ఉంటుంది. మొదటిది, మోడల్ యొక్క కనీస పొడవు కంటే తక్కువ ఉన్న ప్రిఫిక్స్ కాష్ చేయబడదు: ఆగస్టు 2026 నాటికి Claude Opus 5 కోసం 512 టోకెన్లు మరియు Claude Sonnet 5 కోసం 1,024 టోకెన్లు కనీస పరిమితిగా ఉన్నాయి. అంతకంటే తక్కువ ఉన్న అభ్యర్థనలు ఎటువంటి ఎర్రర్ లేకుండా సాధారణంగా ప్రాసెస్ చేయబడతాయి. రెండవది, లైఫ్‌టైమ్ అనేది ఎంట్రీని రైట్ లేదా రీడ్ చేసే అభ్యర్థన ప్రారంభం నుండి లెక్కించబడుతుంది, మరియు ప్రతి రీడ్ ఎటువంటి అదనపు ఖర్చు లేకుండా దానిని రిఫ్రెష్ చేస్తుంది. కాబట్టి, బిజీగా ఉండే ఎండ్‌పాయింట్ 5-నిమిషాల కాష్‌ను నిరవధికంగా సజీవంగా ఉంచుతుంది. ప్రతి పది నిమిషాలకు ఒకసారి కాల్ చేయబడే ఎండ్‌పాయింట్ ప్రతిసారీ రైట్ ప్రీమియంను చెల్లిస్తుంది కానీ ఎటువంటి ప్రయోజనం పొందదు.

ఊహించుకోవడం కంటే రెస్పాన్స్‌ను తనిఖీ చేయండి. usage ఆబ్జెక్ట్ cache_creation_input_tokens మరియు cache_read_input_tokens గురించి నివేదిస్తుంది. ప్రతి కాల్‌లో రీడ్ కౌంట్ సున్నాగా ఉంటే, మీరు రైట్స్ కోసం చెల్లిస్తున్నారు కానీ ఏమీ తిరిగి పొందడం లేదని అర్థం.

రెండు కాష్‌లు కలిసే చోట

ఒక సుదీర్ఘమైన system prompt అనేది ఈ రెండు పద్ధతులు కలిసే ప్రదేశం, ఇది ఒకే సమయంలో రెండు వైపులా మీపై భారాన్ని పెంచుతుంది.

స్థానికంగా (Locally), 20,000-token ల system prompt, Llama 3.1 8B సర్వర్‌లో f16 వద్ద సుమారు 2.4 GiB KV cache ను ఆక్రమిస్తుంది. దీనిని కలిగి ఉన్న ప్రతి concurrent request కోసం ఇది విడివిడిగా జరుగుతుంది. రిమోట్‌గా (Remotely), అదే prefix ఒక cache write ఖర్చును, ఆపై ప్రతి తదుపరి కాల్‌లో 0.1 రెట్లు input ఖర్చును కలిగిస్తుంది. స్థానిక ఖర్చు మీ వినియోగదారుల సంఖ్యను బట్టి పెరుగుతుంది. రిమోట్ ఖర్చు మీ ట్రాఫిక్‌ను బట్టి పెరుగుతుంది మరియు మీ idle సమయంలో రీసెట్ అవుతుంది.

స్థానికంగా ఒక ఫీచర్ ఉంది, ఇది provider prompt caching లాగే కనిపిస్తుంది మరియు దీనితో నిరంతరం గందరగోళానికి గురిచేస్తుంది: అదే prefix caching. vLLM డాక్యుమెంటేషన్ ఆటోమేటిక్ prefix caching ను ఇలా వివరిస్తుంది: "ఇప్పటికే ఉన్న queries యొక్క KV cache ను కాష్ చేయడం, తద్వారా కొత్త query అదే prefix ను కలిగి ఉంటే, అది నేరుగా ఆ KV cache ను తిరిగి ఉపయోగించుకోగలదు". llama.cpp సర్వర్ డిఫాల్ట్‌గా ప్రతి slot కు ఒక prompt cache ను ఉంచుతుంది, మరియు --cache-reuse N అది తిరిగి ఉపయోగించడానికి ప్రయత్నించే అతి చిన్న chunk ను సెట్ చేస్తుంది.

Prefix caching వల్ల prefill compute ఆదా అవుతుంది. మీ 20,000-token ల system prompt ప్రతి అభ్యర్థనపై కాకుండా, ఒకేసారి ప్రాసెస్ చేయబడుతుంది, ఇది మొదటి token వచ్చే సమయాన్ని గణనీయంగా తగ్గిస్తుంది. vLLM లో, shared blocks డూప్లికేట్ చేయబడకుండా తిరిగి ఉపయోగించబడతాయి, కాబట్టి మెమరీ వినియోగం కూడా మెరుగుపడుతుంది. ఇది ఎప్పటికీ చేయలేని పని ఏమిటంటే, ప్రస్తుతం లైవ్‌లో ఉన్న tokens కోసం మీరు ఉంచాల్సిన cache పరిమాణాన్ని తగ్గించడం. అభ్యర్థనల మధ్య weights ను resident గా ఉంచడం అనేది ఒక సంబంధిత కానీ వేరొక అంశం, ఇది Ollama మోడల్‌ను అభ్యర్థనల మధ్య లోడ్ చేసి ఉంచడం లో వివరించబడింది.

మీ సొంత సర్వర్‌లో ఏమి కొలవాలి

మీ లక్ష్య కాంటెక్స్ట్ (context) వద్ద మోడల్‌ను లోడ్ చేయండి, ఆపై అంచనాలను నమ్మే బదులు వాస్తవ సంఖ్యలను పరిశీలించండి.

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

ollama ps లోడ్ అయిన మోడల్ పరిమాణాన్ని మరియు అది GPU పై నడుస్తుందో లేదా CPU పై నడుస్తుందో తెలియజేస్తుంది. పూర్తిగా GPU పై ఉంటుందని మీరు ఆశించిన మోడల్, CPU స్ప్లిట్‌ను చూపిస్తుంటే, KV cache దానిని బయటకు నెట్టిందని అర్థం; దీనివల్ల జనరేషన్ వేగం తగ్గుతుంది. nvidia-smi ఖచ్చితమైన VRAM గణాంకాలను ఇస్తుంది, మరియు free -g CPU-మాత్రమే ఉండే VPS లలో అదే పనిని చేస్తుంది. కాంటెక్స్ట్‌ను దశలవారీగా పెంచి, రీలోడ్ చేసి, ఆ సంఖ్య ఎలా మారుతుందో గమనించండి. మీరు చేసిన లెక్కలు మరియు చూపబడిన సంఖ్యలు ఒకదానికొకటి దగ్గరగా ఉండాలి. ఒకవేళ అలా లేకపోతే, ఆ వ్యత్యాసం సాధారణంగా ఫార్ములాలోని లోపం కాకుండా, రన్‌టైమ్ యొక్క సొంత కంప్యూట్ బఫర్‌ల వల్ల ఏర్పడుతుంది.

ఈ సంఖ్యలు మిమ్మల్ని మీరు అద్దెకు తీసుకోవాలని అనుకోని హార్డ్‌వేర్ వైపు నడిపిస్తుంటే, టోకెన్ల వారీగా చెల్లించే విధానంతో పోలికను GPU VPS మరియు API టోకెన్ల మధ్య పోలిక లో చూడవచ్చు.

FAQ

KV cache మరియు prompt caching ఒకటేనా?

కాదు. KV cache అనేది సర్వింగ్ ప్రాసెస్‌లో ప్రతి అభ్యర్థనకు (request) కేటాయించే మెమరీ. ఇది ప్రస్తుత కాంటెక్స్ట్‌లోని ప్రతి టోకెన్‌కు సంబంధించిన కీ మరియు వాల్యూ వెక్టార్లను కలిగి ఉంటుంది. ఇది మీ RAM లేదా VRAM లో ఉంటుంది మరియు అభ్యర్థన ముగిసినప్పుడు తొలగించబడుతుంది. ప్రొవైడర్ prompt caching అనేది ఒక బిల్లింగ్ ఫీచర్. ఇది స్థిరమైన ప్రాంప్ట్ ప్రిఫిక్స్‌ను ప్రొవైడర్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో నిల్వ చేస్తుంది మరియు మీరు దానిని మళ్ళీ పంపినప్పుడు తక్కువ ఛార్జీలను విధిస్తుంది. KV cache అయిపోతే మోడల్ లోడ్ అవ్వడం ఆగిపోతుంది. prompt cache లేకపోతే మీ బిల్లు పెరుగుతుంది మరియు మొదటి టోకెన్ రావడానికి పట్టే సమయం పెరుగుతుంది.

నా మోడల్ 2k కాంటెక్స్ట్ వద్ద లోడ్ అవుతుంది, కానీ 32k వద్ద ఎందుకు విఫలమవుతుంది?

ఎందుకంటే రన్‌టైమ్ లోడ్ అయ్యే సమయంలోనే మొత్తం KV cache ను కేటాయిస్తుంది. ఇది మీరు పంపే ప్రాంప్ట్ పరిమాణంపై కాకుండా, మీరు కాన్ఫిగర్ చేసిన కాంటెక్స్ట్ పొడవుపై ఆధారపడి ఉంటుంది. Llama 3.1 8B (f16) కోసం cache ప్రతి టోకెన్‌కు 128 KiB ఉంటుంది. కాబట్టి 2k కాంటెక్స్ట్‌కు 0.25 GiB, 32k కు 4 GiB అవసరమవుతుంది. రెండు సందర్భాల్లోనూ మోడల్ వెయిట్స్ సరిపోతాయి, కానీ రిజర్వేషన్ విఫలమవుతుంది. vLLM దీనిని ValueError గా రిపోర్ట్ చేస్తుంది, ఇది నిల్వ చేయగల గరిష్ట టోకెన్ల సంఖ్యను తెలియజేస్తుంది. ఇది gpu_memory_utilization ను పెంచమని లేదా max_model_len ను తగ్గించమని సూచిస్తుంది. కేవలం CPU మాత్రమే ఉన్న సర్వర్‌లో, kernel out-of-memory killer ప్రాసెస్‌ను నిలిపివేస్తుంది; దీనిని మీరు dmesg -T | grep -i "killed process" ద్వారా నిర్ధారించుకోవచ్చు.

నా మోడల్ కోసం KV cache పరిమాణాన్ని ఎలా లెక్కించాలి?

లేయర్ల సంఖ్యను, కీ/వాల్యూ హెడ్స్ సంఖ్యను, హెడ్ డైమెన్షన్‌ను మరియు ఎలిమెంట్‌కు పట్టే బైట్లను 2 తో గుణించండి. ఇది ప్రతి టోకెన్‌కు పట్టే బైట్లను ఇస్తుంది. ఆపై దానిని మీ కాంటెక్స్ట్ పొడవుతో మరియు ఏకకాలంలో వచ్చే అభ్యర్థనల (concurrent requests) సంఖ్యతో గుణించండి. లేయర్ మరియు హెడ్ గణాంకాలను మోడల్ యొక్క config.json నుండి పొందండి. f16 లేదా bf16 కోసం ఎలిమెంట్‌కు 2 బైట్లను ఉపయోగించండి. q8_0 cache దీనిలో సగం ఉంటుంది, మరియు q4_0 సుమారు నాలుగో వంతు ఉంటుంది.

Prompt caching నా సొంత సర్వర్ మెమరీ అవసరాలను తగ్గిస్తుందా?

ప్రొవైడర్ prompt caching మీ హార్డ్‌వేర్‌కు ఏమీ చేయదు, ఎందుకంటే నిల్వ ప్రొవైడర్ వైపు ఉంటుంది. దీనికి స్థానిక ప్రత్యామ్నాయం prefix caching, ఇది vLLM మరియు llama.cpp సర్వర్ రెండింటిలోనూ అందుబాటులో ఉంది. ఇది ఇప్పటికే లెక్కించిన కీ మరియు వాల్యూ వెక్టార్లను షేర్డ్ ప్రిఫిక్స్ కోసం తిరిగి ఉపయోగిస్తుంది, దీనివల్ల prefill కంప్యూటేషన్ ఆదా అవుతుంది మరియు మొదటి టోకెన్ రావడానికి పట్టే సమయం తగ్గుతుంది. vLLM లో షేర్డ్ బ్లాక్‌లు డూప్లికేట్ అవ్వకుండా తిరిగి ఉపయోగించబడతాయి, కాబట్టి మెమరీ వినియోగం మెరుగుపడుతుంది. ఏ ఫీచరూ ప్రస్తుతం ప్రాసెస్ అవుతున్న టోకెన్లకు అవసరమైన cache ను తగ్గించదు, కాబట్టి మీ కాంటెక్స్ట్ మరియు కన్కరెన్సీ లెక్కలే మెమరీ పరిమితిని నిర్ణయిస్తాయి.

నేను ఒక్కసారి మాత్రమే పంపే ప్రాంప్ట్‌ను cache చేయడం విలువైనదేనా?

కాదు. ఆగస్టు 2026 నాటికి, 5-నిమిషాల ఆప్షన్ కోసం cache రైట్ చేయడానికి సాధారణ ఇన్‌పుట్ కంటే 1.25 రెట్లు ఎక్కువ ఖర్చవుతుంది. కాబట్టి, ఆ విండోలో మీరు మళ్ళీ పంపని ప్రిఫిక్స్ వల్ల నష్టమే జరుగుతుంది. ఒకే ప్రిఫిక్స్ పదేపదే ఉపయోగించినప్పుడు (ఉదాహరణకు సుదీర్ఘమైన సిస్టమ్ ప్రాంప్ట్ లేదా మీరు అనేక ప్రశ్నలు అడిగే డాక్యుమెంట్) మాత్రమే caching ఉపయోగకరంగా ఉంటుంది. మీరు రైటింగ్ కోసం చెల్లిస్తున్నారా లేదా హిట్స్ పొందుతున్నారా అని నిర్ధారించుకోవడానికి API రెస్పాన్స్‌లోని cache_read_input_tokens ను తనిఖీ చేయండి.