मैंने स्थानीय LLMs को 2.24 गुना तेजी से चलाया 4GB NVIDIA GPU पर।
llama.cpp 4GB NVIDIA GPU पर ट्यूनिंग स्थानीय LLM गति को दोगुना कर सकता है। Full GPU बेहतर Qwen मॉडल ऑफलोडिंग; केवी कैश मामूली लागत के साथ मेमोरी कम हो गई।
मुख्य जानकारी
- 4GB NVIDIA GTX 1650 Ti laptop पर, सावधानीपूर्वक llama.cpp कॉन्फ़िगरेशन ने अकेले कुछ स्थानीय LLMs को बिना hardware अपग्रेड या मॉडल रीट्रेनिंग के 2.24x तक तेज कर दिया।
- Full GPU लेयर ऑफलोडिंग ने Qwen3 और Qwen3.5 थ्रूपुट में काफी सुधार किया, जबकि Gemma 4 E2B में थोड़ा बदलाव देखा गया, यह दर्शाता है कि इष्टतम सेटिंग्स सार्वभौमिक के बजाय मॉडल-विशिष्ट हैं।
- स्पीडअप अधिक GPU मेमोरी का प्रभावी ढंग से उपयोग करने से आया थाः सबसे तेज Qwen कॉन्फ़िगरेशन ने महंगे CPU/GPU ट्रांसफर को कम करने के लिए लगभग 3.1 जीबी वीआरएएम का इस्तेमाल किया।
- व्यावहारिक मेमोरी ट्यूनिंग प्रदर्शन को संरक्षित कर सकती हैः Q8_0 केवी कैश ने केवल ~ 4% थ्रूपुट हानि के साथ लगभग 260 एमआईबी द्वारा GPU स्मृति उपयोग में कटौती की, और छोटे माइक्रॉबैचों ने कम गति प्रभाव के साथ जेम्मा के लिए स्मृति बचाई।
- एक मॉडल का फ़ाइल आकार सीधे तौर पर GPU मेमोरी आवश्यकताओं की भविष्यवाणी नहीं करता है, क्योंकि GGUF अनुमान आर्किटेक्चर के आधार पर GPU और 8 9 00 5 स्मृति के बीच टेंसर को विभाजित करता है।
पुराने या बजट laptops के मालिक अक्सर स्थानीय LLMs को पहुंच से बाहर मानते हैं। NVIDIA GeForce GTX 1650 Ti पर 4GB GDDR6 के साथ llama.cpp बेंचमार्किंग के दो दौर से पता चलता है कि सावधानीपूर्वक कॉन्फ़िगरेशन, नया नहीं hardware , कुछ मॉडलों के लिए लगभग दोगुना हो सकता है token पीढ़ी।
परीक्षण मशीन एक laptop GPU है जो वर्तमान जनरेटिव AI बूम से कई साल पहले जारी की गई थी। इसमें कोई hardware अपग्रेड, कोई पुनः प्रशिक्षण और कोई CUDA कर्नेल परिवर्तन शामिल नहीं था। लाभ पूरी तरह से ट्यूनिंग GPU, परत प्लेसमेंट, CPU थ्रेड्स, माइक्रोबैच आकार और केवी कैश परिशुद्धता से आया था।
सुर्खियों की संख्या: - (अंग्रेज़ी में) - (ब्रिटिश में)
- Qwen3.5-4B ने 34.96 tokens प्रति सेकंड पर पूर्ण GPU ऑफलोडिंग के साथ, ऑटो पर 15.63 tokens प्रति सेकेंड की तुलना में 2.24 × स्पीडअप तक पहुंच गया।
- Qwen3-4B ने 42.41 tokens प्रति सेकंड बनाम 20.46, एक 2.07 × गति प्राप्त की।
- Gemma 4 E2B ने लगभग 59 tokens प्रति सेकंड बनाए रखा, अनिवार्य रूप से ऑटो और पूर्ण अनलोडिंग के बीच अपरिवर्तित।
- Switching Qwen3 को एक Q8 KV कैश में बदलने से लगभग 4% की थ्रूपुट लागत पर GPU मेमोरी का उपयोग 260 एमआईबी तक कम हो जाता है।
- वैधता दौर में मापा गया प्रत्येक दीर्घ-प्रतिक्रिया अनुरोध सामान्य रूप से पूरा हुआ।
मॉडल और परीक्षण सेटअप
तीन लगभग चार-बिट क्वांटिज़्ड जीजीयूएफ मॉडल का परीक्षण किया गया था:
| मॉडल | मात्राकरण | GGUF का आकार |
|---|---|---|
| जेम्मा 4 ई2बी आईटी | Q4_K_M | 3.22 जीआईबी |
| क्वेन3.5-4B | Q4_K_M | 2.55 जीआईबी |
| Qwen3-4B | Q4_K_M | 2.33 जीआईबी |
सभी परिणाम क्वांटिज़्ड जीजीयूएफ अनुमान को संदर्भित करते हैं, न कि पूर्ण-सटीक अनुमान। एक प्रारंभिक सबक: मॉडल का फ़ाइल आकार आपको यह नहीं बताता है कि GPU मेमोरी इन्फरेंस की कितनी आवश्यकता होगी। कुछ टेंसर CPU - सुलभ स्मृति में रहते हैं जबकि अन्य GPU पर बैठते हैं, इसलिए विभिन्न आर्किटेक्चर समान hardware पर बहुत अलग तरीके से व्यवहार करते हैं। यह अंतर सबसे अधिक मायने रखता था जब जेम्मा 4 की तुलना Qwen मॉडलों के साथ की जाती थी।
क्यों GPU offloading सब कुछ तय करता है
llama.cpp आपको यह नियंत्रित करने की अनुमति देता है कि GPU में कितनी मॉडल परतें `-- GPU -layers` विकल्प के साथ जाती हैं। परीक्षण किए गए कॉन्फ़िगरेशन थे ∀auto`, ≠12゙, ∂24̅ और ∂all̅।
ऑटो मेमोरी-प्रतिबंधित hardware पर एक समझदार प्रारंभिक बिंदु है, लेकिन यह आवश्यक रूप से उच्चतम थ्रूपुट सेटिंग नहीं है। ऑटो के साथ, सभी तीन मॉडलों ने प्रतिक्रियाएं उत्पन्न कीं, फिर भी Qwen मॉडल GPU द्वारा वितरित किए जाने वाले प्रदर्शन से काफी नीचे थे। `-- GPU -लेयर्स ऑल∀ में स्विच करने से Qwen3 और Qwen3.5 नाटकीय रूप से तेज हो गए, जबकि जेम्मा 4 में लगभग कोई सुधार नहीं हुआ था। केंद्रीय खोजः GPU ऑफलोडिंग को प्रति मॉडल ट्यून किया जाना चाहिए, न कि एक सार्वभौमिक सेटिंग के रूप में माना जाए।
बेंचमार्क कैसे चलाए गए
दो राउंड के स्वचालित प्रयोगों ने मैनुअल टाइमिंग की जगह ली। पावरशेल स्क्रिप्ट्स लामा- server लॉन्च किया, तत्परता का इंतजार किया, API अनुरोध जारी किए, समय डेटा एकत्र किया, मेमोरी उपयोग को रिकॉर्ड किया और परिणाम सीएसवी फ़ाइलों में सहेजे गए।
पहला चरण पैरामीटर स्पेस में खोज की गई: चार GPU ऑफलोडिंग रणनीतियाँ, दो CPU थ्रेड काउंट्स (4 और 6), और दो माइक्रोबैच साइज़ (128 और 256). इसने प्रति मॉडल 16 कॉन्फ़िगरेशन बनाए, या तीन मॉडलों पर 48, प्रत्येक के लिए तीन पुनरावृत्तियों के साथ दो घंटे के बजट के तहत चलाए गए। पांच प्रॉम्प्ट प्रकारों का उपयोग किया गया थाः तथ्यात्मक प्रश्न, हास्य, सर्बियाई-से-अंग्रेजी अनुवाद, अंग्रेजी से सर्बियन अनुवाद और सुधार। कोर सेटिंग्स स्थिर रहींः संदर्भ आकार 4096, बैच आकार 512, एक समवर्ती server , वार्म-अप सक्षम, तापमान 0,GPU निगरानी चालू.
एक पद्धतिगत दोष सामने आया: पहले दौर में 192 tokens पर आउटपुट कैप किया गया था, इसलिए कुछ लंबी प्रतिक्रियाएं पूरा होने से पहले समाप्त हो गईं। उन नमूनों ने अभी भी पीढ़ी-गति टिप्पणियां दीं लेकिन उन्हें पूर्ण उपयोगकर्ता कार्यों के रूप में नहीं गिना जा सका।
दूसरा चरण सबसे मजबूत कॉन्फ़िगरेशन को अधिक तकनीकी प्रतिक्रियाओं और KV कैश अनुकूलन के साथ मान्य किया गया। दस मॉडल विन्यास दो राउंड में चले गए, FP16, Q8_0, और Q4_0 कैश प्रारूपों की तुलना करते हुए जहां उपयुक्त हो, एक वार्म-अप और दो मापा अनुरोध प्रत्येक के साथ। आउटपुट सीमा 512 tokens तक बढ़ गई। सभी 40 मापे गए उत्तर ∀finish_reason=stop` के साथ पूरा किए गए थे, जिसने यह विश्वास बढ़ाया कि शॉर्टलिस्टेड सेटअप यथार्थवादी अनुरोधों को संभालते हैं।
स्पीडअप के पीछे स्मृति व्यापार
सबसे तेज विन्यास अधिक GPU मेमोरी का इस्तेमाल कियाः
| मॉडल | ऑटो के साथ GPU स्मृति | सभी के साथ GPU स्मृति |
|---|---|---|
| क्वेन3.5-4B | 2231 एमआईबी | 3089 एमआईबी |
| Qwen3-4B | 2281 एमआईबी | 3163 एमआईबी |
Unused VRAM अपने आप में कोई प्रदर्शन लाभ प्रदान नहीं करता है। सवाल यह है कि क्या इसका अधिक उपयोग करने से महंगे CPU/GPU हस्तांतरण कम हो जाते हैं और वास्तविक अनुमान निष्पादन में सुधार होता है। इन मापों में, यह स्पष्ट रूप से किया गया था। लेकिन 4 जीबी कार्ड पर, रनटाइम आवंटन के लिए पर्याप्त मेमोरी आरक्षित करना, OS, और अन्य अनुप्रयोग महत्वपूर्ण बने हुए हैं।
क्यों Gemma 4 मुश्किल से ले जाया
जेम्मा 4 ई 2 बी लगातार 60 के करीब tokens प्रति सेकंड उत्पन्न करता है, और ऑटो से ऑल में अपनी GPU सेटिंग को बदलने से लगभग कोई अंतर नहीं हुआ। रनटाइम ने CPU -मैप्ड मेमोरी में पर्याप्त टेंसर डेटा बनाए रखते हुए 36 प्रासंगिक परतों में से 36 को ऑफलोड करने की सूचना दी। अवलोकन किए गए बफर्स लगभग 1450 एमआईबी थे जो कि 8 9 004 और 2153 मिब CPU पर मैप किया गया था, जिसका अर्थ यह नहीं है कि पूरे मॉडल में केवल 1450 मीब का कब्जा होता है; रन टाइम बस स्मृति स्थानों के बीच टेन्सर को विभाजित करता है।
एक अलग अन्वेषणात्मक परीक्षण में, GPU पर अतिरिक्त जेमा टेंसर को मजबूर करने से GPU, मॉडल बफर लगभग 3602 एमआईबी तक बढ़ गया, बहुत कम वीआरएएम हेडरूम छोड़ दिया और व्यावहारिक प्रतिक्रियाशीलता में सुधार नहीं हुआ। अधिक GPU -निवासी टेन्सर तेजी से अनुमान की गारंटी नहीं देते हैं यदि परिणामी मेमोरी दबाव निष्पादन को नुकसान पहुंचाता है।
माइक्रोबैच ट्यूनिंग ने भी संयम का पक्ष लिया। 256 बनाम 128 की तुलना में 58.99 बनाम 59.31 tokens प्रति सेकंड, 7.05 बनाम 7.00 सेकंड की विलंबता और GPU मेमोरी 1813 बनाम 1685 एमआईबी, दोनों मामलों में 4/4 पूर्णताओं के साथ दिखाई दी। छोटे माइक्रॉबैक ने प्रभावी रूप से अपरिवर्तित प्रदर्शन के साथ लगभग 128 MiB को बचाया, इसलिए जेम्मा के लिए `-ub 128゙ चुना गया था। एकल-उपयोगकर्ता कार्यभार पर, एक छोटा माइक्रोकैट समान रूप से तेज हो सकता है जबकि अधिक स्मृति हेडरूम छोड़ देता है।
KV कैश क्वांटिज़ेशन: Qwen3 पर बड़ी बचत, Qwen3.5 पर बहुत कम
ऑटोरेग्रेसिव Transformer इन्फेरेंस पहले की जानकारी को एक कुंजी-मूल्य कैश में संग्रहीत करता है, जो संदर्भ लंबाई के साथ बढ़ता है। llama.cpp `--cache-type-k` और `-cache - type-v゙ के माध्यम से कैश प्रारूपों को कॉन्फ़िगर करता है। FP16, Q8_0, और Q4_0 की तुलना की गई थी।
QWEN3.5-4B परिणामः- (अंग्रेज़ी में)
| केवी कैश | गति | GPU स्मृति |
|---|---|---|
| FP16 | 34.58 टन/घंटा | 3090 एमआईबी |
| Q8_0 | 34.21 टन/घंटा | 3041 एमआईबी |
| Q4_0 | 34.14 टन/घंटा | 3009 एमआईबी |
Q4_0 ने लगभग 1.3% की पीढ़ी-गति लागत पर लगभग 81 MiB बचाया, एक उचित लेकिन सम्मोहक ट्रेडऑफ नहीं। server लॉग्स से पता चला कि Qwen3.5 अपने KV कैश के साथ अतिरिक्त आवर्ती स्थिति का उपयोग करता है, इसलिए FP16 को बनाए रखा गया था जब तक कि अतिरिक्त VRAM हेडरूम की आवश्यकता न हो।
Qwen3-4B के परिणामः- (अंग्रेज़ी में अनुवादित)
| केवी कैश | गति | GPU स्मृति |
|---|---|---|
| FP16 | 41.59 टन/घंटा | 3163 एमआईबी |
| Q8_0 | 39.92 टन/घंटा | 2903 एमआईबी |
| Q4_0 | 39.80 टन/घंटा | 2759 एमआईबी |
Q8_0 ने लगभग 4% की गति में कमी के साथ 260 एमआईबी को बचाया; Q4_0 लगभग 4.3% के साथ 404 एमआयबी को बचाते हैं। 4 जीबी कार्ड पर, सैकड़ों मेगाबाइट अर्थपूर्ण होते हैं, और क्यू 8_0 पसंदीदा संतुलन बन गयाः लगभग सभी मापा FP16 प्रदर्शन काफी अधिक मुक्त GPU स्मृति के साथ।
एक चेतावनी: इस प्रयोग ने समय, स्मृति और सफल समापन को मापा। यह औपचारिक रूप से मूल्यांकन नहीं किया कि क्या केवी क्वांटिज़ेशन ने सिमेंटिक सटीकता या तर्क की गुणवत्ता बदल दी है। इसके लिए एक अलग कार्य-गुणवत्ता बेंचमार्क की आवश्यकता होगी।
सोच मोड विलंबता स्रोत है, एक थ्रूपुट नहीं
कुछ तर्क-सक्षम LLMs दृश्यमान आउटपुट का उत्पादन करने से पहले आंतरिक तर्क पर कई tokens खर्च करते हैं। यह जटिल गणितीय तर्क या कठिन योजना के साथ मदद करता है, लेकिन बुनियादी कोडिंग प्रश्नों, अनुवाद, सारांश और प्रत्यक्ष स्पष्टीकरण के लिए अतिरिक्त देरी अवांछनीय हो सकती है। परीक्षण किया गया लामा.सीपीपी बिल्ड ` - रीजनिंग ऑफ 'और' - रिज़निंग बजट 0 ', जिसने छोटे इंटरैक्टिव एक्सचेंजों को अधिक उपयोगी बना दिया और उन मामलों से बचने में मदद की जहां आउटपुट- token भत्ता पूरा होने से पहले समाप्त हो गया था।
अंतर मायने रखता हैः सोच को अक्षम करने से GPU व्यक्तिगत tokens तेजी से उत्पन्न नहीं होता है। यह उपयोगकर्ता के उत्तर प्राप्त करने से पहले उत्पन्न किए गए tokens की कुल संख्या को कम करता है। 2.24 × और 2.07 × GPU -ऑफलोडिंग लाभों को तर्क सेटिंग्स के लिए जिम्मेदार नहीं ठहराया जाना चाहिए। न ही हर कार्य के लिए तर्क सही है; जहां जानबूझकर बहु-चरण तर्क मामलों, एक तर्क सक्षम विन्यास बेहतर विकल्प हो सकता है।
प्रोफाइल है कि परीक्षण से बाहर आया
दोनों प्रयोगों के संयोजन से इन व्यावहारिक विन्यास का उत्पादन हुआ।
जेमा 4 ई 2 बी: (अंग्रेज़ी में) "Gemma 4 E2B" GPU परतें ऑटो, CPU थ्रेड 4, संदर्भ 4096, बैच 512, माइक्रोबैच 128, केवी कैश एफ16/एफ16, तर्क बंद।
Qwen3.5-4B: के बारे में बात कर रहे हैं? - हाँ. सभी GPU परतें, CPU थ्रेड 4, संदर्भ 4096, बैच 512, माइक्रोबैच 128, केवी कैश f16/f16, तर्क बंद।
Qwen3-4B: यह क्या है? (अंग्रेज़ी में) । GPU सभी परतें, CPU थ्रेड 4, संदर्भ 4096, बैच 512, माइक्रोबैच 128, केवी कैश q8_0/q8_0, तर्क बंद।
बजट के लिए इसका क्या अर्थ है?
प्रैक्टिकल टेकआउट यह है कि ऑटो कॉन्फ़िगरेशन एक शुरुआती बिंदु है, उत्तर नहीं। ऑटो के खिलाफ `-- GPU -लेयर्स ऑल∀ का परीक्षण करने में कुछ मिनट लगते हैं और यहां Qwen मॉडल के लिए दो गुना से अधिक थ्रूपुट लौटाया जाता है। जेम्मा 4 विपरीत मामला दिखाता हैः एक बार इसकी परतें पूरी तरह से उतार दी जाती हैं, GPU पर अधिक टेंसोर धक्का देना कुछ भी नहीं खरीदता है और चोट पहुंचा सकता है।
दूसरी बात यह है कि मेमोरी की बचत और गति अलग-अलग लीवर हैं। Qwen3 पर केवी कैश क्वांटिज़ेशन ने कम सिंगल-डिजिट थ्रूपुट लागत के लिए सैकड़ों मेगाबाइट मुक्त किए, जो एक लंबे संदर्भ में फिट होने या न होने के बीच का अंतर हो सकता है। क्यूवेन 3.5 पर, उसी लीवर ने तुलनात्मक रूप से थोड़ा बचाया।
खुले प्रश्न 512- token सत्यापन सीमा से परे KV क्वांटिज़ेशन और व्यवहार के तहत कार्य गुणवत्ता हैं। दोनों को समर्पित बेंचमार्क की आवश्यकता होगी। वर्तमान डेटा का समर्थन क्या संकीर्ण है, लेकिन उपयोगी हैः 4GB GTX 1650 टीआई पर, कॉन्फ़िगरेशन अकेले Qwen3.5-4B और Qwen3-4B के लिए 2.24 × और 2.07 × पीढ़ी गति प्रदान करता है, और लगभग 59 tokens प्रति सेकंड Gemma 4 E2B से, प्रत्येक मापा गया लंबा-प्रतिक्रिया अनुरोध सफलतापूर्वक पूरा होता है।
Comments (0)