KV cache மற்றும் Prompt cache: முக்கிய வேறுபாடுகள் என்ன?

KV cache மற்றும் prompt cache: சுருக்கமான விளக்கம்

KV cache மற்றும் ஒரு provider-ன் prompt cache ஆகியவற்றுக்கு இடையே 'cache' என்ற சொல் மட்டுமே பொதுவானது, மற்றபடி அவற்றுக்கு எந்தத் தொடர்பும் இல்லை. KV cache என்பது ஒவ்வொரு request-க்கும் பயன்படும் working memory ஆகும். இது ஒரு request-ன் வாழ்நாள் முழுவதும் உங்கள் server-ன் RAM அல்லது VRAM-ல் இருக்கும். context length மற்றும் ஒரே நேரத்தில் நீங்கள் இயக்கும் request-களின் எண்ணிக்கையைப் பொறுத்து இதன் அளவு அதிகரிக்கும். Provider prompt caching என்பது கட்டணம் மற்றும் latency தொடர்பான ஒரு வசதியாகும். உங்கள் prompt-ன் நிலையான முன்னொட்டு (prefix) provider-ன் server-களில் சேமிக்கப்படும்; அதை நீங்கள் மீண்டும் அனுப்பும்போது தள்ளுபடி விலையில் கட்டணம் வசூலிக்கப்படும்.

ஒன்று நீங்கள் hardware-ஆக வாங்கும் memory; மற்றொன்று வேறொருவர் வைத்திருக்கும் memory, அதற்காக நீங்கள் வாடகை செலுத்த வேண்டும்.

வரையறையை விட நடைமுறை வேறுபாடுகளே முக்கியமானவை. KV cache தீர்ந்துபோக வாய்ப்புள்ளது; அவ்வாறு நடந்தால், model-ஐ load செய்ய முடியாது அல்லது request நிராகரிக்கப்படும். Prompt cache தீர்ந்துபோகாது. அதை நீங்கள் பயன்படுத்தத் தவறினால், முழு விலையைச் செலுத்த வேண்டியிருக்கும்.

KV cache எதைக் கொண்டுள்ளது மற்றும் அது ஏன் தேவைப்படுகிறது

ஒரு transformer 500-வது token-ஐ உருவாக்கும்போது, அதற்கு முன்னால் உள்ள 499 token-களையும் கவனிக்க (attend) வேண்டும். அந்த ஒவ்வொரு token-க்கும், ஒவ்வொரு layer-லும் ஒரு key vector மற்றும் ஒரு value vector தேவைப்படுகிறது. ஒவ்வொரு புதிய token-க்கும் இவை அனைத்தையும் மீண்டும் கணக்கிட்டால், generation நேரம் நீளத்தின் வர்க்கத்திற்கு (square of the length) ஏற்ப அதிகரிக்கும். எனவே, runtime அவற்றைச் சேமித்து வைக்கிறது. இந்தச் சேமிப்பகமே KV cache (key/value cache) ஆகும்.

இது ஒரு request-க்கான பிரத்யேக நிலை (per-request state) ஆகும், ஏனெனில் இது அந்த request-ன் துல்லியமான token வரிசையிலிருந்து உருவாக்கப்படுகிறது. runtime-ல் prefix caching என்ற தனி அம்சம் இருந்தால் ஒழிய, வெவ்வேறு prompts அனுப்பும் இரு பயனர்கள் இதைப் பகிர்ந்து கொள்ள முடியாது.

Serving இரண்டு நிலைகளில் நடைபெறுகிறது. Prefill உங்கள் முழு prompt-ஐயும் படித்து cache-ஐ நிரப்புகிறது; இது compute திறனால் கட்டுப்படுத்தப்படுகிறது. Decode ஒரு நேரத்தில் ஒரு token-ஐ உருவாக்கி cache-ல் சேர்க்கிறது; இது memory bandwidth-ஆல் கட்டுப்படுத்தப்படுகிறது. இந்த பிரிவினையால்தான், prompt processing மற்றும் token generation ஆகியவற்றுக்கு நீங்கள் உங்கள் கணினியில் tokens per second அளவிடும்போது வெவ்வேறு வேகங்கள் கிடைக்கின்றன.

