AWS EC2 G5g पर जेम्मा 4 चलाना: एक दक्षिण अफ़्रीकी डेवलपर की फ़ील्ड गाइड

जोहान्सबर्ग कार्यालय की खिड़की के बाहर लोड शेडिंग टिमटिमा रही है क्योंकि हमारा टर्मिनल अंततः एक सफल vLLM हैंडशेक के साथ जगमगा उठता है। हम Google के gemma-4-E2B-it मॉडल को AWS EC2 g5g.4xlarge इंस्टेंस पर धकेल रहे हैं—एक हाइब्रिड बीस्ट जो एकल NVIDIA T4G ट्यूरिंग GPU के साथ Graviton2 aarch64 होस्ट को जोड़ता है। गौतेंग और वेस्टर्न केप की इंजीनियरिंग टीमों को क्षेत्रीय क्लाउड नोड्स पर अत्याधुनिक ओपन-सोर्स मॉडल को तैनात करते समय अद्वितीय बुनियादी ढांचे की बाधाओं का सामना करना पड़ता है। यह फ़ील्ड रिपोर्ट विक्रेता-प्रबंधित शॉर्टकट पर भरोसा किए बिना इस विशिष्ट हाइब्रिड स्टैक को तैनात करते समय आने वाली सटीक बाधाओं को उजागर करती है।

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

आर्किटेक्चर का ब्लाइंड स्पॉट

NVIDIA एक्सीलेटर के साथ जोड़े गए ARM64 होस्ट के लिए दस्तावेज़ ढूंढना किसी अज्ञात क्षेत्र को मैप करने जैसा लगता है। मानक स्थापना स्क्रिप्ट तुरंत विफल हो जाती हैं क्योंकि रिपॉजिटरी मेंटेनर्स द्वारा प्रकाशित डिफ़ॉल्ट आर्किटेक्चर सूचियों में इस सटीक हार्डवेयर जोड़ी को शामिल नहीं किया गया है। केप टाउन और जोहान्सबर्ग के डेवलपर्स जो Ubuntu 24.04 पर इस कॉन्फ़िगरेशन को शुरू करने की कोशिश कर रहे हैं, उन्हें स्रोत से पैकेज कंपाइल करने होंगे या निर्भरता मैनिफ़ेस्ट को मैन्युअल रूप से पैच करना होगा। इन लक्षित हस्तक्षेपों के बिना, मॉडल वेट्स के स्थानीय डिस्क स्टोरेज को छूने से पहले ही pip इंस्टॉलेशन में त्रुटि आ जाती है।

जब क्लाउड बिलिंग घड़ी हर सेकंड टिक-टिक करती है, तो स्थानीय इंजीनियरिंग कंपनियों के पास घंटों की ट्रॉयल और एरर का खर्च उठाने का समय नहीं होता है। यह पहचानना कि पैकेज मेंटेनर्स ने विशिष्ट टेंसर लाइब्रेरी के लिए aarch64 व्हील्स को पूरी तरह से छोड़ दिया था, ने हमारी टीम के कई दिनों के अंधे डिबगिंग को बचा लिया। आगे बढ़ने से पहले हमें रिपॉजिटरी को फ़ॉर्क करना पड़ा, बिल्ड लक्ष्यों को फिर से लिखना पड़ा, और विशेष रूप से Graviton2 इंस्ट्रक्शन सेट के लिए अनुकूलित कस्टम बाइनरी डिस्ट्रिब्यूशन को कंपाइल करना पड़ा।

वर्ज़न फ्लोर को पार करना

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

"जब आपका ARM आर्किटेक्चर AWS पर एक NVIDIA GPU से मिलता है, तो मानक डिप्लॉयमेंट प्लेबुक तुरंत बेकार कागज़ बन जाती हैं।"

