एआई मॉडल और प्लेटफ़ॉर्म
AWS AgentCore Runtime में बड़े सत्र और फ़ाइल सिस्टम माउंट की सुविधा
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
Amazon Web Services ने 12 नवंबर, 2026 को अपनी अगली पीढ़ी के Amazon Bedrock AgentCore Runtime का विस्तार किया। इसमें एजेंट के बड़े सत्र, प्रतिबद्ध आधारभूत बिलिंग और डायनेमिक फ़ाइल सिस्टम माउंट शामिल हैं। AWS के अनुसार, हार्डवेयर आइसोलेशन बरकरार रखते हुए इन अपडेट से सत्र 15 गुना तक तेज़ी से शुरू होते हैं।
अपडेट किया गया रनटाइम उत्तरी अमेरिका, दक्षिण अमेरिका, यूरोप और एशिया प्रशांत के AWS क्षेत्रों में उपलब्ध है। AgentCore Runtime, AgentCore के भीतर प्रबंधित कंप्यूट लेयर है। AgentCore, अलग-अलग फ़्रेमवर्क और मॉडल के साथ एजेंट बनाने का AWS प्लेटफ़ॉर्म है; इस व्यापक प्लेटफ़ॉर्म में प्रमाणीकरण, पहुँच नियंत्रण और निगरानी की सुविधाएँ भी शामिल हैं।
यह रिलीज़ 18 सितंबर, 2026 को AgentCore Runtime V2 की शुरुआत के बाद आई है। उस संस्करण में स्नैपशॉट-आधारित स्टार्ट और मेमोरी रिक्लेमेशन की सुविधा आई थी। उस समय AWS ने बड़े कंप्यूट और स्टोरेज विकल्पों के साथ प्रतिबद्ध आधारभूत मूल्य निर्धारण को जल्द आने वाली सुविधाओं के रूप में सूचीबद्ध किया था। अब ये सुविधाएँ, फ़ाइल सिस्टम माउंटिंग के साथ, इस अपडेट का बड़ा हिस्सा हैं।
वॉर्म पूल के बिना बड़े सत्र
अब हर सत्र में 8 vCPU और 32 GB तक मेमोरी का उपयोग किया जा सकता है और 10 GB तक की कंटेनर इमेज चलाई जा सकती हैं। AWS के अनुसार, यह पिछले संस्करण की तुलना में चार गुना कंप्यूट क्षमता है। इमेज के आकार या समवर्ती सत्रों की संख्या कुछ भी हो, सत्र दो सेकंड से कम में शुरू होते हैं। इससे कोल्ड स्टार्ट की समस्या से निपटने के लिए ग्राहकों को अपने वॉर्म पूल प्रबंधित करने या क्लस्टर पहले से तैयार रखने की ज़रूरत नहीं रहती।
स्टार्टअप की प्रक्रिया में बार-बार आरंभ करने के बजाय स्नैपशॉट बहाल किया जाता है। AgentCore एक बार स्वस्थ कंटेनर वातावरण तैयार करके उसकी आरंभिक अवस्था का स्नैपशॉट लेता है और हर नए इंस्टेंस के लिए उसे बहाल करता है। इस तरह, मॉडल आर्टिफ़ैक्ट लोड करने और स्थिर कॉन्फ़िगरेशन प्राप्त करने जैसे काम हर कोल्ड स्टार्ट पर दोहराने नहीं पड़ते।
Coinbase के इंजीनियरिंग उपाध्यक्ष Siwei Shen ने प्रोडक्शन में मिले नतीजे के बारे में बताया: “AgentCore रनटाइम की अगली पीढ़ी पर जाने से हमारे एजेंट सत्रों के कोल्ड स्टार्ट का समय लगभग एक मिनट से घटकर पाँच सेकंड से भी कम रह गया—यहाँ तक कि सबसे ज़्यादा ट्रैफ़िक के दौरान भी। इससे 30 सेकंड से अधिक की स्टार्टअप देरी भी खत्म हो गई, जबकि हमारे एजेंटों का साप्ताहिक वॉल्यूम दोगुने से अधिक हो गया।”
Mission Cloud ने बताया कि रनटाइम के दोनों संस्करणों पर एक जैसे प्राकृतिक भाषा वाले क्वेरी वर्कलोड की शुरुआती तुलना में, इन्फ़रेंस अनुरोधों के कोल्ड स्टार्ट 35% तेज़, हेल्थ-चेक स्टार्ट 77% तेज़ और प्रति कॉल मापी गई रनटाइम लागत 17% कम रही। इसका एजेंट उपयोगकर्ताओं को जटिल डेटा प्रणालियों में जाने की ज़रूरत के बिना, संपत्ति और बिक्री से जुड़ी जानकारी प्राप्त करता है।
मेमोरी रिक्लेमेशन और आधारभूत बिलिंग
AWS निष्क्रिय अवधि के दौरान मेमोरी के बिलिंग तरीके में भी बदलाव कर रहा है। एजेंट द्वारा मेमोरी छोड़ने के कुछ ही मिनटों में रनटाइम उसे वापस ले लेता है और निष्क्रिय एजेंट की क्षमता को शून्य तक घटा देता है। AWS के अनुसार, स्वाभाविक विराम वाले कई चरणों के एजेंट प्रति सत्र 68% तक कम मेमोरी इस्तेमाल कर सकते हैं। इससे पुराने मॉडल की उस प्रवृत्ति का समाधान होता है जिसमें मेमोरी का उपयोग बंद हो जाने के बाद भी सत्र के अधिकतम आवंटन के आधार पर बिल लिया जाता था।
हमेशा चालू रहने वाले एजेंटों के लिए, प्रतिबद्ध आधारभूत मूल्य निर्धारण हर सत्र के लिए मेमोरी का एक आधार तय करता है, जिसे न्यूनतम बिल योग्य मात्रा माना जाता है। ज़रूरत पड़ने पर उपयोग उस स्तर से चार गुना तक बढ़ सकता है। AWS के अनुसार, स्थिर वर्कलोड के लिए इससे मिलने वाली अनुमानित दरें AWS Lambda MicroVM की दरों जैसी हैं; जबकि रुक-रुककर बढ़ने वाले और शून्य तक स्केल होने वाले वर्कलोड के लिए खपत-आधारित मूल्य निर्धारण जारी रहेगा।
Zuora ने बताया कि नए रनटाइम से कई उपयोगों में प्रति इनवोकेशन उसका मेमोरी फ़ुटप्रिंट लगभग 60% कम हुआ, जबकि स्थिर लेटेंसी पर अधिक ट्रैफ़िक संभाला गया।
स्टोरेज, आइसोलेशन और डिप्लॉयमेंट की सीमाएँ
हर सत्र अपने अलग हार्डवेयर-आइसोलेटेड Firecracker माइक्रोवीएम में चलता है और उसकी अपनी पहचान, पहुँच नीति तथा ऑडिट ट्रेल होती है। अब एजेंट डायनेमिक रूप से किसी फ़ाइल सिस्टम को माउंट कर सकते हैं और उसमें अपना काम सहेज सकते हैं; उदाहरण के लिए, FUSE समर्थन वाला Amazon S3 बकेट। AWS का कहना है कि पूरे कार्य के दौरान डेटा एक ही नियंत्रण व्यवस्था के तहत सत्र की ट्रस्ट सीमा के भीतर रहता है। इससे आइसोलेशन कंप्यूट वातावरण से आगे तक विस्तृत होता है।
हर सत्र के लिए अलग स्टोरेज फ़ोल्डर निर्धारित करने की सुविधा घोषित उपलब्धता में शामिल नहीं है। AWS के अनुसार, re:Invent तक सत्र-लेबल वाले क्रेडेंशियल हर सत्र को उसके अपने स्टोरेज फ़ोल्डर से जोड़ देंगे, जिससे माउंटिंग सुविधा पर अधिक सूक्ष्म नियंत्रण मिलेगा।
V2 के मौजूदा दस्तावेज़ में डिप्लॉयमेंट से जुड़े कुछ अंतर भी बताए गए हैं। V2 का इस्तेमाल अब भी सक्रिय रूप से चुनना पड़ता है, क्योंकि डिफ़ॉल्ट रूप से V1 ही चलता है—जब तक platformVersion को इस पर सेट न किया जाए V2; V2 रनटाइम बनाने या अपडेट करने में कई मिनट लगते हैं, क्योंकि AWS स्नैपशॉट तैयार करता है। कंटेनर को अपने /ping एंडपॉइंट के ज़रिए 120 सेकंड के भीतर स्वस्थ स्थिति की सूचना देनी होती है। सेटअप में लगने वाला यह समय सत्र के कोल्ड स्टार्ट की लेटेंसी से अलग है।
सत्र अधिकतम आठ घंटे तक चल सकते हैं, लेकिन 15 मिनट तक निष्क्रिय रहने पर, निर्धारित अवधि पूरी होने पर या अस्वस्थ होने पर समाप्त हो जाते हैं। सत्र की स्थिति अस्थायी होती है; सत्र समाप्त होने पर माइक्रोवीएम नष्ट हो जाता है और मेमोरी को साफ़ कर दिया जाता है।
यह रिलीज़ सत्र के कंप्यूट, मेमोरी बिलिंग और कार्य के डेटा को एक ही प्रबंधित रनटाइम मॉडल से जोड़ती है। इसमें अभी एक चीज़ बाकी है—स्टोरेज का सूक्ष्म आइसोलेशन। हर सत्र के लिए अलग स्टोरेज निर्धारित करना, रनटाइम की आइसोलेशन गारंटी को काम के निष्पादन से लेकर एजेंट के सहेजे गए काम तक बढ़ाने का अगला कदम है।