KV cache எவ்வளவு நினைவகத்தைப் பயன்படுத்துகிறது?

விற்பனையாளர் அட்டவணையைத் தேட வேண்டாம். எந்தவொரு மாதிரிக்கும் (model) நீங்களே கணக்கிடக்கூடிய எளிய கணித முறை இது:

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

இதில் உள்ள 2 என்பது key மற்றும் value ஆகியவற்றைக் குறிக்கிறது. மற்ற அனைத்து எண்களும் அந்த மாதிரியின் config.json-லிருந்து பெறப்படுகின்றன, இவை Hugging Face பக்கத்தில் வெளியிடப்பட்டிருக்கும்.

Llama 3.1 8B மாதிரியை எடுத்துக்கொள்வோம். அதன் config-ல் num_hidden_layers 32 என்றும் num_key_value_heads 8 என்றும் குறிப்பிடப்பட்டுள்ளது. 4096 அளவுள்ள hidden_size-ஐ 32 attention heads-க்கு பிரித்தால், ஒரு head-ன் பரிமாணம் 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 அளவில், ஒரு கோரிக்கைக்கு இது 16 GiB ஆகும்; நான்கு கோரிக்கைகள் ஒவ்வொன்றும் அதை நிரப்பினால் 64 GiB ஆகும். Weights மாறவில்லை, cache மட்டுமே மாறியுள்ளது.

Grouped query attention (GQA) இந்த எண்ணிக்கையில் முக்கியப் பங்கு வகிக்கிறது. Llama 3.1 8B-ல் 32 query heads-க்கு சேவை செய்ய 8 key/value heads உள்ளன, எனவே நான்கு query heads ஒரு சேமிக்கப்பட்ட key/value ஜோடியைப் பகிர்ந்து கொள்கின்றன. ஒரு மாதிரியின் num_key_value_heads அதன் num_attention_heads-க்கு சமமாக இருந்தால், அதே அளவு parameters கொண்ட மற்றொரு மாதிரியை விட நான்கு மடங்கு அதிக cache-ஐ அது பயன்படுத்தும். இரண்டு 8B மாதிரிகளும் ஒரே செலவில் இயங்கும் என்று கருதும் முன், அந்த ஒரு புலத்தைச் சரிபார்க்கவும்.

2k-ல் இயங்கிய ஒரு model ஏன் 32k-ல் load ஆக மறுக்கிறது

ஏனெனில், model load ஆகும்போது, நீங்கள் configure செய்த context length-க்கு ஏற்ப runtime KV cache-ஐ ஒதுக்குகிறது; நீங்கள் அனுப்பும் prompt-ன் நீளத்திற்கு ஏற்ப அல்ல. Ollama-வின் default context window 4096 tokens ஆகும். இதை 32k-க்கு உயர்த்தும்போது, முதல் token வருவதற்கு முன்பே 4 GiB கூடுதல் ஒதுக்கீட்டைக் கோருகிறீர்கள்.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Interactive prompt-ல், ஒவ்வொரு session-க்கும் அதே அமைப்பைப் பயன்படுத்த:

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

ஒவ்வொரு stack-லும் இந்தத் தோல்வி வெவ்வேறு விதமாகத் தெரியும். 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-ல் இத்தகைய சரிபார்ப்பு இருக்காது, ஏனெனில் அந்த ஒதுக்கீடு சாதாரண system RAM-ல் நடக்கும். Kernel-ன் out-of-memory killer அந்த process-ஐ முடித்துவிடும், அதற்கான ஆதாரத்தை kernel ring buffer-ல் காணலாம்:

dmesg -T | grep -i "killed process"

