रेपॉझिटरीत बदल करणाऱ्या AI एजंटला आज्ञा चालवण्यासाठी आणि वेगवेगळ्या टप्प्यांदरम्यान निकाल साठवण्यासाठी जागा लागते. प्रशिक्षणाच्या प्रमाणावर अशी हजारो वातावरणे एकाच वेळी सुरू करावी लागू शकतात आणि मग मॉडेल पुढे काय करायचे हे ठरवेपर्यंत ती थांबू शकतात. DeepSeek Elastic Compute, म्हणजे DSec वरील DeepSeek चा 19 सप्टेंबरचा तांत्रिक अहवाल, या कामाचा भार हाताळणारी सँडबॉक्स प्रणाली स्पष्ट करतो.

विनंतीचा प्रवास, प्रतिमा साठवण्याची पद्धत आणि प्रशिक्षणाचे काम मध्येच थांबल्यास काय घडते, याचे लेखक वर्णन करतात. कामगिरी आणि तैनातीचे आकडे त्यांच्या स्वतःच्या मोजमापांतून आले आहेत. विस्तारलेला अहवाल arXiv वर सादर केला आहे; सारांशानुसार याआधीच्या दोन पानांच्या विस्तारित सारांशाला परिषदेत पहिल्या फेरीतील परीक्षण मिळाले होते.

मोठा बदल

  • काय बदलले: एजंट प्रशिक्षण आणि मूल्यमापनासाठीची सामायिक प्रणाली म्हणून DeepSeek ने DSec चे दस्तऐवजीकरण केले आहे. एकाच अंतर्गत क्लायंट लायब्ररीतून फंक्शन कॉल, कंटेनर, मायक्रोव्हीएम आणि पूर्ण व्हर्च्युअल मशीन वापरता येतात.
  • हे का महत्त्वाचे: एकाच वेळी अनेक कामांची वातावरणे चालू ठेवणाऱ्या पायाभूत सुविधांशी एजंट प्रशिक्षणाचा संबंध हा अहवाल स्पष्ट करतो. विनंत्या अधिकृतता, काम नेमून देणे आणि स्थानिक प्रवेश-तपासणीतून जातात; वातावरण तयार करताना त्याचे थर जोडले जातात आणि गरज पडल्यावर प्रतिमेचा डेटा मिळवला जातो. GPU कामाला मध्येच थांबवले गेल्यास प्रशिक्षणात स्थिती जपणारे सँडबॉक्स थांबवता येतात.
  • कशाकडे लक्ष द्यावे: कोणता बॅकएंड वापरायचा हे विनंती करणारा घटक ठरवतो. प्रत्यक्ष उत्पादनातील भाराविषयीच्या लेखातील मोजमापे कंटेनर आणि मायक्रोव्हीएमपुरती आहेत; त्यांचे साठवण-मार्ग आणि संसाधन-खर्च वेगवेगळे आहेत. प्रमाणाविषयीचे आकडे DSec च्या एका युनिटचे आहेत.

एका विनंतीतून सँडबॉक्सचे चार प्रकार

लेखकांच्या वर्णनानुसार DeepSeek चे प्रशिक्षण फ्रेमवर्क, मूल्यमापन फ्रेमवर्क आणि डेटा-पाइपलाइन नावाच्या Python लायब्ररीला कॉल करतात libdsec एक नेहमीची निर्मिती-विनंती बॅकएंड आणि वातावरणाची सामग्री निवडते, CPU व मेमरीची मर्यादा, आयुष्यकाल आणि नेटवर्कचे नियम ठरवते, तसेच सुरुवातीचा वापरकर्ता-संदर्भ देते. सँडबॉक्स तयार झाल्यावर विनंतीकर्ता आज्ञा किंवा टूल कॉल चालवू शकतो, आउटपुट व स्थिती परत मिळवू शकतो आणि सत्र थांबवू शकतो. लेखातील नमुना-सत्रात कंटेनर, मेमरीची मर्यादा, निष्क्रियतेची वेळ-मर्यादा आणि PyPI ला परवानगी देऊन NPM रोखणारे नेटवर्क नियम वापरले आहेत. हा DeepSeek च्या प्लॅटफॉर्ममध्ये वापरला जाणारा इंटरफेस आहे; बाह्य प्रवेशमार्ग नाही.

