<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>VRAM on kenji.blog</title><link>http://kenji.blog/hi/tags/vram/</link><description>Recent content in VRAM on kenji.blog</description><generator>Hugo -- gohugo.io</generator><language>hi</language><copyright>kenjinote</copyright><lastBuildDate>Fri, 11 Sep 2026 01:00:00 +0900</lastBuildDate><atom:link href="http://kenji.blog/hi/tags/vram/index.xml" rel="self" type="application/rss+xml"/><item><title>AI विकास में GPU मेमोरी की कमी को हल करने की तकनीकें (CPU ऑफलोडिंग आदि)</title><link>http://kenji.blog/hi/p/ai-gpu-vram-optimization-cpu-offloading/</link><pubDate>Fri, 11 Sep 2026 01:00:00 +0900</pubDate><guid>http://kenji.blog/hi/p/ai-gpu-vram-optimization-cpu-offloading/</guid><description>&lt;img src="http://kenji.blog/p/ai-gpu-vram-optimization-cpu-offloading/img/eyecatch.jpg" alt="Featured image of post AI विकास में GPU मेमोरी की कमी को हल करने की तकनीकें (CPU ऑफलोडिंग आदि)" />&lt;h1 id="परचय-ai-वकस-और-vram-क-दवर">परिचय: AI विकास और &amp;ldquo;VRAM की दीवार&amp;rdquo;
&lt;/h1>&lt;p>हाल के वर्षों में, बड़े भाषा मॉडल (LLM) और डिफ्यूज़न मॉडल (Diffusion Models) जैसी जनरेटिव AI तकनीकों का तेजी से विकास हुआ है। हालाँकि, इन अत्याधुनिक AI मॉडलों को स्थानीय वातावरण में प्रशिक्षित (फाइन-ट्यूनिंग) करने या अनुमान (Inference) निष्पादित करते समय, कई डेवलपर्स और शोधकर्ताओं को जिस सबसे बड़ी भौतिक बाधा का सामना करना पड़ता है, वह है &lt;strong>&amp;ldquo;GPU मेमोरी (VRAM) की कमी&amp;rdquo;&lt;/strong>।&lt;/p>
&lt;p>NVIDIA GeForce RTX 4090 जैसे हाई-एंड कंज्यूमर GPU में भी अधिकतम 24GB VRAM होता है, जो Llama 3 70B जैसे विशाल मॉडलों को सीधे लोड करना असंभव बना देता है। डेटा सेंटर के लिए H100 (80GB) या B200 (192GB) बहुत महंगे हैं और व्यक्तियों या छोटी टीमों के लिए आसानी से उपलब्ध नहीं हैं। यदि इस &amp;ldquo;VRAM की दीवार (The Wall of VRAM)&amp;rdquo; को नहीं तोड़ा गया, तो अत्याधुनिक मॉडलों तक पहुँचना भी असंभव है।&lt;/p>
&lt;p>इस लेख में, हम अनुमान और प्रशिक्षण दोनों दृष्टिकोणों से, सॉफ्टवेयर और हार्डवेयर आर्किटेक्चर नवाचारों के माध्यम से VRAM प्रतिबंध की इस भौतिक सीमा को तोड़ने के लिए उन्नत तकनीकों को गहराई से समझाएंगे। CPU ऑफलोडिंग, KV कैश ऑप्टिमाइज़ेशन, ग्रैडिएंट चेकपॉइंटिंग (Gradient Checkpointing) और नवीनतम एकीकृत मेमोरी (Unified Memory) आर्किटेक्चर पर हम गणितीय सूत्रों और आरेखों के साथ चर्चा करेंगे। इस लेख को पढ़कर, आप VRAM के व्यवहार को गहराई से समझ सकेंगे और सीमित संसाधनों के साथ विशाल मॉडलों को संभालने का व्यावहारिक ज्ञान प्राप्त कर सकेंगे।&lt;/p>
&lt;hr>
&lt;h1 id="1-ai-मडल-म-vram-खपत-क-शररक-रचन-अनमनपरशकषण">1. AI मॉडल में VRAM खपत की शारीरिक रचना (अनुमान/प्रशिक्षण)
&lt;/h1>&lt;p>VRAM की कमी को दूर करने का पहला कदम सूक्ष्म दृष्टिकोण से यह समझना है कि &amp;ldquo;क्या&amp;rdquo; और &amp;ldquo;कितनी&amp;rdquo; मेमोरी की खपत हो रही है। इसे ब्लैक बॉक्स के रूप में मानने के बजाय, यदि हम गणितीय सूत्रों का उपयोग करके सटीक रूप से इसका अनुमान लगा सकते हैं, तो हम उचित अनुकूलन विधियों का चयन कर सकते हैं।&lt;/p>
&lt;h2 id="11-मडल-परमटर-वजन-क-ममर-गणन">1.1 मॉडल पैरामीटर (वजन) की मेमोरी गणना
&lt;/h2>&lt;p>AI मॉडल को बनाने वाले पैरामीटर (Weights) द्वारा उपभोग की जाने वाली बुनियादी मेमोरी की मात्रा मॉडल के कुल मापदंडों की संख्या और उन्हें दर्शाने के लिए उपयोग किए जाने वाले डेटा प्रकार (Precision: सटीकता) द्वारा निर्धारित की जाती है।&lt;/p>
&lt;p>डीप लर्निंग में आम तौर पर उपयोग किए जाने वाले डेटा प्रकार और प्रति पैरामीटर बाइट्स की संख्या ($B$) नीचे दी गई है:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>FP32 (सिंगल-प्रिसिजन फ्लोटिंग-पॉइंट नंबर):&lt;/strong> 4 बाइट्स (मानक प्रशिक्षण सटीकता)&lt;/li>
&lt;li>&lt;strong>FP16 / BF16 (हाफ-प्रिसिजन फ्लोटिंग-पॉइंट नंबर):&lt;/strong> 2 बाइट्स (सामान्य अनुमान और मिश्रित सटीकता प्रशिक्षण)&lt;/li>
&lt;li>&lt;strong>INT8 (8-बिट इंटिजर):&lt;/strong> 1 बाइट (क्वांटिज़्ड मॉडल)&lt;/li>
&lt;li>&lt;strong>INT4 (4-बिट इंटिजर क्वांटिज़ेशन):&lt;/strong> 0.5 बाइट्स (GPTQ, AWQ, GGUF जैसे चरम क्वांटिज़ेशन)&lt;/li>
&lt;/ul>
&lt;p>यदि हम मॉडल के कुल मापदंडों की संख्या को $P$ मानते हैं, तो वजन द्वारा घेरी गई बुनियादी मेमोरी मात्रा $M_{weights}$ को निम्नलिखित सूत्र द्वारा व्यक्त किया जा सकता है:&lt;/p>
$$ M_{weights} = P \times B $$&lt;p>उदाहरण के लिए, यदि हम Meta द्वारा जारी किए गए &amp;ldquo;Llama 3 8B&amp;rdquo; मॉडल (लगभग 8 बिलियन पैरामीटर) को FP16 (हाफ-प्रिसिजन) में लोड करते हैं, तो गणना कुछ इस प्रकार होगी:&lt;/p>
$$ M_{weights} = 8,000,000,000 \times 2 \text{ bytes} \approx 16,000,000,000 \text{ bytes} \approx 16 \text{ GB} $$&lt;p>अर्थात, केवल मॉडल के वजन को GPU में लोड करने से ही 16GB VRAM की खपत होती है। RTX 3060 (12GB) में इस स्तर पर ही आउट ऑफ मेमोरी (OOM) त्रुटि उत्पन्न होगी। हालाँकि, यदि मॉडल को INT4 में क्वांटिज़्ड किया जाता है, तो यह $8 \times 0.5 = 4 \text{ GB}$ हो जाता है और आसानी से लोड हो सकता है।&lt;/p>
&lt;h2 id="12-अनमन-क-दरन-ममर-क-खपत-kv-कश-क-बढन">1.2 अनुमान के दौरान मेमोरी की खपत: KV कैश का बढ़ना
&lt;/h2>&lt;p>LLM अनुमान (विशेष रूप से ऑटोरिग्र्रेसिव टेक्स्ट जेनरेशन) के दौरान, जो चीज़ वजन के समान या उससे भी अधिक VRAM पर अत्यधिक दबाव डालती है, वह है &lt;strong>KV कैश (Key-Value Cache)&lt;/strong>।
ट्रांसफॉर्मर आर्किटेक्चर में, पिछले जनरेटेड और प्रोसेस्ड टोकन की जानकारी की पुनर्गणना से बचने के लिए, प्रत्येक अटेंशन लेयर पर Key और Value के टेंसर्स को लगातार VRAM में कैश किया जाता है। यह गणना की गति (Compute) में सुधार करता है, लेकिन जैसे-जैसे संदर्भ की लंबाई (इनपुट प्रॉम्प्ट लंबाई + जनरेटेड लंबाई) बढ़ती है, मेमोरी की खपत रैखिक रूप से विस्फोटक रूप से बढ़ती है।&lt;/p>
&lt;p>1 टोकन को प्रोसेस करते समय उपभोग किए जाने वाले KV कैश मेमोरी की मात्रा $M_{kv\_token}$ की गणना मॉडल आर्किटेक्चर के आधार पर निम्नलिखित सूत्र द्वारा कड़ाई से की जाती है:&lt;/p>
$$ M_{kv\_token} = 2 \times N_{layers} \times N_{heads\_kv} \times D_{head} \times B $$&lt;p>यहाँ प्रत्येक चर का अर्थ है:&lt;/p>
&lt;ul>
&lt;li>$2$ : Key और Value के दो टेंसर मौजूद होने के कारण&lt;/li>
&lt;li>$N_{layers}$ : ट्रांसफॉर्मर की लेयर्स (परतों) की संख्या&lt;/li>
&lt;li>$N_{heads\_kv}$ : KV अटेंशन हेड्स की संख्या (GQA: Grouped Query Attention के मामले में यह सामान्य हेड्स से कम होती है)&lt;/li>
&lt;li>$D_{head}$ : प्रत्येक हेड के आयामों की संख्या (आमतौर पर, छिपी हुई परत के आयामों की संख्या $D_{model} / N_{heads}$)&lt;/li>
&lt;li>$B$ : डेटा प्रकार में बाइट्स की संख्या (FP16 के लिए 2)&lt;/li>
&lt;/ul>
&lt;p>कुल KV कैश मात्रा $M_{kv\_total}$ इस मान को अनुक्रम लंबाई ($L_{seq}$) और बैच आकार ($BatchSize$) से गुणा करके प्राप्त की जाती है।&lt;/p>
$$ M_{kv\_total} = M_{kv\_token} \times L_{seq} \times BatchSize $$&lt;p>&lt;strong>विशिष्ट उदाहरण: Llama 2 7B के लिए&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>$N_{layers} = 32$&lt;/li>
&lt;li>$N_{heads\_kv} = 32$ (MHA के मामले में)&lt;/li>
&lt;li>$D_{head} = 128$&lt;/li>
&lt;li>FP16 ($B=2$)&lt;/li>
&lt;li>बैच आकार 1, अनुक्रम लंबाई 8192 (8K संदर्भ)&lt;/li>
&lt;/ul>
$$ M_{kv\_total} = 2 \times 32 \times 32 \times 128 \times 2 \times 8192 \times 1 = 4,294,967,296 \text{ bytes} \approx 4 \text{ GB} $$&lt;p>यदि हम संदर्भ को 32K (32768 टोकन) तक बढ़ाते हैं, तो केवल KV कैश लगभग 16GB खपत करेगा। यदि हम बैच आकार को 4 तक बढ़ाते हैं, तो यह 64GB हो जाएगा। मॉडल के आकार की तुलना में बहुत अधिक VRAM की आवश्यकता अनुमान के दौरान एक बड़ी चुनौती है।&lt;/p>
&lt;h2 id="13-परशकषण-क-दरन-ममर-क-खपत-ऑपटमइजर-गरडएट-और-एकटवशन">1.3 प्रशिक्षण के दौरान मेमोरी की खपत: ऑप्टिमाइज़र, ग्रैडिएंट और एक्टिवेशन
&lt;/h2>&lt;p>अनुमान की तुलना में, मॉडल प्रशिक्षण (प्री-ट्रेनिंग या फाइन-ट्यूनिंग) बहुत अधिक VRAM खपत करता है। ऐसा इसलिए है क्योंकि इसे केवल एक सरल फॉरवर्ड पास के बजाय बैकप्रोपेगेशन (Backpropagation) के लिए जानकारी बनाए रखने की आवश्यकता होती है। प्रशिक्षण मेमोरी मुख्य रूप से निम्नलिखित 4 तत्वों से बनी होती है:&lt;/p>
&lt;ol>
&lt;li>&lt;strong>मॉडल वजन (Model Weights):&lt;/strong> अनुमान के समान ही, लेकिन मिश्रित सटीकता प्रशिक्षण में FP16 और FP32 (मास्टर वेट) दोनों को बनाए रखा जा सकता है।&lt;/li>
&lt;li>&lt;strong>ग्रैडिएंट (Gradients):&lt;/strong> बैकप्रोपेगेशन में गणना किए गए प्रति पैरामीटर ग्रैडिएंट। FP16 के मामले में प्रति पैरामीटर 2 बाइट्स।&lt;/li>
&lt;li>&lt;strong>ऑप्टिमाइज़र स्टेट (Optimizer States):&lt;/strong> AdamW जैसे उन्नत ऑप्टिमाइज़र प्रत्येक पैरामीटर के लिए पहला मोमेंट (Momentum) और दूसरा मोमेंट (Variance) रखते हैं। प्रशिक्षण स्थिरता बनाए रखने के लिए, इन्हें आमतौर पर FP32 (4 बाइट्स) में रखा जाता है। अर्थात, दो मोमेंट्स $4 + 4 = 8$ बाइट्स/पैरामीटर की खपत करते हैं।&lt;/li>
&lt;li>&lt;strong>एक्टिवेशन (Activations):&lt;/strong> बैकप्रोपेगेशन के ग्रैडिएंट गणना के लिए, फॉरवर्ड पास के दौरान प्रत्येक परत के आउटपुट (मध्यवर्ती स्थिति) को मेमोरी में बनाए रखना आवश्यक है। यह बैच आकार और अनुक्रम लंबाई पर काफी निर्भर करता है, और बहुत बड़ा हो सकता है।&lt;/li>
&lt;/ol>
&lt;p>संक्षेप में, मानक Adam ऑप्टिमाइज़र का उपयोग करते हुए मिश्रित सटीकता प्रशिक्षण (Mixed Precision Training) में, प्रति पैरामीटर &lt;strong>लगभग 16~20 बाइट्स&lt;/strong> (मास्टर वेट 4 + FP16 वेट 2 + ग्रैडिएंट 2 + ऑप्टिमाइज़र 8 + α) मेमोरी की आवश्यकता होती है।&lt;/p>
$$ M_{train\_param} \approx P \times 16 \text{ bytes} $$&lt;p>7B (7 बिलियन पैरामीटर) मॉडल के प्रशिक्षण के लिए, अकेले मापदंडों से संबंधित $7B \times 16 = 112 \text{ GB}$ की आवश्यकता होगी, और एक्टिवेशन को जोड़कर, 140GB से अधिक VRAM की आवश्यकता की गणना की जाती है। इसे 24GB VRAM पर निष्पादित करने调करने के लिए, अगली कुछ परतों में बताई गई गहन अनुकूलन तकनीकों की सख्त आवश्यकता है।&lt;/p>
&lt;hr>
&lt;h1 id="2-अनमन-क-दरन-vram-बचत-क-तकनक">2. अनुमान के दौरान VRAM बचत की तकनीकें
&lt;/h1>&lt;p>अनुमान के दौरान विशाल मॉडलों को चलाने के लिए हार्डवेयर सीमाओं को पार करने वाली कई सॉफ्टवेयर तकनीकें विकसित की गई हैं।&lt;/p>
&lt;h2 id="21-cpu-ऑफलडग-cpu-offloading-और-लयर-सपलटग">2.1 CPU ऑफलोडिंग (CPU Offloading) और लेयर स्प्लिटिंग
&lt;/h2>&lt;p>जब एक विशाल मॉडल एक या कई GPU में फिट नहीं होता है, तो मॉडल के एक हिस्से को सिस्टम मेमोरी (CPU RAM) में रखने और गणना के लिए आवश्यकतानुसार इसे GPU में स्थानांतरित करने की तकनीक &lt;strong>CPU ऑफलोडिंग&lt;/strong> है। &lt;code>llama.cpp&lt;/code> और Hugging Face का &lt;code>Accelerate&lt;/code> इस सुविधा का समर्थन करते हैं।&lt;/p>
&lt;pre class="mermaid">
graph TD
A[&amp;#34;सिस्टम RAM (DDR4 / DDR5)&amp;#34;] --&amp;gt; B[&amp;#34;GPU VRAM (GDDR6X)&amp;#34;]
B[&amp;#34;GPU VRAM (GDDR6X)&amp;#34;] --&amp;gt; C[&amp;#34;टेंसर कोर (कंप्यूट)&amp;#34;]
subgraph &amp;#34;लेयर स्प्लिटिंग और ऑफलोडिंग&amp;#34;
D[&amp;#34;निचली परतें 1-15 (GPU में पिन की गई)&amp;#34;]
E[&amp;#34;ऊपरी परतें 16-32 (CPU में ऑफलोड की गई)&amp;#34;]
end
E[&amp;#34;ऊपरी परतें 16-32 (CPU में ऑफलोड की गई)&amp;#34;] -.-&amp;gt; B[&amp;#34;GPU VRAM (GDDR6X)&amp;#34;]
&lt;/pre>
&lt;p>&lt;strong>प्रणाली और चुनौतियाँ:&lt;/strong>
चूँकि ट्रांसफॉर्मर मॉडल में लेयर्स (परतों) की एक शृंखला संरचना होती है, एक परत की गणना पूरी होने तक अगली परत की गणना शुरू नहीं होती है। इसका लाभ उठाते हुए, केवल वे परतें जो GPU में फिट होती हैं (उदा: परत 1 से 15) VRAM में पिन की जाती हैं, और बाकी परतें (परत 16 से 32) बड़ी क्षमता वाले लेकिन धीमे CPU RAM में रखी जाती हैं। अनुमान के दौरान, 15वीं परत तक गणना पूरी होने के बाद, 16वीं परत का वजन PCIe बस के माध्यम से CPU से GPU में स्थानांतरित (कॉपी) किया जाता है, और गणना GPU पर निष्पादित की जाती है।&lt;/p>
&lt;p>हालाँकि, &lt;strong>PCIe की बैंडविड्थ (Bandwidth) एक गंभीर अड़चन (Bottleneck)&lt;/strong> बन जाती है। यद्यपि PCIe 4.0 x16 की अधिकतम सैद्धांतिक बैंडविड्थ 32GB/s (वन-वे) है, यह नवीनतम GPU की आंतरिक VRAM बैंडविड्थ (उदा: RTX 4090 की GDDR6X में 1008GB/s, H100 की HBM3 में 3TB/s से अधिक) की तुलना में बहुत धीमी है। इसलिए, भारी CPU ऑफलोडिंग का उपयोग करने से अनुमान गति (Tokens per Second) में नाटकीय रूप से गिरावट आती है।
गति में कमी को कम करने के लिए, व्यावहारिक उपाय यह है कि अधिक से अधिक परतों को GPU में रखा जाए (GPU लेयर्स को अधिकतम किया जाए) और कम से कम परतों को ऑफलोड किया जाए।&lt;/p>
&lt;h2 id="22-kv-कश-कवटजशन-और-pagedattention">2.2 KV कैश क्वांटिज़ेशन और PagedAttention
&lt;/h2>&lt;p>अनुमान के दौरान VRAM खपत का मुख्य कारण बनने वाले KV कैश के लिए भी दो शक्तिशाली अनुकूलन लागू किए गए हैं।&lt;/p>
&lt;p>&lt;strong>1. KV कैश क्वांटिज़ेशन (KV Cache Quantization):&lt;/strong>
न केवल मॉडल वजन, बल्कि रनटाइम के दौरान गतिशील रूप से उत्पन्न होने वाले KV कैश को भी VRAM में सहेजने से पहले INT8, INT4, या FP8 में क्वांटिज़्ड किया जाता है। इससे KV कैश का आकार आधा या चौथाई हो जाता है। नवीनतम अनुमान इंजन (vLLM और llama.cpp) इस सुविधा को एकीकृत कर चुके हैं, जो सटीकता के नुकसान को कम करते हुए VRAM में महत्वपूर्ण बचत प्राप्त करते हैं।&lt;/p>
&lt;p>&lt;strong>2. PagedAttention:&lt;/strong>
OS वर्चुअल मेमोरी के &amp;ldquo;पेजिंग&amp;rdquo; अवधारणा को KV कैश में लागू करने को &lt;strong>PagedAttention&lt;/strong> कहा जाता है, जिसे vLLM अनुमान इंजन द्वारा पेश किया गया था। पारंपरिक अनुमान इंजनों में, अधिकतम अनुक्रम लंबाई के अनुसार VRAM के एक निरंतर क्षेत्र को पहले से ही आवंटित (Pre-allocation) किया जाता था। इस वजह से, जब वास्तविक इनपुट छोटा होता था, तो विखंडन (Fragmentation) और अप्रयुक्त मेमोरी की बर्बादी होती थी, जिससे 60% से अधिक VRAM नष्ट हो सकता था।&lt;/p>
&lt;p>PagedAttention KV कैश को निश्चित आकार के ब्लॉक (पेज) में विभाजित करता है और उन्हें गैर-निरंतर भौतिक मेमोरी स्पेस में वितरित रूप से संग्रहीत करने की अनुमति देता है। यह मेमोरी की बर्बादी को लगभग शून्य कर देता है (केवल आंतरिक विखंडन तक सीमित) और समान VRAM क्षमता के साथ बैच आकार को काफी बढ़ा सकता है।&lt;/p>
&lt;pre class="mermaid">
graph LR
A[&amp;#34;लॉजिकल KV कैश&amp;#34;] --&amp;gt; B[&amp;#34;भौतिक VRAM ब्लॉक&amp;#34;]
A1[&amp;#34;टोकन 1, 2, 3, 4&amp;#34;] --&amp;gt; B3[&amp;#34;ब्लॉक 3 (आवंटित)&amp;#34;]
A2[&amp;#34;टोकन 5, 6, 7, 8&amp;#34;] --&amp;gt; B1[&amp;#34;ब्लॉक 1 (आवंटित)&amp;#34;]
A3[&amp;#34;भविष्य के टोकन...&amp;#34;] -.-&amp;gt; B2[&amp;#34;ब्लॉक 2 (स्वतंत्र)&amp;#34;]
&lt;/pre>
&lt;h2 id="23-flashattention-अटशन-गणन-क-ममर-जटलत-क-तडन">2.3 FlashAttention: अटेंशन गणना की मेमोरी जटिलता को तोड़ना
&lt;/h2>&lt;p>VRAM की कमी केवल डेटा स्टोर करने के लिए मेमोरी की मात्रा के कारण नहीं, बल्कि गणना के दौरान &amp;ldquo;अस्थायी कार्यक्षेत्र&amp;rdquo; (Temporary Workspace) की कमी के कारण भी होती है। मानक ट्रांसफॉर्मर के सेल्फ-अटेंशन मैकेनिज्म में, अनुक्रम लंबाई $N$ के लिए $N \times N$ के विशाल अटेंशन मैट्रिक्स को VRAM पर साकार (Materialize) करने की आवश्यकता होती है। इससे मेमोरी जटिलता $O(N^2)$ हो जाती है, जो लंबे संदर्भों के लिए OOM का मुख्य कारण बनता है।&lt;/p>
&lt;p>इसका समाधान &lt;strong>FlashAttention&lt;/strong> (और FlashAttention-2, 3) ने किया।
FlashAttention एक ऐसा एल्गोरिदम है जो GPU के हार्डवेयर आर्किटेक्चर (विशाल लेकिन धीमे HBM और बेहद छोटे लेकिन अल्ट्रा-फास्ट SRAM के पदानुक्रम) का लाभ उठाता है। यह टाइलिंग (Tiling) नामक तकनीक का उपयोग करता है, जहाँ डेटा को ब्लॉक-दर-ब्लॉक SRAM में लोड किया जाता है और अटेंशन की गणना वहीं पूरी की जाती है, जिससे $N \times N$ मैट्रिक्स को HBM (VRAM) में लिखने की आवश्यकता पूरी तरह खत्म हो जाती है।&lt;/p>
&lt;p>इससे अटेंशन लेयर की मेमोरी जटिलता $O(N^2)$ से घटकर $O(N)$ (अनुक्रम लंबाई के अनुपात में) हो जाती है, और संदर्भ लंबाई की सीमा काफी हद तक शिथिल हो जाती है।&lt;/p>
&lt;h2 id="24-एककत-ममर-unified-memory-क-उदय-और-apple-silicon">2.4 एकीकृत मेमोरी (Unified Memory) का उदय और Apple Silicon
&lt;/h2>&lt;p>PC आर्किटेक्चर के मूल स्तर पर इस समस्या से निपटने का काम &lt;strong>एकीकृत मेमोरी आर्किटेक्चर (Unified Memory Architecture: UMA)&lt;/strong> कर रहा है, जिसे Apple Silicon (M1/M2/M3/M4 सीरीज के Max या Ultra) और कुछ नवीनतम APU (जैसे AMD Strix Point) में अपनाया गया है।&lt;/p>
&lt;p>इन आर्किटेक्चर में, मदरबोर्ड पर CPU और GPU एक ही भौतिक मेमोरी (जैसे कि अधिकतम 192GB की LPDDR5) साझा करते हैं। इसलिए, &amp;ldquo;PCIe के माध्यम से CPU से GPU में धीमे डेटा स्थानांतरण&amp;rdquo; की अवधारणा भौतिक रूप से मौजूद ही नहीं है।&lt;/p>
&lt;pre class="mermaid">
graph TD
subgraph &amp;#34;एकीकृत मेमोरी आर्किटेक्चर (उदा. Apple Silicon)&amp;#34;
A[&amp;#34;CPU कोर&amp;#34;] &amp;lt;--&amp;gt; C[&amp;#34;साझा मेमोरी नियंत्रक&amp;#34;]
B[&amp;#34;GPU कोर / न्यूरल इंजन&amp;#34;] &amp;lt;--&amp;gt; C[&amp;#34;साझा मेमोरी नियंत्रक&amp;#34;]
C[&amp;#34;साझा मेमोरी नियंत्रक&amp;#34;] &amp;lt;--&amp;gt; D[&amp;#34;एकीकृत मेमोरी पूल (उदा. 192GB)&amp;#34;]
end
&lt;/pre>
&lt;p>इस आर्किटेक्चर का सबसे बड़ा लाभ यह है कि VRAM की कोई स्पष्ट सीमा नहीं है, और सिस्टम मेमोरी के लगभग पूरे क्षेत्र का उपयोग विशाल LLM को सीधे लोड करने के लिए किया जा सकता है। 192GB यूनिफाइड मेमोरी वाले Mac Studio के साथ, 70B क्लास या उससे भी बड़े मॉडल (जैसे Grok-1) को बिना क्वांटिज़ेशन के एकल उपकरण पर लोड करना और उच्च गति पर अनुमान लगाना संभव है। मेमोरी एक्सेस बैंडविड्थ भी M2 Ultra पर 800GB/s तक पहुँच जाती है, जो कंज्यूमर-ग्रेड डिस्क्रीट GPU के बराबर है। यह एक अत्यंत शक्तिशाली दृष्टिकोण है जो हार्डवेयर स्तर पर &amp;ldquo;मेमोरी क्षमता&amp;rdquo; और &amp;ldquo;बैंडविड्थ&amp;rdquo; की दुविधा को हल करता है।&lt;/p>
&lt;hr>
&lt;h1 id="3-परशकषण-फइन-टयनग-क-दरन-vram-बचत-क-तकनक">3. प्रशिक्षण (फाइन-ट्यूनिंग) के दौरान VRAM बचत की तकनीकें
&lt;/h1>&lt;p>प्रशिक्षण (Training) के दौरान, जहाँ अनुमान से भी अधिक VRAM की आवश्यकता होती है, कई सफलताएं हासिल की गई हैं। सीमित संसाधनों के साथ फाइन-ट्यूनिंग करने के लिए निम्नलिखित तकनीकों का संयोजन आवश्यक है।&lt;/p>
&lt;h2 id="31-गरडएट-चकपइटग-gradient-checkpointing">3.1 ग्रैडिएंट चेकपॉइंटिंग (Gradient Checkpointing)
&lt;/h2>&lt;p>डीप लर्निंग के बैकप्रोपेगेशन (Backpropagation) में, ग्रैडिएंट की गणना करने के लिए फॉरवर्ड पास के दौरान सभी लेयर्स के मध्यवर्ती आउटपुट (Activations) को मेमोरी में रखना आवश्यक होता है। जैसे-जैसे अनुक्रम लंबाई या बैच आकार बढ़ता है, यह एक्टिवेशन मेमोरी VRAM पर हावी होने लगती है।&lt;/p>
&lt;p>&lt;strong>ग्रैडिएंट चेकपॉइंटिंग (Gradient Checkpointing / Activation Recomputation)&lt;/strong> मेमोरी क्षमता और गणना समय (Compute) के ट्रेड-ऑफ का उपयोग करने वाली एक शानदार तकनीक है।
सभी मध्यवर्ती आउटपुट को मेमोरी में सहेजने के बजाय, यह केवल विशिष्ट लेयर्स (चेकपॉइंट्स) के आउटपुट को सहेज कर रखता है। बैकप्रोपेगेशन के दौरान जब गैर-चेकपॉइंटेड मध्यवर्ती मूल्यों की आवश्यकता होती है, तो यह &lt;strong>सहेजे गए निकटतम चेकपॉइंट से फॉरवर्ड पास की फिर से गणना (पुनर्गणना) करके मूल्य को पुनर्प्राप्त करता है&lt;/strong>।&lt;/p>
&lt;p>इससे गणना की मात्रा में लगभग 20-30% की वृद्धि होती है और कुल प्रशिक्षण समय लंबा हो जाता है, लेकिन एक्टिवेशन द्वारा VRAM खपत को $O(N)$ ($N$ लेयर्स की संख्या है) से घटाकर $O(\sqrt{N})$ तक कम कर दिया जाता है। वर्तमान विशाल मॉडलों के प्रशिक्षण में, यह एक अनिवार्य सेटिंग बन गया है जिसके बिना काम शुरू करना लगभग असंभव है।&lt;/p>
&lt;h2 id="32-lora-और-qlora-low-rank-adaptation">3.2 LoRA और QLoRA (Low-Rank Adaptation)
&lt;/h2>&lt;p>VRAM की कमी को बुनियादी स्तर से सुलझाने में मुख्य भूमिका PEFT (Parameter-Efficient Fine-Tuning) के प्रमुख &lt;strong>LoRA&lt;/strong> ने निभाई।&lt;/p>
&lt;p>मॉडल के मूल विशाल वजन मैट्रिक्स $W_0 \in \mathbb{R}^{d \times k}$ को फ्रीज़ (Frozen) कर दिया जाता है, और इसे प्रशिक्षित नहीं किया जाता। इसके बजाय, दो बहुत छोटे कम-रैंक मैट्रिक्स $A \in \mathbb{R}^{r \times k}$ और $B \in \mathbb{R}^{d \times r}$ को समानांतर में पेश किया जाता है, और केवल इन $A$ और $B$ को प्रशिक्षित किया जाता है। (यहाँ रैंक $r$ एक बहुत छोटा मान है जहाँ $r \ll d, k$)।&lt;/p>
$$ W_{adapted} = W_0 + \Delta W = W_0 + B A $$&lt;p>इसके कारण, प्रशिक्षित किए जाने वाले मापदंडों की संख्या मूल के 1% से भी कम (कभी-कभी 0.1% से भी कम) हो जाती है, जिससे &amp;ldquo;ग्रैडिएंट&amp;rdquo; और &amp;ldquo;ऑप्टिमाइज़र स्टेट्स&amp;rdquo; जो बहुत अधिक मेमोरी खाते थे, वे भी 1% से कम हो जाते हैं।&lt;/p>
&lt;p>इसके अलावा, इसे चरम स्तर तक विकसित करने वाला रूप &lt;strong>QLoRA (Quantized LoRA)&lt;/strong> है।
QLoRA में, बेस मॉडल के वजन $W_0$ को चरम स्तर पर 4-बिट (NF4: NormalFloat4 प्रारूप) में क्वांटिज़्ड किया जाता है और VRAM में लोड किया जाता है। फिर, सटीकता बनाए रखने के लिए LoRA के छोटे मैट्रिक्स $A, B$ को BF16 (16-बिट) में प्रशिक्षित किया जाता है।
4-बिट क्वांटिज़ेशन बेस मॉडल के VRAM आकार को मूल के एक-चौथाई तक कम कर देता है, और &lt;strong>Paged Optimizers&lt;/strong> (पेज्ड ऑप्टिमाइज़र) तकनीक का उपयोग करके, जब VRAM खत्म होने वाला होता है, तो यह स्वचालित रूप से ऑप्टिमाइज़र स्थितियों को अस्थायी रूप से CPU RAM में ऑफलोड कर देता है। इसके परिणामस्वरूप, 24GB VRAM (RTX 4090 आदि) वाले सिंगल GPU पर भी Llama 3 70B जैसे अति-विशाल मॉडलों की फाइन-ट्यूनिंग संभव हो गई है।&lt;/p>
&lt;h2 id="33-deepspeed-zero-और-ऑफलडग">3.3 DeepSpeed ZeRO और ऑफलोडिंग
&lt;/h2>&lt;p>कई GPU (मल्टी-GPU) का उपयोग करने वाले वातावरण में, केवल डेटा पैरेललिज़्म (Data Parallelism) से VRAM समस्या हल नहीं होती है। चूँकि प्रत्येक GPU पूरे मॉडल की एक प्रति रखता है, इसलिए व्यक्तिगत VRAM क्षमता की सीमा को पार नहीं किया जा सकता।&lt;/p>
&lt;p>Microsoft द्वारा विकसित &lt;strong>DeepSpeed&lt;/strong> लाइब्रेरी का &lt;strong>ZeRO (Zero Redundancy Optimizer)&lt;/strong> एक ऐसी तकनीक है जो मॉडल के मापदंडों, ग्रैडिएंट्स और ऑप्टिमाइज़र स्थितियों को कई GPU के बीच पूरी तरह से विभाजित (शार्ड) कर देती है। इससे, एकाधिक GPU की &amp;ldquo;कुल&amp;rdquo; VRAM को एक विशाल मेमोरी पूल की तरह माना जा सकता है।&lt;/p>
&lt;pre class="mermaid">
graph TD
subgraph &amp;#34;ZeRO चरण 3 (पैरामीटर विभाजन)&amp;#34;
A[&amp;#34;GPU 0&amp;#34;] --&amp;gt; D[&amp;#34;विभाजन 0 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;]
B[&amp;#34;GPU 1&amp;#34;] --&amp;gt; E[&amp;#34;विभाजन 1 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;]
C[&amp;#34;GPU 2&amp;#34;] --&amp;gt; F[&amp;#34;विभाजन 2 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;]
end
D[&amp;#34;विभाजन 0 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;] &amp;lt;--&amp;gt; E[&amp;#34;विभाजन 1 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;]
E[&amp;#34;विभाजन 1 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;] &amp;lt;--&amp;gt; F[&amp;#34;विभाजन 2 (वजन/ग्रैडिएंट/ऑप्टिमाइज़र का 1/3 भाग रखता है)&amp;#34;]
&lt;/pre>
&lt;ul>
&lt;li>&lt;strong>ZeRO Stage 1:&lt;/strong> ऑप्टिमाइज़र स्थितियों को प्रत्येक GPU में विभाजित करता है&lt;/li>
&lt;li>&lt;strong>ZeRO Stage 2:&lt;/strong> ग्रैडिएंट्स को भी प्रत्येक GPU में विभाजित करता है&lt;/li>
&lt;li>&lt;strong>ZeRO Stage 3:&lt;/strong> मॉडल के मापदंडों (वजन) को भी प्रत्येक GPU में विभाजित करता है&lt;/li>
&lt;/ul>
&lt;p>इसके अतिरिक्त, &lt;strong>ZeRO-Offload&lt;/strong> सुविधा का उपयोग करके, ZeRO द्वारा विभाजित ऑप्टिमाइज़र स्थितियों और ग्रैडिएंट्स की अद्यतन गणना को GPU के बजाय &lt;strong>CPU मेमोरी में ऑफलोड&lt;/strong> करके होस्ट CPU पर निष्पादित किया जा सकता है। इससे GPU VRAM पर बोझ कम हो जाता है, जिससे सीमित GPU वातावरण में भी विशाल मॉडलों का प्रशिक्षण संभव हो जाता है। चूँकि गणना CPU पर होती है और परिणाम PCIe के माध्यम से GPU पर वापस आते हैं, प्रशिक्षण की गति कम हो जाती है, लेकिन यह &amp;ldquo;मेमोरी की कमी के कारण प्रशिक्षण के क्रैश होने&amp;rdquo; जैसी सबसे खराब स्थिति से बचाता है।&lt;/p>
&lt;hr>
&lt;h1 id="4-करयनवयन-उदहरण-hugging-face-accelerate-और-deepspeed">4. कार्यान्वयन उदाहरण: Hugging Face Accelerate और DeepSpeed
&lt;/h1>&lt;p>अंत में, आइए एक सरल उदाहरण देखें कि Python कोड का उपयोग करके CPU ऑफलोडिंग और VRAM अनुकूलन को वास्तव में कैसे लागू किया जाए।&lt;/p>
&lt;h2 id="41-hugging-face-device_mapauto-क-सथ-सवचलत-ऑफलडग">4.1 Hugging Face &lt;code>device_map=&amp;quot;auto&amp;quot;&lt;/code> के साथ स्वचालित ऑफलोडिंग
&lt;/h2>&lt;p>Hugging Face की &lt;code>transformers&lt;/code> और &lt;code>accelerate&lt;/code> लाइब्रेरीज़ का उपयोग करके, मॉडल को लोड करते समय लेयर्स को स्वचालित रूप से GPU और CPU के बीच विभाजित किया जा सकता है।&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt"> 1
&lt;/span>&lt;span class="lnt"> 2
&lt;/span>&lt;span class="lnt"> 3
&lt;/span>&lt;span class="lnt"> 4
&lt;/span>&lt;span class="lnt"> 5
&lt;/span>&lt;span class="lnt"> 6
&lt;/span>&lt;span class="lnt"> 7
&lt;/span>&lt;span class="lnt"> 8
&lt;/span>&lt;span class="lnt"> 9
&lt;/span>&lt;span class="lnt">10
&lt;/span>&lt;span class="lnt">11
&lt;/span>&lt;span class="lnt">12
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-python" data-lang="python">&lt;span class="line">&lt;span class="cl">&lt;span class="kn">from&lt;/span> &lt;span class="nn">transformers&lt;/span> &lt;span class="kn">import&lt;/span> &lt;span class="n">AutoModelForCausalLM&lt;/span>&lt;span class="p">,&lt;/span> &lt;span class="n">AutoTokenizer&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="n">model_id&lt;/span> &lt;span class="o">=&lt;/span> &lt;span class="s2">&amp;#34;meta-llama/Llama-2-13b-hf&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="c1"># device_map=&amp;#34;auto&amp;#34; के साथ, VRAM में फिट न होने वाले हिस्से को CPU RAM में ऑफलोड कर दिया जाता है&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="c1"># load_in_8bit=True से वजन को 8-बिट में क्वांटिज़्ड किया जाता है, जिससे मेमोरी और भी बचती है&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="n">model&lt;/span> &lt;span class="o">=&lt;/span> &lt;span class="n">AutoModelForCausalLM&lt;/span>&lt;span class="o">.&lt;/span>&lt;span class="n">from_pretrained&lt;/span>&lt;span class="p">(&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="n">model_id&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="n">device_map&lt;/span>&lt;span class="o">=&lt;/span>&lt;span class="s2">&amp;#34;auto&amp;#34;&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="n">load_in_8bit&lt;/span>&lt;span class="o">=&lt;/span>&lt;span class="kc">True&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="n">offload_folder&lt;/span>&lt;span class="o">=&lt;/span>&lt;span class="s2">&amp;#34;offload_dir&amp;#34;&lt;/span> &lt;span class="c1"># यदि पर्याप्त नहीं है, तो इसे डिस्क (SSD) में भी ऑफलोड किया जा सकता है&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="p">)&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>जब यह कोड निष्पादित होता है, तो पृष्ठभूमि में &lt;code>accelerate&lt;/code> लाइब्रेरी सिस्टम के VRAM और CPU RAM की उपलब्ध क्षमता का विश्लेषण करती है और लेयर्स को सर्वोत्तम संभव तरीके से व्यवस्थित (Dispatch) करती है।&lt;/p>
&lt;h2 id="42-deepspeed-क-cpu-ऑफलड-कनफगरशन-zero-2">4.2 DeepSpeed का CPU ऑफलोड कॉन्फ़िगरेशन (ZeRO-2)
&lt;/h2>&lt;p>प्रशिक्षण के दौरान DeepSpeed में CPU ऑफलोडिंग सक्षम करने के लिए कॉन्फ़िगरेशन फ़ाइल (JSON) का एक उदाहरण यहाँ दिया गया है।&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt"> 1
&lt;/span>&lt;span class="lnt"> 2
&lt;/span>&lt;span class="lnt"> 3
&lt;/span>&lt;span class="lnt"> 4
&lt;/span>&lt;span class="lnt"> 5
&lt;/span>&lt;span class="lnt"> 6
&lt;/span>&lt;span class="lnt"> 7
&lt;/span>&lt;span class="lnt"> 8
&lt;/span>&lt;span class="lnt"> 9
&lt;/span>&lt;span class="lnt">10
&lt;/span>&lt;span class="lnt">11
&lt;/span>&lt;span class="lnt">12
&lt;/span>&lt;span class="lnt">13
&lt;/span>&lt;span class="lnt">14
&lt;/span>&lt;span class="lnt">15
&lt;/span>&lt;span class="lnt">16
&lt;/span>&lt;span class="lnt">17
&lt;/span>&lt;span class="lnt">18
&lt;/span>&lt;span class="lnt">19
&lt;/span>&lt;span class="lnt">20
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-json" data-lang="json">&lt;span class="line">&lt;span class="cl">&lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;fp16&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;enabled&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="p">},&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;zero_optimization&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;stage&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="mi">2&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;offload_optimizer&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;device&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="s2">&amp;#34;cpu&amp;#34;&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;pin_memory&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="p">},&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;allgather_partitions&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;allgather_bucket_size&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="mf">2e8&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;overlap_comm&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;reduce_scatter&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;reduce_bucket_size&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="mf">2e8&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;contiguous_gradients&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="kc">true&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="p">},&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;train_batch_size&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="mi">16&lt;/span>&lt;span class="p">,&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nt">&amp;#34;gradient_accumulation_steps&amp;#34;&lt;/span>&lt;span class="p">:&lt;/span> &lt;span class="mi">4&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="p">}&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>इस कॉन्फ़िगरेशन में, &lt;code>offload_optimizer&lt;/code> को &lt;code>&amp;quot;cpu&amp;quot;&lt;/code> पर सेट करके, भारी मात्रा में VRAM खपत करने वाले ऑप्टिमाइज़र (जैसे Adam) की स्थिति रखरखाव और अद्यतन गणना सिस्टम के CPU पर निष्पादित की जाती है। यह GPU की VRAM को इसके सबसे महत्वपूर्ण कार्य - मॉडल के फॉरवर्ड/बैकवर्ड गणना - पर ध्यान केंद्रित करने की अनुमति देता है। &lt;code>pin_memory: true&lt;/code> सेट करके, यह पेज फॉल्ट को रोकता है और CPU-GPU के बीच PCIe स्थानांतरण को यथासंभव तेज़ करता है।&lt;/p>
&lt;hr>
&lt;h1 id="नषकरष">निष्कर्ष
&lt;/h1>&lt;p>AI विकास में GPU मेमोरी (Out of Memory) की कमी एक शाश्वत चुनौती है जो मॉडलों के आकार में वृद्धि के साथ डेवलपर्स के सामने बनी रहेगी। हालाँकि, इस लेख में बताई गई हार्डवेयर (आर्किटेक्चर) की गहरी समझ और सॉफ्टवेयर/एल्गोरिदम अनुकूलन तकनीकों का उचित संयोजन करके, स्थानीय वातावरण में विशाल मॉडलों का अनुमान और प्रशिक्षण संभव हो जाता है जो पहले असंभव लगता था।&lt;/p>
&lt;p>&lt;strong>अनुमान के दौरान रणनीतियों का सारांश:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>&lt;strong>क्वांटिज़ेशन (INT4 / INT8 / FP8):&lt;/strong> मॉडल के आकार को नाटकीय रूप से संपीड़ित करता है और VRAM उपयोग को कम करता है।&lt;/li>
&lt;li>&lt;strong>CPU ऑफलोडिंग:&lt;/strong> उन लेयर्स को सिस्टम मेमोरी में स्थानांतरित करता है जो VRAM में फिट नहीं होते (PCIe बैंडविड्थ के कारण गति में कमी के ट्रेड-ऑफ के साथ)।&lt;/li>
&lt;li>&lt;strong>KV कैश अनुकूलन:&lt;/strong> पेजिंग (PagedAttention), कैश क्वांटिज़ेशन, और FlashAttention का उपयोग करके संदर्भ लंबाई (Context Length) सुनिश्चित करता है।&lt;/li>
&lt;li>&lt;strong>एकीकृत मेमोरी उपयोग:&lt;/strong> बड़ी क्षमता वाली मेमोरी का सीधे अनुमान के लिए उपयोग करने के लिए Apple Silicon जैसी UMA तकनीक का लाभ उठाता है।&lt;/li>
&lt;/ol>
&lt;p>&lt;strong>प्रशिक्षण के दौरान रणनीतियों का सारांश:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>&lt;strong>PEFT (LoRA / QLoRA):&lt;/strong> प्रशिक्षित किए जाने वाले मापदंडों को सीमित करता है और बेस मॉडल को चरम सीमा तक क्वांटिज़्ड करता है।&lt;/li>
&lt;li>&lt;strong>ग्रैडिएंट चेकपॉइंटिंग (Gradient Checkpointing):&lt;/strong> फॉरवर्ड पास के मध्यवर्ती आउटपुट को छोड़ देता है और बैकप्रोपेगेशन के दौरान पुनर्गणना करके गणना समय की कीमत पर VRAM खपत को कम करता है।&lt;/li>
&lt;li>&lt;strong>ZeRO और CPU ऑफलोडिंग (DeepSpeed):&lt;/strong> ऑप्टिमाइज़र स्थितियों और ग्रैडिएंट्स को एकाधिक GPU में विभाजित करता है या VRAM की सीमाओं को पार करने के लिए उन्हें CPU मेमोरी में ऑफलोड करता है।&lt;/li>
&lt;/ol>
&lt;p>इन उन्नत तकनीकों का लाभ उठाकर, हम सीमित हार्डवेयर संसाधनों के भीतर अधिकतम AI विकास प्रदर्शन प्राप्त कर सकते हैं। इस तेजी से विकसित होते क्षेत्र में, भविष्य में नई मेमोरी-बचत एल्गोरिदम के उभरने की उम्मीद है। नवीनतम लाइब्रेरी विकासों की नियमित रूप से जांच करना और उन्हें अपने कार्यान्वयन में एकीकृत करना सफलता की कुंजी होगी।&lt;/p></description></item></channel></rss>