लोकल Qwen का लंबा कॉन्टेक्स्ट जल्दी रुकता है: KV Cache, बैकएंड और GPU सीमा जाँचें

आपने लोकल Qwen के लिए 128K कॉन्टेक्स्ट चुना, फिर भी रन लगभग 72K पर क्रैश हो सकता है, बहुत धीमा हो सकता है, या उत्तर पूरा होने के बावजूद शुरुआत के निर्देश भूल सकता है। इसका कारण अक्सर कोई एक “सही फ्लैग” नहीं होता; मॉडल वेट का क्वांटाइज़ेशन, KV Cache, inference बैकएंड और GPU पर डेटा रखने का तरीका मिलकर सीमा बनाते हैं।

इस गाइड का लक्ष्य सिर्फ 128K को चालू करना नहीं, बल्कि यह पता लगाना है कि आपकी मशीन पर कितनी लंबाई स्थिर, पर्याप्त तेज और वास्तव में उपयोगी है। आप पहले लक्षण को वर्गीकृत करेंगे, फिर एक समय में केवल एक चर बदलकर तय करेंगे कि cache बदलना है, बैकएंड बदलना है, GPU split सुधारना है या लक्ष्य लंबाई कम रखनी है।

सीधा उत्तर: configured window केवल ऊपरी सीमा है, गारंटी नहीं

128K की सेटिंग बैकएंड से केवल इतना कहती है कि वह इतनी लंबी input के लिए तैयारी करे। कॉन्फ़िगरेशन तभी चल सकती है जब यह मेमोरी बजट फिट हो:

model weights + KV cache + runtime workspace + safety margin ≤ memory the backend can actually use

मॉडल वेट आमतौर पर लोड होते समय बड़ी और लगभग स्थिर जगह लेते हैं। KV Cache, यानी पिछले token की attention स्थिति, रखे गए token के साथ बढ़ती है; workspace और temporary buffers बैकएंड, batch और kernels के अनुसार बदलते हैं। इसलिए allocation सफल होने के बाद भी prefill बहुत धीमा हो सकता है या मॉडल दूर की जानकारी सही तरह इस्तेमाल करना बंद कर सकता है।

आपको तीन अलग सवालों के जवाब चाहिए: क्या पूरा prompt मेमोरी में फिट होता है, क्या वह स्वीकार्य समय में पूरा होता है, और क्या मॉडल शुरुआत की जानकारी को सही उत्तर में उपयोग करता है। UI में दिखता “128K” इन तीनों का जवाब नहीं देता।

पहले लक्षण पहचानें, वरना गलत चीज़ बदलेंगे

“128K तक नहीं पहुँचता” कई अलग समस्याओं का एक ही नाम है। नीचे अपनी स्थिति से सबसे नज़दीकी लक्षण चुनें और उसी के अनुसार पहली जाँच करें।

लक्षण	अधिक संभावित दिशा	पहली जाँच
मॉडल लोड करते या लंबा कॉन्टेक्स्ट बनाते ही OOM	वेट और KV Cache में VRAM की होड़, या किसी एक GPU पर allocation failure	हर GPU की peak और free VRAM अलग रिकॉर्ड करें
लगभग हर बार एक ही token संख्या के पास backend error	KV format, backend implementation या allocation boundary	मॉडल और हार्डवेयर स्थिर रखकर केवल cache या backend बदलें
prompt स्वीकार होता है, पर prefill या generation बेहद धीमा	memory bandwidth, cross-GPU traffic, kernel या बहुत बड़ा लक्ष्य	prompt processing और generation speed अलग मापें
उत्तर बनता है, पर शुरुआती नियम या facts भूलता है	raw capacity नहीं, effective-context quality	prompt के अलग हिस्सों में रखे facts की recall जाँचें
वही test कभी पास और कभी fail	बहुत कम headroom, साथ चल रहा load या unstable runtime	बाकी load हटाकर एक ही test तीन बार चलाएँ

यदि सिस्टम पूरा prompt रख लेता है लेकिन गति खराब है, तो केवल छोटा KV format चुनना पर्याप्त समाधान नहीं हो सकता। यदि prompt फिट होता है पर शुरुआत याद नहीं रहती, तो और VRAM जोड़ने से भी गुणवत्ता स्वतः नहीं सुधरेगी।

72K से 128K की एक रिपोर्ट क्या बताती है—और क्या नहीं

23 सितंबर 2026 की एक configuration report में Nigel Hungerford-Symes ने RTX 5060 Ti 16GB और RTX 3070 8GB पर Qwen3.8-27B (Unsloth UD-Q5_K_M) चलाने की बात लिखी। रिपोर्ट के अनुसार 128K वाली stack में beellama.cpp + kvarn5 KV + MTP n=2 था, short context पर लगभग 36 tok/s और 126K पर लगभग 18 tok/s मिला; इससे पहले mainline llama.cpp और q8_0 KV वाला setup लगभग 72K पर रुकता था।