चार बॅकएंड वेगवेगळ्या कामांसाठी आहेत. FnCall पुन्हा वापरता येणाऱ्या, आधीच तयार कंटेनरमध्ये लहान, स्थिती न साठवणारी कामे चालवते; प्रत्येक विनंतीसाठी नवा सँडबॉक्स सुरू करावा लागत नाही. कंटेनर रेपॉझिटरीवरील कामे आणि सर्वसाधारण टूल-वापरासाठी आहेत; ते पटकन सुरू होतात आणि दाटीवाटीने चालतात, पण होस्ट व्हर्च्युअल मशीनमधील इतर कंटेनरसोबत कर्नल सामायिक करतात. अधिक मजबूत विलगीकरण लागणाऱ्या कामांसाठी Firecracker मायक्रोव्हीएम व्हर्च्युअल मशीनची सीमा पुरवतात; त्यासाठी सुरू होण्यास अधिक वेळ आणि अधिक मेमरी लागते. हलक्या बॅकएंडमध्ये नसलेल्या क्षमता लागणाऱ्या ऑपरेटिंग सिस्टीम किंवा ग्राफिक्सच्या कामांसाठी पूर्ण व्हर्च्युअल मशीन वापरतात. उत्पादनातील बहुतांश उदाहरणे आणि संसाधन-वापर कंटेनर व मायक्रोव्हीएममधून येतात, असे लेखक सांगतात. हे लेखात वर्णिलेले रचनात्मक निर्णय आहेत; मोजलेली सुरक्षा-तुलना नव्हे.

क्लायंटच्या मागे DSec व्यवस्थापन-विनंतीची ओळख पडताळते, आरोग्य व भाराची वेळोवेळी अद्ययावत होणारी माहिती वापरून नोड निवडते आणि विनंती त्या नोडच्या edge सेवेकडे पाठवते. सँडबॉक्स तयार करण्यापूर्वी एज तपासणी स्थानिक क्षमता पाहते; क्लस्टरची जुनी माहिती वापरून केलेले वाटप ती नाकारू शकते. चालणारे कंटेनर आणि व्हर्च्युअल-मशीन सँडबॉक्स प्रॉक्सी वापरतात, ज्याला aether आणि शेल-सत्र प्रक्रिया म्हणतात, ज्यांना chronus आज्ञा, फाइल-क्रिया आणि थेट आउटपुटसाठी वापरतात. FnCall आधीच तयार कंटेनरमधून वेगळा मार्ग वापरते. हा फरक महत्त्वाचा आहे; एकच क्लायंट प्रवेशद्वार असले तरी अंमलबजावणी आणि बिघाड हाताळण्यातील फरक नाहीसे होत नाहीत.

पूर्ण प्रत न उतरवता वातावरण तयार करणे

एजंटसाठीच्या नेहमीच्या वातावरणाचे तीन भाग लेखात नमूद आहेत: आधार-प्रतिमा, कामाची जागा आणि स्वतंत्रपणे बदलू शकणारी साधन-सामग्री. प्रत्येक जोड एका प्रतिमेत बांधली तर साधन-सामग्री बदलल्यावर अनेक प्रतिमा पुन्हा तयार कराव्या लागतील. त्याऐवजी DSec वर लिहिता येणारा थर ठेवून त्याखाली फक्त-वाचनीय थरांची रचना करते. कंटेनरसाठी सुधारित Docker रनटाइम हे थर overlayfs वापरून जोडते. मायक्रोव्हीएममध्ये फक्त-वाचनीय EROFS थर आणि लिहिता येणाऱ्या डिस्क्स वापरतात; फाइल-सिस्टीम सुसंगततेची गरज असेल तेथे वेगळा ब्लॉक-साठवणूक मार्ग वापरतात.

