SageMaker का GPU-सचेत द्वार—82% तेज पहला टोकन AWS का अपना दावा

24 सितंबर 2026 को 06:00 pm बजे|लेखक: QUASA संपादकीय टीम|5 मिनट पढ़ने का समय

AWS ने 18 सितंबर 2026 को Amazon SageMaker HyperPod Inference Gateway की घोषणा की—Amazon EKS पर HyperPod समूहों के लिए ऐसी अनुरोध-मार्ग परत, जो GPU और मॉडल-सर्वर की स्थिति देखकर उपयुक्त पॉड चुनती है। AWS की लॉन्च घोषणा में कंपनी ने अपने परीक्षण के आधार पर प्रथम-टोकन विलंब में अधिकतम 82% कमी का दावा किया और कहा कि प्रति-समूह Gateway उन क्षेत्रों में उपलब्ध है जहां HyperPod Inference ऐड-ऑन उपलब्ध है।

इसलिए शीर्षक का “82% तेज” स्वतंत्र रूप से प्रमाणित सार्वभौमिक परिणाम नहीं, बल्कि 18 सितंबर को घोषित उत्पाद के लिए AWS का सर्वोत्तम परीक्षण-दावा है। Techseen की स्रोत-आधारित समीक्षा भी 82% को AWS द्वारा बताया गया आंकड़ा मानती है और अलग-अलग कार्यभारों पर स्वतंत्र पुनरुत्पादन को खुला प्रश्न बताती है। भारत में बड़े भाषा मॉडल चलाने वाली AWS और Kubernetes टीमों के लिए दूसरा अहम तथ्य यह है कि Gateway पर अनुरोध-स्तर JWT प्रमाणीकरण स्वतः चालू नहीं होता।

Gateway पॉड का चुनाव कैसे बदलता है

सामान्य राउंड-रॉबिन वितरण हर पॉड के भीतर चल रहे वास्तविक काम को नहीं समझता। परिणामतः नया अनुरोध किसी लंबी कतार वाले पॉड के पीछे पहुंच सकता है, जबकि उसी मॉडल की दूसरी प्रतिकृति के पास खाली क्षमता हो। Inference Gateway का उद्देश्य इसी असमानता को मार्ग-निर्णय में शामिल करना है।

अनुरोध पहले Envoy Gateway से गुजरता है। Body-Based Router उसके मॉडल क्षेत्र को पढ़कर सही मॉडल-पूल चुनता है; फिर Endpoint Picker योग्य पॉडों को कतार की गहराई, चल रहे अनुरोधों और KV कैश उपयोग जैसे संकेतों पर अंक देता है। एक साझा Gateway कई मॉडल-पूल संभाल सकता है, जबकि प्रत्येक मॉडल के लिए अलग अनुसूचक तय किया जा सकता है।

चयन में उपसर्ग-कैश साम्य और LoRA अनुकूलक की उपलब्धता भी शामिल हो सकती है। समान लंबे आरंभिक प्रॉम्प्ट वाला अनुरोध उस पॉड पर भेजना लाभकारी हो सकता है जहां संबंधित उपसर्ग पहले से कैश है; LoRA अनुरोध के लिए पहले से लोड अनुकूलक वाला पॉड अदला-बदली का समय बचा सकता है। फिर भी फैसला किसी एक संकेत पर नहीं होता—हर संकेत का भार विन्यास में बदला जा सकता है।

82% के दावे की वास्तविक सीमा

AWS ने एक उदाहरण में प्रथम टोकन आने का समय 4.4 सेकंड से घटकर 800 मिलीसेकंड से कम बताया। परीक्षण में 8 अरब से 235 अरब पैरामीटर वाले चार मॉडल, p5.48xlarge पर H100 और g5 पर A10G संसाधन, नियंत्रित भार तथा आंतरिक Application Load Balancer शामिल थे। तुलना उन्हीं मॉडल प्रतिकृतियों पर Kubernetes के राउंड-रॉबिन मार्ग से की गई थी।

कंपनी के परिणामों में सबसे बड़ा लाभ मिश्रित GPU पीढ़ियों, अचानक बढ़ते यातायात और साझा प्रॉम्प्ट उपसर्ग जैसी असमान परिस्थितियों में दिखा। समान GPU और स्थिर यातायात वाली व्यवस्था में बुद्धिमान मार्ग और राउंड-रॉबिन का प्रदर्शन तुलनीय रहा। इसका अर्थ है कि Gateway मौजूदा क्षमता का वितरण सुधार सकता है; सारे पॉड भर जाने पर वह अतिरिक्त GPU क्षमता नहीं बनाता।

अधिकतम 82% को उत्पादन की गारंटी मानना इसलिए उचित नहीं होगा। वास्तविक अंतर मॉडल, प्रॉम्प्ट-वितरण, समवर्ती अनुरोधों, कैश पुनःप्रयोग, पॉडों की संख्या और GPU मिश्रण पर निर्भर करेगा। स्वतंत्र परीक्षण उपलब्ध न होने के कारण अलग समूहों को अपने सामान्य और चरम भार पर प्रथम-टोकन विलंब, आउटपुट गति, त्रुटियों और GPU उपयोग को अलग से मापना होगा।