यह उदाहरण उपयोगी है क्योंकि एक निश्चित मशीन पर inference stack बदलने से usable limit बदल सकती है। लेकिन इसमें backend, KV-cache scheme और अन्य runtime settings साथ बदलीं, इसलिए इससे यह सिद्ध नहीं होता कि केवल kvarn5 ने 72K से 128K कराया, न ही यह speed दूसरी मशीन पर मान ली जा सकती है।

इसे diagnostic lead की तरह उपयोग करें। यदि आपकी failure सीमा बार-बार एक ही लंबाई पर आती है, तो मॉडल फ़ाइल के साथ KV Cache और बैकएंड को भी नियंत्रित तुलना में शामिल करें।

कोई बदलाव करने से पहले 72K baseline दर्ज करें

पहले वर्तमान setup को इस तरह लिखें कि आप उसे फिर चला सकें। बिना baseline के नई stack पास हो भी जाए, तो आपको पता नहीं चलेगा कि सुधार किस बदलाव से आया।

क्षेत्र	क्या दर्ज करना है
मॉडल	पूरा model name, exact file, weight quantization, file size
बैकएंड	backend name, version या commit, launch command
कॉन्टेक्स्ट	requested window, actual input tokens, reserved output tokens
KV Cache	data type या scheme, GPU/host placement, compression settings
हार्डवेयर	हर GPU model और VRAM, system RAM, PCIe topology
placement	GPU split, offload, कौन-सा हिस्सा किस device पर है
runtime	batch, concurrency, sampling और maximum output
नतीजा	success/error, exact error, peak VRAM/RAM, prefill और generation speed

16GB और 8GB के दो GPU को एक सरल 24GB pool न मानें। बैकएंड तय करता है कि weights, cache और workspace कहाँ रखे जाएँ; एक कार्ड पहले भर सकता है, जबकि दूसरे में जगह बची हो, और लंबी input पर cross-device transfer गति घटा सकता है।

चार variables को अलग-अलग जाँचें

1. Weight quantization स्थिर memory footprint बदलता है

वेट क्वांटाइज़ेशन मुख्य रूप से मॉडल लोड करने की मेमोरी बदलता है। छोटा quantized model KV Cache के लिए जगह छोड़ सकता है, लेकिन वह लंबा उपयोगी कॉन्टेक्स्ट सुनिश्चित नहीं करता और quality या speed भी बदल सकता है।

यह जाँचने के लिए कि वेट cache को दबा रहे हैं, backend, KV type और prompt को स्थिर रखें। केवल weight quantization बदलें, फिर देखें कितनी VRAM बची और failure point आगे गया या नहीं।

2. KV Cache type प्रति-token बढ़ने वाली memory बदलता है

KV Cache अगला token बनाने के लिए पिछली attention state रखता है। एक ही मॉडल और cache representation में इसका उपयोग retained tokens के साथ लगभग बढ़ता है, इसलिए long context के लिए यह सीधा memory lever है।

दो cache schemes की तुलना करते समय केवल “128K फिट हुआ” न देखें। Peak memory, सबसे लंबी स्थिर input और recall accuracy तीनों दर्ज करें; कम memory वाला cache यदि distant facts बिगाड़ता है या backend अस्थिर करता है, तो वह production जीत नहीं है।

3. Backend तय करता है कि formats वास्तव में कैसे लागू हों

अलग backends cache layout, allocation, multi-GPU placement और kernels में अलग हो सकते हैं। इसलिए एक ही मॉडल फ़ाइल और एक ही window value पर memory curve और speed अलग हो सकती है।

यदि नया backend केवल अलग KV format के साथ चलता है, तो निष्कर्ष लिखें: “यह पूरी stack पास हुई।” यह न लिखें कि अकेले cache format कारण था। जहाँ संभव हो, दोनों backends में समर्थित समान settings पर अतिरिक्त A/B run करें।

4. Hardware placement तय करता है कि कौन-सा resource पहले टूटेगा

Multi-GPU में केवल total VRAM देखना आम गलती है। Fail इसलिए हो सकता है कि एक GPU पर contiguous allocation न मिले, पूरा cache एक कार्ड पर हो, workspace के लिए margin न बचे, या cross-GPU traffic के कारण speed अनुपयोगी हो जाए।

हर GPU को अलग monitor करें। एक कार्ड लगभग भर जाए और दूसरे में साफ़ headroom रहे, तो model quality घटाने से पहले split या placement सुधारें।

Length ladder से repeatable acceptance test चलाएँ

Short prompt से सीधे 128K पर न जाएँ। एक fixed ladder से पता चलता है कि failure अचानक आता है या memory, speed और recall धीरे-धीरे खराब होते हैं।

