KV कैश ऑप्टिमाइज़ेशन: प्रोडक्शन LLMs के लिए मेमोरी दक्षता
अपडेटेड 11 दिसंबर, 2025
दिसंबर 2025 अपडेट: पारंपरिक इन्फरेंस फ्रैगमेंटेशन के कारण 60-80% KV कैश मेमोरी बर्बाद करता है। vLLM का PagedAttention वेस्ट को 4% से कम करके 2-4x थ्रूपुट सक्षम करता है। 8K कॉन्टेक्स्ट वाले 70B मॉडल को प्रति रिक्वेस्ट ~20GB कैश की आवश्यकता होती है, 32 के बैच के लिए ~640GB। KV कैश अब अक्सर मेमोरी खपत में मॉडल वेट्स से अधिक हो जाता है। ऑप्टिमाइज़ेशन तकनीकें मौजूदा हार्डवेयर पर लंबे कॉन्टेक्स्ट और बड़े बैच को सक्षम बना रही हैं।
LLM इन्फरेंस सिस्टम फ्रैगमेंटेशन और ओवर-एलोकेशन के कारण आवंटित KV कैश मेमोरी का 60-80% बर्बाद करते हैं।¹ यह बर्बादी सीधे कम थ्रूपुट, उच्च लागत और कॉन्टेक्स्ट लंबाई पर कृत्रिम सीमाओं में बदल जाती है। vLLM द्वारा पेश किए गए PagedAttention ने KV कैश वेस्ट को 4% से कम कर दिया, जिससे 2-4x थ्रूपुट सुधार संभव हुए जिन्होंने प्रोडक्शन इन्फरेंस अर्थशास्त्र को बदल दिया।² KV कैश ऑप्टिमाइज़ेशन तकनीकों को समझना संगठनों को GPU उपयोग को अधिकतम करने और मौजूदा इंफ्रास्ट्रक्चर से अधिक उपयोगकर्ताओं को सेवा देने में मदद करता है।
KV कैश मैनेजमेंट प्रोडक्शन LLM डिप्लॉयमेंट के लिए महत्वपूर्ण बॉटलनेक बन गया है। मेमोरी खपत सीक्वेंस लंबाई और बैच साइज़ के साथ रैखिक रूप से बढ़ती है, H100 और H200 जैसे हाई-मेमोरी GPUs को भी जल्दी समाप्त कर देती है। कैश ऑप्टिमाइज़ेशन तकनीकों में महारत हासिल करना लंबे कॉन्टेक्स्ट, बड़े बैच और स्केल पर अधिक लागत-प्रभावी इन्फरेंस को सक्षम बनाता है।
KV कैशिंग क्यों महत्वपूर्ण है
Transformer मॉडल प्रत्येक नया टोकन जेनरेट करते समय सभी पिछले टोकन पर attention कंप्यूट करते हैं। कैशिंग के बिना, 1,000 टोकन जेनरेट करने के लिए 1,000 बार स्क्रैच से attention को फिर से कंप्यूट करना पड़ता है—सीक्वेंस लंबाई के साथ लागत को वर्गात्मक रूप से बढ़ाता है।
KV कैशिंग समाधान: पिछले टोकन से key और value टेंसर स्टोर करें, उन्हें बाद के attention कैलकुलेशन के लिए पुन: उपयोग करें। प्रत्येक नया टोकन उन्हें फिर से जेनरेट करने के बजाय कैश्ड वैल्यूज़ के खिलाफ attention कंप्यूट करता है।
मेमोरी प्रभाव: बैच साइज़ 32 के साथ 8,192 टोकन जेनरेट करने वाले 70B पैरामीटर मॉडल को अकेले लगभग 40-50GB KV कैश मेमोरी की आवश्यकता होती है—अक्सर मॉडल वेट्स से भी अधिक।³
स्केलिंग समस्या: KV कैश मेमोरी इस प्रकार बढ़ती है:
Memory = batch_size × seq_length × num_layers × 2 × hidden_dim × precision_bytes
FP16 के साथ Llama 3.1-70B के लिए: - प्रति-टोकन कैश: ~2.5MB - 8K कॉन्टेक्स्ट: प्रति रिक्वेस्ट ~20GB - 32 का बैच: कुल ~640GB KV कैश
PagedAttention: मूलभूत ऑप्टिमाइज़ेशन
vLLM के PagedAttention ने GPU मेमोरी को ऑपरेटिंग सिस्टम वर्चुअल मेमोरी की तरह ट्रीट करके KV कैश मैनेजमेंट में क्रांति ला दी:⁴
यह कैसे काम करता है
पारंपरिक एलोकेशन: अधिकतम संभव सीक्वेंस लंबाई के लिए contiguous मेमोरी ब्लॉक रिज़र्व करें। 4K max कॉन्टेक्स्ट 100-टोकन रिक्वेस्ट के लिए भी 4K के बराबर कैश आवंटित करता है, रिज़र्व मेमोरी का 97.5% बर्बाद करता है।
पेज्ड एलोकेशन: KV कैश को फिक्स्ड-साइज़ ब्लॉक (पेज) में विभाजित करें। सीक्वेंस बढ़ने पर ऑन-डिमांड पेज आवंटित करें। सीक्वेंस पूरा होने पर पेज मुक्त करें।
ब्लॉक टेबल मैपिंग: OS पेज टेबल की तरह, PagedAttention लॉजिकल सीक्वेंस पोज़िशन और फिज़िकल मेमोरी लोकेशन के बीच मैपिंग बनाए रखता है। सीक्वेंस continuous मेमोरी देखते हैं जबकि फिज़िकल स्टोरेज non-contiguous रहता है।
प्रदर्शन प्रभाव
- मेमोरी वेस्ट: 60-80% → 4% से कम
- थ्रूपुट: पारंपरिक एलोकेशन की तुलना में 2-4x सुधार
- मेमोरी फ्रैगमेंटेशन: वस्तुतः समाप्त⁵
vLLM में इम्प्लीमेंटेशन
from vllm import LLM, SamplingParams
# PagedAttention डिफ़ॉल्ट रूप से सक्षम
llm = LLM(
model="meta-llama/Llama-3.1-70B-Instruct",
tensor_parallel_size=4,
gpu_memory_utilization=0.90, # GPU मेमोरी का 90% उपयोग करें
max_model_len=32768,
)
vLLM स्पष्ट कॉन्फ़िगरेशन के बिना स्वचालित रूप से पेज एलोकेशन, डीएलोकेशन और मेमोरी शेयरिंग का प्रबंधन करता है।
प्रीफिक्स कैशिंग और मेमोरी शेयरिंग
PagedAttention सामान्य प्रीफिक्स वाली रिक्वेस्ट में कुशल मेमोरी शेयरिंग सक्षम करता है:
शेयर्ड सिस्टम प्रॉम्प्ट: जब कई रिक्वेस्ट समान सिस्टम प्रॉम्प्ट का उपयोग करती हैं, तो उन टोकन को स्टोर करने वाले फिज़िकल पेज डुप्लीकेट होने के बजाय शेयर हो जाते हैं।
ऑटोमैटिक प्रीफिक्स कैशिंग: vLLM का Automatic Prefix Caching (APC) रिक्वेस्ट में सामान्य प्रीफिक्स का पता लगाता है और स्वचालित रूप से KV कैश ब्लॉक शेयर करता है:
llm = LLM(
model="meta-llama/Llama-3.1-8B-Instruct",
enable_prefix_caching=True,
)
प्रोडक्शन प्रभाव: consistent सिस्टम प्रॉम्प्ट या दोहराए गए कॉन्टेक्स्ट (सामान्य डॉक्यूमेंट के साथ RAG, few-shot उदाहरण) वाले एप्लिकेशन नाटकीय मेमोरी बचत और लेटेंसी कमी देखते हैं। अच्छी तरह से संरचित प्रॉम्प्ट के साथ 87%+ कैश हिट रेट प्राप्त किया जा सकता है।⁶
KV कैश क्वांटाइज़ेशन
KV कैश वैल्यूज़ को कंप्रेस करना मामूली एक्यूरेसी डिग्रेडेशन की कीमत पर मेमोरी आवश्यकताओं को कम करता है:
FP8 KV कैश
Hopper और Blackwell GPUs नेटिव FP8 KV कैश को सपोर्ट करते हैं:
# vLLM FP8 KV कैश
llm = LLM(
model="meta-llama/Llama-3.1-70B-Instruct",
kv_cache_dtype="fp8",
)
FP8 अधिकांश एप्लिकेशन के लिए न्यूनतम क्वालिटी प्रभाव के साथ FP16 की तुलना में KV कैश मेमोरी को आधा कर देता है। यह ऑप्टिमाइज़ेशन लॉन्ग-कॉन्टेक्स्ट इन्फरेंस के लिए आवश्यक हो जाता है जहां कैश मेमोरी खपत पर हावी होता है।
INT4 KV कैश
प्रयोगात्मक 4-बिट KV कैश सपोर्ट मेमोरी को और कम करता है:⁷ - मेमोरी कमी: FP16 की तुलना में 4x - क्वालिटी प्रभाव: टास्क-डिपेंडेंट, मूल्यांकन की आवश्यकता - सर्वश्रेष्ठ: मेमोरी-कंस्ट्रेन्ड लॉन्ग-कॉन्टेक्स्ट एप्लिकेशन के लिए
क्वांटाइज़ेशन चयन
| प्रेसिज़न | मेमोरी बचत | क्वालिटी प्रभाव | उपयोग केस |
|---|---|---|---|
| FP16 | बेसलाइन | कोई नहीं | डिफ़ॉल्ट, क्वालिटी-क्रिटिकल |
| FP8 | 50% | न्यूनतम | प्रोडक्शन इन्फरेंस |
| INT8 | 50% | कम | लागत-संवेदनशील डिप्लॉयमेंट |
| INT4 | 75% | मध्यम | अत्यधिक मेमोरी कंस्ट्रेंट |
कैश इविक्शन स्ट्रैटेजीज़
जब मेमोरी प्रेशर उपलब्ध क्षमता से अधिक हो जाता है, तो कैश इविक्शन पॉलिसी निर्धारित करती है कि कौन से टोकन ड्रॉप करने हैं:
स्लाइडिंग विंडो अटेंशन
कैश में केवल हाल के टोकन बनाए रखें, पुराने कॉन्टेक्स्ट को ड्रॉप करें:
# कॉन्सेप्चुअल स्लाइडिंग विंडो
def sliding_window_cache(kv_cache, window_size):
if len(kv_cache) > window_size:
kv_cache = kv_cache[-window_size:]
return kv_cache
उन एप्लिकेशन के लिए सरल लेकिन प्रभावी जहां हाल का कॉन्टेक्स्ट सबसे ज़्यादा मायने रखता है। आर्किटेक्चरल स्लाइडिंग विंडो (जैसे Mistral) इसे नेटिवली इम्प्लीमेंट करती है।
अटेंशन-बेस्ड इविक्शन
सबसे कम attention स्कोर वाले टोकन हटाएं, महत्वपूर्ण कॉन्टेक्स्ट रखें:
PagedEviction (2025): PagedAttention के लिए तैयार ब्लॉक-वाइज़ इविक्शन एल्गोरिदम जो CUDA कर्नेल को मॉडिफाई किए बिना कम-महत्व वाले ब्लॉक की पहचान करता है और हटाता है।⁸
एंट्रॉपी-गाइडेड कैशिंग: लेयर attention एंट्रॉपी के आधार पर कैश बजट आवंटित करें—ब्रॉड attention पैटर्न वाली लेयर को अधिक कैश मिलता है, फोकस्ड लेयर को कम।⁹
Streaming LLM
अनंत-लंबाई जनरेशन के लिए, Streaming LLM बनाए रखता है: - प्रारंभिक "attention sink" टोकन (पहले 4-8 टोकन) - स्लाइडिंग विंडो के भीतर हाल के टोकन - मध्य कॉन्टेक्स्ट को ड्रॉप करता है
यह दृष्टिकोण फिक्स्ड मेमोरी के साथ सैद्धांतिक रूप से असीमित जनरेशन सक्षम करता है, हालांकि लॉन्ग-रेंज डिपेंडेंसी की आवश्यकता वाले टास्क के लिए क्वालिटी कम हो जाती है।
KV कैश ऑफलोडिंग
जब GPU मेमोरी अपर्याप्त साबित हो, तो कैश को धीमे स्टोरेज टियर में ऑफलोड करें:
CPU ऑफलोडिंग
निष्क्रिय सीक्वेंस कैश को सिस्टम RAM में मूव करें:
# ऑफलोडिंग के लिए LMCache इंटीग्रेशन
from lmcache import LMCacheEngine
cache_engine = LMCacheEngine(
backend="cpu",
max_gpu_cache_size="20GB",
cpu_cache_size="100GB",
)
लेटेंसी प्रभाव: CPU-GPU ट्रांसफर प्रति कैश रिट्रीवल 10-50ms जोड़ता है। बैच वर्कलोड के लिए या जब GPU मेमोरी सीमाएं बिल्कुल भी सर्व करने से रोकती हैं, तब उपयुक्त।
प्रदर्शन: vLLM के साथ LMCache CPU मेमोरी में कैशिंग करके रीकंप्यूटेशन की तुलना में 3-10x लेटेंसी कमी प्राप्त करता है बजाय रीजेनरेट करने के।¹⁰
डिस्क ऑफलोडिंग
अत्यधिक मामलों में, NVMe स्टोरेज में कैश करें: - लेटेंसी: प्रति रिट्रीवल 100-500ms - उपयोग केस: बहुत लंबे कॉन्टेक्स्ट जो अन्यथा असंभव होंगे - इंटरैक्टिव एप्लिकेशन के लिए उपयुक्त नहीं
टियर्ड कैशिंग
प्रोडक्शन सिस्टम अक्सर मल्टी-टियर कैशिंग इम्प्लीमेंट करते हैं:
- GPU HBM: सक्रिय रूप से जेनरेट हो रहे हॉट सीक्वेंस
- CPU RAM: हाल ही में एक्टिव वार्म सीक्वेंस
- NVMe SSD: संभावित पुन: उपयोग के लिए कोल्ड सीक्वेंस
इंटेलिजेंट प्रमोशन और डीमोशन पॉलिसी एक्सेस पैटर्न के आधार पर टियर के बीच कैश मूव करती हैं।
KV कैश-अवेयर राउटिंग
डिस्ट्रीब्यूटेड इन्फरेंस को रिलेवेंट कैश रखने वाले पॉड्स में रिक्वेस्ट राउट करने से लाभ होता है:
llm-d फ्रेमवर्क
KV कैश-अवेयर राउटिंग के साथ Kubernetes-नेटिव फ्रेमवर्क:¹¹
# llm-d कैश राउटिंग कॉन्फ़िगरेशन
routing:
strategy: kv_cache_aware
cache_hit_weight: 0.8
load_balance_weight: 0.2
प्रदर्शन परिणाम: - प्रीफिक्स-हेवी वर्कलोड के साथ 87% कैश हिट रेट - वार्म कैश हिट के लिए 88% तेज़ time-to-first-token - क्लस्टर में रिडंडेंट कंप्यूटेशन में महत्वपूर्ण कमी
इम्प्लीमेंटेशन पैटर्न
स्टिकी सेशन: समान conversation से रिक्वेस्ट को समान पॉड में राउट करें।
प्रीफिक्स हैशिंग: पॉड राउटिंग निर्धारित करने के लिए सिस्टम प्रॉम्प्ट को हैश करें, प्रीफिक्स कैश हिट सुनिश्चित करें।
लोड-अवेयर राउटिंग: हॉटस्पॉट को रोकने के लिए पॉड उपयोग के खिलाफ कैश लोकैलिटी को बैलेंस करें।
प्रोडक्शन साइज़िंग गाइड
मेमोरी एस्टिमेशन
डिप्लॉयमेंट से पहले KV कैश आवश्यकताओं की गणना करें:
def estimate_kv_cache_memory(
num_layers: int,
hidden_dim: int,
num_kv_heads: int,
head_dim: int,
max_seq_len: int,
max_batch_size: int,
precision_bytes: int = 2, # FP16
) -> float:
"""GB में KV कैश मेमोरी का अनुमान लगाएं"""
per_token = num_layers * 2 * num_kv_heads * head_dim * precision_bytes
total = per_token * max_seq_len * max_batch_size
return total / (1024 ** 3)
# Llama 3.1-70B उदाहरण
memory_gb = estimate_kv_cache_memory(
num_layers=80,
hidden_dim=8192,
num_kv_heads=8, # GQA
head_dim=128,
max_seq_len=8192,
max_batch_size=32,
)
print(f"KV कैश मेमोरी: {memory_gb:.1f} GB")
क्षमता योजना
अंगूठे का नियम: KV कैश के लिए GPU मेमोरी का 40-60% रिज़र्व करें, शेष मॉडल वेट्स और एक्टिवेशन के लिए।
उदाहरण H100 80GB: - मॉडल वेट्स (70B FP16): ~140GB → tensor parallelism के साथ 2x GPU - कैश के लिए प्रति-GPU उपलब्ध: वेट्स और ओवरहेड के बाद ~30-35GB - अधिकतम समवर्ती सीक्वेंस: औसत कॉन्टेक्स्ट लंबाई पर निर्भर
ऑप्टिमाइज़ेशन प्राथमिकता
- PagedAttention सक्षम करें: vLLM में डिफ़ॉल्ट, प्रमुख दक्षता लाभ
- प्रीफिक्स कैशिंग सक्षम करें: यदि वर्कलोड में सामान्य प्रीफिक्स हैं
- FP8 KV कैश इम्प्लीमेंट करें: Hopper/Blackwell GPUs का उपयोग करते समय
- कैश-अवेयर राउटिंग जोड़ें: डिस्ट्रीब्यूटेड इन्फरेंस के साथ क्लस्टर स्केल पर
- ऑफलोडिंग पर विचार करें: केवल जब GPU मेमोरी अपर्याप्त साबित हो
मॉनिटरिंग और ऑब्ज़र्वेबिलिटी
प्रोडक्शन में KV कैश मेट्रिक्स ट्रैक करें:
प्रमुख मेट्रिक्स: - कैश उपयोग: उपयोग में आवंटित कैश का प्रतिशत - कैश हिट रेट: प्रीफिक्स कैश प्रभावशीलता - इविक्शन रेट: कैश ओवरफ्लो की आवृत्ति - मेमोरी फ्रैगमेंटेशन: आवंटित ब्लॉक के भीतर बर्बाद स्पेस
vLLM मेट्रिक्स एंडपॉइंट:
# Prometheus मेट्रिक्स /metrics पर उपलब्ध
# kv_cache_usage_percent
# kv_cache_total_blocks
# kv_cache_used_blocks
# prefix_cache_hit_rate
अलर्टिंग थ्रेशोल्ड: - कैश उपयोग > 90%: क्षमता स्केल करें या बैच साइज़ कम करें - हिट रेट < 50%: प्रीफिक्स कैशिंग कॉन्फ़िगरेशन की समीक्षा करें - इविक्शन रेट उच्च: मेमोरी एलोकेशन बढ़ाएं या प्रॉम्प्ट ऑप्टिमाइज़ करें
प्रोडक्शन LLM इन्फरेंस डिप्लॉय करने वाले संगठन ग्लोबल डिप्लॉयमेंट में GPU क्षमता योजना और ऑप्टिमाइज़ेशन के लिए Introl की इंफ्रास्ट्रक्चर विशेषज्ञता का लाभ उठा सकते हैं।
मेमोरी दक्षता अनिवार्यता
KV कैश ऑप्टिमाइज़ेशन प्रोडक्शन LLM डिप्लॉयमेंट के लिए सबसे उच्च-प्रभाव वाले सुधारों में से एक का प्रतिनिधित्व करता है। अकेले PagedAttention 2-4x थ्रूपुट सुधार प्रदान करता है—अतिरिक्त हार्डवेयर लागत के बिना GPU निवेश को दोगुना या चौगुना करने के बराबर।
ऑप्टिमाइज़ेशन लैंडस्केप विकसित होता जा रहा है। Microsoft के FastGen ने adaptive compression के माध्यम से 50% मेमोरी कमी प्रदर्शित की। एंट्रॉपी-गाइडेड कैशिंग लेयर में बुद्धिमानी से बजट आवंटित करता है। कैश-अवेयर राउटिंग पहले असंभव क्लस्टर-स्केल दक्षता लाभ सक्षम करता है।
स्केल पर इन्फरेंस चलाने वाले संगठनों के लिए, KV कैश ऑप्टिमाइज़ेशन को मूल्यांकन किए गए पहले ऑप्टिमाइज़ेशन में से एक के रूप में रैंक करना चाहिए। तकनीकों को न्यूनतम आवश्यकता होती है
