KV cache आणि prompt cache मधील मुख्य फरक काय आहे?

KV cache आणि prompt cache मधील फरक: थोडक्यात उत्तर

KV cache आणि प्रोव्हायडरची prompt cache यामध्ये फक्त 'cache' हा शब्द समान आहे, बाकी काहीही नाही. KV cache ही प्रत्येक विनंतीसाठी (per-request) लागणारी वर्किंग मेमरी असते. ती एका विनंतीच्या संपूर्ण कालावधीत तुमच्या सर्व्हरच्या RAM किंवा VRAM मध्ये राहते. जसा कॉन्टेक्स्टचा आकार वाढतो आणि एकाच वेळी अनेक विनंत्या येतात, तशी ही मेमरी वाढत जाते. प्रोव्हायडरची prompt caching हे बिलिंग आणि लॅटन्सी कमी करण्याचे एक फिचर आहे. तुमच्या प्रॉम्प्टचा एक स्थिर भाग (prefix) प्रोव्हायडरच्या सर्व्हरवर साठवला जातो आणि जेव्हा तुम्ही तो पुन्हा पाठवता, तेव्हा त्यावर सवलतीच्या दरात शुल्क आकारले जाते.

एक म्हणजे तुम्ही हार्डवेअर म्हणून विकत घेतलेली मेमरी, तर दुसरी म्हणजे दुसऱ्या कोणाकडे तरी असलेली मेमरी, ज्याचे भाडे तुम्ही भरता.

व्यावहारिक फरक हा व्याख्येपेक्षा जास्त महत्त्वाचा आहे. तुमची KV cache संपू शकते; असे झाल्यास मॉडेल लोड होण्यास नकार देते किंवा विनंती नाकारली जाते. तुम्ही prompt cache संपवू शकत नाही. तुम्ही फक्त ती वापरण्यात (hit) अपयशी ठरू शकता, ज्याचा परिणाम असा होतो की तुम्हाला पूर्ण किंमत मोजावी लागते.

KV cache मध्ये काय साठवले जाते आणि ते का आवश्यक आहे

जेव्हा एखादा transformer 500 व्या क्रमांकाचे टोकन तयार करत असतो, तेव्हा त्याला त्याआधीच्या सर्व 499 टोकन्सकडे लक्ष द्यावे लागते. या प्रत्येक टोकनसाठी, प्रत्येक लेयरला एक key vector आणि value vector ची आवश्यकता असते. प्रत्येक नवीन टोकनसाठी हे सर्व पुन्हा मोजल्यास, generation चा वेळ लांबीच्या वर्गाच्या प्रमाणात (square of the length) वाढेल. त्यामुळे, runtime हे vectors साठवून ठेवते. या साठवणुकीला KV cache (key/value cache) म्हणतात.

ही स्थिती प्रत्येक request साठी स्वतंत्र असते, कारण ती त्या विशिष्ट request च्या टोकन क्रमानुसार तयार केलेली असते. दोन वापरकर्ते वेगवेगळे prompts पाठवत असतील, तर ते हा cache शेअर करू शकत नाहीत. जोपर्यंत runtime 'prefix caching' वापरत नाही, जे एक वेगळे वैशिष्ट्य आहे आणि पुढे स्पष्ट केले आहे.

सर्व्हिंग दोन टप्प्यांत होते. Prefill टप्प्यात तुमचा संपूर्ण prompt वाचला जातो आणि cache भरला जातो; हे प्रक्रियेच्या क्षमतेवर (compute) अवलंबून असते. Decode टप्प्यात एका वेळी एक टोकन तयार केले जाते आणि ते cache मध्ये जोडले जाते; हे मेमरी बँडविड्थवर अवलंबून असते. या विभाजनामुळेच prompt प्रोसेसिंग आणि टोकन जनरेशनचा वेग तुमच्या स्वतःच्या मशीनवर टोकन्स प्रति सेकंद मोजताना वेगवेगळा दिसतो.

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 चे उदाहरण घेऊ. त्याच्या config मध्ये 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 मध्ये 8 key/value heads आहेत जे 32 query heads ला सेवा देतात, त्यामुळे चार query heads एक साठवलेली key/value जोडी शेअर करतात. ज्या मॉडेलचा num_key_value_heads त्याच्या num_attention_heads इतका असतो, ते मॉडेल समान parameter count वर चार पट जास्त cache वापरते. दोन 8B मॉडेल्स सर्व्ह करण्याचा खर्च समान असेल असे गृहीत धरण्यापूर्वी ते एक field तपासा.

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 file तयार करणे नव्हे: कारण डिस्कवर पेज केलेली KV cache प्रत्येक जनरेट होणाऱ्या टोकनसाठी वाचावी लागते, ज्यामुळे जनरेशनचा वेग इतका मंदावतो की ते निरुपयोगी ठरते. योग्य आकडा कसा निवडावा हे Ollama मधील num_ctx आणि कॉन्टेक्स्ट लेंथवरील आमच्या मार्गदर्शिकेमध्ये दिले आहे.

