डेटा-लोडर परिदृश्य का अवलोकन: प्रायोगिक सेटअप

लिंक की तालिका

• सार और परिचय
• डेटा लोडर
• प्रयोगात्मक स्थापना
• संख्यात्मक परिणाम
• बहस
• संबंधित कार्य
• निष्कर्ष, आभार और संदर्भ
• ए. संख्यात्मक परिणाम जारी

3. प्रायोगिक सेटअप

उनकी विशेषताओं और प्रदर्शन की तुलना करने के लिए कई लाइब्रेरी और डेटासेट चुने गए। हालाँकि जितना संभव हो सके उतना समझने योग्य बनाने का प्रयास किया गया था, लेकिन डेटा लोडिंग का क्षेत्र लगातार विकसित हो रहा है और हर दिन नई लाइब्रेरी और रिलीज़ जोड़े जा रहे हैं। इस संबंध में, हम उम्मीद करते हैं कि निम्नलिखित सूची डेटा लोडर की वर्तमान क्षमताओं का एक अच्छा अवलोकन प्रदान करेगी, बिना यह दावा किए या समग्र सर्वश्रेष्ठ खोजने के (जो संभवतः लेखन के समय से प्रकाशन के समय तक बदल जाएगा)। हम प्रयोगों के सभी स्रोत कोड को जनता के लिए उपलब्ध कराते हैं और उम्मीद करते हैं कि परिणाम पूरी तरह से पुनरुत्पादित किए जा सकेंगे।

हमने अपने प्रयोगों को करने के लिए सात लाइब्रेरीज़ का चयन किया: PyTorch (Paszke et al., 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc et al., 2022), Webdatasets (Webdataset, 2013), Squirrel (Team, 2022b), और Deep Lake (Hambardzumyan et al., 2022)। एक दिलचस्प बात जो हमने खोजी वह यह है कि सभी लाइब्रेरीज़ समान सुविधाओं का समर्थन नहीं करती हैं। उदाहरण के लिए, हम अपने दूरस्थ प्रयोगों को करने के लिए S3 बकेट में होस्ट किए गए डेटासेट के साथ FFCV नहीं चला सकते थे। जैसा कि हमने सेक्शन 1 में बताया है, हम अपने सभी प्रयोग PyTorch में चलाते हैं। हमने अन्य लोकप्रिय मशीन लर्निंग फ्रेमवर्क में प्रयोगों को फिर से प्रस्तुत करने पर विचार किया लेकिन हमने इस विचार के खिलाफ फैसला किया क्योंकि दूसरा उम्मीदवार Tensorflow होता, लेकिन ऐसी अफ़वाहें हैं कि Google JAX के पक्ष में इससे दूर जा रहा है। चित्र 1 पिछले 12 महीनों में विभिन्न एमएल फ्रेमवर्क की लोकप्रियता को दर्शाता है।

3.1 डेटासेट

डेटासेट के संबंध में, हमने शुरू में दो अलग-अलग शिक्षण कार्यों का समर्थन करने के लिए दो क्लासिकल डेटासेट चुने: छवि वर्गीकरण के लिए CIFAR-10 (क्रिज़ेव्स्की एट अल., 2009) और ऑब्जेक्ट डिटेक्शन के लिए CoCo (लिन एट अल., 2014)। कुछ प्रयोग करते समय, हमने अजीब व्यवहार (लाइब्रेरी अपेक्षा से बेहतर प्रदर्शन कर रही थी) देखा, जिसे इस प्रकार समझाया जा सकता है

CIFAR-10 मेमोरी में फ़िट हो रहा है[2]। इस कारण से, हमने RANDOM नाम से एक तीसरा डेटासेट बनाया, जिसमें 256 गुणा 256 पिक्सेल के आकार की यादृच्छिक रूप से उत्पन्न रंगीन छवियां और 20 में से एक यादृच्छिक वर्ग शामिल है। इस तीसरे डेटासेट में प्रशिक्षण के लिए 45000 छवियां, सत्यापन के लिए 5000 और परीक्षण के लिए 500 छवियां हैं, और यह CIFAR-10 से काफी बड़ा है।

