128k कॉन्टेक्स्ट डेस्कटॉप पर झूठ है। KV कैश ने उसे निगल लिया।

हर लोकल मॉडल कार्ड अब 128k कॉन्टेक्स्ट की बात करता है। डेस्कटॉप पर वह अंक एक ऐसी लीज़ है जिस पर आपकी RAM ने बिना पढ़े दस्तखत कर दिए। लंबा डॉक्यूमेंट कितना खिंचेगा, यह वेट नहीं तय करते — KV कैश तय करता है, और वह किसी और की मुद्रा में तय हुआ टैक्स है जो कॉन्टेक्स्ट के साथ बढ़ता है।

कॉन्टेक्स्ट विंडो कोई ऐसा फीचर नहीं जिसे आप ऑन-ऑफ करें। यह मेमोरी की लीज़ है, जो सर्वर चलने की हर सेकंड चुकती है।

128k कॉन्टेक्स्ट असल में कितनी RAM खाता है?

गणित सार्वजनिक है और छोटा। जैसा Transformer Inference Arithmetic समझाता है, KV कैश हर लेयर, हर KV हेड, हर टोकन के लिए दो टेंसर रखता है — key और value:

cache_bytes = 2 × लेयर × कॉन्टेक्स्ट × kv_हेड × head_dim × प्रति_तत्व_बाइट

Llama 3.1 8B लीजिए: 32 लेयर, 8 KV हेड, head_dim 128 — सीधे Hugging Face के config.json से। fp16 (2 बाइट) में 131,072 टोकन पर:

2 × 32 × 131072 × 8 × 128 × 2 = 17,179,869,184 बाइट ≈ 16 GiB

उसी मॉडल के fp16 वेट करीब 16 GiB हैं। अधिकतम कॉन्टेक्स्ट पर कैश उतना ही बड़ा है जितना जिस मॉडल का वह हिस्सा है। “16 GiB में समाने वाला 8B मॉडल” अनायास 32 GiB की समस्या बन जाता है, जिस पल आप num_ctx को 128k पर चढ़ाते हैं।

कैश विंडो के साथ क्यों बढ़ता है?

क्योंकि अटेंशन को हर टोकन की तुलना उससे पहले के हर टोकन से करनी होती है, और इन्फ़रेंस ऑटोरिग्रेसिव है — कुछ भी दोबारा नहीं गिना जाता, सब याद रखा जाता है। जनरेशन को तेज़ बनाने का पूरा जुगाड़ यही है: हर टोकन की key और value एक बार गिनकर संभाल ली जाती हैं। प्रति टोकन भंडारण स्थिर है, इसलिए कुल भंडारण कॉन्टेक्स्ट के साथ रेखीय बढ़ता है। 128k कोई “बड़ा आँकड़ा” नहीं — 1k विंडो के कैश का 128 गुना है, पूरे सेशन के लिए आरक्षित।

Grouped-query attention (GQA) मॉडल-साइड छूट है: कम KV हेड, दुबला कैश। Qwen2.5 7B में 28 लेयरों पर सिर्फ 4 KV हेड हैं (config यहाँ), इसलिए वही 128k विंडो fp16 में लगभग 7 GiB खाती है — असली राहत, और इन मॉडलों के मामूली मशीनों पर दोस्ताना लगने का एक कारण।

मॉडल (fp16)	लेयर × KV हेड	KV कैश @ 128k	वेट	कैश बनाम वेट
Llama 3.1 8B	32 × 8	~16 GiB	~16 GiB	~100%
Qwen2.5 7B	28 × 4	~7 GiB	~15 GiB	~47%

हिसाब खुद चलाइए — पूरी जाँच बस इतनी है:

def kv_cache_gib(layers, kv_heads, head_dim, ctx, bytes_per=2):
    return 2 * layers * ctx * kv_heads * head_dim * bytes_per / 2**30

print(kv_cache_gib(32, 8, 128, 131_072))  # Llama 3.1 8B  -> 16.0
print(kv_cache_gib(28, 4, 128, 131_072))  # Qwen2.5 7B    -> 7.0

मार्केटिंग वाला आँकड़ा क्या छिपाता है

इस तर्क का ईमानदार खाता यहाँ है — जहाँ वह झुकता भी है, वहीं सहित:

• prefill दूसरा बिल है। पहले जवाबी टोकन से पहले पूरा प्रॉम्प्ट एक साथ प्रोसेस होता है। 100k टोकन का प्रॉम्प्ट मतलब पहला अक्षर देखने से पहले 100k टोकन चबाना। 3060 पर यह मिलीसेकंड नहीं, मिनट हैं।
• sliding-window मॉडल गणित तोड़ देते हैं — आपके पक्ष में। Mistral-शैली के आर्किटेक्चर हर लेयर में अटेंशन को स्थिर विंडो तक सीमित करते हैं, कैश बढ़ना बंद कर देता है। सरल फॉर्मूला उन्हें बढ़ा-चढ़ाकर गिनता है। यह लेख पूर्ण-अटेंशन ट्रांसफॉर्मर के बारे में है — जो लोग ज़्यादातर चलाते हैं।
• KV क्वांटाइज़ेशन असली है, पर आंशिक। llama.cpp KV को q8_0 में रख सकता है — कैश लगभग आधा, गुणवत्ता का कुछ जोखिम। 16 GiB का आधा भी 8 GiB ही है।
• स्पेशिफिकेशन KV हेड बताती ही नहीं। config.json खुरचना पड़ता है — यह अपने आप बता देता है कि वह आँकड़ा किस नज़र से पढ़ा जाना चाहता है।

इनमें से कोई बात लंबे कॉन्टेक्स्ट को बेकार नहीं ठहराती। RAG इसीलिए है कि विंडो भर देना “सेक्शन 4 पढ़ो” कहने का महँगा तरीका है। पर जो कार्ड “128k” छापे और मेमोरी का बिल न छापे, वह गाड़ी टॉप-स्पीड पर बेचे और टंकी का ज़िक्र ही न करे।

कोई 128,000 टोकन नहीं पढ़ता। फिर भी आपकी RAM सबका बिल चुकाती है।

इलाज नीरस है: कॉन्टेक्स्ट उतना रखें जितना आपका काम सच में इस्तेमाल करता है। 32k विंडो की कीमत 128k कैश का एक चौथाई है और वह अकेले डेवलपर के भेजे लगभग हर प्रॉम्प्ट को ढक लेती है। यह लोकल LLM के लिए RAM गणित जैसा ही खाता-अनुशासन है — मॉडल का साइज़ बजट का आधा हिस्सा है, और क्वांटाइज़ेशन लेवल वेट घटाते हैं पर कैश के हिसाब को नहीं छेड़ते।

अगर कैश ही कॉन्टेक्स्ट की असली कीमत है, तो कार्ड विंडो बेचते हैं और बिल क्यों नहीं? और इक़रारनामे का दौर: सबसे बड़ा कॉन्टेक्स्ट जिसे आपने आख़िरी टोकन तक वाकई भरा — और आउटपुट ने गीगाबाइट का मोल चुकाया? कमेंट खुले हैं; सीरीज़ का अगला लेख हारने वाले पक्ष की ओर खड़ा होगा।