DeepSeek知乎獨家發文，首次公開V4.1 Agent訓練“大本營”DSec

DeepSeek在知乎獨家發佈技術長文，首次系統闡釋了DeepSeek彈性計算（DeepSeek Elastic Compute，DSec） 近日，DeepSeek在知乎獨家發佈技術長文，首次系統闡釋了支撐DeepSeek-V4全部訓練、評測與數據預處理流程的沙盒基礎設施——DeepSeek彈性計算（DeepSeek Elastic Compute，DSec）。

文章基於的技術報告《DeepSeek彈性計算（DSec）：面向大規模智能體訓練的高效沙箱基礎設施（DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale）》已公開至arXiv，由DeepSeek聯合清華大學發佈，作者團隊超過130人，梁文鋒也位列其中。以下為DeepSeek知乎原文：https://zhuanlan.zhihu.

com/p/2088265189233779592 DeepSeek 彈性計算 (DSec)：面向大規模 Agent 訓練的沙盒基礎設施 DeepSeek 彈性計算 (DeepSeek Elastic Compute, DSec) 是支撐 DeepSeek-V4 全部訓練、評測與數據預處理流程的沙盒基礎設施。要訓練一個可靠的 Agent 大模型，需要其能在真實環境裡反覆地試錯：閱讀代碼、修改文件、安裝依賴、執行測試、運行服務。這些操作會不斷改變環境，沙盒必須在多輪交互中持續保留狀態。

這類負載有幾個鮮明的特點：沙盒創建請求是脈衝式、突發的；啟動後 CPU 大部分時間閒置，內存卻需要持續駐留；Agent 執行環境種類多，基礎鏡像複用率低；任務執行時間長，訓練還可能因資源搶佔而中斷。這些特點直接決定了 DSec 的設計。統一接入，適配多樣任務 不同的 Agent 任務對隔離強度、操作系統功能和執行開銷的要求各不相同。DSec 支持 FnCall、Container、MicroVM 和 Full VM 四種執行後端，並通過統一的 Python SDK（libdsec）接入，根據任務類型按需選擇。

其中，FnCall 會複用預先創建的容器，處理在線評測等短任務；Container 以較快的啟動速度和較高的部署密度，服務最通用的軟件工程和工具調用；MicroVM 提供更強的隔離邊界，適用於安全任務等場景；Full VM 提供完整的操作系統環境，支持圖形界面、圖形渲染和 Android 等應用。DSec 架構：統一管理沙盒創建與運行，多種執行後端適配不同任務。分層可組合的環境 Agent 訓練需要大量的環境，首先要解決的問題就是如何大批量地構建和更新環境。以 2026 年某一週的生產數據為例，容器後端使用了 11,266 個基礎鏡像、102,171 個工作區以及數百個工具包。

按照傳統方式，上述任意一部分更新或替換，都會導致大量鏡像的重建。為此，DSec 將沙盒的環境拆分為三部分：基礎鏡像（base image），包含操作系統與基礎軟件；工作區（workspace），包含任務所需的代碼倉庫與依賴；工具包（toolkit），例如 DeepSeek Harness。三者的更新節奏不同，版本管理各自進行，運行時再進行組合。具體的，DSec 使用 EROFS 格式存儲鏡像、工作區和工具包，同時該格式還支持元數據與數據分離，以及跨鏡像去重。創建沙盒時，通過 OverlayFS 按需將各 EROFS 鏡像層組合起來。