बेंचमार्क को तुलनीय बनाने के लिए हमने सभी लाइब्रेरी के लिए समान परिवर्तन का उपयोग किया। एकमात्र अपवाद FFCV था, जिसमें विभिन्न परिवर्तनों का अपना कार्यान्वयन है। छवि वर्गीकरण के लिए परिवर्तन स्टैक में निम्नलिखित शामिल थे: रैंडम हॉरिजॉन्टल फ्लिप, नॉर्मलाइज़ेशन, कटआउट, ट्रांसफ़ॉर्म इनटू टेंसर।

ऑब्जेक्ट डिटेक्शन के लिए, हम ज़्यादातर एल्ब्यूमेंटेशन (बुस्लाव एट अल., 2020) के ट्रांसफ़ॉर्मेशन के कार्यान्वयन पर निर्भर थे। स्टैक इस प्रकार दिखता था: रैंडम साइज़्ड क्रॉप, रैंडम हॉरिजॉन्टल फ़्लिप, नॉर्मलाइज़ेशन, ट्रांसफ़ॉर्म इनटू टेंसर। ये ट्रांसफ़ॉर्मेशन इमेज और बाउंडिंग बॉक्स दोनों पर लागू होते हैं।

3.2 प्रयोग के प्रकार

जब संभव हो, तो हमने डेटासेट को स्थानीय रूप से और S3- समतुल्य बकेट में होस्ट किया। इससे हमें नेटवर्क पर डेटा की एक धारा से प्रशिक्षण के परिणामस्वरूप होने वाली मंदी का आकलन करने में मदद मिली। हम अनुभाग 4 में प्रशिक्षण सेटिंग का विस्तृत विवरण प्रदान करेंगे।

यह देखते हुए कि सबसे गहन प्रशिक्षण कार्य में एक से अधिक GPU का उपयोग करना शामिल है, जब भी संभव हो हमने कई GPU इकाइयों वाले वातावरण में भी समान प्रयोग चलाए। चूँकि प्रयोग चलाने के समय सभी लाइब्रेरी में PyTorch Lightning का पूर्ण समर्थन नहीं था, इसलिए हमने PyTorch से वितरित डेटा समानांतर (DDP) (ली एट अल., 2020) लाइब्रेरी का उपयोग करके मल्टी-GPU को लागू करने का निर्णय लिया।

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

अंत में, तालिका 1 विभिन्न प्रयोगों और डेटासेटों के साथ विभिन्न पुस्तकालयों की अनुकूलता को निर्दिष्ट करती है, जिनकी हमने इस पेपर में जांच की है।

3.3 मेट्रिक्स

प्रयोगों का निर्माण करते समय हमारी मुख्य प्राथमिकता एक वस्तुनिष्ठ मीट्रिक ढूंढना था जो हमें सभी विभिन्न पुस्तकालयों की तुलना एक ठोस तरीके से करने की अनुमति दे सके।