अलग-थलग विकास वातावरण में निर्भरता श्रृंखलाओं के माध्यम से काम करना बहु-आर्किटेक्चर कंटेनरों की नाजुकता को उजागर करता है। इंजीनियर अक्सर यह मान लेते हैं कि आधिकारिक डीप लर्निंग इमेज खींचने से तुरंत हार्डवेयर त्वरण (acceleration) की गारंटी मिलती है। g5g.4xlarge जैसे विशिष्ट इंस्टेंस पर, बेस OS कर्नेल से लेकर इन्फेरेंस सर्वर तक हर परत को मैन्युअल रूप से ऑडिट किया जाना चाहिए और T4G एक्सीलेटर की भौतिक बाधाओं के खिलाफ सत्यापित किया जाना चाहिए।

64 KiB मेमोरी वॉल

ARM होस्ट CPU और NVIDIA T4G GPU के बीच टेंसर डेटा पास करना एक कठिन बुनियादी ढांचे की सीमा को उजागर करता है जो निष्पादन को पूरी तरह रोक देता है। डिफ़ॉल्ट इंटर-प्रोसेस कम्युनिकेशन शेयर्ड मेमोरी सीलिंग एक प्रतिबंधात्मक 64 KiB पर है, जिससे टेंसर पैरेलल लोडिंग के दौरान तत्काल सेगमेंटेशन फॉल्ट होता है। भारी ट्रांसफॉर्मर मॉडल चलाने वाली स्थानीय टीमों को इन मूक मेमोरी एबॉर्स्ट को रोकने के लिए कर्नेल पैरामीटर को सक्रिय रूप से पुनर्व्यवस्थित करना होगा।

📌 मुख्य बिंदु: स्पष्ट IPC होस्ट कॉन्फ़िगरेशन का उपयोग करके डिफ़ॉल्ट 64 KiB शेयर्ड मेमोरी लिमिट को ओवरराइड करना एकमात्र अनिवार्य कदम है जो मॉडल वेट एलोकेशन के दौरान g5g.4xlarge इंस्टेंस को क्रैश होने से बचाता है।

क्लस्टर को स्थिर करने के लिए उठाए गए सटीक कदम यहाँ दिए गए हैं:

1. Ubuntu 24.04 के साथ डीप लर्निंग ARM64 AMI चलाने वाला AWS EC2 g5g.4xlarge इंस्टेंस प्रोविज़न करें।
2. NVIDIA ड्राइवर को अपडेट करें और T4G एक्सीलेटर के लिए कंप्यूट क्षमता 7.5 संगतता को सत्यापित करें।
3. इंटर-प्रोसेस कम्युनिकेशन बफर को 64 KiB से आगे बढ़ाने के लिए कस्टम पर्यावरण चर (environment variables) कॉन्फ़िगर करें।
4. स्पष्ट रूप से संकलित (compiled) aarch64 बाइनरी व्हील्स का उपयोग करके vLLM इंजन को इनिशियलाइज़ करें।

मुख्य तथ्य

• लक्षित मॉडल: नेटिव bf16 प्रेसिजन रिलीज़ में google/gemma-4-E2B-it।
• हार्डवेयर प्लेटफ़ॉर्म: Graviton2 और 1x NVIDIA T4G वाला AWS EC2 g5g.4xlarge।
• कंप्यूट सीमाएं: कंप्यूट क्षमता 7.5 और 15,360 MiB VRAM पर काम करने वाला ट्यूरिंग आर्किटेक्चर।
• ऑपरेटिंग सिस्टम: Ubuntu 24.04 पर निर्मित डीप लर्निंग ARM64 AMI।

निष्कर्ष

उभरते बाजारों में लचीले क्लाउड बुनियादी ढांचे की इंजीनियरिंग करने का मतलब वैश्विक क्लाउड प्रदाताओं द्वारा छोड़ी गई कमियों में महारत हासिल करना है। जब मानक दस्तावेज़ समाप्त हो जाते हैं और डाउनटाइम का हर मिनट स्थानीय परिचालन बजट को प्रभावित करता है, तो आपकी इंजीनियरिंग टीम हार्डवेयर कॉन्फ़िगरेशन को कैसे संभालेगी?