"यह model 128K context support करता है" सुनने में शानदार लगता है – जब तक आप इसे चलाने की कोशिश न करें और सोचें कि आपकी सारी memory कहाँ चली गई। इसका कारण KV cache है: LLM का वह हिस्सा जो context के हर token के साथ बढ़ता है, और यही कारण है कि बड़ा context window वास्तव में gigabytes खर्च करता है।
यह गाइड बताती है कि KV cache क्या है, यह इस तरह scale क्यों करता है, और आप अपने hardware पर किसी भी context window के लिए कितनी memory चाहिए, इसकी सटीक गणना कैसे कर सकते हैं।
KV cache क्या है
जब LLM किसी token को process करता है, तो वह बहुत अधिक computation करता है – और महत्वपूर्ण रूप से, बाद के tokens को समझने के लिए उसे पहले वाले tokens के परिणामों की आवश्यकता होती है। प्रत्येक token का अतीत के प्रति attention हर layer में दो चीज़ों से बनता है: एक key (यह token क्या offer करता है) और एक value (इसमें क्या निहित है)।
हर नए token पर पिछले सभी tokens की keys और values को दोबारा compute करने के बजाय – जिससे generation quadratically धीमी हो जाएगी – model उन्हें store कर लेता है। वही store KV cache है। Context में हर token, हर layer और हर attention head में एक निश्चित मात्रा जोड़ता है।
यह context के साथ linearly memory क्यों खाता है
यहाँ मुख्य तथ्य यह है: KV cache model के size से नहीं, बल्कि tokens की संख्या के साथ बढ़ता है। अधिक context = अधिक cached keys और values। Context को दोगुना करें तो KV cache लगभग दोगुना हो जाता है।
dense model के लिए अनुमानित size है:
KV cache ≈ layers × kv_heads × head_dim × 2 × bytes_per_value × context
सटीक आँकड़े model architecture पर निर्भर करते हैं। व्यावहारिक बात यह है: 7B या 13B जैसे mid-size model के लिए, बड़े context (जैसे 32K या 128K) पर KV cache आसानी से weights के बराबर या उससे बड़ा हो सकता है।
वास्तविक आँकड़े
इसे व्यवहार में देखने के लिए, LLM VRAM Calculator आपके सटीक model, quantization और context के लिए weights + KV cache का ब्रेकडाउन देता है। कुछ उदाहरण:
- Q4 पर 7B model 8K context के साथ: KV cache लगभग 1 GB – कुल ~4 GB का एक छोटा हिस्सा।
- वही model 32K context पर: KV cache बढ़कर ~4 GB हो जाता है, अब weights के बराबर।
- Q4 पर 32B model 64K context के साथ: केवल KV cache ही 8–12 GB हो सकता है – कई GPU से अधिक।
इसलिए "8K context पर चलता है" और "128K context पर चलता है" एक ही model के लिए भी पूरी तरह अलग hardware आवश्यकताएँ हैं।
इसे कैसे कम करें
यदि KV cache आपकी memory खा रहा है, तो आपके पास कुछ विकल्प हैं:
- Context window (
-c) कम करें – सबसे बड़ा लीवर। model जितना support करता है उतना नहीं, बल्कि जितना आपको चाहिए उतना ही context उपयोग करें। - KV cache को quantize करें (
q8_0,q4_0) – keys/values को 8-bit या 4-bit में store करने से cache लगभग आधा या एक-चौथाई रह जाता है, और अधिकांश tasks के लिए quality में बहुत कम गिरावट आती है। - MoE या long-context-optimized model उपयोग करें – MoE model जैसे Ornith 35B tokens के बीच KV को share करते हैं, जिससे cache dense model की तुलना में छोटा रहता है।
- Offload करें – llama.cpp KV cache का हिस्सा system RAM में रख सकता है, गति की कीमत पर।
आप q8 KV का प्रभाव हमारे Qwen 27B Lab test में देख सकते हैं, जहाँ q8 KV के साथ 16K, partial offload के साथ 12 GB कार्ड पर मुश्किल से fit हुआ।
MoE vs dense (क्यों अंतर है)
dense model हर token को अपने सभी parameters से process करता है। MoE model हर token को केवल कुछ "expert" layers से routing करता है – लेकिन KV cache की कहानी अलग है। चूँकि attention सभी tokens में share होता है, भले ही उन्हें किस expert ने handle किया हो, MoE model कुछ configurations में प्रति token छोटा KV cache रख सकते हैं। यही एक कारण है कि 35B MoE 262K context पर चल सकता है जहाँ 35B dense कभी नहीं चल पाता। Head-to-head के लिए MoE vs Dense Lab test देखें।
निष्कर्ष
KV cache LLM की छिपी हुई memory लागत है, और यह context के हर token के साथ बढ़ती है। जब कोई model कहता है कि वह "128K support करता है", तो यह एक ऊपरी सीमा है, सिफारिश नहीं। आपको वास्तव में जितने context की आवश्यकता है उतना ही उपयोग करें, KV cache को quantize करें, और commit करने से पहले VRAM calculator जाँच लें – और आपका model आधी memory में चल जाएगा।