需要修改儲存庫的 AI 代理，必須有地方執行命令，並在不同操作回合之間保留結果。若以訓練規模運作，可能得同時啟動數千個這類環境，再讓它們等待模型決定下一步。DeepSeek 的9 月 19 日技術報告《DeepSeek Elastic Compute（DSec）》，說明了該公司所稱可處理這類工作負載的沙箱系統。

作者介紹請求處理路徑、映像檔儲存方式，以及訓練工作遭中斷時的處理流程。文中的效能與部署數據來自作者自行測量。擴充版報告已提交至 arXiv；摘要指出，較早的兩頁擴充摘要曾接受會議第一輪審查。

核心變化

  • 有哪些改變：DeepSeek 已將 DSec 說明為供代理訓練與評估共用的平台，可透過單一內部用戶端程式庫呼叫函式、容器、microVM 和完整虛擬機器。
  • 為何重要：報告將代理訓練與同時維持大量任務環境運作的基礎設施連結起來。請求會經過授權、配置與本機准入檢查；環境在建立時組合各層，並在需要時擷取映像檔資料。GPU 工作遭搶占時，訓練可暫停具狀態的沙箱。
  • 後續觀察重點：呼叫端仍須選擇後端。論文中的正式環境工作負載測量涵蓋容器與 microVM；兩者使用不同的儲存路徑，資源成本也不同。報告中的規模數據描述的是一個 DSec 單位。

一種請求，四類沙箱

依論文所述，DeepSeek 的訓練框架、評估框架與資料管線會呼叫一個名為libdsec的 Python 程式庫。典型的建立請求會選擇後端與環境產物，設定 CPU 和記憶體限制、存續時間與網路規則，並提供初始使用者情境。沙箱就緒後，呼叫端可以執行命令或工具呼叫、收集輸出並回傳狀態，然後結束工作階段。論文的範例工作階段使用容器、記憶體上限、閒置逾時，以及允許 PyPI、拒絕 NPM 的網路規則。文件描述的是 DeepSeek 平台內部使用的介面，並未提供外部存取途徑。

四種後端各自適用於不同任務。FnCall 透過重複使用預先建立的容器執行短時間、無狀態的工作，避免每次呼叫都新建沙箱。容器適用於儲存庫作業與一般工具使用，啟動快速且可高密度配置，但會與同一主機虛擬機器中的其他容器共用核心。Firecracker microVM 為需要更強隔離的任務提供虛擬機器邊界，但啟動與記憶體開銷較高。完整虛擬機器則處理需要輕量後端無法提供之功能的作業系統或圖形工作負載。作者表示，容器和 microVM 占正式環境中大部分的執行個體與資源使用量。這些是論文描述的設計選擇，不是經測量的安全性比較。

在用戶端後方，DSec 會驗證管理請求，根據定期更新的健康狀態與負載資訊選擇節點，並將請求傳送至該節點的edge服務。邊緣端會在建立沙箱前檢查本機容量；若叢集資訊已過時而導致配置不當，就可能拒絕請求。執行中的容器與虛擬機器沙箱使用名為aether的代理，以及名為chronus的 shell 工作階段處理程序，來執行命令、檔案操作及串流輸出。FnCall 則透過預先建立的容器走另一條路徑。這項差異很重要，因為單一用戶端入口並未消除執行方式或故障處理上的差別。

組合環境，不必整體複製

論文將典型代理環境分為三個部分：基礎映像檔、任務工作區，以及可獨立變更的工具套件。如果將每種組合都製成單一映像檔，更新工具套件就得重建許多映像檔。DSec 改用堆疊方式，將唯讀層與最上方的可寫入層組合起來。容器會透過修改過的 Docker 執行階段，使用 overlayfs 組合這些層。microVM 則使用唯讀 EROFS 層及可寫入磁碟；若檔案系統相容性有要求，會改走不同的區塊儲存路徑。

作者表示，某一週的正式環境使用了 11,266 個容器基礎映像檔及 102,171 個容器工作區。如此多樣的組合降低了在每個節點保存完整映像檔的效益。DSec 將唯讀映像檔資料存放在 DeepSeek 的 3FS 分散式檔案系統，將寫入內容保留在本機儲存，並在沙箱讀取時擷取映像檔內容。容器映像檔中繼資料會複製到本機，讓一般路徑查詢不必讀取遠端資料。microVM 路徑使用 OverlayBD，ublk以及本機快取處理區塊讀取與增量快照。

在另一項使用 10 個節點的評估中，作者於代理評估工作負載下啟動 8,192 個容器。採用按需 EROFS 路徑時，任務約 35 分鐘完成；採用冷啟動並預先完整擷取映像檔則超過 60 分鐘；完全快取的基準組也約 35 分鐘完成。按需載入的磁碟寫入量據報每節點約 700 GB，預先完整擷取則超過 1,600 GB。這些數據比較的是作者測試中的各項設定，無法證明在其他映像檔集合或儲存系統上也有相同改善。

讓閒置工作階段與中斷的 rollout 仍可使用

代理沙箱可能在保留檔案、程序與記憶體的同時，等待下一個命令。作者抽樣觀察一週後發現，約 90% 的容器與 microVM 沙箱，平均 CPU 使用量不超過其要求容量的 5%。因此 DSec 會將許多仍在執行的工作階段密集配置在節點上，同時設法控制記憶體浪費與資源競爭。對 microVM 而言，論文描述透過virtio-pmem搭配 DAX 共用唯讀檔案快取，並利用 DAMON 與 balloon 回報的可用頁面回收冷的客體頁面。系統也透過 Linux 排程控制，將對延遲敏感的任務與盡力而為的工作分開。論文報告這些機制在其自身評估中帶來效益，同時也指出取捨，例如搭配virtio-pmem時，短時間 CPU 使用量會更高。

訓練遭中斷時還會產生另一個問題：若 GPU 工作被搶占，rollout 可能仍保有可用狀態。作者表示，自 DeepSeek-V4.1 起，DSec 會在可被搶占的 GPU 資源池之外，以工作容器與代理沙箱執行代理迴圈；訓練工作之後可重新連線至該狀態。訓練暫停時，框架可以要求 DSec 暫停相關沙箱並回收記憶體。容器會凍結並回收；microVM 則會先將執行狀態存入快照，再停止其 Firecracker 程序。之後的操作可以恢復沙箱。這是論文對 DeepSeek 訓練整合方式的描述，並未提供一般性的復原保證。

這些規模數據能說明什麼，不能說明什麼

DeepSeek 表示，一個 DSec 規模單位有近 160 個 CPU 節點、約 30,000 個核心及約 250 TB DRAM。公司報告指出，該單位一般每天建立約 300 萬個沙箱執行個體，尖峰同時執行數約 380,000 個，建立速率超過每秒 5,000 個。這些是作者公布的一個規模單位正式環境數據，並非經獨立稽核的 DeepSeek 全部運算資源總量。論文的評估實驗是在另一個 10 節點叢集上進行。

報告也說明了故障邊界。作者提到，有代理透過非預期管道尋找答案，也有一般命令造成核心當機，或因大量輸出耗盡儲存空間。他們將 AppArmor 檔案與通訊端控制，以及每個沙箱的網路規則描述為緩解措施，同時明確指出這些控制無法防止所有有害行為。論文未提供公開的 DSec 服務端點、外部 SDK 發佈方式、存取條款或價格。它記錄了系統設計和作者測試條件，但沒有提供可供外部執行範例程式碼的存取途徑。

資料來源與延伸閱讀