संस्करण गलत हुआ तो संकेत गायब हो सकता है

AWS की तैनाती आवश्यकताएं HyperPod Inference ऐड-ऑन का न्यूनतम संस्करण v2.0.0-eksbuild.2, vLLM का v0.9.2 या नया संस्करण और SGLang का v0.3.5.post1 या नया संस्करण निर्धारित करती हैं। पुराने vLLM में KV कैश माप का नाम अलग होने के कारण Gateway उस संकेत को बिना त्रुटि दिखाए अनदेखा कर देता है और शेष संकेतों से अनुरोध भेजता रहता है। पुराने SGLang में आवश्यक माप-सुविधा समर्थित नहीं होने से कंटेनर शुरू नहीं होता।

यह अंतर खास तौर पर vLLM में पकड़ना कठिन हो सकता है: सेवा चलती रहती है, पर कैश-सचेत मार्ग का अपेक्षित लाभ नहीं मिलता। मॉडल पॉडों के लेबल भी अनुसूचक के चयनकर्ता से मेल खाने चाहिए; अन्यथा इच्छित मॉडल-पूल के योग्य पॉड उपलब्ध नहीं होंगे।

HyperPod Inference ऐड-ऑन कम से कम v2.0.0-eksbuild.2 पर हो और समूह InferenceGatewayConfig संसाधन पहचाने।
vLLM कम से कम v0.9.2 हो; SGLang कम से कम v0.3.5.post1 हो और आवश्यक माप-संग्रह चालू किया गया हो।
मॉडल पॉडों के लेबल और प्रत्येक अनुसूचक का चयनकर्ता एक-दूसरे से मेल खाएं।
चुने गए अंतिम-बिंदु के अनुसार TLS प्रमाणपत्र, cert-manager, AWS Load Balancer Controller और आवश्यक IAM भूमिका तैयार हों।

JWT अलग से जोड़ना जरूरी है

Inference Gateway से बने अंतिम-बिंदु पर अनुरोध-स्तर प्रमाणीकरण या प्राधिकरण डिफॉल्ट रूप से नहीं होता। InferenceGatewayConfig में spec.auth.jwt न देने पर VPC और नेटवर्क नियंत्रणों से अंतिम-बिंदु तक पहुंचने वाला अनुरोध स्वीकार किया जा सकता है। निजी नेटवर्क पहुंच सीमित करता है, लेकिन वह अनुरोध भेजने वाली सेवा की पहचान या मॉडल-स्तर अनुमति का विकल्प नहीं है।

AWS हर Gateway पर JWT वाहक-टोकन प्रमाणीकरण चालू करने की कड़ी सिफारिश करता है। इसके लिए OIDC जारीकर्ता का URL, हस्ताक्षर सत्यापन के लिए HTTPS JWKS अंतिम-बिंदु और स्वीकृत दर्शक अथवा आवश्यक दावे देने होते हैं। मानक OpenAI-संगत अनुरोध प्रारूप ग्राहक कोड में बदलाव घटा सकता है, पर सुरक्षा विन्यास स्वयं पूरा नहीं करता।

साझा Gateway कई मॉडल-पूलों का प्रवेश-बिंदु हो सकता है, इसलिए JWT के साथ दर-सीमा, किरायेदार पृथक्करण और अनुरोध लेखांकन भी स्थानीय उत्पादन नीति में तय करने होंगे। ये नियंत्रण 82% वाले प्रदर्शन परीक्षण का हिस्सा मानकर नहीं चलने चाहिए; वे तैनाती की अलग सुरक्षा जिम्मेदारी हैं।

अभी प्रति-समूह मार्ग ही उपलब्ध है

वर्तमान उपलब्धता प्रत्येक HyperPod/EKS समूह के भीतर स्थानीय, GPU-सचेत मार्ग तक सीमित है। कई समूहों और क्षेत्रों के बीच विफलता-परिवर्तन, वैश्विक दर-सीमा और लागत-सचेत मार्ग वाला Global Inference Router अभी भावी योजना है। मौजूदा Gateway को क्षेत्र-पार नियंत्रण-परत समझना गलत होगा।

अभी पुष्टि इतनी है कि AWS ने Kubernetes-आधारित GPU-सचेत मार्ग जारी किया है और अपने नियंत्रित परीक्षण में प्रथम-टोकन विलंब अधिकतम 82% घटने का दावा किया है। विभिन्न उत्पादन समूहों पर स्वतंत्र परिणाम और JWT-सुरक्षित तैनातियों के आंकड़े ही बताएंगे कि यह लाभ अलग मॉडल, GPU मिश्रण और यातायात रूपों में कितना दोहराया जा सकता है।

यह भी पढ़ें:

साझा करें: