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

來源原標題

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

作者

量子位的朋友们

原始標籤

資訊 · 知乎

原始連結

https://www.qbitai.com/2026/09/499308.html

摘要原文

DeepSeek知乎獨家發文，首次公開V4.1 Agent訓練“大本營”DSec 量子位的朋友們 2026-09-30 13:18:05 來源： 量子位 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 為環境構建引入了 pack_diff 打包機制：Agent 可以指揮平臺對沙盒建立增量快照，以在未來將其恢復為新的沙盒。如此，我們可以輕鬆儲存沙盒的狀態，甚至於可以把 Agent 執行的每一輪互動都轉化為可複用的沙箱環境。 這種增量快照更可用於軌跡分叉：在第 k 步儲存快照，從同一狀態恢復出多個沙盒，分別繼續探索。各分支共享只讀層，同時只記錄變更，避免反覆執行分叉前的步驟。MicroVM 的快照支援儲存和恢復記憶體及程序狀態，但容器側目前主要支援磁碟級快照。 面向 Agent 的安全邊界 隨著 Agent 智慧體能力增強，訓練環境的安全邊界也需要持續完善。在生產環境中，我們觀察到 Agent 會嘗試讀取殘留答案、偽造 RPC 請求、覆蓋 /bin/bash 以注入命令，甚至嘗試通過 XFS_IOC_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 基礎模型。 本文由知乎提供，量子位獲授權轉載，觀點歸原作者所有。 版權所有，未經授權不得以任何形式轉載及使用，違者必究。 知乎 量子位的朋友們 正行創新聯合創始人楊宇欣正式亮相：出任總裁，負責全球業務拓展 2026-09-29 DeepSeek官方開源昇騰基礎元件，與昇騰共建高效易用的AI晶片軟體生態 2026-09-30 成立一年完成5輪融資，諾因智慧再獲數億元，累計超10億元 2026-09-29 從真機到世界模型，具身智慧正在補一條看不見的資料產線 2026-09-24 相關閱讀