8GB लैपटॉप पर लोकल AI चलाते समय हैंग होने पर उसे ठीक करने का तरीका
YouTube देखकर टर्मिनल में मॉडल इंस्टॉल करने की कमांड डालने पर स्क्रीन के फ़्रीज़ हो जाने का अनुभव आपने किया होगा। 8GB या 16GB रैम वाले पुराने MacBook या एंट्री-लेवल लैपटॉप पर लोकल LLM के क्रैश होने का कारण कंप्यूटिंग कोर की कमी नहीं है। असली वजह यह है कि मेमोरी बैंडविथ बहुत कम होने पर रनटाइम सीमा से ज़्यादा डेटा पढ़ने की कोशिश करता है। डिवाइस के बैंडविथ का आकलन करके और केवल कॉन्टेक्स्ट साइज़ को ठीक करके, आप पुराने डिवाइस पर भी कोड असिस्टेंस मॉडल चला सकते हैं।
सिस्टम पाइथन को छेड़े बिना पर्यावरण निदान (Environment Diagnostics) टूल इंस्टॉल करना
लेटेस्ट macOS और Ubuntu सिस्टम पाइथन पर बिना अनुमति के पैकेज इंस्टॉल करने से रोकते हैं। pip install डालते ही यह PEP 668 एरर (error: externally-managed-environment) देकर रुक जाता है। अगर आप झंझट से बचने के लिए सिस्टम सुरक्षा को जबरन हटाने वाला फ़्लैग (--break-system-packages) लगाते हैं, तो बाद में OS के बुनियादी टूल गड़बड़ा जाएंगे और आपको OS रीइंस्टॉल करना पड़ेगा। अलग वर्चुअल एनवायरनमेंट आइसोलेशन को सपोर्ट करने वाले pipx का उपयोग करके डायग्नोस्टिक टूल इंस्टॉल करें।
Alex Jones द्वारा विकसित ओपन-सोर्स डायग्नोस्टिक टूल llmfit को आइसोलेटेड तरीके से डिप्लॉय करें और अपने हार्डवेयर स्पेसिफ़िकेशन निकालें।
`bash
macOS के लिए pipx इंस्टॉल करें (Linux के लिए sudo apt install -y pipx)
brew install pipx
pipx ensurepath
llmfit इंस्टॉल करें और हार्डवेयर स्कैन परिणाम सेव करें
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
टर्मिनल में इस प्रक्रिया को पूरा करने के बाद, सिस्टम लाइब्रेरी को छुए बिना 1 मिनट के भीतर डिवाइस की रैम क्षमता और मेमोरी बस की जानकारी system_specs.json फ़ाइल में व्यवस्थित हो जाती है।
बैंडविथ की गणना करना और 3B व 7B मॉडल चुनना
लोकल भाषा मॉडल द्वारा टेक्स्ट जनरेट करने की प्रक्रिया पिछले टोकन को देखकर अगले अक्षर को टाइप करने का एक क्रमिक कार्य है। हर चरण में मॉडल के अरबों वेट्स (weights) को मेमोरी बस से पूरी तरह पढ़ना पड़ता है। यानी, यूज़र एक्सपीरियंस की स्पीड GPU क्लॉक तय नहीं करती, बल्कि मेमोरी बैंडविथ का नंबर तय करता है।
प्रति सेकंड टोकन आउटपुट स्पीड (TPS) की गणना नीचे दिए गए फ़ॉर्मूले से की जाती है:
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes etaफ़ॉर्मूले में eta रनटाइम की प्रभावी बैंडविथ दक्षता (MBU) मान है जो आमतौर पर 0.65 के आसपास होता है।
लगभग 45GB/s बैंडविथ वाले सामान्य DDR4 डेस्कटॉप रैम पर 4-बिट क्वांटाइज़्ड 7B मॉडल (लगभग 4.5GB) को पूरी तरह लोड करने पर कंप्यूटिंग स्पीड 45div4.5imes0.65approx6.5extTPS तक सीमित रह जाती है। अक्षर एक-एक करके रुक-रुक कर आते हैं, जिससे प्रैक्टिकल वर्क में बहुत झुंझलाहट होती है। इसके विपरीत, 288GB/s बैंडविथ वाले RTX 4060 8GB मॉडल या 100GB/s से अधिक बैंडविथ वाली M-सीरीज़ यूनिफाइड मेमोरी पर इसे लोड करने पर प्रति सेकंड 35~40 टोकन मिलते हैं, जो रियल-टाइम टाइपिंग स्पीड से आसानी से आगे निकल जाते हैं।
अपने डिवाइस के स्पेक्स की जाँच करने के बाद, उपयोग करने के लिए केवल दो मॉडल चुने जाते हैं:
- कोडिंग और टेस्ट लिखना: 4.7GB साइज़ का
Qwen2.5-Coder-7B-Instruct (Q4_K_M) लोड किया जाता है। 16GB यूनिफाइड मेमोरी वाले MacBook या 8GB VRAM वाले एक्सटर्नल ग्राफ़िक्स पर 35 TPS से ज़्यादा मिलता है।
- दस्तावेज़ सारांश और कमिट लॉग लिखना: 2.0GB साइज़ का
Llama-3.2-3B-Instruct (Q4_K_M) उपयोग किया जाता है। लो-पावर लैपटॉप के DDR4 एनवायरनमेंट में भी यह कम रैम का उपयोग करता है और लगातार 15 TPS के आसपास आउटपुट देता है।
OOM एरर को रोकने के लिए कॉन्टेक्स्ट विंडो को 4096 तक सीमित करना
मॉडल को सफलतापूर्वक लोड करने के बाद भी, यदि आप कुछ सवाल-जवाब करते हैं, तो प्रोसेस चुपचाप बंद हो जाता है। टर्मिनल में दिखने वाला Exit Code 137 यह दर्शाता है कि ऑपरेटिंग सिस्टम के मेमोरी मैनेजमेंट कर्नेल (Linux OOM-Killer या macOS JetSam) ने रैम की कमी के कारण प्रोसेस को जबरन समाप्त (SIGKILL) कर दिया है।
एक्सटर्नल GPU का उपयोग करते समय अधिक कष्टदायक साइलेंट CPU फ़ॉलबैक (Silent CPU Fallback) होता है। VRAM की सीमा पार होने पर यह प्रोसेस को समाप्त नहीं करता बल्कि कुछ कंप्यूटिंग लेयर्स को धीमे सिस्टम रैम में धकेल देता है, इस दौरान GPU का उपयोग तेजी से गिर जाता है और यह प्रति सेकंड 1 टोकन की स्पीड पर रेंगने लगता है।
इस समस्या की जड़ KV (Key-Value) कैश है, जो बातचीत लंबी होने पर रैम को भर देता है। Llama-3 आर्किटेक्चर के आधार पर यदि कॉन्टेक्स्ट को 32,768 (32K) टोकन तक खुला रखा जाता है, तो 4.5GB वेट्स के अलावा केवल कैश मेमोरी के रूप में 4.0GB अतिरिक्त जुड़ जाता है। 8GB डिवाइस में यह निश्चित रूप से क्रैश हो जाता है। यदि इस लंबाई को 4,096 (4K) टोकन तक सीमित कर दिया जाए, तो कैश क्षमता घटकर 512MB रह जाती है और यह 8GB एनवायरनमेंट में भी क्रैश नहीं होता है।
वर्तमान स्थिति की जाँच करने और सीमा को फ़िक्स करने की प्रक्रिया इस प्रकार है।
सबसे पहले टर्मिनल में ollama ps दर्ज करें। यदि PROCESSOR फ़ील्ड में 100% GPU के बजाय 30%/70% CPU/GPU जैसा विभाजन दिखाई देता है, तो इसका मतलब है कि VRAM पहले ही ओवरफ़्लो हो चुका है और इसे कम स्पीड वाले रैम में धकेल दिया गया है।
कॉन्टेक्स्ट साइज़ को फिक्स करने के लिए एक कॉन्फ़िगरेशन फ़ाइल बनाएँ। ~/local-ai-workspace/configs/Modelfile.coder खोलें और नीचे दी गई सामग्री लिखें:
`dockerfile
FROM qwen2.5-coder:7b
कैश में अत्यधिक वृद्धि को रोकने के लिए 4096 टोकन की ऊपरी सीमा
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
टर्मिनल में कस्टम मॉडल के साथ बिल्ड करें:
`bash
ollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
बिल्ड समाप्त होने के बाद, डिस्क कैश को साफ़ करने के लिए macOS टर्मिनल में sudo purge दर्ज करें, और विंडोज पर अप्रयुक्त WSL इंस्टेंस को wsl --shutdown से साफ़ करें ताकि कम से कम 2GB या अधिक बेसिक उपलब्ध रैम सुनिश्चित हो सके।
बाहरी लीक के बिना लोकल पाइपलाइन बनाना
यह सुनिश्चित करने के लिए कि कंपनी का सोर्स कोड या व्यक्तिगत प्रोजेक्ट बाहर लीक न हों, मॉडल सर्विंग एंडपॉइंट को केवल लोकल लूपबैक (127.0.0.1) तक सीमित करें।
~/local-ai-workspace/scripts/serve_secure.sh फ़ाइल बनाएँ और नीचे दिया गया कोड डालें:
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
स्क्रिप्ट को निष्पादित करने के बाद, जब आप टर्मिनल में lsof -i :11434 | grep LISTEN दर्ज करते हैं, तो जाँच लें कि受信 पता (receiving address) 127.0.0.1:11434 के रूप में दिखाई दे रहा है या नहीं। यदि 0.0.0.0:11434 दिखाई देता है जिसे बाहर से एक्सेस किया जा सकता है, तो प्रोसेस को तुरंत बंद कर दिया जाना चाहिए।
एकीकरण के लिए VS Code प्लगइन Continue.dev का उपयोग करें। चैट मॉडल और ऑटोकम्पलीट मॉडल को अलग करने के लिए कॉन्फ़िगरेशन फ़ाइल (~/.continue/config.json) खोलें:
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
प्रश्न और उत्तर के लिए 7B मॉडल को निर्दिष्ट किया जाता है जिसके कॉन्टेक्स्ट को अभी सीमित किया गया है, और टैब ऑटोकम्पलीट के लिए 1GB के अति-हल्के मॉडल qwen2.5-coder:1.5b को निर्दिष्ट किया जाता है। ऑटोकम्पलीट में होने वाली देरी समाप्त हो जाती है।
सत्यापन इंटरनेट बंद करके किया जाता है। वाई-फाई बंद करके ऑफ़लाइन स्थिति में टर्मिनल खोलें और सीधे क्वेरी भेजें:
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "लोकल आइसोलेटेड नेटवर्क टेस्ट",
"stream": false
}' | grep "response"
`
जब नेटवर्क के कटे होने पर भी सामान्य JSON प्रतिक्रिया वापस आ जाती है, तो बाहरी क्लाउड पर निर्भर रहे बिना केवल मेरे लैपटॉप के संसाधनों के भीतर सुरक्षित रूप से चलने वाले डेवलपमेंट एनवायरनमेंट की सेटिंग समाप्त हो जाती है।