AWS EC2 G5g पर Gemma 4 डिप्लॉय करना: हार्डवेयर बेमेल की एक सच्चाई

दिल्ली के नेहरू प्लेस में एक को-वर्किंग स्पेस में बैठे हुए, हमारी इंजीनियरिंग टीम एक टर्मिनल स्क्रीन को देख रही थी जिस पर सेगमेंटेशन फॉल्ट आ रहे थे जो मानक AWS डॉक्यूमेंटेशन को धेंगा दिखा रहे थे। हम AWS EC2 g5g.4xlarge इंस्टेंस पर google/gemma-4-E2B-it को स्पिन अप करने की कोशिश कर रहे थे—यह एक हाइब्रिड मशीन है जो Graviton2 aarch64 CPU को NVIDIA T4G GPU के साथ जोड़ती है। क्लाउड आर्किटेक्ट इन हेटेरोजेनस सेटअप को लागत प्रभावी चमत्कारों के रूप में पेश करते हैं, लेकिन जैसे ही आप आधुनिक AI मॉडल को अपरंपरागत निर्देश सेट (instruction sets) पर धकेलते हैं, वास्तविकता में मुश्किलें सामने आने लगती हैं।

आर्किटेक्चर का वह अंतर जिसके बारे में कोई दस्तावेज़ नहीं लिखता

अधिकांश इंफ्रास्ट्रक्चर टीमें मानती हैं कि आधुनिक LLM रनटाइम मनमाने हार्डवेयर स्टैक को आसानी से संभाल लेते हैं। वे ऐसा नहीं करते। जब उबंटू 24.04 पर चलने वाले 7.5 कंप्यूट क्षमता वाले NVIDIA T4G के खिलाफ gemma-4-E2B-it को डिप्लॉय किया जाता है, तो पैकेज मेंटेनर्स महत्वपूर्ण ARM आर्किटेक्चर लिस्टिंग से चूक जाते हैं।

सही pip व्हील्स खोजने के लिए क्रॉस-कंपाइलेशन त्रुटियों से जूझते हुए सोर्स से कस्टम डिपेंडेंसी को संकलित (compile) करने की आवश्यकता पड़ी। यदि आप दिल्ली क्षेत्र से काम कर रहे हैं जहाँ बैंडविड्थ और इंस्टेंस की उपलब्धता तेज़ इटेशन तय करती है, तो अनडॉक्यूमेंटेड आर्किटेक्चर सूचियों पर घंटों बर्बाद करना मुनाफे के मार्जिन को नुकसान पहुंचाता है।

"हेटेरोजेनस क्लाउड इंस्टेंस बहुत बड़े वादे करते हैं, लेकिन एक भी टोकन जनरेट होने से पहले वे कस्टम बिल्ड फेलियर थमा देते हैं।"

📌 मुख्य बिंदु: vLLM के लिए मानक pip व्हील्स लेगेसी ट्यूरिंग GPU के साथ जोड़े गए aarch64 होस्ट्स पर चुपचाप फेल हो जाते हैं, जब तक कि आप प्री-कंपाइलड बाइनरी धारणाओं को हटा नहीं देते।

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

आधुनिक वेट्स को चलाने के लिए आधुनिक सर्विंग इंजन की आवश्यकता होती है। vLLM के पुराने वर्ज़न Gemma 4 द्वारा आवश्यक मेमोरी लेआउट पर तुरंत अटक जाते हैं, और अस्पष्ट dtype त्रुटियाँ फेंकते हैं जो अंतर्निहित वर्ज़न बेमेल को छिपा देती हैं।

अत्याधुनिक मुख्य शाखा (bleeding-edge main branch) में अपग्रेड करने से इनिशियलाइज़ेशन क्रैश ठीक हो गए, लेकिन हमारे Deep Learning ARM64 AMI पर नए कर्नेल कंपाइलेशन बॉटलनैक पैदा हो गए। इस तिमाही में जारी किए गए मॉडलों का परीक्षण करते समय डेवलपर्स लेगेसी स्थिर रिलीज़ पर भरोसा नहीं कर सकते।

64 KiB शेयरड मेमोरी की दीवार

जब आप इसकी सबसे कम उम्मीद करते हैं, तब हार्डवेयर इंटीग्रेशन आश्चर्यजनक झटके देता है। हमारा क्लस्टर तब रुक गया जब T4G कर्नेल स्पेस कॉन्फ़िगरेशन में अंतर्निहित 64 KiB शेयरड मेमोरी सीमा के कारण मॉडल निष्पादन पाइपलाइन क्रैश हो गई।

IPC सीमाओं को समायोजित करने से प्रक्रिया जीवित रही, जिससे साबित होता है कि रॉ कंप्यूट क्षमता का कोई मतलब नहीं है यदि इंटर-प्रोसेस कम्यूनिकेशन (IPC) कम-स्तरीय सिस्टम डिफ़ॉल्ट पर अटक जाता है। माइग्रेशन से बचने के लिए हमने जो चेकलिस्ट बनाई वह यहाँ है:

1. ARM64 टारगेट आर्किटेक्चर के खिलाफ vLLM नाइटली बिल्ड को सत्यापित करें।
2. डिफ़ॉल्ट 64 KiB शेयरड मेमोरी आवंटन से अधिक करने के लिए सिस्टम IPC पैरामीटर पैच करें।
3. डीप लर्निंग ARM64 AMI के खिलाफ स्पष्ट रूप से PyTorch 2.12 पिन करें।
4. कस्टम कंपाइलेशन फ्लैग से असमर्थित निर्देश सेट (instruction sets) हटाएँ।

मुख्य तथ्य (Key Facts)

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

निष्कर्ष

हेटेरोजेनस इंस्टेंस डेवलपर्स को अमूर्त (abstracted) क्लाउड डैशबोर्ड के नीचे की गंदी वास्तविकता का सामना करने के लिए मजबूर करते हैं। जैसे-जैसे दिल्ली भर के इंजीनियरिंग हब स्थानीय और हाइब्रिड इन्फेरेंस नोड्स को बढ़ाते हैं, क्लाउड प्रदाता क्रॉस-आर्किटेक्चर संगतता परतों को मानकीकृत (standardise) करने में कितना समय लेंगे?