एका प्रत्यक्ष वापराच्या आठवड्यात 11,266 कंटेनर आधार-प्रतिमा आणि 102,171 कंटेनर कामाच्या जागा वापरल्या गेल्या, असे लेखक सांगतात. इतकी विविधता असल्याने प्रत्येक नोडवर संपूर्ण प्रतिमा साठवण्याचा फायदा मर्यादित होतो. DSec फक्त-वाचनीय प्रतिमा-डेटा DeepSeek च्या 3FS वितरित फाइल-सिस्टीममध्ये साठवते, लिहिण्याची कामे स्थानिक साठवणुकीत ठेवते आणि सँडबॉक्सने वाचल्यावर प्रतिमेचा मजकूर मिळवते. नेहमीच्या पाथ-शोधांसाठी दूरस्थ वाचन लागू नये म्हणून कंटेनर प्रतिमेची मेटाडेटा प्रत स्थानिक ठेवली जाते. मायक्रोव्हीएम मार्गात OverlayBD ublk आणि ब्लॉक-वाचन तसेच वाढीव स्नॅपशॉटसाठी स्थानिक कॅशे वापरतात.

वेगळ्या 10-नोड मूल्यमापनात एजंट-मूल्यमापनाच्या भाराखाली लेखकांनी 8,192 कंटेनर सुरू केले. गरजेनुसार EROFS वापरणाऱ्या मार्गाने कामे सुमारे 35 मिनिटांत पूर्ण केली; प्रतिमा आधीपासून साठवलेली नसताना सर्व प्रतिमा आधी उतरवण्याच्या पद्धतीला 60 मिनिटांहून अधिक लागले. पूर्ण कॅशे असलेली आधार-पद्धतही सुमारे 35 मिनिटांत पूर्ण झाली. गरजेनुसार लोड करताना प्रत्येक नोडवरील डिस्क-लेखन सुमारे 700 GB होते; सर्व प्रतिमा आधी उतरवताना ते 1,600 GB पेक्षा अधिक होते, असे नोंदवले आहे. हे आकडे लेखकांच्या चाचणीतील संरचनांची तुलना करतात. दुसऱ्या प्रतिमा-संग्रहात किंवा साठवणूक प्रणालीत तितकाच फायदा होईल, हे ते सिद्ध करत नाहीत.

निष्क्रिय सत्रे आणि मध्येच थांबलेले रोलआउट वापरण्यायोग्य ठेवणे

एजंटचा सँडबॉक्स आज्ञांदरम्यान थांबू शकतो आणि तरीही फाइल्स, प्रक्रिया व मेमरी जपतो. आठवडाभराच्या नमुन्यात कंटेनर आणि मायक्रोव्हीएम सँडबॉक्सपैकी सुमारे 90% सँडबॉक्सनी मागितलेल्या CPU क्षमतेच्या सरासरी 5% पेक्षा जास्त वापर केला नाही, असे लेखक सांगतात. त्यामुळे DSec मेमरीचा अपव्यय आणि स्पर्धा नियंत्रित करण्याचा प्रयत्न करत अनेक सुरू सत्रे नोड्सवर एकत्र चालवते. मायक्रोव्हीएमसाठी फक्त-वाचनीय फाइल-कॅशे सामायिक करण्यासाठी virtio-pmem मायक्रोव्हीएमसाठी फक्त-वाचनीय फाइल-कॅशे DAX च्या मदतीने सामायिक करण्याचे, तसेच DAMON आणि balloon द्वारे मोकळ्या पानांची माहिती देऊन अतिथी प्रणालीतील थंडावलेली पाने परत मिळवण्याचे वर्णन लेखात आहे. Linux नियोजन-नियंत्रण वापरून विलंब-संवेदनशील कामे सर्वोत्तम-प्रयत्न कामांपासून वेगळी ठेवली जातात. या उपायांचे फायदे स्वतःच्या मूल्यमापनात दिसल्याचे लेख सांगतो; त्याचबरोबर तात्पुरता CPU वापर वाढणे यांसारखे तडजोडीचे परिणामही नोंदवतो virtio-pmem.

