निष्क्रिय Inference GPU Pool का उपयोग करके GPU job scheduling: LG AI Yeonguwon की इंफ्रास्ट्रक्चर दक्षता का एक उदाहरण

LG AI Yeonguwon Platform&Infra Team द्वारा प्रकाशित यह लेख बताता है कि बड़े भाषा मॉडल (LLM) सेवा संचालन के दौरान खाली पड़े GPU संसाधनों को शोध और प्रयोगात्मक कार्यों में कैसे पुन: उपयोग किया गया। AI सेवा चलाने वाली कंपनियाँ आम तौर पर ट्रैफ़िक के शिखर स्तर को आधार मानकर पहले से GPU सुरक्षित रखती हैं, इसलिए ट्रैफ़िक कम होने वाले समय में महंगे GPU केवल memory घेरकर खाली पड़े रहते हैं। इस संस्थान ने ऐसे खाली समय के GPU को training और evaluation jobs में अपने-आप आवंटित करने वाली pipeline बनाई, और अतिरिक्त उपकरण खरीदे बिना compute resources सुरक्षित करने में सफलता हासिल की।

मुख्य समस्या की परिभाषा

  • LLM सेवाओं की ऑटो स्केलिंग सीमा: सामान्य web services से अलग, LLM में input-output token लंबाई और model structure के अनुसार प्रति request GPU खपत काफी बदलती रहती है। इसलिए CPU उपयोग दर या memory occupancy जैसे पारंपरिक संकेतकों से वास्तविक load को मापना कठिन है।
  • निष्क्रिय संसाधनों का पैमाना: replica (service instance replica) एक के GPU 4 कार्ड उपयोग करने वाले environment में, रात के non-peak समय (20:00~अगले दिन 8:00) में प्रतिदिन औसतन 52 GPU लगभग 12 घंटे तक खाली पड़े रहते थे।

समाधान का तरीका

  • vLLM के आंतरिक संकेतकों का उपयोग: सामान्य system metrics के बजाय LLM inference engine vLLM द्वारा दिए गए real-time throughput और queue waiting status जैसे संकेतकों को ऑटो स्केलिंग का आधार बनाकर, LLM की विशेषताओं के अनुरूप सटीक resource adjustment लागू किया गया।
  • Best-effort तरीके से jobs चलाना: रात के निष्क्रिय GPU पर शोध कार्य चलाए जाते हैं, लेकिन जैसे ही ट्रैफ़िक फिर बढ़े, शोध कार्यों को कभी भी रोककर GPU को सेवा में वापस देने वाली संरचना बनाई गई, ताकि service stability प्रभावित न हो।
  • Argo Workflows आधारित pipeline: Docker image इकाई पर jobs को परिभाषित किया गया, और data preprocessing, pretraining, supervised fine-tuning, reinforcement learning, evaluation आदि को step (चरण) में बाँटकर क्रमिक या समानांतर रूप से चलाने योग्य बनाया गया।

डिज़ाइन सिद्धांतों की विशेषताएँ

  • सार्वभौमिकता: training हो या inference, किसी भी framework को Docker image में पैक किया जाए तो उसे उसी रूप में चलाया जा सकता है।
  • विस्तारशीलता और लचीलापन: नए job type जुड़ने पर भी pipeline code बदले बिना उन्हें स्वीकार किया जा सकता है।
  • पुनरुत्पादकता: सभी settings को code के बजाय external parameters के रूप में inject किया जाता है, और input-output को cloud storage में manage किया जाता है, इसलिए समान conditions पर समान results सुनिश्चित होते हैं। pipeline का state preserve न करने वाला stateless structure भी operational stability में योगदान देता है।

संचालन परिणाम

  • संचित उपयोग: नवंबर 2025 से जनवरी 2026 तक लगभग 3 महीनों में 85 jobs चलाई गईं, और कुल GPU उपयोग 95,000 GPU घंटे तक पहुँचा।
  • वृद्धि रुझान: जनवरी का GPU उपयोग नवंबर की तुलना में लगभग 70% बढ़ा, और 24 घंटे के मानक पर यह लगभग 55 नए GPU हासिल करने के बराबर प्रभाव था।
  • लागत में कमी: समान computation को public cloud के 3-वर्षीय commitment मानक पर बदलकर देखें तो जनवरी के एक महीने में लगभग 7.5 करोड़ वॉन, और 3 महीनों के संचयी आधार पर लगभग 18.5 करोड़ वॉन के बराबर बचत हुई।

आगे की योजना

  • स्केलिंग संकेतकों का उन्नयन: प्रत्येक service के usage pattern को और सूक्ष्म स्तर पर विभाजित करके resource allocation logic को अधिक परिष्कृत किया जाएगा।
  • सदैव सक्रिय scheduling का विस्तार: Kubernetes और अपने model EXAONE का उपयोग करके केवल रात में ही नहीं, बल्कि जैसे ही resources खाली हों, तुरंत jobs चलाने वाली always-on execution system तक विस्तार करने की योजना है।
  • UX सुधार: शोधकर्ताओं के लिए job request से monitoring तक का कार्य सहज रूप से करने योग्य interface तैयार किया जाएगा।

यह उदाहरण इस बात का संकेत देता है कि GPU की कमी जैसी उद्योग-व्यापी समस्या को hardware expansion के बजाय operational structure में सुधार करके भी हल किया जा सकता है। खासकर LLM services में load measurement की कठिनाई को vLLM के आंतरिक संकेतकों से पार किया गया, और शोध कार्यों को Best-effort पर रखकर service stability तथा resource utilization जैसे दो परस्पर-विरोधी लक्ष्यों को एक साथ साधा गया। अतिरिक्त निवेश के बिना लगभग 18 करोड़ वॉन स्तर की लागत बचत का यह मात्रात्मक परिणाम GPU infrastructure चलाने वाले अन्य संगठनों के लिए भी एक उपयोगी operational model प्रस्तुत करता है。

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.