লেখক:
(1) ইয়াসন ওফিডিস, ইলেকট্রিক্যাল ইঞ্জিনিয়ারিং বিভাগ, এবং ইয়েল ইনস্টিটিউট ফর নেটওয়ার্ক সায়েন্স, ইয়েল ইউনিভার্সিটি, নিউ হ্যাভেন {সমান অবদান};
(2) ডিয়েগো কিডানস্কি, ইলেকট্রিক্যাল ইঞ্জিনিয়ারিং বিভাগ, এবং ইয়েল ইনস্টিটিউট ফর নেটওয়ার্ক সায়েন্স, ইয়েল ইউনিভার্সিটি, নিউ হ্যাভেন {সমান অবদান};
(3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, USA, ডিপার্টমেন্ট অফ ইলেকট্রিক্যাল ইঞ্জিনিয়ারিং, এবং ইয়েল ইনস্টিটিউট ফর নেটওয়ার্ক সায়েন্স, ইয়েল ইউনিভার্সিটি, নিউ হ্যাভেন।
তাদের বৈশিষ্ট্য এবং কর্মক্ষমতা তুলনা করার জন্য বেশ কিছু লাইব্রেরি এবং ডেটাসেট নির্বাচন করা হয়েছিল। যদিও যতটা সম্ভব বোধগম্য হওয়ার চেষ্টা করা হয়েছিল, ডেটা লোড করার ক্ষেত্র ক্রমাগত বিকশিত হচ্ছে এবং প্রতিদিন নতুন লাইব্রেরি এবং রিলিজ যুক্ত হচ্ছে। এই বিষয়ে, আমরা আশা করি যে নিম্নলিখিত তালিকাটি ডেটালোডারগুলির বর্তমান ক্ষমতাগুলির একটি ভাল ওভারভিউ প্রদান করবে, অগত্যা দাবি না করে বা সামগ্রিক সেরাটি খুঁজে না পেয়ে (যা সম্ভবত লেখার সময় থেকে প্রকাশের সময় পরিবর্তিত হবে)। আমরা পরীক্ষাগুলির সমস্ত উত্স কোড জনসাধারণের জন্য উপলব্ধ করি এবং ফলাফলগুলি সম্পূর্ণরূপে পুনরুত্পাদনযোগ্য বলে আশা করি৷
আমাদের পরীক্ষা-নিরীক্ষা করার জন্য আমরা সাতটি লাইব্রেরি বেছে নিয়েছি: পাইটর্চ (পাজকে এট আল।, 2019), টর্চডেটা (টর্চডেটা, 2021), হাব (টিম, 2022এ), এফএফসিভি (লেক্লারক এট আল।, 2022), ওয়েবডেটাসেট (ওয়েবডেটাসেট), 2031 কাঠবিড়ালি (টিম, 2022বি), এবং ডিপ লেক (হাম্বারডজুমিয়ান এট আল।, 2022)। একটি আকর্ষণীয় জিনিস যা আমরা আবিষ্কার করেছি তা হল যে সমস্ত লাইব্রেরি একই বৈশিষ্ট্যগুলি সমর্থন করে না। উদাহরণস্বরূপ, আমরা আমাদের দূরবর্তী পরীক্ষাগুলি সম্পাদন করার জন্য একটি S3 বালতিতে হোস্ট করা ডেটাসেটের সাথে FFCV চালাতে পারিনি। যেমন আমরা বিভাগ 1 এ উল্লেখ করেছি, আমরা পাইটর্চে আমাদের সমস্ত পরীক্ষা চালাই। আমরা অন্যান্য জনপ্রিয় মেশিন লার্নিং ফ্রেমওয়ার্কগুলিতে পরীক্ষাগুলি পুনরুত্পাদন করার কথা বিবেচনা করেছি কিন্তু আমরা এই ধারণার বিরুদ্ধে সিদ্ধান্ত নিয়েছি যেহেতু দ্বিতীয় প্রার্থী টেনসরফ্লো হবেন, কিন্তু গুজব রয়েছে যে Google JAX এর পক্ষে এটি থেকে সরে যাচ্ছে। চিত্র 1 গত 12 মাসে বিভিন্ন এমএল ফ্রেমওয়ার্কের জনপ্রিয়তা চিত্রিত করে।
ডেটাসেটগুলির বিষয়ে, আমরা প্রাথমিকভাবে দুটি ভিন্ন শিক্ষার কাজকে সমর্থন করার জন্য দুটি ক্লাসিক্যাল ডেটাসেট বেছে নিয়েছিলাম: চিত্র শ্রেণীবিভাগের জন্য CIFAR-10 (Krizhevsky et al., 2009), এবং CoCo (Lin et al., 2014) অবজেক্ট সনাক্তকরণের জন্য৷ কিছু পরীক্ষা-নিরীক্ষা করার সময়, আমরা অদ্ভুত আচরণ লক্ষ্য করেছি (লাইব্রেরিগুলি প্রত্যাশার চেয়ে ভাল পারফর্ম করছে) যা দ্বারা ব্যাখ্যা করা যেতে পারে
CIFAR-10 মেমরিতে ফিটিং[2]। এই কারণে, আমরা র্যান্ডম নামে একটি তৃতীয় ডেটাসেট তৈরি করেছি, যার মধ্যে 256 বাই 256 পিক্সেল আকারের এলোমেলোভাবে জেনারেট করা রঙিন ছবি এবং 20টির মধ্যে একটি র্যান্ডম ক্লাস রয়েছে। এই তৃতীয় ডেটাসেটে প্রশিক্ষণের জন্য 45000টি, যাচাইকরণের জন্য 5000টি এবং পরীক্ষার জন্য 500টি ছবি রয়েছে, এবং এটি CIFAR-10 এর চেয়ে যথেষ্ট বড়।
বেঞ্চমার্ক তুলনীয় করতে আমরা সমস্ত লাইব্রেরির জন্য একই রূপান্তর ব্যবহার করেছি। একমাত্র ব্যতিক্রম ছিল FFCV, যার বিভিন্ন রূপান্তরের নিজস্ব বাস্তবায়ন রয়েছে। ইমেজ শ্রেণীবিভাগের জন্য ট্রান্সফরমেশন স্ট্যাক নিম্নলিখিতগুলি নিয়ে গঠিত: র্যান্ডম হরাইজন্টাল ফ্লিপ, নরমালাইজেশন, কাটআউট, টেনসরে রূপান্তর।
অবজেক্ট ডিটেকশনের জন্য, আমরা বেশিরভাগই নির্ভর করতাম অ্যালবামেন্টেশনের (Buslaev et al., 2020) রূপান্তর বাস্তবায়নের উপর। স্ট্যাকটি এইরকম দেখাচ্ছিল: র্যান্ডম সাইজ ক্রপ, র্যান্ডম হরাইজন্টাল ফ্লিপ, নরমালাইজেশন, টেনসরে রূপান্তর। এই রূপান্তরগুলি ছবি এবং বাউন্ডিং বাক্স উভয় ক্ষেত্রেই প্রযোজ্য।
যখন সম্ভব, আমরা স্থানীয়ভাবে এবং একটি S3- সমতুল্য বালতিতে ডেটাসেট হোস্ট করেছি। এটি আমাদের নেটওয়ার্কে ডেটার প্রবাহ থেকে প্রশিক্ষণের ফলে মন্থরতা মূল্যায়ন করতে সক্ষম করেছে। আমরা অধ্যায় 4 এ প্রশিক্ষণ সেটিং এর একটি বিশদ বিবরণ প্রদান করব।
প্রদত্ত যে সবচেয়ে নিবিড় প্রশিক্ষণের কাজগুলিতে একাধিক GPU ব্যবহার করা জড়িত, যখনই সম্ভব আমরা একাধিক GPU ইউনিট সহ পরিবেশে একই পরীক্ষা চালিয়েছি। কারণ পরীক্ষা চালানোর সময় সমস্ত লাইব্রেরিতে PyTorch Lightning-এর সম্পূর্ণ সমর্থন ছিল না, আমরা PyTorch থেকে ডিস্ট্রিবিউটেড ডেটা প্যারালাল (DDP) (Li et al., 2020) লাইব্রেরি ব্যবহার করে মাল্টি-GPU প্রয়োগ করার সিদ্ধান্ত নিয়েছি।
কিছু মেশিন লার্নিং প্রকল্পের জন্য, আমাদের শুধুমাত্র একটি বড় ডেটাসেটের একটি উপসেটে অ্যাক্সেসের প্রয়োজন হতে পারে। এই ক্ষেত্রে, পুরো ডেটাসেটের উপর পুনরাবৃত্তি না করেই প্রয়োজনীয় ডেটা পয়েন্টগুলি দ্রুত ফিল্টার করার ক্ষমতা থাকা মোট প্রশিক্ষণের সময়কে ব্যাপকভাবে হ্রাস করতে পারে। কিছু লাইব্রেরি নির্দিষ্ট বৈশিষ্ট্যের উপর ভিত্তি করে ফিল্টার করার অনুমতি দেয়, যেমন ক্লাস (ছবির শ্রেণীবিভাগের কাজের জন্য)। আমরা লাইব্রেরি দ্বারা প্রদত্ত ফিল্টারিং পদ্ধতি ব্যবহার করার জন্য গতিতে লাভ (বা ক্ষতি) অন্বেষণ করেছি (যদি এটি একটি প্রস্তাব দেয়) বনাম মোটেও ফিল্টারিং না করে। যখনই লাইব্রেরি একটি ফিল্টারিং পদ্ধতি অফার করেনি, আমরা সেগুলিকে সহজভাবে প্রয়োগ করেছি, অর্থাৎ, পুরো ডেটাসেট স্ক্যান করে এবং শুধুমাত্র সেই উপাদানগুলিকে রাখি যা নির্দিষ্ট শর্তের সাথে মেলে। দ্রুত ফিল্টারিং কার্যকর করার জন্য অগত্যা তুচ্ছ নয় কারণ এটির জন্য সমস্ত নমুনার পুনরাবৃত্তি এড়াতে একটি সূচকের মতো অতিরিক্ত কাঠামো বজায় রাখতে হবে।
অবশেষে, সারণী 1 আমরা এই কাগজে অন্বেষণ করা বিভিন্ন পরীক্ষা এবং ডেটাসেটের সাথে বিভিন্ন লাইব্রেরির সামঞ্জস্যতা নির্দিষ্ট করে।
পরীক্ষাগুলি তৈরি করার সময় আমাদের প্রধান অগ্রাধিকার ছিল একটি উদ্দেশ্যমূলক মেট্রিক খুঁজে বের করা যা আমাদের সমস্ত বিভিন্ন লাইব্রেরিকে এমনভাবে তুলনা করতে দেয় যা সঠিক ছিল।
আদর্শ মেট্রিক হবে প্রশিক্ষণের কাজের মোট চলমান সময় যেহেতু এটিই আমাদের অপেক্ষা করতে হবে এবং অর্থ প্রদান করতে হবে। দুর্ভাগ্যবশত, এটি আমরা চালানোর পরীক্ষাগুলির সংখ্যাকে ব্যাপকভাবে সীমিত করবে। সতর্কতার সাথে বিবেচনা করার পরে, আমরা প্রতি সেকেন্ডে প্রক্রিয়াকৃত ডেটা পয়েন্টের (ছবি) সংখ্যা বেছে নিয়েছি, এটি আমাদের সংখ্যাগত পরীক্ষা দ্বারা সমর্থিত ফলাফল। আমরা এই মেট্রিকের দুটি রূপ বিবেচনা করি: একটি যেখানে আমরা প্রশিক্ষণের জন্য ML মডেল ব্যবহার করি এবং আমরা ব্যাকপ্রোপাগেশন করি এবং একটি যেখানে আমরা ML মডেল ব্যবহার করি না এবং শুধুমাত্র নমুনাগুলিকে জিপিইউতে অনুলিপি করি। দুটি মেট্রিকের মধ্যে পার্থক্য অ্যালগরিদম 1-এ প্রশিক্ষণ লুপের ছদ্ম-কোড থেকে উপলব্ধি করা যেতে পারে, যেখানে m গতি পরিবর্তনশীলকে বোঝায়। আমরা মোট চলমান সময়ও সংগ্রহ করেছি[3] এবং ডেটালোডারগুলি শুরু হতে যে সময় লেগেছিল। পরবর্তীটি এই সত্য দ্বারা অনুপ্রাণিত হয়েছিল যে কিছু লাইব্রেরি প্রশিক্ষণের সময় তাদের গতি বাড়ানোর জন্য আগে থেকেই ব্যয়বহুল গণনা করতে পারে। আমরা গতি গণনা করার জন্য একটি ওয়ার্ম-আপও শেষ করেছি। এটি উপধারা 3.5 এ আরও আলোচনা করা হয়েছে।
প্রতিটি লাইব্রেরিতে অভ্যন্তরীণ প্রক্রিয়া সম্পর্কে আমাদের বোধগম্যতা বাড়ানোর জন্য, আমরা প্রতিটি ব্যাচ চালানোর পাশাপাশি ডেটালোডার আরম্ভ করতে কত সময় লেগেছে তা একবার চালানোর জন্য পরিদর্শন করার সিদ্ধান্ত নিয়েছি। চিত্র 3 পরামিতিগুলির একটি একক সংমিশ্রণের জন্য চিত্রিত করেছে [4], অ্যালগরিদম 1 দ্বারা বর্ণিত পদক্ষেপগুলিতে প্রতিটি লাইব্রেরি দ্বারা নেওয়া সময়। এই সমস্ত পরীক্ষাগুলি 10 ব্যাচের পরে একটি কাটঅফ জড়িত।
মজার বিষয় হল, প্রথম ব্যাচটি অন্যদের তুলনায় যথেষ্ট সময় নেয়। এটিকে নিম্নরূপ ব্যাখ্যা করা যেতে পারে: যেহেতু বেশিরভাগ ডেটালোডার এই মুহুর্তে অলস লোডিং ডেটার উপর নির্ভর করে, ভবিষ্যতের কলগুলি প্রি-ফেচিং, ইতিমধ্যে মেমরিতে থাকা ডেটা এবং সমান্তরালকরণ (জিপিইউ গণনা করতে ব্যস্ত থাকাকালীন কাজগুলি করা) থেকে উপকৃত হবে৷
1 থেকে 9 ব্যান্ডের আকার প্রতিটি লাইব্রেরি কতটা ভালভাবে স্কেল করেছে তার সর্বোত্তম ইঙ্গিত দেয়
বড় ডেটাসেট সেই প্রস্থের সাথে রৈখিকভাবে বৃদ্ধি পায়। আমরা লক্ষ্য করতে পারি যে বেশিরভাগ লাইব্রেরির একটি অভিন্ন প্রস্থ রয়েছে, ডিপ লেকটি সবচেয়ে ছোট (দ্রুততম)। অন্যদিকে, একমাত্র লাইব্রেরি যা অ-সমজাতীয় প্রস্থ দেখায় তা হল FFCV, যেখানে 1 থেকে 3 ব্যান্ডগুলি এতটাই পাতলা যে সেগুলি ছবিতে দেখা যায় না।
এফএফসিভি এবং ডিপ লেক ব্যতীত সমস্ত লাইব্রেরির জন্য মোড়ানো সময়কাল প্রায় একই সময় নেয়, যা যথেষ্ট বেশি সময় নেয়। মোড়ানোর সময় ব্যয় করা বেশিরভাগ মডেলের উপর নির্ভর করে এবং প্রতিটি লাইব্রেরি কতটা ভালভাবে স্কেল করে তার ইঙ্গিত দেয় না।
এই চিত্রের উপর ভিত্তি করে, আমরা গতি গণনা করার সময় একটি ওয়ার্ম-আপ করার সিদ্ধান্ত নিয়েছি। এটি সমস্ত গতির গণনায় প্রথম ব্যাচের সময়কে উপেক্ষা করে অনুবাদ করে।
এই কাগজটি CC 4.0 লাইসেন্সের অধীনে arxiv-এ উপলব্ধ ।
[২] এটি প্রায়শই কিছু পর্যালোচনা সাহিত্যে আকাঙ্খিত এবং প্রত্যাশিত কিছু, তবে আমরা ছোট দল এবং অভ্যন্তরীণ ওয়ার্কস্টেশনগুলি জড়িত বেশ কয়েকটি ব্যবহারিক অ্যাপ্লিকেশনের ক্ষেত্রে এটি দেখতে পাইনি।
[৩] এটি সিমুলেশনের শুরু থেকে কাটঅফ পর্যন্ত সময়, যা প্রায়শই ছিল মাত্র 10 ব্যাচ।
[৪] র্যান্ডম ডেটাসেট, একক জিপিইউ, ০ জন কর্মী, ব্যাচের আকার ৬৪