हमने शुरुआत में ही एक दांव खेला था कि LLM को मनमाना कोड चलाने की शक्ति दी जाए। यह पोस्ट इस बारे में है कि हमने वह दांव क्यों खेला, और एक साथ हजारों सैंडबॉक्स (sandboxes) चलाने के लिए क्या करना पड़ता है, जो उतनी ही तेज़ी से शुरू और बंद होते हैं जितनी तेज़ी से लोग एजेंट के साथ चैट शुरू और खत्म करते हैं।
Adapt एजेंट के साथ उपयोगकर्ता की हर बातचीत उसके अपने कंप्यूटर द्वारा समर्थित होती है। यह केवल किसी साझा सर्वर पर लॉक-डाउन किया गया कंटेनर नहीं है, बल्कि एक अलग VM है जिसके साथ मॉडल जो चाहे कर सकता है: सॉफ़्टवेयर इंस्टॉल करना, प्रोग्राम लिखना और चलाना, वेब ब्राउज़ करना, API से बात करना। हम इन्हें सैंडबॉक्स कहते हैं, और ये उन मुख्य आधारों में से एक हैं जिन पर Adapt बना है।
पूर्ण नियंत्रण
LLM कोडिंग के उस्ताद हैं, और मेरा काम काफी हद तक उनके काम करने के लिए एक बेहतरीन डेवलपर वातावरण बनाना रहा है।
AI को बाहरी दुनिया से जोड़ने का सामान्य तरीका मैन्युअल रूप से इंटीग्रेशन बनाना है, जैसे GitHub के लिए एक विशेष कनेक्टर, HubSpot के लिए दूसरा, Stripe के लिए तीसरा, या प्रत्येक सर्विस के MCP सर्वर जारी करने का इंतज़ार करना। यह तरीका बड़े स्तर पर काम नहीं करता, और मुझे दिन-रात इंटीग्रेशन कोड लिखने में कोई दिलचस्पी नहीं है।
इसलिए, वह काम खुद करने के बजाय, हमने मॉडल को ऐसा करने दिया। कोई भी सर्विस जो API प्रदान करती है, उसे Adapt से एक्सेस किया जा सकता है, क्योंकि हम LLM को वह सब कुछ देते हैं जिसकी उसे उस API से बात करने वाला स्क्रिप्ट या प्रोग्राम लिखने के लिए आवश्यकता होती है। जब हम Adapt को "हॉरिजॉन्टल इंटेलिजेंस" कहते हैं, तो हमारा यही मतलब होता है: यह टूल की किसी निश्चित सूची से नहीं जुड़ा है, यह ज़रूरत पड़ने पर मौके पर ही अपना टूल बना सकता है।
इसका आधार LLM को सैंडबॉक्स तक पूर्ण पहुँच देना है। मॉडल को सीमित फ़ाइल सिस्टम एक्सेस वाली भाषाओं और CLI टूल का एक स्थिर सेट देने के बजाय, हम उसे हर चीज़ तक पूरी पहुँच देते हैं। यह रूट (root) के रूप में चलता है। और हालाँकि हमारे सैंडबॉक्स Node और Python जैसे सामान्य रनटाइम के साथ आते हैं, लेकिन क्या होगा अगर किसी सर्विस के API के लिए सबसे अच्छा SDK Go में लिखा गया हो? मॉडल बस उसे इंस्टॉल करके चला सकता है।
क्या LLM को Go प्रोग्राम लिखने की ज़रूरत है? आगे बढ़ें, Go इंस्टॉल करें और इसे चलाएं।
तो अगर हम मॉडल को अपनी मर्ज़ी से कुछ भी इंस्टॉल करने और ऐसा कोड चलाने की अनुमति दे रहे हैं जिसे किसी इंसान ने सत्यापित नहीं किया है, तो हम इसे सुरक्षित कैसे रखते हैं? सौभाग्य से, हम ऐसे पहले लोग नहीं हैं जिन्हें अनट्रस्टेड (अविश्वसनीय) कोड चलाने की आवश्यकता पड़ी है। इसके लिए दो बहुत लोकप्रिय सुरक्षित रनटाइम हैं: gVisor और Firecracker। हमारी अब तक की यात्रा ने हमें इन दोनों से बहुत अच्छी तरह परिचित करा दिया है।
gVisor से Firecracker तक
LLM के लिए सुरक्षित सैंडबॉक्स में हमारा पहला प्रयास "आसान" तरीका था: GKE (Google Kubernetes Engine) के ऊपर gVisor के साथ प्रत्येक सैंडबॉक्स चलाना, GKE Sandbox का उपयोग करके। हम अपनी अन्य सभी सेवाएँ पहले से ही GKE पर चला रहे हैं, इसलिए यह हमारे लिए स्वाभाविक कदम था।
gVisor एक कंटेनर और होस्ट कर्नेल के बीच स्थित होता है। किसी प्रोग्राम को सीधे असली Linux कर्नेल पर सिस्टम कॉल करने देने के बजाय—जिसके साथ आप नहीं चाहते कि अनट्रस्टेड कोड छेड़छाड़ करे—gVisor उन कॉल्स को अपने स्वयं के यूजर-स्पेस कर्नेल में इंटरसेप्ट करता है और उन्हें खुद पूरा करता है। आपको एक सामान्य कंटेनर की अधिकांश सुविधा बहुत छोटे अटैक सरफेस के साथ मिलती है। और GKE Sandbox इन सबको पैकेज करता है। आप Pods (कंटेनर) तैनात करते हैं और वे बिना किसी बुनियादी ढांचे के कॉन्फ़िगरेशन के gVisor के तहत चलते हैं।
और शुरुआत में यह बहुत अच्छा काम कर रहा था। हमने "बेस" सैंडबॉक्स को Docker इमेज के रूप में परिभाषित किया और GKE को इसे ज़रूरत के अनुसार सैंडबॉक्स की संख्या तक स्केल करने दिया। सैंडबॉक्स के साथ आने वाले सॉफ़्टवेयर के अपडेट साधारण Dockerfile अपडेट और मैनिफ़ेस्ट में वर्शन बंप थे।
GKE Sandbox के तहत चलने वाले सैकड़ों सैंडबॉक्स Pods।
लेकिन जिस एब्स्ट्रैक्शन ने gVisor को आसान बनाया, उसी से हम जूझते रहे। चूँकि gVisor यूजर स्पेस में Linux सिस्टम कॉल सरफेस को फिर से लागू करता है, इसलिए सब कुछ वैसे व्यवहार नहीं करता जैसा कि असली कर्नेल पर होता, और हमारा मॉडल जो वर्कलोड सोचता है, वह काफी अप्रत्याशित होता है। इंटरसेप्शन जो आपको सुरक्षा देता है, वह सिस्टम कॉल- और I/O-भारी काम पर आपको महंगा पड़ता है। और पूरे जीवनचक्र के लिए GKE पर निर्भर रहने का मतलब था कि जिन हिस्सों को हम सबसे ज्यादा नियंत्रित करना चाहते थे—बूट टाइम, पैकिंग डेंसिटी, नेटवर्किंग, और हम मशीनों को कितनी आक्रामकता से रिसाइकिल करते हैं—उन पर हमारा सबसे कम नियंत्रण था। ऊपर दिया गया 'OutOfcpu' Pod उस तरह की चीज़ है जिसे आप तब देखना शुरू करते हैं जब आप किसी और के शेड्यूलर पर उसकी क्षमता से अधिक दबाव डाल रहे होते हैं।
यही वह चीज़ है जिसने हमें Firecracker की ओर धकेला।
Firecracker microVMs असली वर्चुअल मशीनें हैं, जिनमें से प्रत्येक का अपना गेस्ट कर्नेल होता है, जो हार्डवेयर वर्चुअलाइजेशन के साथ चलता है, लेकिन कुछ ही मिलीसेकंड में बूट होने के लिए तैयार होता है और इसमें केवल कुछ मेगाबाइट का ओवरहेड होता है। यह वही तकनीक है जिसे AWS ने साझा हार्डवेयर पर Lambda और Fargate वर्कलोड की भारी संख्या को पैक करने के लिए बनाया था। यह हमें साझा कर्नेल की तुलना में एक मजबूत आइसोलेशन बाउंड्री देता है, इतना तेज़ बूट होता है कि यह तुरंत महसूस होता है, और एक ही होस्ट पर बहुत सारे VM पैक करने के लिए पर्याप्त छोटा है।
इसका ट्रेड-ऑफ यह है कि Firecracker आपको एक VM देता है और उसके अलावा कुछ खास नहीं। शेड्यूलिंग, नेटवर्किंग और लाइफसाइकिल ऑर्केस्ट्रेशन करने वाली GKE जैसी कोई लेयर नहीं है। इसलिए हमने एक बनाया, और हम इसे orc कहते हैं।
rootfs सिर्फ एक इमेज है
कंटेनर से बाहर निकलने में हम एक चीज़ जो नहीं छोड़ना चाहते थे, वह थी सैंडबॉक्स को एक साधारण Dockerfile के रूप में परिभाषित करना। कंटेनर इसे आसान बनाते हैं; VM पारंपरिक रूप से ऐसा नहीं करते, क्योंकि एक microVM एक रूट फ़ाइल सिस्टम को बूट करता है, न कि OCI इमेज को।
इसलिए orc दोनों को जोड़ता है। जब इसे VM बनाने के लिए कहा जाता है, तो यह एक साधारण Docker/OCI इमेज लेता है और उससे तुरंत VM का रूट फ़ाइल सिस्टम तैयार करता है, परिणाम को कैश करता है ताकि उसी इमेज के बाद के बूट तेज़ हों। हमारा बेस सैंडबॉक्स अभी भी सिर्फ एक Dockerfile है, और orc अनुरोध के समय इसे बूट करने योग्य rootfs में बदल देता है।
यह हमारे वर्कफ़्लो को GKE के दिनों जैसा ही रखता है: एक Dockerfile संपादित करें, एक नया सैंडबॉक्स शिप करें, जबकि नीचे असली VM पर चल रहे हों। और यह एक ऐसा दरवाज़ा खोलता है जिसे हम अभी खोलना शुरू ही कर रहे हैं। चूँकि कोई भी OCI इमेज एक microVM बन सकती है, हम डिफ़ॉल्ट इमेज के अलावा अन्य इमेज से सैंडबॉक्स बूट कर सकते हैं। क्या आप एक ऐसा VM चाहते हैं जिसमें पहले से ही Postgres और pgvector हो? orc को उस इमेज पर पॉइंट करें और आपको यह अपनी अलग मशीन के रूप में मिल जाएगा। सैंडबॉक्स एक निश्चित वातावरण नहीं रहता, बल्कि "जो भी इमेज जॉब को चाहिए, वह अपने VM के रूप में बूट हो जाती है" बन जाता है।
बड़े पैमाने पर निष्पादन
और यहाँ वह बात है जो इसे वास्तव में एक कठिन समस्या बनाती है: हर चैट को अपना सैंडबॉक्स मिलता है। प्रति बातचीत एक मशीन। किसी भी समय हमारे पास हज़ारों सैंडबॉक्स जीवित होते हैं, और यह संख्या कभी स्थिर नहीं रहती। हर बार जब कोई चैट खोलता है, तो एक सैंडबॉक्स प्रकट होना चाहिए; हर बार जब कोई चैट शांत हो जाती है, तो एक गायब हो जाना चाहिए ताकि हम उसके लिए भुगतान न करें। हम लगातार सैंडबॉक्स को ऊपर और नीचे स्पिन कर रहे हैं।
दो संख्याएँ हर चीज़ पर हावी हैं: हम कितनी तेज़ी से सैंडबॉक्स तैयार कर सकते हैं, और हम एक होस्ट पर कितने फिट कर सकते हैं।
स्टार्टअप लेटेंसी। एक Firecracker microVM कुछ सौ मिलीसेकंड में बूट हो जाता है। यह इतना तेज़ है कि हम कोई वार्म पूल नहीं रखते हैं, जो इस बदलाव की सबसे बड़ी जीत में से एक है। GKE के तहत हमें स्टार्टअप समय को छिपाने के लिए अतिरिक्त क्षमता रखनी पड़ती थी। orc के साथ एक नया सैंडबॉक्स आपके ध्यान देने से पहले ही तैयार हो जाता है, इसलिए हम चैट शुरू होने पर मांग पर एक बनाते हैं और चैट खत्म होने पर उसे हटा देते हैं। अब बेकार पड़े पूल की देखभाल करने या उसके लिए भुगतान करने की ज़रूरत नहीं है।
डेंसिटी (घनत्व)। चूँकि प्रत्येक microVM छोटा होता है, हम उनमें से बहुत सारे को एक भौतिक होस्ट पर पैक कर सकते हैं। हम प्रत्येक सैंडबॉक्स के CPU और मेमोरी को उसकी वास्तविक ज़रूरत के अनुसार आकार देते हैं, न कि ज़रूरत से ज़्यादा प्रावधान (over-provisioning) करते हैं, जो हमें हज़ारों सैंडबॉक्स को आर्थिक रूप से चलाने की अनुमति देता है।
orc खुद जानबूझकर छोटा है। यह एक कंट्रोल प्लेन है जो एक सरल API पर बात करता है: दी गई इमेज से N vCPUs और M मेगाबाइट मेमोरी के साथ एक VM बनाएँ, इसमें कमांड स्ट्रीम करें, इसके अंदर फ़ाइलें पढ़ें और लिखें, इसे लेबल के साथ टैग करें ताकि हम इसे बाद में ढूंढ सकें, और काम पूरा होने पर इसे हटा दें। प्रत्येक गेस्ट PID 1 के रूप में एक छोटा init प्रोसेस चलाता है और उसे अपना अलग नेटवर्क मिलता है। बस इतना ही। जादू कोई एक चालाकी नहीं है, बल्कि यह है कि ये प्रिमिटिव इतने सरल और तेज़ हैं कि इन पर एक पूरा फ्लीट चलाया जा सके।
इस सारी प्लंबिंग का प्रतिफल वही है जिससे हमने शुरुआत की थी: एक ऐसा मॉडल जो कुछ भी इंस्टॉल कर सकता है, प्रोग्राम लिख सकता है, API को हिट कर सकता है, और आपको जवाब वापस दे सकता है, वह भी एक असली कंप्यूटर पर।