प्रशिक्षणात व्यत्यय आल्यास आणखी एक प्रश्न निर्माण होतो: GPU काम थांबवले गेले तरी रोलआउटची उपयुक्त स्थिती जिवंत असू शकते. DeepSeek-V4.1 पासून DSec एजंटचे चक्र GPU मधील काम कधीही थांबवता येईल अशा पूलच्या बाहेर, कामगार कंटेनर आणि एजंट सँडबॉक्समध्ये चालवते, असे लेखक सांगतात. प्रशिक्षणाचे काम त्या स्थितीशी पुन्हा जोडले जाऊ शकते. प्रशिक्षण थांबल्यावर संबंधित सँडबॉक्स थांबवून मेमरी परत मिळवण्याची विनंती फ्रेमवर्क DSec ला करू शकते. कंटेनर गोठवून त्यांची संसाधने परत घेतली जातात; मायक्रोव्हीएममध्ये Firecracker प्रक्रिया थांबवण्यापूर्वी अंमलबजावणीची स्थिती स्नॅपशॉटमध्ये साठवली जाते. नंतरची क्रिया सँडबॉक्स पुन्हा सुरू करते. DeepSeek च्या प्रशिक्षणाशी एकत्रीकरणाचे हे लेखातील वर्णन आहे; सर्वसाधारण पुनर्प्राप्तीची हमी नाही.

नोंदवलेले प्रमाण काय दाखवते आणि काय नाही

एका DSec प्रमाण-युनिटमध्ये जवळपास 160 CPU नोड्स, सुमारे 30,000 कोअर्स आणि जवळजवळ 250 TB DRAM असल्याचे DeepSeek सांगते. नेहमीच्या दिवशी सुमारे 30 लाख सँडबॉक्स उदाहरणे, एकाच वेळी कमाल जवळपास 3,80,000 उदाहरणे आणि त्या युनिटमध्ये दर सेकंदाला 5,000 पेक्षा जास्त उदाहरणे तयार होण्याचा वेग नोंदवला आहे. हे लेखकांनी सांगितलेले एका प्रमाण-युनिटमधील उत्पादन-वापराचे आकडे आहेत; DeepSeek च्या संपूर्ण प्रणालीचे स्वतंत्र लेखापरीक्षित एकूण आकडे नाहीत. मूल्यमापनाच्या चाचण्या वेगळ्या 10-नोड क्लस्टरवर चालल्या.

अपयशाच्या मर्यादाही अहवालात वर्णिल्या आहेत. एजंट्सनी अनपेक्षित मार्गांनी उत्तरे शोधल्याच्या आणि सामान्य आज्ञांमुळे कर्नल बंद पडल्याच्या किंवा आउटपुटने साठवणूक भरल्याच्या घटना लेखक सांगतात. AppArmor मधील फाइल व सॉकेट नियंत्रणे आणि प्रत्येक सँडबॉक्ससाठीचे नेटवर्क नियम हे प्रतिबंधक उपाय म्हणून वर्णिले आहेत; मात्र या नियंत्रणांमुळे प्रत्येक हानिकारक वर्तन रोखले जाईलच असे नाही, हेही स्पष्ट केले आहे. DSec सेवेसाठी सार्वजनिक प्रवेश-बिंदू, बाह्य SDK वितरण, प्रवेशाच्या अटी किंवा किंमत दिलेली नाही. प्रणालीची रचना आणि लेखकांच्या चाचण्यांच्या अटी अहवालात आहेत; नमुना कोड चालवण्यासाठी बाह्य प्रवेशमार्ग मात्र दिलेला नाही.

स्रोत आणि पुढील वाचन