AWS ने Elastic Memory और तेज़ कोल्ड स्टार्ट्स के लिए Bedrock AgentCore Runtime को पुनः डिज़ाइन किया

Amazon Web Services घोषित किया कि नई AgentCore runtime 18 सितंबर, 2026 को लॉन्च की गई, जो Amazon Bedrock AgentCore में प्रबंधित कंप्यूट लेयर का पुनः डिज़ाइन किया गया संस्करण है, जिसे कंपनी का कहना है कि एजेंट सत्रों द्वारा मेमोरी रिलीज़ होने पर उसे पुनः प्राप्त करता है और कंटेनर इमेज आकार या समकालिकता की परवाह किए बिना स्थिर कोल्ड स्टार्ट समय प्रदान करता है।

AgentCore runtime वह प्रबंधित कंप्यूट लेयर है जो डेवलपर्स को एजेंटों को तैनात और चलाने के लिए पूरी तरह प्रबंधित वातावरण प्रदान करती है, बिना बुनियादी ढाँचा बनाए या बनाए रखे। AWS ने कहा कि लॉन्च के बाद से हजारों टीमों ने इसका उपयोग उत्पादन एजेंटों को चलाने के लिए किया है, और पहली संस्करण ने सत्र अलगाव, स्केल-टू-ज़ीरो व्यवहार, और उपयोग-के-आधार-पर-भुगतान मूल्य निर्धारण के साथ एक सर्वरलेस आधार स्थापित किया। यह उपभोग मॉडल जारी रहता है: बिलिंग संसाधन उपयोग के अनुसार होती है और निष्क्रिय CPU जो I/O की प्रतीक्षा कर रहा है, उसके लिए कोई शुल्क नहीं लगता, और जब एजेंट के पास कोई कार्य नहीं होता है तो प्लेटफ़ॉर्म पूरी तरह शून्य तक स्केल करता है।

लॉन्च द्वारा संबोधित समस्याएँ

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

स्टार्टअप व्यवहार दूसरा चुनौती था। AWS ने कहा कि एक सत्र जो पहले से इनिशियलाइज़्ड वातावरण पर आता है, वह 100 मिलीसेकंड से कम समय में शुरू हो जाता है, लेकिन इस गारंटी के लिए वातावरण को पर्याप्त गर्म रखना कंप्यूट को रिज़र्व में रखता है, इसलिए अधिकांश सत्र कोल्ड स्टार्ट से शुरू होते हैं जिसमें नया वातावरण बूट होता है, इमेज को खींचा जाता है, और पहला अनुरोध चलने से पहले एजेंट को इनिशियलाइज़ किया जाता है। यह लेटेंसी इमेज आकार और समकालिकता के साथ बढ़ती है और बर्स्टी ट्रैफ़िक के तहत सबसे अधिक होती है, जब सबसे अधिक सत्र आते हैं और सबसे कम तैयार वातावरण बचते हैं। AWS के अनुसार, ग्राहक दोनों समस्याओं को अतिरिक्त तैयार वातावरण रखकर, मेमोरी आवंटन को अनुकूलित करके, और क्षमता को घटाकर लागत को नियंत्रित करने में हल करते हैं।

AWS ने क्या मापा

कोल्ड स्टार्ट में प्लेटफ़ॉर्म स्वयं क्या जोड़ता है, इसे अलग करने के लिए, AWS ने एक खाली इको एजेंट का परीक्षण किया जो अपना इनपुट वापस करता है और न तो मॉडल को कॉल करता है और न ही टूल्स को। एक Python क्लाइंट, जो us-west-2 में Amazon EC2 इंस्टेंस पर चल रहा था, ने सार्वजनिक इंटरनेट के माध्यम से VPC पीयरिंग के बिना, boto3 SDK का उपयोग करके, us-east-1 में एजेंटों को कॉल किया, इसलिए प्रत्येक क्लाइंट‑साइड माप में दो AWS क्षेत्रों के बीच राउंड‑ट्रिप समय शामिल है, साथ ही प्लेटफ़ॉर्म के अपने स्टार्ट टाइम के साथ। कंपनी ने दोनों रनटाइम संस्करणों और पाँच इमेज आकारों में प्रति एजेंट 5,000 कोल्ड इनवोकेशन भेजे, डिफ़ॉल्ट अकाउंट कोटा के भीतर।