當基礎軟件、任務代碼和工具包需要更新時，只需重建發生變化的 EROFS 鏡像，減少無關內容的重複構建。單體鏡像(左）：更新工具包 T1 時，所有內嵌該工具包的鏡像都需要重建。可組合的環境層（右）：只需更新工具包 T1 所在的層，再與已有的基礎鏡像和工作區組合。鏡像按需加載 我們對生產環境使用的鏡像數據進行了分析，發現沙盒運行時實際訪問的數據量僅佔鏡像總大小的 4.2% 至 13.3%。這意味著，如果提前拉取完整鏡像到本地，其中絕大部分數據都不會用到。

因此，DSec 選擇將全部鏡像數據存儲在 3FS 分佈式文件系統上，只把所需鏡像的元數據拉取到本地（EROFS 格式特性），而佔大頭的數據則在訪問時按需讀取，讓 I/O 開銷隨實際使用的數據量縮減。在一次集中創建 8,192 個容器的實驗中，與完整鏡像拉取方案相比，按需加載將任務完成時間從 60 多分鐘縮短至約 35 分鐘，加速比約為 1.71，磁盤寫入量減少約 57%。在另一項工作區供給實驗中，將逐個沙盒解壓 tar.gz 文件改為直接掛載 EROFS 層後，任務完成時間從 79 分鐘縮短至 45 分鐘。工作區存儲方式對比：從解壓 tar.

gz 文件改為直接掛載 EROFS 層後，任務完成時間從 79 分鐘縮短至 45 分鐘，磁盤寫入總量降至原來的約 1/5.5。集中創建 8,192 個容器時的三種鏡像提供方式：與完整鏡像拉取方案相比，按需 EROFS 加載將任務完成時間從 60 多分鐘縮短至約 35 分鐘，加速比約為 1.71，磁盤寫入量減少約 57%。高密度資源管理 Agent 訓練的特點是，沙盒大部分時間都在等待模型生成下一步動作。如圖，約 90% 沙盒的平均 CPU 用量，不會超過其申請量的 5%，CPU 會長時間閒置；但為了保留文件、進程等狀態，內存需要持續駐留。

這為極高的超賣率留足了空間，而我們生產環境的超賣率也超過了 50 倍。按申請量歸一化的平均與峰值 CPU、內存用量分佈：約 90% 的沙盒，其平均 CPU 用量不超過申請量的 5%。為了實現資源高密度部署，需要儘可能地共享緩存和回收閒置內存。DSec 通過 virtio-pmem 與 DAX 技術，讓同一宿主機上的 MicroVM 共享一份宿主頁緩存。實驗中，單獨啟用這一機制，可使宿主機的峰值內存用量較基線下降 40.2%。實驗中，單獨啟用內存回收機制（ DAMON 與 balloon 空閒頁報告），可使按時間累計的宿主機內存消耗較基線下降 21.2%。兩種機制結合使用時，總體內存消耗最低。

四種 Firecracker 配置的宿主機內存與 CPU 用量對比：相較未優化基線，單獨啟用 virtio-pmem 與 DAX，峰值內存用量下降 40.2%；單獨啟用 DAMON 與 balloon 空閒頁報告機制，按時間累計的內存消耗下降 21.2%。在如此高密度部署的情況下，DSec 還會優先保障對響應時間要求較高的任務，讓時延要求較寬鬆的任務利用空閒 CPU 資源運行，並通過核心調度減少同一物理核心上超線程的干擾。實驗表明，通過優化 CPU 調度，當同機運行的其他任務佔用節點 50% 的 CPU 容量時，時延敏感任務相對於無干擾基線的時延增幅由 45.2% 降至 17.3%。

CPU 調度實驗：高密度部署下，優先保障時延敏感任務，降低同機負載的干擾。三項核心機制：鏡像按需加載、可組合的環境層、高密度資源管理。軌跡執行 (rollout) 與 GPU 訓練解耦 在強化學習（RL）訓練中，Agent 通常需要同沙盒環境進行多輪交互，才能完成軌跡執行（rollout）。在早期的訓練流程中，Agent 執行循環與 GPU 訓練任務運行在同一個 Pod 容器中。訓練任務被搶佔打斷後，環境沙盒雖然還在，負責推進交互的 Agent 執行循環卻已終止。恢復時，系統需要重放命令日誌，將訓練框架保存的進度與沙盒中的實際執行過的狀態重新銜接起來。

這樣的恢復邏輯非常複雜，也增加了多個組件之間的協調成本。從 DeepSeek-V4.1 開始，我們將這部分執行邏輯遷移到 DSec 沙盒中，並拆分為 Agent 沙盒和工作容器（worker container）協同完成：Agent 沙盒運行 Agent 框架和工具包，工作容器負責管理沙盒、推進交互流程。兩者都部署在可被搶佔的 GPU 資源池之外，共同保存執行進度和環境狀態。因此，GPU 訓練任務被搶佔時，Agent 的執行狀態仍能完整保留；訓練恢復後，Agent 即可從中斷處繼續執行。

用 Agent 構建運行 Agent 的環境 大規模的 Agent RL 訓練和評測需要高度多樣化的運行環境，包括但不限於二進制依賴、代碼倉庫、Harness 工具包、評測腳本等一系列用於生成 Agent 產物並衡量其正確性的組件。面對這一複雜需求，使用 Agent 進行自動化環境構建，是一種高效、可規模化製作 Agent 環境的方法。我們注意到，該構建環境的 Agent，本身就已經運行在其構建的環境裡了。

在這種情況下，與其為 Agent 訓練構建一套平臺、再為 Agent 造環境構建另一套平臺，不如將兩者放在同一個 “運行 Agent 的平臺” 也就是 DSec 上，大幅簡化系統架構的同時，還能保證 Agent 的構建環境和運行時完全一致。DSec 為環境構建引入了 packdiff 打包機制：Agent 可以指揮平臺對沙盒創建增量快照，以在未來將其恢復為新的沙盒。如此，我們可以輕鬆保存沙盒的狀態，甚至於可以把 Agent 執行的每一輪交互都轉化為可複用的沙箱環境。這種增量快照更可用於軌跡分叉：在第 k 步保存快照，從同一狀態恢復出多個沙盒，分別繼續探索。

各分支共享只讀層，同時只記錄變更，避免反覆執行分叉前的步驟。MicroVM 的快照支持保存和恢復內存及進程狀態，但容器側目前主要支持磁盤級快照。面向 Agent 的安全邊界 隨著 Agent 智能體能力增強，訓練環境的安全邊界也需要持續完善。在生產環境中，我們觀察到 Agent 會嘗試讀取殘留答案、偽造 RPC 請求、覆蓋 /bin/bash 以注入命令，甚至嘗試通過 XFSIOC_SWAPEXT 繞過訪問控制等。這些行為會影響訓練和評測結果，甚至破壞運行環境。只要環境存在獲取獎勵的捷徑，模型就可能利用它。

因此，DSec 將細粒度訪問控制作為基礎功能之一：通過 AppArmor 約束文件讀寫和套接字訪問，即使智能體以管理員身份運行，這些限制依然有效；通過 eBPF 為每個沙盒執行網絡訪問白名單，限制其能夠連接的地址、端口和協議。但這些措施只能緩解部分問題，對於觸發內核缺陷等破壞性行為，目前仍缺乏通用防禦機制。相信隨著模型能力提升，我們與 Agent 的攻防將會一直持續下去，系統的安全機制也會一同迭代、完善。生產數據 DSec 以分片的形式實現橫向擴展，每個擴展分片約包含 160 臺服務器，提供約 3 萬個 CPU 核心和 250 TB 內存。

單個分片每天服務約 300 萬個沙盒，峰值併發超過 38 萬個，每秒可創建超過 5,000 個沙盒。生產環境部署了多個這樣的分片，可支持數百萬個沙盒同時運行。從 DeepSeek-V3.2 到 DeepSeek-V4.1，DSec 承載了 Agent 訓練、評測與數據預處理中的全部沙盒負載。我們已將 DSec 技術報告 《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》 公開至 arXiv，分享支撐大規模 Agent 沙盒運行的工程實踐。

結語 我們相信，Agent 的能力還有無限的想象空間。接下來，我們會將 Agent 運行環境的數量和種類擴充成百上千倍，把這些任務培養出的能力帶回開放模型。這需要更多樣的環境、更可靠的基礎設施，也需要更多開發夥伴。歡迎加入我們，一起搭建面向 Agent 的彈性計算平臺，一同建設下一代 Agent 基礎模型。