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

# Inilalarawan ng DeepSeek ang DSec, sistema nitong sandbox para sa pagsasanay ng mga ahente

> Inilalarawan sa ulat ng pananaliksik noong Setyembre ang DSec, plataporma ng DeepSeek para sa sandbox sa pagsasanay ng mga ahente, kabilang ang maraming backend, pinagsasama-samang kapaligiran at lawak ng deployment na iniulat ng mga may-akda.

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.

Kailangan ng AI agent na nag-eedit ng repositoryo ng lugar upang magpatakbo ng mga utos at magpanatili ng mga resulta sa pagitan ng mga turn. Sa lawak ng pagsasanay, maaaring sabay-sabay na magsimula ang libo-libong kapaligirang ito, saka maghintay habang nagpapasya ang modelo kung ano ang susunod na gagawin. Inilalarawan sa [teknikal na ulat noong Setyembre 19 tungkol sa DeepSeek Elastic Compute o DSec](https://arxiv.org/html/2609.22978) ang sistema ng sandbox na sinasabi nitong humahawak sa ganitong karga.

Inilalarawan ng mga may-akda ang landas ng kahilingan, imbakan ng image at nangyayari kapag naputol ang isang gawain sa pagsasanay. Mula sa sarili nilang mga sukat ang mga bilang nila sa performance at deployment. Isinumite sa arXiv ang pinalawak na ulat; sinasabi sa abstrak na dumaan sa unang yugto ng pagsusuri sa kumperensiya ang mas naunang pinalawak na abstrak na may dalawang pahina.

## Ang malaking pagbabago

- **Ano ang nagbago:**Idinokumento na ng DeepSeek ang DSec bilang pinagsasaluhang plataporma para sa pagsasanay at pagsusuri ng mga ahente, kung saan magagamit sa iisang panloob na client library ang mga function call, container, microVM at buong VM.
- **Bakit mahalaga:**Iniuugnay ng ulat ang pagsasanay ng ahente sa imprastrakturang sabay-sabay na nagpapatakbo ng maraming kapaligiran ng gawain. Dumaraan ang mga kahilingan sa awtorisasyon, paglalagay at lokal na pagtanggap; pinagsasama ang mga layer sa paglikha at kinukuha ang image data kung kinakailangan. Maaaring i-pause ng pagsasanay ang mga sandbox na nagpapanatili ng estado kapag inagaw ang mga GPU job.
- **Ano ang dapat bantayan:**Backend pa rin ang pinipili ng tumatawag. Saklaw ng mga sukat sa produksyon sa papel ang mga container at microVM, na magkaiba ang landas ng imbakan at gastos sa mapagkukunan. Isang yunit ng DSec lamang ang inilalarawan ng mga bilang nito sa lawak.

## Iisang kahilingan, apat na uri ng sandbox

Ayon sa paliwanag sa papel, tumatawag ang mga framework ng DeepSeek sa pagsasanay, pagsusuri at pipeline ng datos sa isang Python library na pinangalanang `libdsec`. Pumipili sa karaniwang kahilingan sa paglikha ng backend at artifact ng kapaligiran, nagtatakda ng limitasyon sa CPU at memory, tagal ng buhay at tuntunin sa network, at nagbibigay ng paunang konteksto ng user. Kapag handa na ang sandbox, makapagpapatakbo ng mga utos o tool call ang tumatawag, makakakuha ng output at makapagbabalik ng katayuan, at makapaghihinto ng sesyon. Gumagamit ang halimbawang sesyon sa papel ng container, limitasyon sa memory, timeout kapag walang aktibidad at mga tuntunin sa network na nagpapahintulot sa PyPI ngunit nagbabawal sa NPM. Interface itong ginagamit sa loob ng plataporma ng DeepSeek, hindi panlabas na paraan ng pag-access.

Saklaw ng apat na backend ang magkakaibang gawain. Nagpapatakbo ang FnCall ng maiikli at walang-state na gawain sa mga container na puwedeng gamitin muli at paunang ginawa, kaya hindi na kailangan ng bagong sandbox sa bawat tawag. Para sa gawain sa repositoryo at pangkalahatang paggamit ng tool ang mga container; mabilis magsimula at siksik ang mga ito, ngunit iisang kernel ang pinagsasaluhan nila ng ibang container sa kanilang host VM. Nagbibigay ng hangganang VM ang mga microVM ng Firecracker para sa mga gawaing nangangailangan ng mas matibay na paghihiwalay, kapalit ng dagdag na oras ng pagsisimula at memory. Para naman sa operating system o graphics workload na nangangailangan ng kakayahang wala sa mas magagaan na backend ang buong VM. Sinasabi ng mga may-akda na container at microVM ang karamihan ng mga instance at paggamit ng mapagkukunan sa produksyon. Mga pasya sa disenyo ang inilalarawan sa papel, hindi nasukat na paghahambing sa seguridad.

Sa likod ng client, pinatutunayan ng DSec ang kahilingan sa pamamahala, pumipili ng node batay sa pana-panahong ina-update na tala ng kalusugan at karga, at ipinadadala ang kahilingan sa `edge` serbisyo ng node na iyon. Sinusuri ng edge ang lokal na kapasidad bago likhain ang sandbox; maaari nitong tanggihan ang paglalagay batay sa lumang impormasyon ng cluster. Gumagamit ang tumatakbong container at VM sandbox ng proxy na tinatawag na `aether` at mga prosesong shell-session na tinatawag na `chronus` para sa mga utos, pagpapatakbo ng file at tuluy-tuloy na output. Ibang ruta sa paunang nalikhang container ang gamit ng FnCall. Mahalaga ang pagkakaibang ito dahil hindi inaalis ng iisang pasukan ng client ang pagkakaiba sa pagsasagawa o paghawak sa pagkabigo.

## Pagbuo ng kapaligiran nang hindi kinokopya ang lahat

Tinutukoy sa papel ang tatlong bahagi ng karaniwang kapaligiran ng ahente: batayang image, workspace ng gawain at toolkit na maaaring magbago nang hiwalay. Kung ilalagay sa iisang image ang bawat kumbinasyon, kakailanganing buuing muli ang maraming image sa tuwing mag-a-update ang toolkit. Sa halip, pinapatong ng DSec ang mga read-only na layer at naglalagay ng writable na layer sa ibabaw. Para sa mga container, pinagsasama ng binagong Docker runtime ang mga layer sa overlayfs. Gumagamit ang mga microVM ng read-only na EROFS layer kasabay ng writable na disk at ibang block-storage na ruta kapag kailangan ito ng pagiging tugma ng filesystem.

Iniulat ng mga may-akda na kinasangkutan ng isang linggo sa produksyon ang 11,266 batayang image ng container at 102,171 workspace ng container. Nililimitahan ng ganitong pagkakaiba-iba ang pakinabang ng pag-iimbak ng buong image sa bawat node. Iniimbak ng DSec ang read-only na image data sa distributed filesystem na 3FS ng DeepSeek, inilalaan ang mga write sa lokal na imbakan at kinukuha ang nilalaman ng image kapag binasa ito ng sandbox. Lokal na kinokopya ang metadata ng image ng container upang hindi mangailangan ng malayuang pagbasa ang karaniwang paghahanap ng path. Gumagamit ang ruta ng microVM ng OverlayBD, `ublk` at lokal na cache upang humawak ng block read at unti-unting snapshot.

Sa hiwalay na pagsusuri sa 10 node, nagpaandar ang mga may-akda ng 8,192 container sa ilalim ng karga ng pagsusuri sa ahente. Natapos ng on-demand na EROFS na ruta ang mga gawain sa humigit-kumulang 35 minuto, kumpara sa mahigit 60 minuto kapag malamig at maagang hinila ang mga image; natapos din sa mga 35 minuto ang batayang konfigurasyong ganap na naka-cache. Humigit-kumulang 700 GB bawat node ang iniulat na disk write sa on-demand na pag-load, kumpara sa mahigit 1,600 GB sa maagang paghila. Paghahambing ito ng mga konfigurasyon sa pagsubok ng mga may-akda. Hindi nito pinatutunayan ang kaparehong pakinabang sa ibang koleksiyon ng image o sistema ng imbakan.

## Pagpapanatiling magagamit ang mga idle na sesyon at naudlot na rollout

Maaaring maghintay ang sandbox ng ahente sa pagitan ng mga utos habang pinananatili ang mga file, proseso at memory. Natuklasan sa isang linggong sampol ng mga may-akda na gumamit sa karaniwan ng hindi hihigit sa 5% ng hiniling na kapasidad ng CPU ang humigit-kumulang 90% ng container at microVM sandbox. Kaya nagsasama ang DSec ng maraming aktibong sesyon sa mga node habang sinusubukan nitong kontrolin ang nasasayang na memory at pagsisikip. Para sa microVM, inilalarawan sa papel ang pagbabahagi ng read-only na file cache sa pamamagitan ng `virtio-pmem` gamit ang DAX, at pagbawi sa mga lumang pahina ng guest sa tulong ng DAMON at pag-uulat ng bakanteng pahina sa pamamagitan ng balloon. Inihihiwalay rin nito ang mga gawaing sensitibo sa latency sa mga best-effort na gawain gamit ang kontrol sa iskedyul ng Linux. Iniuulat sa papel ang mga pakinabang ng mga mekanismong ito sa sarili nitong pagsusuri, kasabay ng mga kapalit gaya ng mas mataas na pansamantalang paggamit ng CPU sa `virtio-pmem`.

Lumilikha ng isa pang suliranin ang pagkaantala sa pagsasanay: maaaring may kapaki-pakinabang pang estado ang rollout kapag inagaw ang GPU job nito. Sinasabi ng mga may-akda na simula sa DeepSeek-V4.1, pinatatakbo ng DSec ang siklo ng ahente sa labas ng maaaring maagaw na GPU pool, sa loob ng worker container at sandbox ng ahente. Muling makakakonekta ang training job sa estadong iyon. Kapag huminto ang pagsasanay, maaaring hilingin ng framework sa DSec na i-pause ang kaugnay na mga sandbox at bawiin ang memory. Pina-freeze at binabawi ang mga container; nagse-save naman muna ng execution state ang mga microVM bilang snapshot bago ihinto ang proseso ng Firecracker. Ipinagpapatuloy ng susunod na operasyon ang sandbox. Salaysay ito ng papel tungkol sa integrasyon sa pagsasanay ng DeepSeek, hindi pangkalahatang garantiya ng pagbawi.

## Ano ang ipinakikita at hindi ipinakikita ng iniulat na lawak

Sinasabi ng DeepSeek na may halos 160 CPU node, mga 30,000 core at humigit-kumulang 250 TB ng DRAM ang iisang yunit ng DSec. Nag-uulat ito ng mga tatlong milyong instance ng sandbox sa karaniwang araw, rurok na sabayang paggamit na nasa 380,000 at bilis ng paglikha na mahigit 5,000 instance bawat segundo para sa yunit na iyon. Mga bilang sa produksyon na iniulat ng mga may-akda ang mga ito para sa isang yunit, hindi malayang awditadong kabuuan ng buong imprastraktura ng DeepSeek. Sa hiwalay na cluster na may 10 node isinagawa ang mga eksperimento sa pagsusuri sa papel.

Inilalarawan din sa ulat ang mga hangganan ng pagkabigo. Ikinukuwento ng mga may-akda ang mga ahenteng naghahanap ng sagot sa di-nilalayong mga daluyan at karaniwang utos na nagpabagsak ng kernel o pumuno sa imbakan ng output. Inilalarawan nila ang mga kontrol ng AppArmor sa file at socket at mga tuntunin sa network kada sandbox bilang pananggalang, habang tahasang sinasabing hindi nito napipigilan ang bawat mapaminsalang kilos. Walang pampublikong service endpoint, panlabas na pamamahagi ng SDK, tuntunin sa pag-access o presyo para sa DSec sa papel. Idinodokumento nito ang disenyo ng sistema at mga kondisyon ng pagsubok ng mga may-akda, ngunit wala itong ibinibigay na panlabas na paraan upang patakbuhin ang halimbawang code.

## Mga sanggunian at karagdagang babasahin

- [Huang et al., *DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale*, arXiv:2609.22978v1, Setyembre 19, 2026](https://arxiv.org/html/2609.22978). Pangunahing sanggunian ang buong teknikal na ulat tungkol sa SDK, mga backend, arkitektura, imbakan ng kapaligiran, integrasyon sa pagsasanay, mga limitasyon at pagsusuring ginawa ng mga may-akda. Inilalarawan sa seksiyon 2 at 3 ang ruta ng kahilingan, sa seksiyon 5 at 6 ang mga mekanismo, at sa seksiyon 8 ang setup at resulta ng pagsubok. Hindi malayang napatunayan para sa artikulong ito ang mga bilang sa operasyon.
- [Abstrak at tala ng pagsumite sa arXiv para sa bersiyon 1](https://arxiv.org/abs/2609.22978). Itinatala nito ang petsa ng pagsumite, katayuan bilang ulat na may 31 pahina at limitadong kasaysayan ng pagsusuri sa naunang pinalawak na abstrak na may dalawang pahina. Hindi nito pinatutunayang dumaan sa peer review ang pinalawak na papel.

## Sources

- [Huang et al., DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — Pangunahing teknikal na ulat; iniulat ng mga may-akda ang disenyo ng sistema at mga bilang sa operasyon. Hindi tinukoy na dumaan sa peer review ang pinalawak na bersiyon v1.