शुरुआत के लिए 8K → 32K → 64K → 72K → 96K → 126K उपयोग करें। 126K, 128K के करीब है और output के लिए स्पष्ट budget छोड़ता है; लंबा output चाहिए तो input target उसी हिसाब से कम करें।

एक ही controlled prompt set तैयार करें

1. Token उसी tokenizer से गिनें जो target model वास्तव में उपयोग करता है; characters या file size से अनुमान न लगाएँ।
2. Input के लगभग 10%, 20% और आगे 90% स्थानों पर अलग “canary facts” रखें, जैसे ORBIT-17 = copper।
3. शुरुआत, मध्य और अंत में एक-एक coding constraint रखें; अंतिम प्रश्न में constraints दोहराने और छोटा code change करने को कहें।
4. हर length पर content order, sampling और output budget समान रखें।
5. दूसरे workload बंद करके critical lengths को तीन बार दोहराएँ।

Canary facts retrieval मापते हैं, पूरी coding quality नहीं। अंतिम acceptance run में अपने वास्तविक काम जैसा code, logs या repository documentation भी जोड़ें।

हर run पर वही metrics लिखें

Metric	यह किस सवाल का जवाब देता है
Actual input tokens	क्या backend ने target length सच में स्वीकार की?
Allocation result और exact error	capacity या compatibility कहाँ टूटी?
Per-GPU peak VRAM और peak RAM	कौन-सा device bottleneck बना?
Prompt processing time/rate	long-input prefill व्यावहारिक है?
Generation speed	लंबे prompt के बाद interaction उपयोगी है?
Canary recall count	मॉडल दूर की जानकारी इस्तेमाल कर रहा है?
Coding constraints satisfied	लंबा window वास्तविक task में मदद करता है?

Test से पहले pass criteria लिखें। उदाहरण के लिए: target length पर लगातार तीन successful runs, कोई memory/backend error नहीं, 10 में कम से कम 9 canaries सही, और prefill तथा generation आपके workflow की समय सीमा में। 9/10 केवल उदाहरण है; threshold पहले तय करना ज़रूरी है, ताकि “128K चल गया” दिखाने के लिए बाद में नियम न बदले जाएँ।

नतीजे के अनुसार अगला कदम चुनें

एक निश्चित length पर लगातार OOM होता है

पहले देखें कौन-सा device भर रहा है। यदि context बढ़ने पर cache बाकी headroom खा रहा है, तो कम-memory KV scheme की तुलना करें। यदि weights लोड होते ही जगह लगभग खत्म है, तो छोटा weight quantization जाँचें। हर run में एक बदलाव करें और देखें failure point अपेक्षित दिशा में गया या नहीं।

नया backend 128K तक जाता है, पुराना 72K पर रुकता है

नई stack को candidate मानें, फिर तीन बार reproduce करके recall test चलाएँ। क्योंकि backend और cache साथ बदल सकते हैं, अभी सुरक्षित निष्कर्ष केवल यह है कि candidate stack काम करती है; single root cause अलग सिद्ध नहीं हुआ।

128K पूरा होता है, पर speed स्वीकार्य नहीं

यह capacity failure नहीं, operating boundary है। रोज़ के लिए छोटा default window रखें और केवल ज़रूरी tasks पर बहुत लंबा context चालू करें; साथ में छोटा model, दूसरा backend या बेहतर placement compare करें। “चल सकता है” और “हर दिन चलाना उचित है” अलग फैसले हैं।

128K चलता है, पर शुरुआती जानकारी भूलता है

इसे effective-context quality समस्या मानें। वही prompt 64K, 72K और 96K पर चलाकर recall curve बनाएँ। यदि छोटी input साफ़ रूप से भरोसेमंद है, तो production limit वहाँ रखें जहाँ quality pass होती है, न कि जहाँ allocation बस सफल हो जाती है। बहुत बड़े repository task में retrieval, chunking या पहले summary बनाना भी irrelevant context घटा सकता है।

अंतिम लक्ष्य: प्रमाणित working window, सबसे बड़ा menu value नहीं

यदि 72K आपके सामान्य repository और logs के लिए पर्याप्त है, तो केवल 128K दिखाने के लिए quantization, KV Cache, backend और GPU split एक साथ न बदलें। Stable baseline रखें और हर बदलाव से capacity, speed या recall में मापने योग्य लाभ माँगें।

यदि काम सच में 100K से अधिक input चाहता है, तो पहले length ladder और pass criteria बनाएं, फिर cache और backend combinations compare करें। उपयोगी अंतिम निष्कर्ष यह है: “इस model, backend, cache और hardware ने 126K पर तीन बार आवश्यक speed और recall के साथ pass किया”—सिर्फ “configuration 128K support करती है” नहीं।