DeepSeek揭大規模Agent訓練平台 單一任曾啟動3.2萬個沙盒
DeepSeek創辦人梁文鋒署名的最新論文公開，首次系統披露Agent訓練沙盒平台DSec（DeepSeek Elastic Compute）的技術細節。
這篇於9月19日提交、由超過130人共同署名的論文顯示，DeepSeek已透過DSec支撐大規模Agent訓練與評測；平台每日服務約300萬個沙盒，尖峰同時運行數量超過38萬個。
Agent訓練需要大量沙盒
DSec曾出現在DeepSeek V4技術報告中。根據新論文，從DeepSeek V3.2到V4.1的強化學習訓練與評測，所有沙盒負載均運行於DSec。
一個生產單元約有160個CPU節點、3萬個CPU核心及250TB記憶體，並託管PB級鏡像。平台每秒可建立超過5000個沙盒，單一訓練任務最多曾一次啟動3.2萬個。
與圍繞靜態輸入、輸出和獎勵訊號進行的傳統大型語言模型訓練相比，Agent必須在環境中執行程式碼、呼叫工具、下達指令及修改檔案。每一步操作都可能改變環境狀態，後續動作則取決於先前結果。
因此，訓練不只需要模型與資料，還需要大量可執行任務、保存狀態，並在任務結束後恢復的工作環境。
這些沙盒並非持續使用CPU。Agent等待下一步操作時，CPU可能閒置，但記憶體及可寫入狀態仍須保留。
當沙盒數量達數萬個，批量建立、資源調度、環境複製與狀態管理便成為訓練能否穩定運行的關鍵。
四種後端共用一套介面
不同Agent任務所需的環境差異很大。簡單任務可能只需呼叫函數；軟體工程任務需要能安裝依賴、修改程式碼及執行測試的Linux環境；安全攻防、電腦操作或商業軟體任務，則可能需要更高程度的隔離或完整作業系統。
DSec為此提供FnCall、容器、Firecracker微型虛擬機及完整虛擬機四種後端。訓練框架透過同一套Python SDK，即可建立沙盒、執行指令並取得結果，無須分別適配底層環境。
平台收到請求後，先驗證身分與權限，再依叢集負載選擇節點並建立沙盒；鏡像資料則由3FS按需提供。
分層鏡像加快部署
大量沙盒還帶來環境部署問題。論文統計，DSec在一個生產週內使用了11,266個基礎鏡像、102,171個工作區及103個工具包；實際運行時，67.8%的沙盒會在基礎鏡像上疊加工作區或工具包。
若將所有組件包進單一鏡像，任一部分更新都可能需要重新建置及分發整個鏡像。
DSec因此把基礎鏡像、工作區及工具包拆成三個獨立版本的唯讀層，啟動沙盒時再組合。哪個組件變動，就更新對應部分。
論文也指出，沙盒實際讀取的資料僅占完整鏡像的4.2%至13.3%，因此平台將鏡像放在3FS上按需讀取，並把元資料預先載入本地。
在8,192個容器同時部署的測試中，按需載入耗時35分鐘，Docker冷拉取則超過60分鐘；單一節點的累計磁碟寫入量，也由約1,600GB降至約700GB。
Agent還可透過增量快照保存自行配置的環境，供後續沙盒恢復使用。
執行任務與GPU訓練分離
DeepSeek早期讓Agent推論、任務執行與模型訓練共用GPU資源。一旦GPU任務遭搶占，正在執行的任務也會中斷。從V4.1開始，DeepSeek將任務執行移至DSec獨立運行，使GPU訓練被搶占時，執行狀態仍可保留。
當本地叢集容量不足，DSec也支援向雲端擴容。論文指出，叢集使用率超過80%後，符合條件的沙盒可轉移至雲端虛擬機；在生產環境中，200台雲端虛擬機可承接約30%的尖峰負載。
真實環境也帶來安全挑戰
沙盒越接近真實環境，Agent的操作風險也越高。論文記錄，部分Agent曾翻查日誌、偽造RPC請求、修改系統程式，或掃描可連線服務、下載外部程式碼，試圖透過預期流程以外的方式完成任務。另有操作造成核心崩潰，或使日誌膨脹至數十GB。
DSec使用AppArmor及eBPF限制檔案、連線與網路存取，並可依任務階段調整規則。不過，論文也指出，現有措施只能涵蓋部分風險，仍難以完全防範核心層級漏洞。
這篇論文呈現的DSec，是DeepSeek為Agent訓練建立的執行平台：在大量沙盒之間兼顧建立速度、環境更新、狀態保存與安全隔離。
隨著Agent任務延長、互動步驟增加，如何讓大規模執行環境穩定運行並控制資源消耗，將持續考驗這套基礎設施。
更多鉅亨報導
•DeepSeek赴聯合國安理會談AI風險！OpenAI、Anthropic罕見同場
•DeepSeek大模型再暴衝 2兆參數訓練中、下一步挑戰8兆