Towards Multi-Model LLM Schedulers: Empirical Insights into Offloading and Preemption
यह शोध पत्र एक अनुभवजन्य अध्ययन प्रस्तुत करता है जो यह प्रकट करता है कि विषम हार्डवेयर पर मल्टी-मॉडल LLM शेड्यूलिंग, CPU-GPU ऑफलोडिंग से मॉडल-निर्भर प्रदर्शन गिरावट और स्टेट रीलोड्स द्वारा संचालित पर्याप्त प्रीएम्प्शन ओवरहेड का सामना करती है, जिससे कुशल अगली पीढ़ी के शेड्यूलर डिजाइन करने के लिए महत्वपूर्ण कारकों की पहचान होती है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक व्यस्त रसोई (एक कंप्यूटर सर्वर) चला रहे हैं जिसमें कुछ सुपर-फास्ट शेफ (GPUs) और एक धीमा, लेकिन बहुत विशाल भंडार वाला सहायक (CPU) है। आपका लक्ष्य एक ही समय में कई अलग-अलग प्रकार के जटिल व्यंजन (Large Language Models या LLMs) बनाना है। कभी-कभी, रसोई इतनी भीड़भाड़ वाली हो जाती है कि शेफ के पास काउंटर की जगह खत्म हो जाती है, तो आपको भंडार सहायक से मदद माँगनी पड़ती है ताकि वह कुछ सामग्री संभाल सके या कुछ कटाई-छटाई का काम भी कर सके।
यह पेपर इस बात का एक विस्तृत अध्ययन है कि जब आप काम को तेज़ शेफ और धीमे सहायक के बीच विभाजित करने की कोशिश करते हैं, या जब आपको किसी अधिक ज़रूरी व्यंजन को पकाने के लिए अचानक एक मौजूदा व्यंजन को रोकना पड़ता है, तो क्या होता है।
यहाँ इस अध्ययन की मुख्य खोजों को सरल भाषा में समझाया गया है:
1. "हाफ-शेफ" समस्या (Offloading)
जब कोई व्यंजन शेफ के काउंटर के लिए बहुत बड़ा होता है, तो आप रेसिपी के कुछ चरणों को भंडार सहायक के पास भेज देते हैं।
- निष्कर्ष: यह एक सुचारू बदलाव नहीं है। यदि आप काम का केवल एक छोटा सा हिस्सा भी धीमे सहायक को सौंपते हैं, तो खाना बनाने की गति थोड़ी सी कम नहीं होती; बल्कि वह बुरी तरह गिर जाती है।
- उपमा: इसे एक रिले रेस की तरह समझें। यदि तेज़ धावक (GPU) को दौड़ के एक छोटे से हिस्से के लिए भी बैटन एक धीमे चलने वाले (CPU) को सौंपना पड़ता है, तो पूरी टीम नाटकीय रूप से धीमी हो जाती है।
- आश्चर्य: छोटे व्यंजन (छोटे AI मॉडल) सबसे अधिक प्रभावित होते हैं। यदि आप एक छोटे मॉडल का एक छोटा सा हिस्सा भी ऑफलोड करने की कोशिश करते हैं, तो वह बहुत धीमा हो जाता है। बड़े व्यंजन (बड़े मॉडल) इस विभाजन को बेहतर तरीके से संभालते हैं, वे अधिक धीरे-धीरे धीमे होते हैं।
- सबक: आप केवल अंदाज़ा नहीं लगा सकते कि CPU को कितना काम देना है। आपको पता होना चाहिए कि आप कौन सा "व्यंजन" बना रहे हैं, क्योंकि कुछ मॉडल बँटने (split होने) को अन्य मॉडलों की तुलना में बहुत अधिक नापसंद करते हैं।
2. "स्विचिंग कॉस्ट" (Preemption)
कभी-कभी, एक VIP ग्राहक एक नया व्यंजन ऑर्डर करता है, और आपको वर्तमान शेफ को रोकना पड़ता है, उनका स्टेशन खाली करना पड़ता है, और नया काम शुरू करना पड़ता है। इसे "प्रीएम्प्शन" (Preemption) कहा जाता है।
- निष्कर्ष: एक व्यंजन को बदलने में लगने वाला समय लगभग एक जैसा ही होता है, चाहे आप वर्तमान व्यंजन को 1 मिनट के बाद रोकें या 1 घंटे के बाद।
- उपमा: कल्पना कीजिए कि आप एक विशाल भित्ति चित्र (mural) पेंट कर रहे हैं। यदि आपको किसी और को पेंट करने देने के लिए रुकना पड़ता है, तो अपने ब्रश साफ करने और नए पेंटर के ब्रश तैयार करने में लगने वाला समय वही रहता है, चाहे आपने 10 फीट पेंट किया हो या 1,000 फीट। आपने कितना पेंट किया, इससे फर्क नहीं पड़ता; स्विच करने में लगने वाला समय निश्चित है।
- बड़ा खुलासा: अधिकांश लोग सोचते थे कि "नोट्स" (वह स्मृति जो पहले पेंट किया गया था, जिसे KV cache कहा जाता है) को स्थानांतरित करने में लगने वाला समय ही मुख्य कारण है। अध्ययन ने पाया कि नोट्स को स्थानांतरित करना वास्तव में तात्कालिक है (1% से भी कम समय लेता है)। असली समय बर्बाद करने वाला कारक पुराने शेफ के औजारों को अनपैक करना और नए शेफ के औजारों को अनपैक करना है (हार्ड ड्राइव से मॉडल वेट्स को लोड करना)।
- सबक: कार्य बदलना महंगा है, लेकिन इसकी लागत अनुमानित है। यह पूरी तरह से "टूलकिट" (मॉडल का आकार) के भारी होने पर निर्भर करता है, न कि इस बात पर कि काम कितनी देर से चल रहा है।
3. "ट्रैफिक जाम" (Data Movement)
जब चीज़ों को तेज़ शेफ और धीमे सहायक के बीच ले जाया जाता है, तो उन्हें एक गलियारे (डेटा केबल) से होकर गुजरना पड़ता है।
- निष्कर्ष: भले ही "नोट्स" (मेमोरी) बहुत बड़े हो जाएं क्योंकि व्यंजन बहुत लंबा है, फिर भी उन्हें स्थानांतरित करना औजारों को अनपैक करने की तुलना में बहुत तेज़ है।
- उपमा: यह एक कागज़ के एक पन्ने को ले जाने बनाम एक पूरी बुकशेल्फ़ को ले जाने जैसा है। पन्ने (नोट्स) को ले जाना इतना तेज़ है कि वह गिनती में भी नहीं आता। बुकशेल्फ़ (मॉडल टूल्स) को ले जाने में बहुत समय लगता है।
- सबक: कार्य बदलने का निर्णय लेते समय "नोट्स" के आकार की चिंता न करें। "बुकशेल्फ़" के आकार की चिंता करें।
4. "हार्डवेयर व्यक्तित्व" (Hardware Personality)
अध्ययन ने दो अलग-अलग प्रकार की रसोइयों (दो अलग-अलग GPU) का परीक्षण किया।
- निष्कर्ष: एक रसोई दूसरे की तुलना में खाना बनाने में तेज़ थी लेकिन स्विच करने में धीमी थी।
- उपमा: एक रसोई में एक सुपर-फास्ट शेफ है लेकिन गलियारा संकरा है, जिससे औजारों को जल्दी बदलना मुश्किल है। दूसरी रसोई में थोड़ा धीमा शेफ है लेकिन गलियारा चौड़ा है, जिससे बदलाव आसान है।
- सबक: आप "एक ही नियम सबके लिए" (one-size-fits-all) वाला नियम इस्तेमाल नहीं कर सकते। कार्यों को शेड्यूल करने का सबसे अच्छा तरीका आपके पास मौजूद हार्डवेयर पर निर्भर करता है।
भविष्य के लिए सारांश
लेखकों का निष्कर्ष है कि अगली पीढ़ी के "किचन मैनेजरों" (schedulers) को अधिक स्मार्ट होने की आवश्यकता है। उन्हें केवल कतार (queue) में कितने ऑर्डर हैं, यह नहीं देखना चाहिए। उन्हें पता होना चाहिए:
- यह कौन सा मॉडल है? (कुछ मॉडल बँटने को नापसंद करते हैं)।
- टूलकिट कितनी बड़ी है? (यह निर्धारित करता है कि एक स्विच में कितना समय लगेगा)।
- यह किस तरह की रसोई है? (अलग-अलग हार्डवेयर नियमों को बदल देते हैं)।
इन विशिष्ट बारीकियों को समझकर, मैनेजर चीज़ों को गलत तरीके से थोपने के बजाय, एक ऐसा सिस्टम बना सकते हैं जो कई अलग-अलग AI मॉडल को कुशलतापूर्वक चला सके बिना रसोई को ठप किए।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।