कॉन्करन्सीचा (concurrency) संख्येवर होणारा परिणाम

प्रत्येक इन-फ्लाईट विनंती स्वतःचा KV cache सोबत ठेवते. क्षमता नियोजनामध्ये (capacity planning) बहुतेक वेळा हाच मुद्दा दुर्लक्षित केला जातो. प्रत्येकी 32k कॉन्टेक्स्ट असलेल्या चार वापरकर्त्यांना मॉडेलच्या वेट्सव्यतिरिक्त (weights) 16 GiB मेमरीची आवश्यकता असते.

हे किती काटेकोरपणे पाळले जाते, यात रनटाइम्समध्ये फरक असतो. Ollama आणि llama.cpp मॉडेल लोड होतानाच तुम्ही मागितलेला कॉन्टेक्स्ट रिझर्व्ह करतात, त्यामुळे कोणी वापरले असो वा नसो, मेमरी कमिट केलेली असते. vLLM पूलचे रूपांतर निश्चित आकाराच्या ब्लॉक्समध्ये करते आणि विनंती जशी वाढेल तसे ते वाटप करते, त्यामुळे 500-टोकनची विनंती फक्त 500 टोकन्सइतकीच मेमरी वापरते. दोन्ही पद्धतींमध्ये पूल मर्यादित असतो आणि तो एकदा भरला की, नवीन विनंत्या रन होण्याऐवजी रांगेत (queue) उभ्या राहतात. ही रांग रिस्पॉन्स टाइमवर काय परिणाम करते, हे self-hosted LLM किती कॉन्करंट वापरकर्त्यांना सर्व्ह करू शकते यामध्ये स्पष्ट केले आहे.

KV cache लहान करण्याचे चार मार्ग

1. कॉन्टेक्स्टची लांबी (context length) कमी करा. हा सर्वात प्रभावी उपाय आहे आणि सहसा सर्वात स्वस्त पडतो. बहुतेक चॅट वर्कलोड्समध्ये 32k पर्यंतची गरज कधीच भासत नाही.
2. कॅशेचेच क्वांटायझेशन (quantise) करा. Ollama चे OLLAMA_KV_CACHE_TYPE डीफॉल्टनुसार f16 वापरते आणि q8_0 ला सपोर्ट करते, ज्यामुळे मेमरीचा वापर साधारण निम्म्यावर येतो, तसेच q4_0 वापरल्यास तो पावभागावर येतो. llama.cpp मधील याचे समतुल्य पर्याय -ctk q8_0 आणि -ctv q8_0 हे आहेत.
3. कमी key/value हेड्स किंवा कमी लेयर्स असलेले मॉडेल निवडा. 40 GB वजनाचे मॉडेल्स डाउनलोड करण्यापूर्वी config.json वाचा.
4. एका वेळी कमी विनंत्या (requests) सर्व्ह करा आणि उर्वरित विनंत्या रांगेत (queue) ठेवा.

q4_0 वर Llama 3.1 8B चा आकडा प्रति टोकन 128 KiB वरून साधारण 32 KiB पर्यंत खाली येतो, त्यामुळे 32k कॉन्टेक्स्टसाठी 4 GiB ऐवजी फक्त 1 GiB खर्च येतो. ही बचत विनामूल्य नाही. की (keys) आणि व्हॅल्यूज (values) कमी अचूकतेसह साठवल्या जातात, त्यामुळे कायमस्वरूपी वापरण्यापूर्वी तुमच्या स्वतःच्या प्रॉम्प्ट्सवर आउटपुटची तुलना करून खात्री करा.

प्रोव्हायडर प्रॉम्प्ट कॅशिंगचा प्रत्यक्ष फायदा काय आहे

