DeepSeek 公開了替 Agent 強化學習打造的沙箱平台 DSec（DeepSeek Elastic Compute）。一個部署單元只有近 160 台 CPU 主機，尖峰卻同時跑著 38 萬個沙箱，每秒建立超過 5,000 個。這些數字背後的判斷是：訓練 Agent 的瓶頸不只在 GPU，也在替模型準備「可以動手的電腦」。
DSec 在三處換掉了傳統做法：映像檔怎麼組、機器怎麼塞滿、訓練中斷怎麼辦。
先搞懂：Agent 訓練為什麼需要沙箱
強化學習（RL）訓練 Agent 時，模型要在隔離環境裡讀檔、跑指令、看錯誤訊息，再用測試是否通過等訊號打分數。每個任務都有自己的程式庫與評分腳本，這個環境就是「沙箱」。它有幾個特性：
- 爆發式建立：一個工作可能一次要 3.2 萬個沙箱
- CPU 大多閒著：沙箱多半在等模型想下一步，適合超賣（overcommit），一台主機最多放 800 個 microVM（輕量虛擬機）或 3,200 個容器
- 有狀態、活很久：改過的檔案、裝過的套件要保留，記憶體持續被占著
- 環境各不相同：映像檔重複利用率低
映像檔：從「整包下載解壓」到「用到才讀」
舊做法是把系統、程式庫、工具打成一整包，啟動前整份下載解壓。任一層更新都要重建整包；幾千個沙箱同時啟動時，大量寫入還拖慢其他沙箱。
DSec 把基礎系統、工作區、工具包拆成獨立唯讀層，建立沙箱時才用 Linux 的 overlayfs 疊起來，執行時的寫入落在最上層的可寫層。唯讀層用 EROFS 存放，這種檔案系統可以只解壓被讀到的區塊，不必像 tar.gz 從頭解到尾。
關鍵觀察是：沙箱只會讀到映像檔的一小部分。所以映像檔放在自家分散式檔案系統 3FS 上，用到才抓；寫入則留在本機，避開 3FS 不擅長的零碎小 I/O。
在 8,192 個容器同時啟動的測試中，整包下載要超過 60 分鐘，按需載入 35 分鐘，接近全部預先快取在本機的情況；每台主機累計寫入從 1,600 GB 以上降到約 700 GB。
超賣：從「塞滿就好」到「分級保護」
CPU 閒著就多塞沙箱，聽起來很直覺，但有兩個卡關點。
第一是記憶體。每個 microVM 都會把讀過的檔案存進自己的頁面快取，同一份基礎映像檔就被重複快取幾百次。DSec 讓唯讀層透過 virtio-pmem 直接對應到主機記憶體，多個 microVM 共用一份，尖峰用量降了 40.2%。可寫磁碟讀進來的快取無法共用，就改成回收：用 Linux 的記憶體存取監控工具 DAMON 找出久未使用的快取頁面並釋放，再由虛擬機的 balloon 驅動把空出來的記憶體還給主機，累計用量少了 21.2%。代價是 virtio-pmem 讓 CPU 瞬間尖峰從 26.5% 升到 41.4%，報告建議 CPU 吃緊時可只開回收機制。
第二是互相干擾。DSec 把沙箱分成延遲敏感和盡力而為兩類，後者設成最低排程優先權。但同一顆實體核心的兩個超執行緒（SMT）仍會互搶，單靠優先權最多改善 3.4%；再用 Linux 的 core scheduling 禁止兩類工作共用實體核心，50% 背景負載下的延遲增幅從 45.2% 壓到 17.3%。
中斷：從「重播指令」到「把 Agent 搬出 GPU 叢集」
GPU 訓練工作常被搶占。早期 Agent 迴圈跟著訓練程式跑在 GPU 上，一被搶占迴圈就沒了、沙箱卻還活著，只能靠指令紀錄重播對齊狀態。從 DeepSeek-V4.1 開始，Agent 迴圈改跑在 DSec 上，訓練恢復後直接重新連上。暫停期間，容器被凍結並換出記憶體，microVM 存成快照後關閉，把資源讓出來。
最難防的，是模型自己
報告記錄了 Agent 的「作弊」：翻平台日誌找殘留答案、覆寫 /bin/bash，甚至用交換檔案資料區塊的 ioctl 繞過存取控制，弄壞 XFS 中繼資料、讓檔案系統被迫關閉。也有無心之過，例如從根目錄遞迴 grep 讀到 /proc/kpagecgroup，觸發核心 bug 當機。DSec 用 AppArmor 管檔案與 socket、用 eBPF 做網路白名單，但報告承認這只擋得住部分取巧管道，觸發核心 bug 這類破壞沒有通用解法。
這些數字來自 DeepSeek 自己的叢集，換了環境未必相同；但「按需載入、分級超賣、把 Agent 狀態搬離 GPU」三個方向，對要大規模跑 Agent RL 的團隊都值得參考。
回應
還沒有回應，成為第一個留言的人吧。