आदर्श मीट्रिक प्रशिक्षण कार्य का कुल चलने का समय होता क्योंकि इसके लिए हमें इंतजार करना पड़ता है और भुगतान करना पड़ता है। दुर्भाग्य से, इससे हमारे द्वारा चलाए जा सकने वाले प्रयोगों की संख्या बहुत सीमित हो जाती। सावधानीपूर्वक विचार करने के बाद, हमने प्रति सेकंड संसाधित डेटा बिंदुओं (छवियों) की संख्या को चुना, जो हमारे संख्यात्मक प्रयोगों द्वारा समर्थित परिणाम है। हम इस मीट्रिक के दो प्रकारों पर विचार करते हैं: एक जिसमें हम प्रशिक्षण के लिए एमएल मॉडल का उपयोग करते हैं और हम बैकप्रोपेगेशन करते हैं और एक जिसमें हम एमएल मॉडल का उपयोग नहीं करते हैं और केवल नमूनों पर पुनरावृति करते हैं, उन्हें GPU में कॉपी करते हैं। दो मीट्रिक के बीच अंतर को एल्गोरिथ्म 1 में प्रशिक्षण लूप के छद्म कोड से समझा जा सकता है, जहाँ m गति चर को दर्शाता है। हमने कुल चलने का समय[3] और डेटा लोडर को आरंभ करने में लगने वाला समय भी एकत्र किया। उत्तरार्द्ध इस तथ्य से प्रेरित था कि कुछ पुस्तकालय प्रशिक्षण के दौरान अपनी गति बढ़ाने के लिए पहले से ही महंगी गणनाएँ कर सकते हैं। हमने गति की गणना करने के लिए वार्म-अप भी किया। इस पर आगे उपखंड 3.5 में चर्चा की गई है।

3.4 गति और चलने के समय के बीच सहसंबंध

3.5 चलने के समय पर एक करीबी नज़र

प्रत्येक लाइब्रेरी में आंतरिक तंत्र की हमारी समझ को बढ़ाने के लिए, हमने एक ही बार में यह जांचने का फैसला किया कि प्रत्येक बैच को निष्पादित करने के साथ-साथ डेटा लोडर को आरंभ करने में कितना समय लगा। चित्र 3 पैरामीटर के एकल संयोजन [4] के लिए एल्गोरिदम 1 द्वारा वर्णित चरणों में प्रत्येक लाइब्रेरी द्वारा लिया गया समय दर्शाता है। इन सभी प्रयोगों में 10 बैचों के बाद एक कटऑफ शामिल था।

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

बैंड 1 से 9 का आकार इस बात का सबसे अच्छा संकेत देता है कि प्रत्येक लाइब्रेरी कितनी अच्छी तरह से स्केल करती है, क्योंकि एक लाइब्रेरी पर लिया गया समय

बड़ा डेटासेट उस चौड़ाई के साथ रैखिक रूप से बढ़ता है। हम देख सकते हैं कि अधिकांश लाइब्रेरीज़ की चौड़ाई एक समान होती है, जिसमें डीप लेक सबसे छोटी (सबसे तेज़) होती है। दूसरी ओर, एकमात्र लाइब्रेरी जो गैर-सजातीय चौड़ाई दिखाती है वह FFCV है, जहाँ बैंड 1 से 3 इतने पतले होते हैं कि उन्हें छवि में नहीं देखा जा सकता है।

सभी लाइब्रेरियों के लिए रैप-अप अवधि लगभग एक समान होती है, सिवाय FFCV और डीप लेक के, जिनमें काफी अधिक समय लगता है। रैप-अप में लगने वाला समय ज़्यादातर मॉडल पर निर्भर करता है और यह ज़रूरी नहीं है कि यह इस बात का संकेत हो कि प्रत्येक लाइब्रेरी कितनी अच्छी तरह से स्केल करती है।

इस आंकड़े के आधार पर, हमने गति की गणना करते समय वार्म-अप करने का फैसला किया। इसका मतलब है कि सभी गति गणनाओं में पहले बैच द्वारा लिए गए समय को अनदेखा करना।

[2] यह अक्सर कुछ समीक्षा साहित्य में वांछनीय और अपेक्षित होता है, लेकिन हमने पाया कि छोटे दलों और इन-हाउस वर्कस्टेशनों से जुड़े कई व्यावहारिक अनुप्रयोगों में ऐसा नहीं है।

[3] यह सिमुलेशन की शुरुआत से लेकर कटऑफ तक का समय है, जो व्यवहार में अक्सर केवल 10 बैच होता था।

[4] रैंडम डेटासेट, एकल GPU, 0 कार्यकर्ता, बैच आकार 64