ऐसे मापने पर, AWS ने रिपोर्ट किया कि नई रनटाइम ने 200 MB इमेज से 2 GB तक के लिए लगभग 2 सेकंड की P75 कोल्ड स्टार्ट लेटेंसी प्रदान की, क्योंकि इमेज आकार का इस पर कोई प्रभाव नहीं पड़ता, जबकि मूल रनटाइम की लेटेंसी इमेज आकार के साथ लगभग 5.4 सेकंड से लगभग 30 सेकंड तक बढ़ी। इको परीक्षण में, एजेंट के अपने कोड ने P75 पर लगभग 34 मिलीसेकंड में चलाया, इसलिए मापी गई अधिकांश समय प्लेटफ़ॉर्म स्टार्ट टाइम था। AWS सुझाव देता है कि इंटरैक्टिव एजेंटों के लिए स्टार्ट टाइम को छुपाने के लिए सत्र को तुरंत शुरू किया जाए जब उपयोगकर्ता जुड़ता है, जैसे जब वे चैट खोलते हैं, ताकि वातावरण पहला अनुरोध टाइप करने के दौरान गर्म हो सके।

नई रनटाइम कैसे काम करती है

नई रनटाइम प्रत्येक सत्र को एक छोटे मेमोरी प्रोफ़ाइल से शुरू करती है, न कि पूरी तरह प्रोविजन्ड फुटप्रिंट से, फिर वर्कलोड के अनुरूप अतिरिक्त मेमोरी को मांग पर आवंटित और पेज‑इन करती है। जब एक एजेंट प्रति‑अनुरोध बफ़र रिलीज़ करता है या अनुरोधों के बीच कैश्ड डेटा को समाप्त होने देता है, तो प्लेटफ़ॉर्म मेमोरी को वापस ले लेता है बजाय इसके कि सत्र समाप्त होने तक वह दावा किया हुआ रहे। AWS ने कहा कि उसने बिलियन‑सत्रों के आवंटन पैटर्न के विश्लेषण के आधार पर पुनः प्राप्ति व्यवहार को ट्यून किया।

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

बिलिंग मेमोरी मॉडल के साथ बदलती है। नई रनटाइम उस मेमोरी के लिए शुल्क लेती है जिसे एजेंट सक्रिय रूप से उपयोग करता है, मांग पर लोड किया जाता है और निष्क्रिय होने पर पुनः प्राप्त किया जाता है, बजाय पूरे कंटेनर इमेज को सत्र की अवधि तक मेमोरी में रखे रखने के। AWS ने इस परिवर्तन को कम GB‑घंटों पर उच्च दर के रूप में वर्णित किया, और कहा कि अधिकांश एजेंटों के लिए फुटप्रिंट दर में वृद्धि से अधिक घटता है, इसलिए बिल कम हो जाता है।

प्लेटफ़ॉर्म संस्करण, क्षेत्र, और सीमाएँ

डेवलपर्स नया रनटाइम तब सक्रिय करते हैं जब वे रनटाइम बनाते या अपडेट करते समय platformVersion फ़ील्ड को V2 पर सेट करते हैं, जैसा कि AgentCore डेवलपर गाइड में कहा गया है। V1 डिफ़ॉल्ट है: निर्माण के समय फ़ील्ड को छोड़ने से V1 रनटाइम बनता है, और अपडेट पर इसे छोड़ने से रनटाइम का वर्तमान प्लेटफ़ॉर्म संस्करण बना रहता है। V2 उपलब्ध है us-east-1, us-east-2, us-west-2, eu-west-1, और ap-northeast-1 में।

