AgentCore Runtime V2 दो सेकंड में शुरू—भारत के AWS क्षेत्र सूची से बाहर

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

AWS ने 18 सितंबर 2026 को Amazon Bedrock AgentCore Runtime V2 सामान्य रूप से उपलब्ध किया। AWS की आधिकारिक घोषणा के अनुसार, उसके परीक्षण में 200 MB से 2 GB की कंटेनर इमेज का P75 कोल्ड स्टार्ट 1.9–2.0 सेकंड रहा, जबकि V1 का परिणाम 5.4–30 सेकंड था; V2 अभी केवल us-east-1, us-east-2, us-west-2, eu-west-1 और ap-northeast-1 में उपलब्ध है। यह AWS का माप है, हर कार्यभार के लिए दो सेकंड की गारंटी नहीं।

उसी 18 सितंबर की उपलब्धता में भारत की सीमा स्पष्ट है: मुंबई और हैदराबाद V2 की पांच-क्षेत्रीय सूची में शामिल नहीं हैं। इसलिए भारत में उत्पादन एजेंट चलाने वाली टीम को गति और लचीली मेमोरी के लाभ तभी मिलेंगे जब वह समर्थित विदेशी क्षेत्र चुन सके; भारतीय क्षेत्र में बने मौजूदा Runtime को केवल संस्करण बदलकर V2 पर ले जाना अभी संभव नहीं है।

दो सेकंड का परिणाम क्या मापता है

V2 हर नई इकाई के लिए कंटेनर का पूरा आरंभ क्रम दोहराने के बजाय पहले से तैयार वातावरण का स्नैपशॉट पुनर्स्थापित करता है। इसी वजह से AWS के परीक्षण में अलग आकार की कंटेनर इमेज के परिणाम 1.9–2.0 सेकंड के संकरे दायरे में रहे। प्रकाशित संख्या P75 है: तीन-चौथाई माप इस सीमा तक आए, लेकिन इससे सबसे धीमे अनुरोध या सभी उत्पादन विन्यासों का विलंब निर्धारित नहीं होता।

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

टोक्यो में किए गए DevelopersIO के स्वतंत्र तुलनात्मक परीक्षण में 46 MB, 335 MB और 859 MB की इमेज पर V2 के एकल कोल्ड-स्टार्ट माप क्रमशः 2.1, 2.2 और 1.8 सेकंड रहे; V1 के माप 3.4, 5.5 और 13.6 सेकंड थे। ये सीमित एकल माप AWS के बड़े परीक्षण का विकल्प नहीं हैं, लेकिन स्नैपशॉट के साथ इमेज आकार का प्रभाव घटने वाले दावे को अलग वातावरण में समर्थन देते हैं। उसी परीक्षण में V2 Runtime को तैयार होने में लगभग 188–204 सेकंड लगे, इसलिए तेज अनुरोध आरंभ और Runtime बनाने या अद्यतन करने का समय अलग माप हैं।

लचीली मेमोरी बिल को कैसे प्रभावित करती है

V1 में सत्र के दौरान आवंटित मेमोरी बाद के अनुरोधों में जरूरत न रहने पर भी सत्र के अंत तक बनी रह सकती थी। V2 छोटे मेमोरी आकार से शुरू होता है, मांग के साथ अतिरिक्त क्षमता देता है और छोड़ी गई या निष्क्रिय मेमोरी वापस लेता है। इससे दर्ज उपयोग सत्र की अधिकतम खपत के बजाय उसके बदलते मेमोरी आकार का अधिक निकट अनुसरण कर सकता है।

इस बदलाव का अर्थ हर परिस्थिति में कम बिल नहीं है। वास्तविक लागत सत्र की अवधि, सक्रिय CPU समय, मेमोरी कितनी देर आवंटित रही और लागू इकाई दरों पर निर्भर करेगी। लगातार ऊंची मेमोरी वाले छोटे सत्र को वही लाभ नहीं मिलेगा जो थोड़े समय के उछाल के बाद लंबे समय तक कम मेमोरी इस्तेमाल करने वाले सत्र को मिल सकता है। इसलिए AWS का प्रदर्शन परिणाम लागत-बचत का स्वतंत्र प्रमाण नहीं है।

