DSec：分層鏡像加 CPU 超賣，撐住 38 萬沙盒並發
DeepSeek-AI（arXiv）· 2026-09-19
DeepSeek 把 agent 訓練用的沙盒鏡像從「整包預熱」改成「隨用隨讀」，同時把單機 CPU 排程拆成延遲敏感與盡力而為兩級，讓同一台機器能塞下 800 台 microVM 或 3,200 個容器而不互相拖慢。這套系統叫 DSec（DeepSeek Elastic Compute），論文 arXiv:2609.22978 由 DeepSeek-AI 於 2026 年 9 月 19 日提交，描述的是支撐大規模 agentic 強化學習訓練與評測的沙盒基礎設施，單一生產單元約 160 台機器、3 萬核心、250 TB DRAM，每天服務約 300 萬個沙盒，尖峰同時撐住超過 38 萬個並發沙盒、每秒建立超過 5,000 個。
背景
Agent 訓練跟推論不同：模型要在一個隔離、有狀態的環境裡讀 repo、跑指令、裝依賴、啟服務，而且沙盒常常是一次性、大批量建立——訓練一個 batch 就要瞬間開出成千上萬個環境。DeepSeek 觀察到，把 base image、任務 workspace、常更新的工具包（如 DeepSeek Harness）三者打包成單一 OCI image 會製造組合爆炸：維護 M 個 base image、N 個 workspace、K 個工具包，光是升級 m 個 base image 就要重建 O(m·N) 種組合，升級工具包則是 O(k·N)。論文的例子是升級一個工具包 T1，即使 base image 跟 workspace 都沒變，每個包含 T1 的整包 image 仍要全部重建。
另一個問題是鏡像分發。production 一週內光容器後端就用到 11,266 個 base image、102,171 個 workspace，總資料量超過 130 TB，遠超單機能存的範圍，且沙盒實際只會用到 image 裡 4.2% 到 13.3% 的檔案。論文的消融實驗顯示：一旦沙盒批量建立時去 registry 搶著整包拉取，完成時間會被拖慢 1.7 倍。CPU 使用型態也很浪費——約 90% 的容器與 microVM 平均只用到申請額度的 5% 以下 CPU，但因為部分任務有嚴格的單步延遲預算（例如遊戲類 agent），單純靠排程優先權無法阻止同一實體核心的 SMT 兄弟執行緒互相干擾。
核心改動
DSec 把上述三個問題各自對應到一個機制。第一，環境改成可組合分層：base image、workspace、工具包各自獨立版號化，容器端用 EROFS 只讀層搭配 overlayfs，microVM 端則用同一套疊層邏輯掛進 Firecracker 的 disk 路徑，升級一個工具包只需要重建它自己那一層。第二，鏡像改成隨選讀取：不再整包預熱，而是透過 Fire-Flyer File System（3FS）在真正被讀到時才拉取資料，論文的消融數字是磁碟累積寫入量減少 57%。第三，CPU 排程分成兩級：延遲敏感（LS）沙盒之外的都歸為盡力而為（BE），BE 統一放進 SCHED_IDLE，並啟用 Linux core scheduling 避免 BE 任務跑到 LS 沙盒的 SMT 兄弟執行緒上，把 SMT 造成的延遲膨脹從 45.2% 壓到 17.3%。記憶體方面則用 virtio-pmem 讓多台 microVM 共享同一份 host page cache，並用 DAMON 搭配 balloon free-page reporting 回收冷頁面，在消融實驗裡讓記憶體用量再降 21.2%。
| 舊方法（單體鏡像／預熱拉取） | DSec（分層鏡像／隨選讀取） | |
|---|---|---|
| 鏡像升級成本 | 升級工具包需重建所有含它的整包 image，成本 O(k·N) | 只重建對應那一層，成本降到 O(k) |
| 批量建立時的鏡像拉取 | 整包預熱，完成時間被拖慢 1.7× | 依實際存取隨選讀取，累積磁碟寫入減 57% |
| CPU 排程 | 單一優先權，SMT 延遲膨脹 45.2% | LS/BE 分級 + core scheduling，延遲膨脹降到 17.3% |
| 單機沙盒密度（觀測操作點） | 未分級時容易互相干擾，密度受限 | 穩定運行下可達 3,200 容器或 800 microVM／節點 |
影響範圍
這套設計是給大規模跑 agentic RL 訓練與評測的團隊看的：如果你的沙盒平台是每個任務打包成一個完整 image、批次建立時去 registry 整包拉取，遇到訓練 batch 瞬間開出上萬個環境時就會撞上論文描述的同一種拉取風暴。可以檢查的具體項目包括：鏡像是否把易變的工具包跟穩定的 base image 綁在一起打包、批量建立沙盒時的 I/O 路徑有沒有走隨選讀取、CPU 排程有沒有區分延遲敏感與可延後的任務。論文也提到 GPU 訓練任務常被搶占，因此沙盒狀態要能在 DSec 上保留到訓練恢復，這對耦合 rollout 與訓練 job 生命週期的框架也有參考價值。
論文本身沒有釋出 DSec 整套系統的程式碼，但作者提到其中的 storage 元件——Rust 版 OverlayBD 與 ublk 用戶態函式庫——已經開源在 github.com/kvcache-ai/AgentENV；至於 placement engine、watcher、IAM 等叢集層元件，論文未公布是否開源。
原始來源：arXiv:2609.22978