एआई मॉडल और प्लेटफ़ॉर्म
उच्च घनत्व वाले एजेंट सैंडबॉक्स बेड़ों के लिए E2B ने NVIDIA Vera का परीक्षण किया
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
E2B ने 9 नवंबर, 2026 को उत्पादन-पूर्व परीक्षण के नतीजे प्रकाशित किए। इनमें दिखाया गया कि दो सॉकेट वाले एक NVIDIA Vera सर्वर पर चार ट्यून किए गए परीक्षणों में 1,400 से 1,550 तक लोडेड सैंडबॉक्स लगातार चलाए गए। वहीं, अलग सूक्ष्म-बेंचमार्क में AMD EPYC 9B45 के संदर्भ सिस्टम की तुलना में प्रोसेसर और मेमोरी का थ्रूपुट अधिक मापा गया।
यह मूल्यांकन उत्पादन में तैनाती नहीं है। E2B SDK के ज़रिए अलग-थलग माइक्रोवीएम उपलब्ध कराता है, जिनसे एजेंट कमांड चला सकते हैं, फ़ाइलों के साथ काम कर सकते हैं और सुरक्षित रखी गई चालू स्थिति में लौट सकते हैं। हर सैंडबॉक्स स्नैपशॉट से फिर शुरू होता है और ज़रूरत के अनुसार मेमोरी लोड करता है। मॉडल कहीं और चल रहा हो, तब भी उस सत्र का काफ़ी काम CPU पर होता है। इसलिए E2B ने अलग-अलग कार्रवाइयों के साथ-साथ बड़ी संख्या में एक साथ चलने वाले परिवेशों का भी परीक्षण किया।
प्रोसेसर और मेमोरी के सूक्ष्म-बेंचमार्क
Vera के परीक्षण 9–13 अक्टूबर, 2026 को उत्पादन-पूर्व दो-सॉकेट वाले एक सर्वर पर किए गए, जिसमें 176 भौतिक कोर और 1,479 GiB RAM थी। AMD के संदर्भ माप अगस्त 2026 में लिए गए थे। बिना होस्ट-स्तर के अतिरिक्त सॉफ़्टवेयर वाले सिस्टम पर, सिंगल-थ्रेड कंप्यूट परीक्षण में E2B के अनुसार Vera ने प्रति सेकंड 7,759 इवेंट दर्ज किए, जबकि AMD EPYC 9B45 ने 5,131; यानी संदर्भ थ्रूपुट का 1.51 गुना। यह आँकड़ा कम-से-कम तीन परीक्षणों के मध्यक पर आधारित है। कंप्यूट परीक्षण में Vera के 64K-पेज कर्नेल का इस्तेमाल किया गया।
मेमोरी परीक्षण में 4K कर्नेल और 2 MiB के विशाल पेजों का इस्तेमाल करके 2 GiB का क्षेत्र भरा गया। E2B के सैंडबॉक्स में भी इसी तरह के विशाल पेजों पर मेमोरी आधारित होती है। E2B के अनुसार Vera का थ्रूपुट 62.8 GB/s और AMD का 17.4 GB/s रहा, यानी 3.61 गुना। यह माप पूरी सैंडबॉक्स शुरुआत के बजाय मेमोरी भरने की गति बताता है—ऐसे रनटाइम के लिए यह एक अहम काम है, जो स्नैपशॉट पर आधारित परिवेशों को बार-बार बहाल करता है।
इस तुलना की सीमाएँ संकीर्ण हैं। चार्ट में विशिष्ट सूक्ष्म-बेंचमार्क में नामित सिस्टम के नतीजे दिए गए हैं; इससे एजेंटों की शुरू से अंत तक की गति में समान बढ़ोतरी या AMD की तुलना में सैंडबॉक्स बेड़े की अधिक क्षमता साबित नहीं होती। E2B यह भी कहता है कि अलग-अलग टूल और ऐप्लिकेशन के लिए मिलने वाले लाभ अलग होंगे।
पूरे सॉफ़्टवेयर स्टैक की क्षमता और होस्ट ट्यूनिंग
पूरे सॉफ़्टवेयर स्टैक के परीक्षण के लिए E2B ने E2B Embed का इस्तेमाल किया। यह ओपन-सोर्स E2B Runtime और डैशबोर्ड को एक ही मशीन पर पैकेज करता है; पूरा स्टैक सीधे होस्ट पर चलता है। Embed, Firecracker माइक्रोवीएम के ज़रिए आइसोलेशन और Python तथा JavaScript SDK का समर्थन देता है। मूल्यांकन में सैंडबॉक्स बनाना, कमांड चलाना, स्नैपशॉट बहाल करना, क्षमता मापना और बार-बार सैंडबॉक्स बनाकर बंद करना शामिल था।
E2B के अनुसार, Vera पर अलग-अलग नंगे हार्डवेयर वाले परीक्षणों में कम लोड पर सैंडबॉक्स को गर्म अवस्था में क्रमशः शुरू होने में 50 ms और कमांड आने-जाने में 3.8 ms लगे। ये दोनों आँकड़े अलग परीक्षणों से मिले, बेड़े पर लोड के माप से नहीं। एक अलग परीक्षण अभियान में सैंडबॉक्स बनाने और मिटाने के 22,145 चक्र बिना किसी त्रुटि के पूरे हुए।
मिश्रित क्षमता वाले कार्यभार में हर सैंडबॉक्स बार-बार CPU पर थोड़े समय के लिए भारी काम करता, डिस्क पर 10 MiB लिखता और फिर रुकता था; वहीं, हर 10 में से एक सैंडबॉक्स लगातार चलता रहा। क्षमता की उच्चतम सीमा पर E2B ने कमांड के आने-जाने में 95वें प्रतिशतक की विलंबता 255 ms बताई। जब सभी सैंडबॉक्स लगातार चल रहे थे, तब एक अलग परीक्षण में 550 सैंडबॉक्स लगातार चलाए गए।
इन क्षमता परीक्षणों में हर सैंडबॉक्स के लिए 512 MiB आरक्षित किए गए थे। परीक्षण के उद्देश्यों के अनुसार, 95वें प्रतिशतक की विलंबता हर परीक्षण के गर्म किए गए बर्स्ट आधार-स्तर की 5× सीमा के भीतर रहनी थी और हर चरण में त्रुटि की सीमा 1% थी। इसलिए यह नतीजा तय की गई प्रतिक्रियाशीलता और विश्वसनीयता के लक्ष्यों के तहत क्षमता बताता है, न कि लोड की कोई निरपेक्ष सीमा।
होस्ट का कॉन्फ़िगरेशन एक बड़ी सीमा था। डिफ़ॉल्ट सेटिंग में 320 सैंडबॉक्स चलाए जा सकते थे; नेटवर्क-पड़ोसियों की ट्यूनिंग से यह संख्या बढ़कर 1,000 हो गई, जबकि 1,024 डिवाइस की सीमा बनी रही। मुख्य क्षमता नतीजे के लिए पूरी ट्यूनिंग ज़रूरी थी। E2B इस प्रगति को एक ही सर्वर के अलग-अलग कॉन्फ़िगरेशन की तुलना बताता है, Vera और x86 की गति की तुलना नहीं।
मूल्यांकन की सीमाएँ और नियोजित परीक्षण
उत्पादन-पूर्व स्थिति के कारण कई सवाल अब भी अनसुलझे हैं। E2B ने पाया कि कुछ बहाली कार्रवाइयाँ x86 संदर्भ सिस्टम पर अब भी अधिक तेज़ी से पूरी हुईं, जबकि नेस्टेड वर्चुअलाइज़ेशन के लिए और काम करने की ज़रूरत है। लागत या बिजली खपत के कोई माप नहीं लिए गए, इसलिए परिचालन की अर्थव्यवस्था इस मूल्यांकन के दायरे से बाहर रही।
E2B के बताए अगले कदम हैं: कई नोड वाला Vera क्लस्टर, ऑब्जेक्ट स्टोरेज से समर्थित कोल्ड रिज़्यूम और उसी E2B पैकेजिंग तथा होस्ट ट्यूनिंग का उपयोग करके x86 से तुलना। अब व्यापक तैनाती का मामला इन आगे के परीक्षणों पर निर्भर करता है: क्या पूरे स्टैक के नतीजे समान पैकेजिंग और ट्यूनिंग वाले x86 सिस्टम के सामने भी कायम रहते हैं, और क्या एकल-सर्वर की क्षमता के नतीजे पूरे क्लस्टर पर भी लागू होते हैं।