प्रोव्हायडर प्रॉम्प्ट कॅशिंग हे एक वेगळे उत्पादन असून त्याचे मोजमाप करण्याचे एककही वेगळे आहे. तुम्ही एक स्थिर प्रीफिक्स (prefix) चिन्हांकित करता, प्रोव्हायडर तो साठवून ठेवतो आणि नंतर जेव्हा त्याच प्रीफिक्सचा वापर करून विनंत्या केल्या जातात, तेव्हा पूर्ण इनपुट किमतीऐवजी सवलतीच्या दरात बिल आकारले जाते.

ऑगस्ट 2026 पर्यंत Anthropic ने प्रसिद्ध केलेले मल्टिप्लायर्स खालीलप्रमाणे आहेत: 5-मिनिटांच्या कॅशे राईटसाठी मूळ इनपुट टोकन किमतीच्या 1.25 पट खर्च येतो. 1-तासाच्या राईटसाठी 2 पट खर्च येतो आणि कॅशे रीडसाठी 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 विरुद्ध 20,000 (जेव्हा ते कॅश न करता पाठवले जाते). त्या कालावधीत नंतर येणाऱ्या प्रत्येक कॉलसाठी 20,000 ऐवजी 2,000 बिल आकारले जाते, म्हणजेच 18,000 टोकन्सची बचत होते. त्यामुळे, दुसऱ्या कॉलपासून 5-मिनिटांचे कॅशे फायदेशीर ठरते.

1-तासाचे कॅशे हे एक वेगळे गणित आहे. राईट करताना ते 40,000 बिल आकारते, जो 20,000 टोकन इतका प्रीमियम आहे. त्यामुळे फायद्यात येण्यासाठी एका तासाच्या आत किमान दोन हिट्स मिळणे आवश्यक आहे. हा प्रश्न तुमच्या ट्रॅफिक पॅटर्नशी संबंधित आहे, मॉडेलशी नाही. विंडो कशी निवडावी यासह संपूर्ण गणना Claude प्रॉम्प्ट कॅशिंगसाठी ब्रेक-इव्हन गणित मध्ये दिली आहे.

तुम्ही कॅशे वापरू शकता की नाही हे दोन तपशीलांवर अवलंबून असते. पहिले, मॉडेलच्या किमान लांबीपेक्षा कमी असलेला प्रीफिक्स आपोआप कॅश केला जात नाही: ऑगस्ट 2026 पर्यंत, Claude Opus 5 साठी किमान 512 टोकन्स आणि Claude Sonnet 5 साठी 1,024 टोकन्स अशी मर्यादा आहे. यापेक्षा लहान विनंती सामान्यपणे प्रक्रिया केली जाते आणि कोणतीही त्रुटी (error) दिली जात नाही. दुसरे, कॅशेचे आयुष्य (lifetime) एंट्री लिहिणाऱ्या किंवा वाचणाऱ्या विनंतीच्या सुरुवातीपासून मोजले जाते आणि प्रत्येक रीडमुळे ते विनामूल्य रिफ्रेश होते. त्यामुळे, ज्या एंडपॉईंटवर सतत ट्रॅफिक असते, तिथे 5-मिनिटांचे कॅशे अनिश्चित काळासाठी जिवंत राहते. मात्र, दर दहा मिनिटांनी एकदा कॉल होणाऱ्या एंडपॉईंटला प्रत्येक वेळी राईट प्रीमियम भरावा लागतो आणि त्याचा कोणताही फायदा मिळत नाही.

गृहीत धरण्याऐवजी रिस्पॉन्स तपासा. usage ऑब्जेक्ट cache_creation_input_tokens आणि cache_read_input_tokens बद्दल माहिती देते. प्रत्येक कॉलवर रीड काउंट शून्य असणे म्हणजे तुम्ही राईटसाठी पैसे मोजत आहात पण तुम्हाला काहीही फायदा मिळत नाहीये.

जिथे दोन कॅशे एकत्र येतात

एक मोठा सिस्टिम प्रॉम्प्ट हे असे ठिकाण आहे जिथे हे दोन्ही एकत्र येतात आणि त्याचे शुल्क दोन्ही बाजूंनी एकाच वेळी आकारले जाते.

स्थानिक पातळीवर (Locally), Llama 3.1 8B सर्व्हरवर f16 फॉरमॅटमध्ये 20,000-टोकनचा सिस्टिम प्रॉम्प्ट सुमारे 2.4 GiB KV कॅशे व्यापतो आणि तो समाविष्ट असलेल्या प्रत्येक समवर्ती (concurrent) विनंतीसाठी स्वतंत्रपणे केला जातो. रिमोटली, तोच प्रीफिक्स एका कॅशे राईटसाठी खर्च होतो आणि त्यानंतरच्या प्रत्येक कॉलवर इनपुटच्या 0.1 पट खर्च होतो. स्थानिक खर्च तुमच्या वापरकर्त्यांच्या संख्येनुसार वाढतो. रिमोट खर्च तुमच्या ट्रॅफिकनुसार वाढतो आणि आयडल वेळेत रिसेट होतो.

एक स्थानिक फिचर आहे जे प्रोव्हायडर प्रॉम्प्ट कॅशिंगसारखे दिसते आणि त्यामुळे सतत गोंधळ होतो: ते म्हणजे प्रीफिक्स कॅशिंग. vLLM डॉक्युमेंटेशन स्वयंचलित प्रीफिक्स कॅशिंगचे वर्णन "विद्यमान क्वेरीजचा KV कॅशे साठवणे, जेणेकरून नवीन क्वेरी जर विद्यमान क्वेरीजपैकी एकाशी समान प्रीफिक्स शेअर करत असेल, तर ती थेट KV कॅशेचा पुनर्वापर करू शकेल" असे करते. llama.cpp सर्व्हर डीफॉल्टनुसार प्रत्येक स्लॉटसाठी एक प्रॉम्प्ट कॅशे ठेवतो आणि --cache-reuse N तो पुनर्वापर करण्याचा प्रयत्न करेल अशा सर्वात लहान तुकड्याचा आकार निश्चित करतो.

प्रीफिक्स कॅशिंगमुळे प्रीफिल कॉम्प्युटची बचत होते. तुमचा 20,000-टोकनचा सिस्टिम प्रॉम्प्ट प्रत्येक विनंतीवर प्रक्रिया करण्याऐवजी एकदाच प्रक्रिया केला जातो, ज्यामुळे पहिल्या टोकनसाठी लागणारा वेळ लक्षणीयरीत्या कमी होतो. vLLM मध्ये शेअर केलेले ब्लॉक्स डुप्लिकेट करण्याऐवजी पुन्हा वापरले जातात, त्यामुळे मेमरीचा वापरही सुधारतो. हे कधीही सध्या सक्रिय असलेल्या टोकन्ससाठी तुम्हाला ठेवावा लागणारा कॅशे कमी करत नाही. विनंत्यांच्या दरम्यान वेट्स (weights) मेमरीमध्ये ठेवणे हे एक संबंधित पण वेगळे साधन आहे, ज्याची माहिती keeping an Ollama model loaded between requests मध्ये दिली आहे.

तुमच्या स्वतःच्या सर्व्हरवर काय मोजावे

तुमच्या टार्गेट कॉन्टेक्स्टवर मॉडेल लोड करा, त्यानंतर अंदाजावर विश्वास ठेवण्याऐवजी प्रत्यक्ष आकडेवारी तपासा.

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 ही सर्व्हिंग प्रक्रियेतील प्रति-विनंती (per-request) मेमरी आहे, जी सध्याच्या कॉन्टेक्स्ट मधील प्रत्येक टोकनसाठी की (key) आणि व्हॅल्यू (value) वेक्टर्स साठवून ठेवते. ही मेमरी तुमच्या RAM किंवा VRAM मध्ये असते आणि विनंती पूर्ण झाल्यावर ती मोकळी केली जाते. प्रोव्हायडरचे prompt caching हे बिलिंगशी संबंधित फिचर आहे, जे प्रोव्हायडरच्या इन्फ्रास्ट्रक्चरवर एक स्थिर प्रॉम्प्ट प्रीफिक्स साठवते आणि तुम्ही तो पुन्हा पाठवल्यास कमी दर आकारते. KV cache संपल्यामुळे मॉडेल लोड होणे थांबते. प्रॉम्प्ट कॅशे नसल्यास फक्त तुमचे बिल वाढते आणि पहिल्या टोकनसाठी लागणारा वेळ (time to first token) वाढतो.

माझे मॉडेल 2k कॉन्टेक्स्टवर लोड होते पण 32k वर का अपयशी ठरते?

