लोकल LLM चलाने के लिए कितनी मेमोरी चाहिए?
लोकल पर चलाने के लिए कोई मॉडल डाउनलोड करने से पहले सवाल यह है कि वह मेमोरी में आएगा या नहीं। अनुमान तीन चीज़ों को जोड़कर निकलता है, और फिर उसकी तुलना उस मेमोरी से की जाती है जो मशीन असल में मॉडल को दे सकती है: need =
लोकल पर चलाने के लिए कोई मॉडल डाउनलोड करने से पहले सवाल यह है कि वह मेमोरी में आएगा या नहीं। अनुमान तीन चीज़ों को जोड़कर निकलता है, और फिर उसकी तुलना उस मेमोरी से की जाती है जो मशीन असल में मॉडल को दे सकती है:
need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory
नीचे के नंबर उसी अनुमान पर चलते हैं जो डेस्कटॉप ऐप osFoundry का लोकल मॉडल ब्राउज़र इस्तेमाल करता है, और उन्हें 16GB M3 MacBook के लिए ऐप के दिखाए नंबरों से मिलाकर जाँचा गया है।
Weights
Weights का साइज़ पैरामीटर की संख्या गुणा हर weight के बाइट होता है, और ये बाइट क्वांटाइज़ेशन पर निर्भर करते हैं:
| Quant | प्रति weight बाइट |
|---|---|
| FP16 / BF16 | 2.0 |
| Q8_0 | 1.0 |
| Q6_K | 0.82 |
| Q5_K_M | 0.69 |
| Q4_K_M | 0.56 |
| Q3_K_M | 0.44 |
| Q2_K | 0.31 |
Q4_K_M के लिए 0.5 की जगह 0.56 इसलिए है क्योंकि K-quants weights के हर छोटे ब्लॉक के लिए एक स्केल भी स्टोर करते हैं। इससे लगभग 4.5 बिट प्रति weight बैठता है।
Q4_K_M में 14B मॉडल के लिए: 14 × 10⁹ × 0.56 = 7.84 × 10⁹ बाइट, यानी लगभग 7.3 GiB।
अगर आप quant का नाम नहीं पहचानते, तो FP16 मान लें। यह सबसे निराशावादी अंदाज़ा है, इसलिए आप ऐसी चीज़ को "फिट हो जाएगा" नहीं मानेंगे जो असल में फिट नहीं होती।
KV cache
जनरेट करते समय मॉडल कॉन्टेक्स्ट के हर टोकन के keys और values अपने पास रखता है। इसका साइज़ है:
2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element
Qwen2.5 14B में 48 layers, 8 KV heads (यह grouped-query attention इस्तेमाल करता है) और head dimension 128 है। FP16 cache के साथ:
- 4K कॉन्टेक्स्ट: 2 × 48 × 8 × 128 × 4096 × 2 बाइट = 768 MiB
- 32K कॉन्टेक्स्ट: 6 GiB
Cache कॉन्टेक्स्ट की लंबाई के साथ सीधी रेखा में बढ़ता है, इसलिए जो मॉडल 4K पर आराम से फिट हो जाता है, वह 32K पर फिट होना बंद कर सकता है। जो अनुमान कॉन्टेक्स्ट की लंबाई नहीं बताता, उसका ज़्यादा काम नहीं; स्क्रीनशॉट वाला अनुमान 4K मानकर चलता है।
Overhead
llama.cpp को compute buffers और scratch space भी चाहिए। मोटा हिसाब weights का 10% और ऊपर से लगभग 200 MB है। 14B मॉडल के लिए यह करीब 0.9 GB है।
Weights, cache और overhead जोड़ने पर Q4_K_M में 14B मॉडल 8 से 9 GB के बीच आता है। ऐप 8.4 GB दिखाता है।
इस्तेमाल लायक मेमोरी
सबसे ज़्यादा गलती लोग यहीं करते हैं।
- Discrete GPU: कार्ड की VRAM ही ऊपरी सीमा है। 12 GB का कार्ड है तो 12 GB, चाहे सिस्टम RAM कितनी भी हो।
- Apple Silicon: मेमोरी unified होती है, लेकिन GPU उसे पूरा इस्तेमाल नहीं कर सकता और OS को भी अपना हिस्सा चाहिए। कुल RAM का 75% गिनना काम चलाऊ ठीक नंबर है, यानी 16 GB में लगभग 12 GB।
फिर तुलना करें:
- need ≤ इस्तेमाल लायक मेमोरी का 80%: फिट है, OS और दूसरे ऐप्स के लिए जगह बचती है
- 80% से 100%: तंग है; लोड हो जाता है, पर पहले दूसरे ऐप्स बंद कर लें
- 100% से ऊपर: डिस्क पर पेज होने लगता है और इतना धीमा हो जाता है कि चलाना बेकार
16GB Mac पर इससे यह निकलता है: Q4_K_M 8.4 GB (70%, फिट), Q5_K_M 10.4 GB (87%, तंग), Q6_K 12.3 GB और Q8_0 14.9 GB (सीमा से ऊपर)।
Q4_K_M पर कई मॉडलों पर लगाएँ तो इस मशीन पर कटऑफ 20B (11.9 GB, तंग) और 27B (15.9 GB, बहुत बड़ा) के बीच पड़ता है।
स्पीड भी इसी नंबर से तय होती है
हर टोकन जनरेट करने के लिए सारे weights को मेमोरी से एक बार पढ़ना पड़ता है, इसलिए जनरेशन स्पीड की ऊपरी सीमा मेमोरी बैंडविड्थ को मॉडल के साइज़ से भाग देने पर मिलती है। बेस M3 की बैंडविड्थ लगभग 100 GB/s है, तो 8.4 GB का मॉडल ज़्यादा से ज़्यादा 12 टोकन प्रति सेकंड के आसपास चलेगा, और 4.9 GB का 8B मॉडल लगभग 20 पर। असल नंबर इससे नीचे आते हैं, पर मॉडलों के बीच का अनुपात काफ़ी सही बैठता है।
यानी साइज़ का अनुमान एक साथ दो सवालों का जवाब देता है: मॉडल लोड होगा भी या नहीं, और लोड होने पर वह लगभग कितनी तेज़ी से लिखेगा।
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

