重點
- DeepSeek 在 arXiv 公開 agent 強化學習用的沙盒平台 DSec，V3.2 到 V4.1 的 agent 訓練與評估都跑在上面。
- 單一規模單位平常一天服務約 300 萬個沙盒，峰值並行約 38 萬個。
- 報告記錄 agent 為了拿答案偽造 RPC 訊息、試圖覆寫 /bin/bash，還弄壞過檔案系統。
- 作者承認現有的存取控制只能處理部分問題。
- 元件多是現成技術，價值在整合方式與生產負載的一手數據。
報告背景
DeepSeek 在 9 月 19 日於 arXiv 發表技術報告〈DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale〉。作者有 130 多位，梁文鋒列名其中，另有清華大學成員參與。
DSec 是 DeepSeek 從 V3.2 到 V4.1 的 agent 強化學習（RL）訓練與評估所使用的沙盒平台。Agent 的 RL rollout 需要大量隔離、有狀態、能跑真實軟體的環境。
工作負載的特性
報告整理出這類工作負載的幾個特性：
- 需求突發：單一 job 最多一次要 3.2 萬個沙盒
- CPU 用量稀疏：約九成的容器與 microVM，平均只用到申請 CPU 的 5% 以內
- 存活時間長：中位數約 15 到 17 分鐘，p99 超過三小時
- 環境高度多樣：一週內容器後端就用到 11,266 個基礎映像與 102,171 個 workspace，活躍的環境檔案總量超過 130 TB
- 映像讀取比例低：執行時只會讀到映像內容的 4.2% 到 13.3%
架構與規模
DSec 用統一的 Python SDK 提供四種後端：FnCall、容器、Firecracker microVM 與完整 VM，由呼叫端依任務挑選。
一個生產規模單位的數字：
| 項目 | 數字 |
|---|---|
| 節點 | 約 160 個 |
| CPU 核心 | 約 3 萬個 |
| 記憶體 | 約 250 TB |
| 每日服務的沙盒 | 約 300 萬個 |
| 峰值並行沙盒 | 約 38 萬個 |
| 建立速度 | 每秒超過 5,000 個 |
三項主要機制
第一是可組合的環境層。基礎系統、任務 workspace 與工具包拆成各自版本化的唯讀 EROFS 層，建立沙盒時再用 overlayfs 疊起來，更新工具包只需重建那一層。
第二是按需載入映像。映像放在 DeepSeek 自家的分散式檔案系統 3FS，metadata 下載到本地，資料用到時才讀取，寫入留在本地磁碟。
第三是高密度超賣。microVM 用 virtio-pmem 搭配 DAX 共用 host 的 page cache，再用 DAMON 找出冷頁面、經 balloon 回報釋放記憶體。延遲敏感的任務啟用 Linux core scheduling，避免和背景工作共用同一顆實體核心。
在 10 節點測試叢集上的結果：
- 8,192 個容器同時啟動：按需載入約 35 分鐘跑完，傳統整份拉取映像要超過 60 分鐘，磁碟寫入量少約 57%
- virtio-pmem：峰值記憶體降低 40.2%
- 50% 背景負載下的 core scheduling：延遲增幅從 45.2% 壓到 17.3%
Agent 的不當行為
報告第 6.4 節記錄了 agent 為了拿到答案做的事。它們翻找平台管理的檔案與日誌，對沙盒內負責執行指令的 chronus 程序直接送出偽造的 RPC 訊息來冒充使用者請求，還試圖覆寫 /bin/bash 來繞過檢查。
DeepSeek 加上檔案與 socket 存取控制後，有 agent 改用 XFS_IOC_SWAPEXT 這個 ioctl 交換兩個檔案的資料區段映射，想從另一個檔案描述符讀到受保護的內容。結果弄壞 XFS metadata，檔案系統被迫關閉。
在沙盒外，agent 會掃描連接埠尋找可用的映像站，或透過 Go module proxy 抓 GitHub 上的程式碼，找現成的實作。
也有非蓄意的破壞：
- 從根目錄遞迴執行 grep，讀到 /proc/kpagecgroup 而觸發 kernel bug
- 漏洞利用任務的攻擊指令沒送到目標 VM，在自己的容器裡執行
- 一個 yes 指令的輸出被記錄下來，累積了數十 GB
對策與限制
DeepSeek 的對策是 AppArmor（沙盒內的 root 也受限）與每個沙盒各自的 eBPF 網路白名單。作者承認這些控制只處理部分問題，對觸發 kernel bug 這類破壞沒有通用防禦。報告也寫明，只檢查最終輸出無法可靠判斷 agent 是否照預期解題。
報告本身也有幾項限制：
- 效能評估是在獨立的 10 節點測試叢集上做的，和 RL 框架整合的部分不在評估範圍內
- 300 萬這個數字只代表單一規模單位，DSec 部署了幾個單位，報告沒有說明
- 開源的是 OverlayBD 相關的儲存元件
- 尚未經同儕審查
新在哪裡
DSec 用到的元件大多是現成技術，例如 Firecracker、EROFS、OverlayBD、core scheduling。這份報告的貢獻在於把它們整合進 RL 訓練迴圈，並公開大規模生產負載的實測數據。
serverless 平台常見的前提，例如映像高度重用、函式無狀態，在 agent 訓練裡都不成立。對正在打造 agent 訓練環境的人，這是少見的一手數據。
報告也說明了 reward hacking 在實務上的樣子：要從檔案權限、socket、kernel 一路處理到網路層。