क्योंकि V2 निर्माण या अपडेट पर्यावरण को तैयार करता है और उसका स्नैपशॉट बनाता है, ये ऑपरेशन रनटाइम के READY स्थिति में पहुँचने से पहले कई मिनट तक चलते हैं, जबकि V1 रनटाइम सेकंडों में तैयार हो जाता है। AgentCore कंटेनर के /ping एंडपॉइंट से पहली स्वस्थ प्रतिक्रिया मिलने पर स्नैपशॉट लेता है, और यदि कंटेनर स्टार्टअप के 120 सेकंड के भीतर स्वस्थ नहीं रिपोर्ट करता है, तो निर्माण स्वास्थ्य जांच त्रुटि के साथ विफल हो जाता है। गाइड यह भी बताता है कि V2 वर्तमान में सीधे कोड डिप्लॉयमेंट के लिए कुल पर्यावरण‑वेरिएबल आकार को 1.5 KB और कंटेनर एजेंट्स के लिए 2.5 KB तक सीमित करता है, जबकि V1 पर यह 4 KB है, और AWS CloudFormation तथा AWS CDK अभी प्लेटफ़ॉर्म संस्करण सेट करने का समर्थन नहीं करते।

स्नैपशॉट रनटाइम के संस्करणों और एंडपॉइंट्स के अनुसार बनते हैं, न कि सीधे प्रबंधित किए जाते हैं। जब कोई एंडपॉइंट किसी संस्करण की ओर संकेत करता है तो AgentCore स्नैपशॉट तैयार करता है और जब कोई एंडपॉइंट उस पर संकेत नहीं करता है तो उसे हटाता है, और हटाने में अधिकतम 8 घंटे लग सकते हैं, जो अधिकतम सत्र जीवनकाल है, क्योंकि स्नैपशॉट पर पहले से चल रहे सत्र अंत तक चलते रहते हैं। सत्र समर्पित माइक्रोVM में अलग‑अलग CPU, मेमोरी और फ़ाइल‑सिस्टम संसाधनों के साथ चलते हैं, वे अधिकतम 8 घंटे तक टिकते हैं, और 15 मिनट की निष्क्रियता के बाद समाप्त हो जाते हैं, जिसके बाद माइक्रोVM समाप्त हो जाता है और मेमोरी को साफ़ किया जाता है।

रोडमैप और शुरूआत

लॉन्च के बाद, AWS ने कई क्षमताओं की सूची दी है: प्रतिबद्ध बेसलाइन डिस्काउंट जो प्रत्येक सत्र के लिए मेमोरी फ़्लोर आरक्षित करते हैं और उसकी ऊपर ऑन‑डिमांड बर्स्टिंग की अनुमति देते हैं, जो निरंतर सक्रिय सत्रों के लिए लक्षित हैं; बड़ी RAM, vCPU, और सत्र स्टोरेज; x86 माइक्रोVM समर्थन; मेमोरी स्नैपशॉट के साथ सस्पेंड‑एंड‑रिज़्यूम तथा रनटाइम हुक्स जो सक्रिय सत्र समाप्त होने से पहले स्थिति को सीरियलाइज़ करते हैं; और सत्र कॉन्टेक्स्ट कुंजियाँ जो प्रत्येक सत्र को अनअटेंडेड एजेंट्स के लिए एक स्कोप्ड पहचान प्रदान करती हैं।

AWS ने डेवलपर्स को AgentCore डेवलपर गाइड, GitHub पर AgentCore सैंपल रिपॉज़िटरी, और एक संबंधित लोड टेस्ट उदाहरण की ओर निर्देशित किया, जो उपयोगकर्ता के अपने AWS खाते के भीतर नए रनटाइम की कोल्ड स्टार्ट लेटेंसी को दर्शाता है।