लोकल LLM की VRAM खत्म? gputaskman से weights बनाम KV cache देखें

आपका लोकल मॉडल कल ठीक से लोड हुआ था, आज लोड होते ही क्रैश हो रहा है या बहुत धीमा चल रहा है, और आपने सिर्फ़ context length बदली थी। इसका एक आम कारण KV cache है, और gputaskman नाम का एक मुफ़्त टर्मिनल टूल आपको अनुमान लगाने के बजाय यह दिखा सकता है।

एक सामान्य GPU मॉनिटर बताता है कि VRAM कितनी भरी है। वह "क्या" है, "क्यों" नहीं। gputaskman का README (5 नवंबर 2026 को जाँचा गया) खुद को "आपके GPU के अंदर क्या है, सिर्फ़ यह नहीं कि वह कितना भरा है, के लिए एक htop" कहता है। यह एक शुरुआती, प्रयोगात्मक, MIT-लाइसेंस वाला प्रोजेक्ट है, इसलिए इसे एक उपयोगी लेंस मानें, अंतिम फ़ैसला नहीं।

आपकी VRAM असल में क्या भरता है#

VRAM को एक सूटकेस समझें। उसमें तीन चीज़ें जाती हैं:

• Weights: मॉडल खुद। किसी दिए गए मॉडल और quantization के लिए तय आकार।
• KV cache: आपकी बातचीत की मॉडल की अल्पकालिक स्मृति। यह context बढ़ने के साथ बढ़ती है।
• Compute buffers: रनटाइम को काम करते समय जो स्क्रैच स्पेस चाहिए।

जब लोग कहते हैं "मॉडल फ़िट नहीं होता", तो अक्सर उनका मतलब होता है कि weights फ़िट होते हैं लेकिन ऊपर से माँगी गई cache नहीं। यही अंतर तय करता है कि क्या ठीक करना है, और एक सामान्य मॉनिटर ठीक यही छिपा देता है।

gputaskman इंस्टॉल करें और प्रति प्रोसेस देखें#

README तीन तरीके बताता है: एक पोर्टेबल Windows ZIP, uv run --locked gputaskman से चलाया गया क्लोन, या Python 3.11+ virtual environment के अंदर pip। प्लेटफ़ॉर्म, जैसा README बताता है:

• Windows 10/11 64-bit, NVIDIA या AMD GPU के साथ (Releases पेज पर x64 और ARM64 ZIPs);
• Linux और WSL, NVIDIA GPU के साथ (glibc 2.35+; WSL Windows host counters पढ़ सकता है);
• macOS केवल Apple Silicon पर, source clone से, कोई पोर्टेबल बिल्ड नहीं।

Windows ZIPs unsigned हैं। इन्हें केवल आधिकारिक रिपॉज़िटरी के Releases पेज, github.com/shanselman/gputaskman, से डाउनलोड करें। README से सटीक कमांड कॉपी करें: प्रोजेक्ट नया है और विकल्प बदल सकते हैं।

एक बार चलने पर, इस समस्या के लिए दो views मायने रखते हैं:

1. Device view: VRAM उपयोग, GPU गतिविधि, PCIe, तापमान, पावर, क्लॉक और history charts। "क्या कुछ स्पाइक हुआ?" के लिए अच्छा।
2. Process view: प्रति प्रोसेस लोकल GPU मेमोरी, GPU-accessible system RAM, engine गतिविधि और पहचाना गया रनटाइम (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime)।

Process view में अपना मॉडल सर्वर खोजें (Ollama के लिए, उसका बंडल किया गया runner)। फिर बाकी सूची देखें। अगर कोई ब्राउज़र या गेम कुछ गीगाबाइट रखे हुए है, तो आपको मॉडल को छुए बिना जवाब मिल गया।

Weights, KV cache, buffers: संख्याएँ कहाँ से आती हैं#

Model inspector आर्किटेक्चर, quantization और buffer आकार दिखाता है जहाँ उपलब्ध हों। एक चेतावनी मायने रखती है: README के अनुसार, weights, KV cache और compute buffers रनटाइम के load logs से आते हैं जब संगत लॉगिंग सक्षम हो। llama.cpp के लिए, अपना llama-server लॉगिंग के साथ शुरू करें (--log-file server.log -lv 4; README कहता है buffer आकारों के लिए level 4 चाहिए)। Ollama के लिए, gputaskman Ollama का server.log उपयोग करता है अगर उपलब्ध हो। अन्यथा ये GGUF metadata और context size से अनुमान हैं, llama.cpp-शैली प्लेसमेंट मानकर। एक ही प्रोसेस के अंदर प्रति-मॉडल KV accounting अभी समर्थित नहीं है।

इसलिए अनुमानित split को "लगभग" पढ़ें, और log-आधारित split को "जो रनटाइम ने बताया"। Ollama के लिए README कहता है बंडल किए गए runners पहचाने जाते हैं, GGUF blobs Ollama के manifests से नामित होते हैं, और server.log उपयोग होता है जब उपलब्ध हो। LM Studio समर्थन आंशिक है: मॉडल उसके फ़ोल्डर से नामित होते हैं और उसके लोकल API से जाँचे जाते हैं, लेकिन यह fixture responses के साथ परखा गया, end to end नहीं।

आप दो snapshots JSON के रूप में सहेजकर diff कमांड से तुलना भी कर सकते हैं। यह "जब मैं 4K से 16K context पर गया तो क्या बदला?" का साफ़ जवाब देने का तरीका है: एक snapshot लें, सेटिंग बदलें, reload करें, दूसरा लें।

कौन सा नॉब घुमाएँ#

Split पढ़ने से आपको सिर्फ़ तस्वीर नहीं, फ़ैसला मिलता है।

Weights बड़ा हिस्सा हैं। छोटे quantization या छोटे मॉडल पर जाएँ। यही एकमात्र लीवर है जो weights छोटा करता है। अगर आप इसके पीछे का मेमोरी गणित चाहते हैं, तो देखें क्या 125B मॉडल 16 GB GPU पर चल सकता है?

KV cache बड़ा हिस्सा है। Context छोटा करें। Ollama में आप इसे सीधे सेशन में आज़मा सकते हैं:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 केवल एक उदाहरण मान है; जो आपके काम को वाकई चाहिए वह चुनें (कमांड Ollama के दस्तावेज़ के अनुसार, 5 नवंबर 2026 को जाँचा गया)।

अगर बाद में llama.cpp में quantized cache के साथ prompt processing में अजीब धीमापन दिखे, तो q5_1 KV cache के लिए यह फ़िक्स अगला पड़ाव है। context window में आख़िर होता क्या है, यह जानने के लिए पढ़ें context window क्या है?

कोई और प्रोसेस बड़ा हिस्सा है। उसे बंद करें, या integrated GPU पर चलाएँ। मॉडल में कुछ भी बदलने की ज़रूरत नहीं।

अगर यह काम न करे#

• Split गलत लगता है। जाँचें कि यह अनुमान है या नहीं (कोई संगत load logs नहीं)। llama.cpp के साथ, अपना llama-server --log-file server.log -lv 4 के साथ चलाएँ और मॉडल reload करें। Ollama के साथ, gputaskman server.log उपयोग करता है अगर मौजूद हो; वहाँ अनुमान लेबल सामान्य है।
• LM Studio कम विवरण दिखाता है। समर्थन आंशिक है, जैसा ऊपर बताया।
• NVIDIA या AMD GPU नहीं। टूल केवल लोकल GPU workloads कवर करता है; CPU-only, NPU-only और cloud workloads दायरे से बाहर हैं।
• macOS। Source clone से चलाएँ; कोई पोर्टेबल बिल्ड नहीं है।

जब hosted मॉडल आसान हल हो#

मान लें आपको एक काम के लिए लंबा context चाहिए, जैसे किसी बड़े दस्तावेज़ का सारांश, और आपका GPU मॉडल को केवल छोटे context के साथ फ़िट करता है। आप ट्यूनिंग जारी रख सकते हैं, या VRAM को समीकरण से हटा सकते हैं। ऐसे कामों के लिए CheapTokens DeepSeek-V4-Flash देता है: 380K context, प्रति उत्तर अधिकतम 32,768 output tokens, दिन के किसी भी समय एक ही कीमत, OpenAI-संगत API के ज़रिए। GLM-5.3-Flash में 390K context और अधिकतम 8,192 output tokens हैं।

कॉल सामान्य OpenAI फ़ॉर्मैट में है (अपनी key एक environment variable में रखें):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

सेटअप विवरण docs में हैं। तय करने का एक सामान्य नियम: अगर किसी काम को बार-बार आपके कार्ड से ज़्यादा context या बड़ा मॉडल चाहिए, और process view दिखाता है कि आपकी VRAM पहले से काफ़ी इस्तेमाल में है, तो वह काम API को भेजें और छोटे, तेज़ काम लोकल रखें। DeepSeek लोकल चलाएँ या API उपयोग करें? इस trade-off पर गहराई से जाता है।

मान लें आप 100 बड़े दस्तावेज़ों का सारांश बनाते हैं, हर एक में 60,000 input tokens और 1,000 output tokens (380K window के अंदर आराम से)। आज इसकी कीमत यह है:

इन संख्याओं पर, $0.001 प्रति दस्तावेज़ ऐसी एक कॉल की लाइव कीमत है, और कुल मिलाकर, input और output दोनों मिलाकर, यह OpenRouter से कम आता है।