உங்கள் serving process-ன் பெயரைக் கொண்ட ஒரு வரி இருந்தால், அந்த server-ல் இருந்ததை விட அதிக memory கோரப்பட்டுள்ளது என்று அர்த்தம். இதற்கான தீர்வு, swap file-ஐ அதிகரிப்பது அல்ல, context-ஐக் குறைப்பதே ஆகும்: disk-க்கு மாற்றப்பட்ட (paged) KV cache, உருவாக்கப்படும் ஒவ்வொரு token-க்கும் வாசிக்கப்படும், இதனால் generation வேகம் பயனற்ற நிலைக்குக் குறைந்துவிடும். சரியான எண்ணைத் தேர்ந்தெடுப்பது பற்றி Ollama-வில் num_ctx மற்றும் context length குறித்த எங்கள் வழிகாட்டியில் விவரிக்கப்பட்டுள்ளது.

ஒரே நேரத்தில் இயங்கும் கோரிக்கைகள் (concurrency) எண்ணிக்கையை எவ்வாறு பாதிக்கிறது

ஒவ்வொரு in-flight கோரிக்கையும் அதன் சொந்த KV cache-ஐக் கொண்டிருக்கும். பெரும்பாலான capacity திட்டமிடல்களில் இந்த அம்சம் கவனிக்கப்படுவதில்லை. தலா 32k context-ஐக் கொண்ட நான்கு பயனர்களுக்கு, model weights-க்கு மேலதிகமாக 16 GiB நினைவகம் தேவைப்படுகிறது.

இந்தக் கட்டுப்பாட்டை runtime-கள் கையாளும் விதம் மாறுபடும். Ollama மற்றும் llama.cpp ஆகியவை model load ஆகும்போது நீங்கள் கேட்ட context-ஐ முன்பதிவு செய்துவிடும்; எனவே, யாராவது அதைப் பயன்படுத்துகிறார்களா இல்லையா என்பதைப் பொருட்படுத்தாமல் அந்த நினைவகம் ஒதுக்கப்பட்டுவிடும். vLLM, நினைவகத் தொகுப்பை (pool) நிலையான அளவுள்ள blocks-களாகப் பிரித்து, ஒவ்வொரு கோரிக்கையும் வளரும்போது அவற்றை வழங்குகிறது; இதனால் 500-token கோரிக்கை 500 tokens-க்குத் தேவையான நினைவகத்தை மட்டுமே எடுத்துக்கொள்ளும். எப்படியிருப்பினும், இந்த நினைவகத் தொகுப்பு வரையறுக்கப்பட்டது. அது நிரம்பியவுடன், புதிய கோரிக்கைகள் இயங்குவதற்குப் பதிலாக வரிசையில் (queue) காத்திருக்கும். இந்த வரிசைமுறை response times-ஐ எவ்வாறு பாதிக்கிறது என்பது ஒரு self-hosted LLM எத்தனை பயனர்களுக்கு ஒரே நேரத்தில் சேவை வழங்க முடியும் என்பதில் விளக்கப்பட்டுள்ளது.

KV cache-ஐச் சிறியதாக்குவதற்கான நான்கு வழிகள்

1. Context length-ஐக் குறைக்கவும். இதுவே மிக முக்கியமான காரணி மற்றும் பொதுவாகச் செலவு குறைந்ததும் கூட. பெரும்பாலான chat workloads 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 கொண்ட model-ஐத் தேர்ந்தெடுக்கவும். 40 GB எடையுள்ள weights-ஐப் பதிவிறக்கும் முன் 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) சேமிக்கப்படுவதால், நிரந்தரமாகப் பயன்படுத்துவதற்கு முன்பு உங்கள் சொந்த prompts-களைக் கொண்டு வெளியீட்டைச் சரிபார்க்கவும்.

Provider prompt caching எதைக் கொண்டுவருகிறது

Provider prompt caching என்பது ஒரு மாறுபட்ட தயாரிப்பு, இது கணக்கீட்டிற்கு வேறுபட்ட அலகைப் பயன்படுத்துகிறது. நீங்கள் ஒரு நிலையான முன்னொட்டை (prefix) குறிக்கிறீர்கள், அதை provider சேமித்து வைக்கிறது. பின்னர் அதே முன்னொட்டை மீண்டும் பயன்படுத்தும் அழைப்புகள், முழுமையான உள்ளீட்டு விலைக்குப் பதிலாகக் குறைக்கப்பட்ட கட்டணத்தில் கணக்கிடப்படுகின்றன.