भारतीय तैनाती के लिए क्षेत्रीय सीमा

शुरुआती V2 सूची में अमेरिका के तीन क्षेत्र, आयरलैंड और टोक्यो हैं। एशिया-प्रशांत विकल्प होने के बावजूद टोक्यो भारतीय क्षेत्र नहीं है; मुंबई और हैदराबाद की अनुपस्थिति उन कार्यभारों के लिए निर्णायक हो सकती है जिन्हें भारत में ही गणना, डेटा-निवास या आंतरिक अनुपालन सीमा बनाए रखनी है।

यह अनुपस्थिति पूरे Amazon Bedrock AgentCore की भारत में उपलब्धता पर दावा नहीं है; यह विशेष रूप से नई microVM मंच-पीढ़ी की सूची की सीमा है। विदेशी क्षेत्र चुनने पर नेटवर्क विलंब, डेटा की आवाजाही और संगठन की क्षेत्रीय नीति अलग से लागू होंगी। AWS ने मुंबई या हैदराबाद में V2 के विस्तार की तारीख प्रकाशित नहीं की है।

microVM अलग है, उपयोगकर्ता-सत्र मिलान नहीं

AgentCore Runtime प्रत्येक सत्र को समर्पित microVM देता है, जिसमें गणना, मेमोरी और फाइल-प्रणाली संसाधन दूसरे सत्रों से अलग रहते हैं। सत्र समाप्त होने पर microVM हटती है और मेमोरी साफ की जाती है। फिर भी AWS का सत्र-दस्तावेज़ स्पष्ट करता है कि सेवा उपयोगकर्ता और सत्र पहचान का संबंध लागू नहीं करती; यह मिलान और प्रति उपयोगकर्ता सत्र-जीवनचक्र ग्राहक के बैकएंड को संभालना होता है।

संबंधित अनुरोधों में एक ही सत्र पहचान भेजने पर संदर्भ उसी microVM में बना रहता है। अलग उपयोगकर्ताओं को गलती से एक पहचान देने पर अलगाव की सीमा गलत जगह खिंच सकती है, जबकि एक बातचीत में बार-बार नई पहचान भेजने से नया वातावरण बन सकता है, संदर्भ टूट सकता है और अतिरिक्त कोल्ड स्टार्ट हो सकते हैं। हार्डवेयर-प्रवर्तित पृथक्करण अनुप्रयोग के गलत पहचान-मानचित्रण को स्वयं ठीक नहीं करता।

V2 चुनना और स्नैपशॉट के साथ कोड बदलना

सामान्य उपलब्धता मौजूदा Runtime को अपने आप स्थानांतरित नहीं करती। V2 को Runtime बनाते या अद्यतन करते समय platformVersion के रूप में स्पष्ट रूप से चुनना पड़ता है; नया Runtime बनाते समय यह मान न देने पर V1 डिफॉल्ट रहता है।

स्नैपशॉट आरंभिक कोड के परिणाम भी सुरक्षित कर लेता है। इसलिए प्रत्येक सत्र के लिए अलग होने वाले टोकन, अस्थायी प्रमाण-पत्र, समय-मुद्रा या यादृच्छिक पहचान को मॉड्यूल स्तर पर बनाना जोखिमपूर्ण है: पुनर्स्थापित इकाइयों में वही पुराना मान दोहर सकता है। ऐसे मान अनुरोध संभालने वाले कोड में नए बनाए जाने चाहिए।

अभी पुष्टि की गई स्थिति इतनी है: AgentCore Runtime V2 सामान्य रूप से उपलब्ध है, AWS के P75 परीक्षण में अलग आकार की कंटेनर इमेज करीब दो सेकंड में शुरू हुईं, मेमोरी मांग के साथ आवंटित और वापस ली जाती है, और सत्र अलग microVM में चलते हैं। लेकिन परिणाम पूरे एजेंट की गति या हर बिल में कमी की गारंटी नहीं देता, उपयोगकर्ता-सत्र संबंध ग्राहक की जिम्मेदारी है और भारत के AWS क्षेत्र शुरुआती V2 सूची से बाहर हैं। आगे की क्षेत्रीय उपलब्धता के लिए AWS की नई घोषणा का इंतजार रहेगा।

यह भी पढ़ें:

साझा करें: