कैरस के साथ मल्टी-जीपीयू प्रशिक्षण के लिए 5 सुझाव

• जनवरी ७,२०२१
• वासिलिस व्र्यनोटिस
• । 1 टिप्पणी

डीप लर्निंग (ब्लॉकचेन / बिटकॉइन और डेटा साइंस / मशीन लर्निंग के साथ 2010 के अंत में पसंदीदा चर्चा) ने हमें पिछले कुछ वर्षों में कुछ बहुत अच्छा सामान करने में सक्षम किया है। एल्गोरिदम में अग्रिमों के अलावा (जो कि 1990 के दशक के उर्फ ​​"डाटा माइनिंग युग" के बाद से पहले से ज्ञात विचारों पर आधारित हैं), इसकी सफलता के मुख्य कारणों में बड़े मुक्त डेटासेट की उपलब्धता, ओपन-सोर्स लाइब्रेरी की शुरूआत को जिम्मेदार ठहराया जा सकता है। GPU का उपयोग इस ब्लॉग पोस्ट में मैं अंतिम दो पर ध्यान केंद्रित करूंगा और मैं आपके साथ कुछ टिप्स साझा करूंगा जिन्हें मैंने कठिन तरीके से सीखा।

TensorFlow & Keras क्यों?

TensorFlow Google द्वारा विकसित एक बहुत लोकप्रिय डीप लर्निंग लाइब्रेरी है जो आपको जल्दी से जटिल नेटवर्क को प्रोटोटाइप करने की अनुमति देता है। यह ऑटो-भेदभाव (जो आपको लागत कार्यों के ग्रेडिएंट का अनुमान लगाने / कोडिंग करने से बचाता है) और जीपीयू समर्थन (जो आपको सभ्य हार्डवेयर का उपयोग करके आसानी से 200x गति सुधार करने की अनुमति देता है) जैसी बहुत सी दिलचस्प विशेषताओं के साथ आता है। इसके अलावा यह एक पायथन इंटरफ़ेस प्रदान करता है जिसका अर्थ है कि आप C या CUDA कोड लिखने की आवश्यकता के बिना जल्दी से प्रोटोटाइप कर सकते हैं। माना जाता है कि TensorFlow के बजाय Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK इत्यादि जैसे कई अन्य फ्रेमवर्क का उपयोग किया जा सकता है, लेकिन यह सभी आपके उपयोग-मामले और आपकी व्यक्तिगत प्राथमिकता के लिए उबलता है।

पर क्यों Keras? मेरे लिए सीधे TF का उपयोग करना Numpy के साथ मशीन लर्निंग करने जैसा है। हां यह संभव है और समय-समय पर आपको इसे करना पड़ता है (विशेषकर यदि आप कस्टम लेयर्स / लॉस-फंक्शन्स लिखते हैं) लेकिन क्या आप वास्तव में ऐसे कोड लिखना चाहते हैं जो जटिल नेटवर्क को वेक्टर ऑपरेशन की श्रृंखला के रूप में वर्णित करता है (हां, मुझे पता है टीएफ में उच्च-स्तरीय विधियां हैं लेकिन वे केरस की तरह शांत नहीं हैं)? इसके अलावा, यदि आप एक अलग पुस्तकालय में जाना चाहते हैं तो क्या होगा? खैर फिर आपको कोड को फिर से लिखना होगा, जो बेकार है। ता ता ता, बचाव के लिए करेस! केरस आपको उच्च स्तर की अवधारणाओं का उपयोग करके अपने नेटवर्क का वर्णन करने और कोड लिखने की अनुमति देता है जो कि बैकएंड अज्ञेय है, जिसका अर्थ है कि आप नेटवर्क को विभिन्न गहन शिक्षण पुस्तकालयों में चला सकते हैं। केरस के बारे में कुछ चीजें जो मुझे पसंद हैं, वह यह है कि यह अच्छी तरह से लिखी गई है, इसमें एक वस्तु उन्मुख वास्तुकला है, यह योगदान करना आसान है और इसमें एक अनुकूल समुदाय है। यदि आप इसे पसंद करते हैं, तो धन्यवाद कहें फ्रांकोइस चॉलेट इसे विकसित करने और इसे खोलने के लिए।

मल्टी-जीपीयू प्रशिक्षण के लिए टिप्स और गोचैक

आगे की हलचल के बिना, आइए कुछ खास टिप्स के साथ कूदें कि कैसे करेस पर अधिकांश जीपीयू प्रशिक्षण और एक जोड़ी गोथेक जो आपको ध्यान में रखना चाहिए:

1. मल्टी-जीपीयू प्रशिक्षण स्वचालित नहीं है

Keras & Tensorflow का उपयोग कर GPU पर प्रशिक्षण मॉडल निर्बाध है। यदि आपके पास एक NVIDIA कार्ड है और आपने CUDA स्थापित किया है, तो पुस्तकालय स्वतः इसका पता लगा लेंगे और इसे प्रशिक्षण के लिए उपयोग करेंगे। इतना ठंडा! लेकिन क्या होगा अगर आप एक खराब हो चुकी बव्वा हैं और आपके पास कई GPU हैं? खैर दुर्भाग्य से आपको मल्टी-जीपीयू प्रशिक्षण प्राप्त करने के लिए थोड़ा काम करना होगा।

एक नेटवर्क को समानांतर करने के कई तरीके हैं जो आप प्राप्त करना चाहते हैं इसके आधार पर लेकिन मुख्य दो दृष्टिकोण मॉडल और डेटा समानांतर है। यदि आपका मॉडल किसी एकल जीपीयू में फिट होने के लिए बहुत जटिल है, तो सबसे पहले आपकी मदद कर सकता है, जबकि बाद में जब आप निष्पादन को गति देना चाहते हैं, तब मदद करता है। आमतौर पर जब लोग मल्टी-जीपीयू प्रशिक्षण के बारे में बात करते हैं तो उनका मतलब बाद में होता है। इसे प्राप्त करना कठिन हुआ करता था, लेकिन शुक्र है कि केरस ने हाल ही में एक उपयोगिता विधि को शामिल किया है mutli_gpu_model जो समानांतर प्रशिक्षण / भविष्यवाणियों को आसान बनाता है (वर्तमान में केवल TF बैकएंड के साथ उपलब्ध है)। मुख्य विचार यह है कि आप अपने मॉडल को विधि के माध्यम से पास करते हैं और इसे विभिन्न जीपीयू में कॉपी किया जाता है। मूल इनपुट को विखंडू में विभाजित किया गया है जो विभिन्न जीपीयू को खिलाया जाता है और फिर उन्हें एकल आउटपुट के रूप में एकत्र किया जाता है। इस पद्धति का उपयोग समानांतर प्रशिक्षण और भविष्यवाणियों को प्राप्त करने के लिए किया जा सकता है, फिर भी ध्यान रखें कि प्रशिक्षण के लिए यह आवश्यक सिंक्रनाइज़ेशन के कारण जीपीयू की मात्रा के साथ रैखिक पैमाने पर नहीं होता है।

2. बैच साइज पर ध्यान दें

जब आप मल्टी-जीपीयू प्रशिक्षण बैच आकार पर ध्यान देते हैं, क्योंकि यह गति / मेमोरी, आपके मॉडल के अभिसरण पर कई प्रभाव डालता है और यदि आप सावधान नहीं हैं तो आप अपने मॉडल भार को भ्रष्ट कर सकते हैं!

स्पीड / स्मृति: जाहिर है जितना बड़ा बैच उतना ही तेज प्रशिक्षण / भविष्यवाणी। इसका कारण यह है कि GPU में डेटा डालने और बाहर निकालने में एक ओवरहेड होता है, इसलिए छोटे बैचों में अधिक ओवरहेड होता है। फ्लिप-साइड पर, बैच जितना बड़ा होता है उतनी ही मेमोरी आपको GPU में चाहिए। विशेष रूप से प्रशिक्षण के दौरान, प्रत्येक परत के इनपुट को स्मृति में रखा जाता है क्योंकि उन्हें बैक-प्रचार कदम पर आवश्यक होता है, इसलिए आपके बैच का आकार बहुत अधिक बढ़ जाने से स्मृति त्रुटियां हो सकती हैं।

कन्वर्जेंस: यदि आप अपने मॉडल को प्रशिक्षित करने के लिए स्टोचस्टिक ग्रेडिएंट डिसेंट (SGD) या इसके कुछ वेरिएंट का उपयोग करते हैं, तो आपको ध्यान रखना चाहिए कि बैच का आकार आपके नेटवर्क की अभिसरण और सामान्यीकरण की क्षमता को प्रभावित कर सकता है। कई कंप्यूटर दृष्टि समस्याओं में विशिष्ट बैच आकार 32-512 उदाहरणों के बीच हैं। जैसा केसकर एट अल इसे लागू करें, "यह व्यवहार में देखा गया है कि बड़े बैच (512 से अधिक) का उपयोग करते समय मॉडल की गुणवत्ता में गिरावट होती है, जैसा कि इसकी सामान्यीकरण की क्षमता से मापा जाता है।" ध्यान दें कि अन्य अलग-अलग ऑप्टिमाइज़र के पास अलग-अलग गुण हैं और विशेष रूप से वितरित अनुकूलन तकनीक समस्या के साथ मदद कर सकती है। यदि आप गणितीय विवरणों में रुचि रखते हैं, तो मैं जोरी हर्मन की थीसिस को पढ़ने की सलाह देता हूं।स्केलेबल डीप लर्निंग और पैरललाइजिंग ग्रैडिएंट डिसेंट पर".

वजन को कम करने: यह एक बुरा तकनीकी विस्तार है जिसके विनाशकारी परिणाम हो सकते हैं। जब आप मल्टी-जीपीयू प्रशिक्षण करते हैं, तो डेटा के साथ सभी जीपीयू को खिलाना महत्वपूर्ण है। ऐसा हो सकता है कि आपके युग के अंतिम बैच में परिभाषित की तुलना में कम डेटा हो (क्योंकि आपके डेटासेट के आकार को आपके बैच के आकार से बिल्कुल विभाजित नहीं किया जा सकता है)। यह अंतिम चरण के दौरान कुछ GPU को कोई डेटा प्राप्त नहीं करने का कारण हो सकता है। दुर्भाग्य से कुछ केर लेयर्स, विशेष रूप से बैच सामान्यीकरण लेयर, वजन में दिखने वाले नैन मूल्यों (बीएन परत में चलन और विचरण) के लिए अग्रणी नहीं हो सकते हैं। चीजों को और भी नस्टीयर बनाने के लिए, व्यक्ति प्रशिक्षण के दौरान समस्या का निरीक्षण नहीं करेगा (जबकि सीखने का चरण 1 है) क्योंकि विशिष्ट परत अनुमानों में बैच के माध्य / विचरण का उपयोग करती है। फिर भी भविष्यवाणियों के दौरान (सीखने का चरण 0 पर सेट), रनिंग मीन / विचरण का उपयोग किया जाता है, जो हमारे मामले में खराब परिणामों के लिए अग्रणी बन सकता है। तो अपने आप को एक एहसान करो और हमेशा सुनिश्चित करें कि जब आप मल्टी-जीपीयू प्रशिक्षण करते हैं तो आपके बैच का आकार तय हो। इसे प्राप्त करने के दो सरल तरीके या तो बैचों को अस्वीकार करने से हैं जो पूर्वनिर्धारित आकार से मेल नहीं खाते हैं या जब तक आप पूर्वनिर्धारित आकार तक नहीं पहुंचते हैं तब तक बैच के भीतर रिकॉर्ड दोहराते हैं। अंतिम लेकिन कम से कम यह ध्यान रखें कि मल्टी-जीपीयू सेटअप में, बैच का आकार आपके सिस्टम पर उपलब्ध जीपीयू की संख्या का कई होना चाहिए।

3. GPU डेटा भुखमरी उर्फ ​​CPUs GPU के साथ नहीं रख सकते

दीप नेटवर्क का प्रशिक्षण / भविष्यवाणी करते समय आमतौर पर सबसे महंगा हिस्सा वह अनुमान है जो जीपीयू पर होता है। डेटा को पृष्ठभूमि में सीपीयू में प्रीप्रोसेस किया गया है और वे समय-समय पर जीपीयू को खिलाए जाते हैं। फिर भी किसी को कम नहीं समझना चाहिए कि जीपीयू कितने तेज हैं; ऐसा हो सकता है कि यदि आपका नेटवर्क बहुत उथला है या प्रीप्रोसेसिंग कदम बहुत जटिल है, तो आपका सीपीयू आपके जीपीयू के साथ या दूसरे शब्दों में उन्हें डेटा के साथ जल्दी से पर्याप्त फीड नहीं कर सकता है। इससे कम जीपीयू उपयोग हो सकता है जो व्यर्थ धन / संसाधनों में बदल जाता है।

केरेस आमतौर पर पाइथन के GIL (ग्लोबल इंटरप्रेटर लॉक) के कारण समान रूप से समानांतर बैचों का अनुमान लगाता है, आप वास्तव में पाइथन में सही मल्टी-थ्रेडिंग प्राप्त नहीं कर सकते हैं। उसके लिए दो समाधान हैं: या तो कई प्रक्रियाओं का उपयोग करें (ध्यान दें कि इस में बहुत सारे गोचर्स हैं जो मैं यहां कवर नहीं करने जा रहा हूं) या अपने प्रीप्रोसेसिंग चरण को सरल रखें। अतीत में मैंने कुछ अनावश्यक तनाव को कम करने के लिए केर पर एक पुल-रिक्वेस्ट भेजी है जो हम इमेज प्रीप्रोसेसिंग के दौरान सीपीयू पर डाल रहे थे, इसलिए अधिकांश उपयोगकर्ता प्रभावित नहीं होने चाहिए यदि वे मानक जनरेटर का उपयोग करते हैं। यदि आपके पास कस्टम जनरेटर हैं, तो सी पुस्तकालयों जैसे Numpy में यथासंभव तर्क को आगे बढ़ाने का प्रयास करें क्योंकि इनमें से कुछ तरीके वास्तव में GIL जारी करें जिसका मतलब है कि आप समानांतर की डिग्री बढ़ा सकते हैं। यह पता लगाने का एक अच्छा तरीका है कि क्या आप GPU डेटा भुखमरी का सामना कर रहे हैं, GPU उपयोग की निगरानी करना है, फिर भी चेतावनी दी जाती है कि यह देखने का एकमात्र कारण नहीं है (एकाधिक GPU में प्रशिक्षण के दौरान होने वाला सिंक्रनाइज़ेशन भी कम उपयोग के लिए दोषी है। )। आम तौर पर GPU डेटा भुखमरी का पता लगाया जा सकता है GPU के फटने के बाद लंबे समय तक बिना किसी उपयोग के साथ विराम दिया जाता है। अतीत में मैंने Dstat के लिए एक ओपन-सोर्स किया है जो आपके GPU उपयोग को मापने में मदद कर सकता है, इसलिए एक नज़र डालें मूल ब्लॉग पोस्ट.

4. अपने समानांतर मॉडल को सहेजना

मान लें कि आपने अपने मॉडल को समानांतर बनाने के लिए mutli_gpu_model विधि का उपयोग किया, प्रशिक्षण समाप्त हो गया और अब आप इन वज़न को जारी रखना चाहते हैं। बुरी खबर यह है कि आप इस पर सेव () कॉल नहीं कर सकते। वर्तमान में केरस की एक सीमा है जो आपको अनुमति नहीं देती है एक समानांतर मॉडल को बचाओ। इसके आसपास 2 तरीके हैं: या तो मूल मॉडल के संदर्भ में सेव () को कॉल करें (वेट अपने आप अपडेट हो जाएगा) या आपको समानांतर संस्करण को काट-छाँट करके और सभी अनावश्यक कनेक्शनों को साफ करके मॉडल को क्रमबद्ध करने की आवश्यकता है। पहला विकल्प रास्ता आसान है, लेकिन भविष्य में मैं एक क्रमिक-स्रोत को खोलने की योजना बनाता हूं जो बाद में करता है।

5. उपलब्ध जीपीयू को गिनने से बुरा साइड-इफेक्ट होता है

दुर्भाग्य से, वर्तमान में, टेनसोरफ़्लोस्टोनथॉन .client.device_lib.list_local_devices () पद्धति पर एक बुरा साइड-इफेक्ट होता है, जिसके कारण एक नया TensorFlow सत्र बनता है और सिस्टम पर सभी उपलब्ध GPU का आरंभ होता है। इससे अनपेक्षित परिणाम हो सकते हैं जैसे कि नए सत्रों को निर्दिष्ट या समय से पहले शुरू करने से अधिक जीपीयू देखना (आप इस पर सभी विवरण पढ़ सकते हैं पुल अनुरोध)। इसी तरह के आश्चर्य से बचने के लिए आपको इसके बजाय Keras 'K.get_session ()। List_devices () पद्धति का उपयोग करने की सलाह दी जाती है, जो सत्र में वर्तमान में पंजीकृत सभी GPU आपको लौटा देगा। अंतिम लेकिन कम से कम, ध्यान रखें कि list_devices () विधि को कॉल करना कुछ हद तक महंगा है, इसलिए यदि आप उपलब्ध GPU की संख्या पर रुचि रखते हैं, तो एक बार विधि को कॉल करें और स्थानीय चर पर उनकी संख्या को संग्रहीत करें।

बस! आशा है कि आपको यह सूची उपयोगी लगी होगी। यदि आपको केआरएस पर जीपीयू प्रशिक्षण के लिए अन्य गोच / टिप्स मिले हैं, तो उन्हें नीचे टिप्पणी पर साझा करें। 🙂