ஆகஸ்ட் 2026 நிலவரப்படி, Anthropic வெளியிட்ட பெருக்கிகள் (multipliers): 5-நிமிட cache write, அடிப்படை உள்ளீட்டு token விலையை விட 1.25 மடங்கு செலவாகும். 1-மணிநேர write 2 மடங்கு செலவாகும், மற்றும் cache read 0.1 மடங்கு செலவாகும். 20,000-token system prompt-ஐ இந்த எண்களுக்குப் பின்னால் வைத்தால், இந்த ஒப்பந்தத்தின் லாபம் தெளிவாகத் தெரியும்.

[
  {
    "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-நிமிட write பிரீமியம் முதல் அழைப்பில் 5,000 token-களுக்குச் சமம்: 25,000, இது cache செய்யப்படாமல் அனுப்பப்படும் 20,000 விலைக்கு எதிரானது. அந்த காலக்கெடுவிற்குள் வரும் ஒவ்வொரு அடுத்தடுத்த அழைப்பும் 20,000 விலைக்குப் பதிலாக 2,000 என வசூலிக்கப்படும், இது 18,000 token-கள் சேமிப்பு. எனவே, இரண்டாவது அழைப்பிலிருந்தே 5-நிமிட cache லாபகரமாகிறது.

1-மணிநேர cache என்பது ஒரு மாறுபட்ட கணக்கீடு. இது write-ன் போது 40,000 என வசூலிக்கிறது, இது 20,000 token-களுக்குச் சமமான பிரீமியம் ஆகும். எனவே, லாபகரமாக மாற இது ஒரு மணி நேரத்திற்குள் இரண்டு முறை பயன்படுத்தப்பட வேண்டும். இது உங்கள் traffic pattern-ஐப் பொறுத்தது, model-ஐப் பொறுத்தது அல்ல. window-ஐ எவ்வாறு தேர்ந்தெடுப்பது என்பது உட்பட முழுமையான கணக்கீடு Claude prompt caching-க்கான break-even கணிதத்தில் உள்ளது.

cache-ஐ நீங்கள் சரியாகப் பயன்படுத்துகிறீர்களா என்பதை இரண்டு விவரங்கள் தீர்மானிக்கின்றன. முதலாவதாக, model-ன் குறைந்தபட்ச நீளத்திற்குக் குறைவான முன்னொட்டு cache செய்யப்படாது: ஆகஸ்ட் 2026 நிலவரப்படி, ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச அளவு Claude Opus 5-க்கு 512 token-கள் மற்றும் Claude Sonnet 5-க்கு 1,024 token-கள் ஆகும். இதைவிடக் குறைவான கோரிக்கைகள் பிழை ஏதுமின்றி சாதாரணமாகவே செயலாக்கப்படும். இரண்டாவதாக, cache-ன் ஆயுட்காலம் அந்த உள்ளீட்டை எழுதும் அல்லது படிக்கும் கோரிக்கையின் தொடக்கத்திலிருந்து கணக்கிடப்படுகிறது, மேலும் ஒவ்வொரு read-ம் கூடுதல் செலவின்றி அதை மீண்டும் புதுப்பிக்கும். எனவே, அதிக traffic உள்ள endpoint-ல் 5-நிமிட cache காலவரையின்றி நீடிக்கும். பத்து நிமிடங்களுக்கு ஒருமுறை மட்டும் அழைக்கப்படும் endpoint, ஒவ்வொரு முறையும் write பிரீமியத்தைச் செலுத்தும், ஆனால் எந்தப் பலனையும் பெறாது.

ஊகிப்பதற்குப் பதிலாக response-ஐச் சரிபார்க்கவும். usage object, cache_creation_input_tokens மற்றும் cache_read_input_tokens ஆகியவற்றைத் தெரிவிக்கிறது. ஒவ்வொரு அழைப்பிலும் read count பூஜ்ஜியமாக இருந்தால், நீங்கள் write-க்கு மட்டும் பணம் செலுத்துகிறீர்கள், எந்தப் பலனும் கிடைக்கவில்லை என்று அர்த்தம்.

இரண்டு caches சந்திக்கும் இடம்

நீளமான system prompt என்பது இவை இரண்டும் சந்திக்கும் இடமாகும், இது ஒரே நேரத்தில் இரண்டு பக்கங்களிலும் உங்களைச் செலவு செய்ய வைக்கிறது.

உள்ளூர் அளவில் (Locally), 20,000-token கொண்ட system prompt, f16-ல் இயங்கும் Llama 3.1 8B server-ல் சுமார் 2.4 GiB KV cache-ஐ எடுத்துக்கொள்ளும். இதை உள்ளடக்கிய ஒவ்வொரு concurrent request-க்கும் இது தனித்தனியாகச் செயல்படும். தொலைதூர அளவில் (Remotely), அதே prefix ஒருமுறை cache write செலவையும், பின்னர் ஒவ்வொரு அழைப்பிலும் 0.1 மடங்கு input செலவையும் ஏற்படுத்தும். உள்ளூர் செலவு உங்கள் பயனர்களின் எண்ணிக்கையைப் பொறுத்து அதிகரிக்கும். தொலைதூரச் செலவு உங்கள் traffic-ஐப் பொறுத்து அதிகரிக்கும் மற்றும் idle நேரத்தில் இது reset ஆகும்.

provider prompt caching போன்றே தோற்றமளிக்கும் மற்றும் அடிக்கடி குழப்பத்தை ஏற்படுத்தும் ஒரு உள்ளூர் அம்சம் உள்ளது: அதுதான் prefix caching. vLLM ஆவணங்கள், automatic prefix caching-ஐ "ஏற்கனவே உள்ள queries-ன் KV cache-ஐச் சேமித்து வைப்பது, இதன் மூலம் ஒரு புதிய query ஏற்கனவே உள்ள query-களுடன் ஒரே prefix-ஐப் பகிர்ந்துகொண்டால், அந்த KV cache-ஐ நேரடியாக மீண்டும் பயன்படுத்த முடியும்" என்று விவரிக்கிறது. llama.cpp server இயல்பாகவே ஒரு slot-க்கு ஒரு prompt cache-ஐ வைத்திருக்கும், மேலும் --cache-reuse N என்பது அது மீண்டும் பயன்படுத்த முயற்சிக்கும் மிகச்சிறிய chunk அளவை அமைக்கிறது.

prefix caching எதைக் குறைக்கிறது என்றால், prefill compute-ஐத்தான். உங்கள் 20,000-token system prompt ஒவ்வொரு request-க்கும் செயலாக்கப்படாமல், ஒருமுறை மட்டுமே செயலாக்கப்படுகிறது. இது முதல் token-ஐப் பெறுவதற்கான நேரத்தை (time to first token) கணிசமாகக் குறைக்கிறது. vLLM-ல், பகிரப்பட்ட blocks நகலெடுக்கப்படாமல் மீண்டும் பயன்படுத்தப்படுவதால், நினைவகப் பயன்பாடும் (memory) மேம்படுகிறது. ஆனால், தற்போது பயன்பாட்டில் உள்ள tokens-க்காக நீங்கள் வைத்திருக்க வேண்டிய cache அளவை இது ஒருபோதும் குறைக்காது. request-களுக்கு இடையில் weights-ஐ நினைவகத்தில் வைத்திருப்பது இதனுடன் தொடர்புடைய ஆனால் தனித்துவமான ஒரு காரணியாகும், இது request-களுக்கு இடையில் Ollama model-ஐத் தொடர்ந்து வைத்திருத்தல் பகுதியில் விளக்கப்பட்டுள்ளது.

உங்கள் சொந்த கணினியில் எதை அளவிட வேண்டும்

உங்கள் இலக்கு context-ல் மாதிரியை (model) ஏற்றி, மதிப்பீடுகளை நம்புவதற்குப் பதிலாக உண்மையான எண்களைப் பார்க்கவும்.

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

ollama ps ஏற்றப்பட்ட மாதிரியின் அளவு மற்றும் அது GPU-ல் இயங்குகிறதா அல்லது CPU-ல் இயங்குகிறதா என்ற விவரத்தைப் பட்டியலிடுகிறது. முழுமையாக GPU-ல் இருக்கும் என்று நீங்கள் எதிர்பார்த்த மாதிரி, CPU-ல் இயங்குவதாகக் காட்டினால், KV cache அதன் ஒரு பகுதியை வெளியே தள்ளியுள்ளது என்று அர்த்தம்; இதனால் generation வேகம் குறையும். nvidia-smi உண்மையான VRAM அளவைக் காட்டுகிறது, free -g CPU-மட்டும் கொண்ட VPS-ல் அதே பணியைச் செய்கிறது. Context-ஐ படிப்படியாக உயர்த்தி, மீண்டும் ஏற்றி, அந்த எண்கள் மாறுவதைக் கவனிக்கவும். உங்கள் கணக்கீடும், காட்டப்படும் எண்ணும் நெருக்கமாக இருக்க வேண்டும். அவை பொருந்தவில்லை என்றால், அந்த இடைவெளி பொதுவாக runtime-ன் சொந்த compute buffers காரணமாக இருக்குமே தவிர, சூத்திரத்தில் உள்ள பிழையாக இருக்காது.

இந்த எண்கள் நீங்கள் வாடகைக்கு எடுக்க விரும்பாத வன்பொருளை (hardware) நோக்கி உங்களைத் தள்ளினால், token-க்கு பணம் செலுத்தும் முறைக்கும் இதற்கும் உள்ள ஒப்பீடு GPU VPS மற்றும் API tokens ஒப்பீடு பகுதியில் விளக்கப்பட்டுள்ளது.

FAQ

KV cache மற்றும் prompt caching ஆகிய இரண்டும் ஒன்றா?

இல்லை. KV cache என்பது ஒரு request-ஐ கையாளும் process-க்குள் இருக்கும் தற்காலிக நினைவகம் (memory). இது தற்போதைய context-ல் உள்ள ஒவ்வொரு token-க்கான key மற்றும் value vectors-ஐ வைத்திருக்கும். இது உங்கள் RAM அல்லது VRAM-ல் இருக்கும், request முடிந்தவுடன் நீக்கப்படும். Provider prompt caching என்பது ஒரு billing வசதி; இது ஒரு நிலையான prompt prefix-ஐ provider-ன் infrastructure-ல் சேமித்து வைக்கும். நீங்கள் அதை மீண்டும் அனுப்பும்போது குறைந்த கட்டணம் வசூலிக்கப்படும். KV cache தீர்ந்துவிட்டால், model-ஐ load செய்ய முடியாது. Prompt cache இல்லையென்றால், உங்கள் கட்டணம் அதிகரிக்கும் மற்றும் முதல் token-ஐப் பெறுவதற்கான நேரம் (time to first token) அதிகமாகும்.

எனது model 2k context-ல் load ஆகிறது, ஆனால் 32k-ல் ஏன் தோல்வியடைகிறது?

ஏனெனில், நீங்கள் அனுப்பும் prompt-க்கு ஏற்ப அல்லாமல், நீங்கள் configure செய்த context length-க்கு ஏற்ப runtime முழு KV cache-ஐயும் load செய்யும்போதே ஒதுக்கிவிடும். Llama 3.1 8B (f16) model-க்கு ஒரு token-க்கு 128 KiB தேவைப்படும். எனவே, 2k context-க்கு 0.25 GiB-ம், 32k-க்கு 4 GiB-ம் தேவைப்படும். இரண்டு நிலைகளிலும் model weights-க்கு இடம் உண்டு, ஆனால் இந்த ஒதுக்கீடு (reservation) செய்யும் இடத்தில்தான் தோல்வி ஏற்படுகிறது. vLLM இதை ஒரு ValueError பிழையாகக் காட்டி, அதில் சேமிக்கக்கூடிய அதிகபட்ச token எண்ணிக்கையைக் குறிப்பிடும். மேலும், gpu_memory_utilization-ஐ அதிகரிக்கவோ அல்லது max_model_len-ஐக் குறைக்கவோ பரிந்துரைக்கும். CPU-மட்டும் கொண்ட கணினிகளில், kernel-ன் out-of-memory killer அந்த process-ஐ முடித்துவிடும்; இதை dmesg -T | grep -i "killed process" மூலம் நீங்கள் உறுதிப்படுத்தலாம்.

எனது model-க்கான KV cache அளவை எவ்வாறு கணக்கிடுவது?

Layer எண்ணிக்கை, key/value heads எண்ணிக்கை, head dimension மற்றும் ஒரு element-க்கான bytes ஆகியவற்றை 2-ஆல் பெருக்கவும். இது ஒரு token-க்கான bytes அளவைத் தரும். பிறகு, அதை உங்கள் context length மற்றும் ஒரே நேரத்தில் இயங்கும் requests-ன் எண்ணிக்கையால் பெருக்கவும். Layer மற்றும் head எண்ணிக்கையை model-ன் config.json கோப்பிலிருந்து அறியலாம். f16 அல்லது bf16-க்கு ஒரு element-க்கு 2 bytes பயன்படுத்தவும். q8_0 cache இதற்கு பாதியளவு இருக்கும், q4_0 கால் பங்கு இருக்கும்.

Prompt caching எனது சொந்த server-ன் நினைவகத் தேவையை குறைக்குமா?

Provider prompt caching உங்கள் hardware-க்கு எந்த உதவியும் செய்யாது, ஏனெனில் சேமிப்பு provider-ன் பக்கமே நடக்கிறது. இதற்கு இணையான உள்ளூர் வசதி prefix caching ஆகும்; இது vLLM மற்றும் llama.cpp server இரண்டிலும் உள்ளது. இது ஏற்கனவே கணக்கிடப்பட்ட key மற்றும் value vectors-ஐ மீண்டும் பயன்படுத்துவதால், prefill compute குறையும் மற்றும் முதல் token-ஐப் பெறுவதற்கான நேரம் குறையும். vLLM-ல், shared blocks மீண்டும் பயன்படுத்தப்படுவதால், நினைவகப் பயன்பாடும் மேம்படும். ஆனால், இந்த வசதிகள் எதுவும் தற்போது இயங்கிக்கொண்டிருக்கும் tokens-க்குத் தேவையான cache-ஐக் குறைக்காது. எனவே, உங்கள் context மற்றும் concurrency கணக்கீடுகளே அடிப்படைத் தேவையைத் தீர்மானிக்கும்.

ஒருமுறை மட்டும் அனுப்பும் prompt-ஐ cache செய்வது பயனுள்ளதா?

இல்லை. ஆகஸ்ட் 2026 நிலவரப்படி, 5 நிமிட விருப்பத்திற்கு (option) cache write செய்வது சாதாரண input-ஐ விட 1.25 மடங்கு அதிக கட்டணம் கொண்டது. எனவே, அந்த காலக்கெடுவுக்குள் மீண்டும் பயன்படுத்தாத ஒரு prefix-ஐ cache செய்வது நஷ்டமே. ஒரே prefix மீண்டும் மீண்டும் பயன்படுத்தப்படும்போது மட்டுமே caching லாபகரமானது; உதாரணமாக, நீண்ட system prompt அல்லது பல கேள்விகளைக் கேட்கப்போகும் ஒரு ஆவணம். நீங்கள் cache hits பெறுகிறீர்களா அல்லது write-க்கு பணம் செலுத்துகிறீர்களா என்பதை உறுதிப்படுத்த API response-ல் உள்ள cache_read_input_tokens-ஐச் சரிபார்க்கவும்.