Markdown संस्करण

AI-translated from English; not yet reviewed by a fluent editor.

# DeepSeek ने एजेंट प्रशिक्षण के लिए अपना DSec सैंडबॉक्स सिस्टम बताया

> सितंबर की एक शोध-रिपोर्ट में एजेंट प्रशिक्षण के लिए DeepSeek के सैंडबॉक्स मंच DSec का वर्णन है। इसमें कई बैकएंड, परतों से जोड़े जा सकने वाले परिवेश और लेखकों द्वारा बताई गई परिनियोजन क्षमता शामिल हैं।

By BIG CHANGE Editorial

Published: 2026-09-27T06:48:31.966Z
Updated: 2026-09-27T06:48:31.966Z
Canonical: https://bigchange.ai/blog/deepseek-dsec-agent-training-sandbox-platform

![Conceptual charcoal illustration of an open, unbranded equipment cabinet with connected cables entering a floor channel; two closed cabinets recede behind it.](https://bigchange.ai/api/media/file/dsec-cabinet-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

कोड रिपॉज़िटरी में बदलाव करने वाले AI एजेंट को कमांड चलाने और एक चरण से अगले चरण तक नतीजे सँभालकर रखने के लिए जगह चाहिए। बड़े पैमाने के प्रशिक्षण में ऐसे हज़ारों परिवेशों को एक साथ शुरू करना पड़ सकता है, फिर मॉडल के अगले कदम का निर्णय लेने तक उन्हें प्रतीक्षा करनी पड़ती है। DeepSeek की [DeepSeek Elastic Compute यानी DSec पर 19 सितंबर की तकनीकी रिपोर्ट](https://arxiv.org/html/2609.22978) में उस सैंडबॉक्स सिस्टम का वर्णन है जिसके बारे में कंपनी कहती है कि वह इस काम का भार सँभालता है।

लेखक अनुरोध के रास्ते, इमेज भंडारण और प्रशिक्षण कार्य बीच में रुकने पर होने वाली प्रक्रिया बताते हैं। प्रदर्शन और परिनियोजन के आँकड़े उनके अपने मापों पर आधारित हैं। विस्तृत रिपोर्ट arXiv पर प्रस्तुत की गई है; उसके सार में कहा गया है कि इससे पहले दो पृष्ठों के विस्तारित सार को सम्मेलन की समीक्षा के पहले दौर से गुज़रना पड़ा था।

## बड़ा बदलाव

- **क्या बदला:** DeepSeek ने DSec को एजेंट प्रशिक्षण और मूल्यांकन के साझा मंच के रूप में दस्तावेज़ित किया है। एक आंतरिक क्लाइंट लाइब्रेरी से फ़ंक्शन कॉल, कंटेनर, माइक्रोVM और पूरे VM उपलब्ध हैं।
- **यह क्यों मायने रखता है:** रिपोर्ट एजेंट प्रशिक्षण को उस ढाँचे से जोड़ती है जो एक साथ कई कार्य-परिवेशों को चालू रखता है। अनुरोध प्रमाणीकरण, स्थान-चयन और स्थानीय प्रवेश-जाँच से गुज़रते हैं; परिवेश बनाते समय परतें जोड़ी जाती हैं और इमेज डेटा ज़रूरत पड़ने पर मँगाया जाता है। GPU कार्यों को बीच में रोकने पर प्रशिक्षण में स्थिति सँभालने वाले सैंडबॉक्स ठहराए जा सकते हैं।
- **अब किन बातों पर नज़र रखें:** उपयोगकर्ता अब भी बैकएंड चुनते हैं। लेखकों के उत्पादन-कार्यभार के माप कंटेनर और माइक्रोVM तक सीमित हैं; दोनों के भंडारण रास्ते अलग हैं और संसाधनों की लागत भी अलग पड़ती है। क्षमता के आँकड़े DSec की एक इकाई के हैं।

## एक अनुरोध, चार तरह के सैंडबॉक्स

रिपोर्ट के अनुसार, DeepSeek के प्रशिक्षण और मूल्यांकन ढाँचे तथा डेटा पाइपलाइनें Python लाइब्रेरी का उपयोग करती हैं जिसका नाम `libdsec` है। आम तौर पर सैंडबॉक्स बनाने के अनुरोध में बैकएंड और परिवेश की फ़ाइल चुनी जाती है, CPU और मेमोरी की सीमाएँ, जीवन-अवधि और नेटवर्क नियम तय किए जाते हैं तथा शुरुआती उपयोगकर्ता संदर्भ दिया जाता है। सैंडबॉक्स तैयार होने पर अनुरोधकर्ता कमांड या टूल कॉल चला सकता है, आउटपुट और स्थिति पा सकता है तथा सत्र रोक सकता है। रिपोर्ट के उदाहरण में एक कंटेनर, मेमोरी सीमा, निष्क्रियता-समय सीमा और ऐसे नेटवर्क नियम हैं जो PyPI की अनुमति देते हैं लेकिन NPM को रोकते हैं। यह DeepSeek के मंच के भीतर इस्तेमाल होने वाले इंटरफ़ेस का दस्तावेज़ है, बाहरी पहुँच का रास्ता नहीं।

चार बैकएंड अलग-अलग काम सँभालते हैं। FnCall छोटे, स्थिति-रहित काम को पहले से बनाए गए दोबारा इस्तेमाल योग्य कंटेनरों में चलाता है, ताकि हर बार नया सैंडबॉक्स न बनाना पड़े। कंटेनर रिपॉज़िटरी के काम और सामान्य टूल इस्तेमाल के लिए हैं; वे जल्दी शुरू होते हैं और कम जगह में अधिक तादाद में चल सकते हैं, लेकिन अपने होस्ट VM के दूसरे कंटेनरों के साथ कर्नेल साझा करते हैं। Firecracker माइक्रोVM उन कामों के लिए VM-स्तर की अलगाव सीमा देते हैं जिन्हें अधिक पृथक्करण चाहिए, लेकिन उन्हें शुरू करने और मेमोरी की लागत ज़्यादा है। पूरे VM ऐसे ऑपरेटिंग सिस्टम या ग्राफ़िक्स कार्य सँभालते हैं जिन्हें हल्के बैकएंड की क्षमताओं से अधिक चाहिए। लेखकों के अनुसार, उत्पादन में अधिकांश इंस्टेंस और संसाधनों का इस्तेमाल कंटेनर तथा माइक्रोVM करते हैं। ये रिपोर्ट में बताए गए डिज़ाइन विकल्प हैं, सुरक्षा की मापी गई तुलना नहीं।

क्लाइंट के पीछे DSec प्रबंधन अनुरोध का प्रमाणीकरण करता है, स्वास्थ्य और लोड की समय-समय पर ताज़ा की गई जानकारी के आधार पर नोड चुनता है और अनुरोध उस नोड की `edge` सेवा तक भेजता है। सैंडबॉक्स बनाने से पहले एज स्थानीय क्षमता जाँचता है; क्लस्टर की पुरानी जानकारी पर आधारित आवंटन अस्वीकार कर सकता है। चल रहे कंटेनर और VM सैंडबॉक्स एक प्रॉक्सी का इस्तेमाल करते हैं, जिसका नाम `aether` तथा शेल-सत्र प्रक्रियाओं का नाम `chronus` है। इनका उपयोग कमांड, फ़ाइल संचालन और स्ट्रीमिंग आउटपुट के लिए होता है। FnCall पहले से बने कंटेनर के रास्ते अलग से काम करता है। यह अंतर अहम है क्योंकि एक ही क्लाइंट प्रवेश-बिंदु से निष्पादन या विफलता सँभालने के तरीके एक जैसे नहीं हो जाते।

## पूरा परिवेश कॉपी किए बिना उसे बनाना

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

लेखक बताते हैं कि उत्पादन के एक सप्ताह में 11,266 कंटेनर आधार इमेज और 102,171 कंटेनर कार्यस्थल इस्तेमाल हुए। इतनी विविधता के कारण हर नोड पर पूरी इमेज रखना कम उपयोगी होता है। DSec केवल-पढ़ने योग्य इमेज डेटा DeepSeek के वितरित 3FS फ़ाइल सिस्टम में रखता है, लिखने का काम स्थानीय भंडारण पर करता है और सैंडबॉक्स द्वारा पढ़े जाने पर इमेज सामग्री लाता है। कंटेनर इमेज का मेटाडेटा स्थानीय रूप से कॉपी किया जाता है ताकि सामान्य पथ खोज के लिए दूरस्थ डेटा न पढ़ना पड़े। माइक्रोVM का रास्ता ब्लॉक पढ़ने और क्रमिक स्नैपशॉट सँभालने के लिए OverlayBD, `ublk` और स्थानीय कैश का इस्तेमाल करता है।

10 नोड वाले अलग मूल्यांकन में लेखकों ने एजेंट मूल्यांकन-कार्यभार के तहत 8,192 कंटेनर शुरू किए। ज़रूरत पर EROFS डेटा लाने वाले रास्ते ने काम लगभग 35 मिनट में पूरा किया, जबकि इमेज पहले से पूरी मँगाने वाले ठंडे रास्ते में 60 मिनट से अधिक लगे; पूरी तरह कैश की गई आधार व्यवस्था ने भी लगभग 35 मिनट लिए। रिपोर्ट में ज़रूरत पर डेटा लोड करने से हर नोड पर लगभग 700 GB डिस्क लेखन बताया गया, जबकि पहले से सब कुछ मँगाने पर यह 1,600 GB से अधिक था। ये आँकड़े लेखकों के परीक्षण की व्यवस्थाओं की तुलना करते हैं। वे किसी अन्य इमेज-संग्रह या भंडारण व्यवस्था में समान लाभ सिद्ध नहीं करते।

## निष्क्रिय सत्रों और रुके हुए प्रशिक्षण-दौर को उपयोगी बनाए रखना

कमांडों के बीच एजेंट का सैंडबॉक्स प्रतीक्षा कर सकता है और फ़ाइलें, प्रक्रियाएँ तथा मेमोरी बनाए रख सकता है। लेखकों के एक सप्ताह के नमूने में लगभग 90% कंटेनर और माइक्रोVM सैंडबॉक्स औसतन माँगी गई CPU क्षमता के 5% से अधिक का इस्तेमाल नहीं करते थे। इसलिए DSec बहुत-से सक्रिय सत्र एक ही नोड पर चलाता है और साथ ही मेमोरी की बर्बादी तथा संसाधन-प्रतिस्पर्धा को नियंत्रित करने की कोशिश करता है। माइक्रोVM के लिए रिपोर्ट में केवल-पढ़ने योग्य फ़ाइल कैश साझा करने हेतु `virtio-pmem` के साथ DAX और DAMON तथा balloon के खाली-पृष्ठ की रिपोर्टिंग से अतिथि मशीन के ठंडे पृष्ठ वापस लेने का वर्णन है। Linux शेड्यूलिंग नियंत्रणों से कम विलंबता वाले काम को सर्वोत्तम-प्रयास वाले काम से अलग भी रखा जाता है। रिपोर्ट अपने मूल्यांकन में इन तरीकों के लाभ बताती है, साथ ही CPU के अस्थायी तौर पर अधिक इस्तेमाल जैसे समझौते भी बताती है, जो `virtio-pmem` से जुड़ा है।

प्रशिक्षण रुकने पर दूसरी समस्या आती है: GPU कार्य बीच में रोक दिया जाए, तब भी प्रशिक्षण-दौर की उपयोगी स्थिति बची हो सकती है। लेखकों के अनुसार, DeepSeek-V4.1 से शुरू करके DSec एजेंट चक्र को बीच में रोके जा सकने वाले GPU समूह से बाहर, एक वर्कर कंटेनर और एजेंट सैंडबॉक्स में चलाता है। प्रशिक्षण कार्य उस स्थिति से फिर जुड़ सकता है। प्रशिक्षण रुकने पर ढाँचा DSec से संबंधित सैंडबॉक्स ठहराने और मेमोरी वापस लेने को कह सकता है। कंटेनर रोककर उनसे संसाधन वापस ले लिए जाते हैं; माइक्रोVM में Firecracker प्रक्रिया बंद होने से पहले निष्पादन स्थिति स्नैपशॉट में सहेजी जाती है। बाद की कार्रवाई में सैंडबॉक्स फिर शुरू किया जाता है। यह DeepSeek के प्रशिक्षण से एकीकरण के बारे में रिपोर्ट का विवरण है, हर स्थिति में बहाली की सामान्य गारंटी नहीं।

## रिपोर्ट में बताए गए पैमाने से क्या पता चलता है—और क्या नहीं

DeepSeek कहता है कि DSec की एक पैमाना-इकाई में लगभग 160 CPU नोड, करीब 30,000 कोर और लगभग 250 TB DRAM हैं। कंपनी एक सामान्य दिन में करीब 30 लाख सैंडबॉक्स इंस्टेंस, एक समय में अधिकतम लगभग 3,80,000 और उस इकाई के लिए प्रति सेकंड 5,000 से अधिक इंस्टेंस बनाने की दर बताती है। ये लेखकों द्वारा एक इकाई के उत्पादन के बारे में दिए गए आँकड़े हैं; DeepSeek के पूरे समूह के स्वतंत्र रूप से जाँचे गए कुल आँकड़े नहीं। रिपोर्ट के मूल्यांकन प्रयोग अलग 10-नोड क्लस्टर पर किए गए थे।

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

## स्रोत और आगे पढ़ें

- [Huang और सहलेखक, *DeepSeek Elastic Compute (DSec): बड़े पैमाने पर प्रभावी एजेंट प्रशिक्षण के लिए सैंडबॉक्स ढाँचा*, arXiv:2609.22978v1, 19 सितंबर 2026](https://arxiv.org/html/2609.22978)। पूरे तकनीकी शोधपत्र में SDK, बैकएंड, संरचना, परिवेश-भंडारण, प्रशिक्षण एकीकरण, सीमाओं और लेखकों के मूल्यांकन का प्राथमिक विवरण है। अनुरोध का रास्ता खंड 2 और 3 में, तरीके खंड 5 और 6 में, तथा परीक्षण की व्यवस्था और परिणाम खंड 8 में हैं। इस लेख के लिए संचालन संबंधी आँकड़ों की स्वतंत्र पुष्टि नहीं की गई है।
- [संस्करण 1 का arXiv सार और प्रस्तुति रिकॉर्ड](https://arxiv.org/abs/2609.22978)। इसमें प्रस्तुति की तारीख, 31-पृष्ठ की रिपोर्ट और पहले के दो-पृष्ठ के विस्तारित सार की सीमित समीक्षा का इतिहास दर्ज है। इससे विस्तृत शोधपत्र की समकक्ष समीक्षा सिद्ध नहीं होती।

## Sources

- [Huang और सहलेखक, DeepSeek Elastic Compute (DSec): बड़े पैमाने पर प्रभावी एजेंट प्रशिक्षण के लिए सैंडबॉक्स ढाँचा, arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — प्राथमिक तकनीकी रिपोर्ट; सिस्टम डिज़ाइन और परिचालन आँकड़े लेखकों द्वारा बताए गए हैं। विस्तृत संस्करण 1 को समकक्ष-समीक्षित नहीं बताया गया है।