कारण रनटाइम लोड होतानाच संपूर्ण KV cache अलोकेट करतो. हे अलोकेशन तुम्ही कॉन्फिगर केलेल्या कॉन्टेक्स्ट लांबीनुसार असते, तुम्ही पाठवलेल्या प्रॉम्प्टनुसार नाही. Llama 3.1 8B (f16) साठी कॅशे प्रति टोकन 128 KiB असते, त्यामुळे 2k कॉन्टेक्स्टसाठी 0.25 GiB आणि 32k साठी 4 GiB जागा लागते. दोन्ही प्रकरणांत मॉडेलचे वेट्स (weights) मावतात, पण मेमरी रिझर्व्हेशन अपयशी ठरते. vLLM हे ValueError म्हणून रिपोर्ट करते, ज्यामध्ये ते साठवू शकणाऱ्या टोकन्सची कमाल संख्या सांगते आणि gpu_memory_utilization वाढवण्याचा किंवा max_model_len कमी करण्याचा सल्ला देते. फक्त CPU असलेल्या मशीनवर कर्नलचा out-of-memory killer ही प्रक्रिया बंद करतो, जे तुम्ही dmesg -T | grep -i "killed process" वापरून तपासू शकता.

माझ्या मॉडेलसाठी KV cache चा आकार कसा मोजावा?

लेयरची संख्या, की/व्हॅल्यू हेड्सची संख्या, हेड डायमेंशन आणि प्रति एलिमेंट बाइट्स यांना 2 ने गुणा. यातून तुम्हाला प्रति टोकन लागणारे बाइट्स मिळतील. त्यानंतर याला तुमच्या कॉन्टेक्स्टची लांबी आणि एकाच वेळी येणाऱ्या विनंत्यांच्या (concurrent requests) संख्येने गुणा. लेयर आणि हेडची संख्या मॉडेलच्या config.json मधून मिळवा. f16 किंवा bf16 साठी प्रति एलिमेंट 2 बाइट्स वापरा. q8_0 कॅशेचा आकार याच्या निम्म्या असतो आणि q4_0 चा आकार साधारण एक चतुर्थांश असतो.

prompt caching मुळे माझ्या स्वतःच्या सर्व्हरला लागणारी मेमरी कमी होते का?

प्रोव्हायडरचे prompt caching तुमच्या हार्डवेअरसाठी काहीही करत नाही, कारण ते स्टोरेज प्रोव्हायडरच्या बाजूला असते. स्थानिक पातळीवर याला पर्याय म्हणून vLLM आणि llama.cpp सर्व्हरद्वारे prefix caching दिले जाते. हे फिचर सामायिक प्रीफिक्ससाठी आधीच गणना केलेले की आणि व्हॅल्यू वेक्टर्स पुन्हा वापरते, ज्यामुळे प्रीफिल कॉम्प्युटेशन वाचते आणि पहिल्या टोकनसाठी लागणारा वेळ कमी होतो. vLLM मध्ये सामायिक ब्लॉक्स पुन्हा वापरले जातात, त्यामुळे मेमरीचा वापरही सुधारतो. मात्र, दोन्हीपैकी कोणतेही फिचर सध्या चालू असलेल्या टोकन्ससाठी लागणारी कॅशे कमी करत नाही, त्यामुळे तुमचे कॉन्टेक्स्ट आणि कॉनकरन्सीचे गणितच मेमरीची किमान मर्यादा ठरवते.

मी एकदाच पाठवलेला प्रॉम्प्ट कॅशे करणे फायदेशीर आहे का?

नाही. ऑगस्ट 2026 पर्यंतच्या दरानुसार, 5-मिनिटांच्या पर्यायासाठी कॅशे राईटचा खर्च मूळ इनपुटच्या 1.25 पट आहे, त्यामुळे जो प्रीफिक्स तुम्ही त्या कालावधीत पुन्हा कधीच पाठवत नाही, तो कॅशे करणे म्हणजे थेट नुकसान आहे. जेव्हा एखादा प्रीफिक्स वारंवार वापरला जातो, जसे की मोठा सिस्टम प्रॉम्प्ट किंवा एखादा दस्तऐवज ज्यावर तुम्ही अनेक प्रश्न विचारणार आहात, तेव्हाच कॅशिंग फायदेशीर ठरते. तुम्ही राईटसाठी पैसे न भरता हिट्स मिळवत आहात हे तपासण्यासाठी API रिस्पॉन्स मधील cache_read_input_tokens तपासा.