1. 從標題拆解DSec 到底想解決什么問題第一次看到 DeepSeek Elastic Compute (DSec) A Sandbox Infrastructure for Effective Agentic Training at Scale 這個標題我腦子里蹦出來的第一個念頭是終于有人把 Agentic RL 訓練里最臟最累的那塊活兒單獨拎出來講了。標題里三個關鍵詞——Elastic Compute、Sandbox Infrastructure、Agentic Training at Scale——每一個都踩在當前大模型后訓練post-training最痛的神經(jīng)上。先說 Agentic Training。傳統(tǒng)的 RLHF 或者 PPO 訓練環(huán)境基本是靜態(tài)的給一個 prompt模型生成一個回答reward model 打個分完事。但 Agentic 場景完全不是這么回事。Agent 要調工具、要執(zhí)行代碼、要讀寫文件、要跟外部環(huán)境多輪交互每一步的 action 都會改變環(huán)境狀態(tài)reward 往往是稀疏的、延遲的、甚至帶隨機性的。這就意味著訓練框架必須能同時跑幾千上萬個環(huán)境實例每個實例都是一個獨立的、隔離的、可執(zhí)行代碼的沙箱。再說 at Scale。小規(guī)模玩 Agentic RL你開幾個 Docker 容器手動管管就行了。但一旦上到千卡集群、上萬并發(fā)環(huán)境問題就爆炸了容器生命周期管理、資源碎片、冷啟動延遲、狀態(tài)回收、故障隔離、安全邊界……這些在傳統(tǒng)訓練框架里根本不是一等公民。DSec 這個標題里的 Elastic Compute 就是在說算力要能像橡皮筋一樣隨訓練負載伸縮環(huán)境要能按需創(chuàng)建、用完即焚。最后是 Sandbox Infrastructure。這個詞是整篇論文的題眼。Sandbox 不是簡單的 Docker 容器它要滿足幾個硬性條件強隔離Agent 執(zhí)行的代碼不能污染宿主或其他實例、快啟動RL 訓練對 rollout 吞吐極其敏感環(huán)境啟動慢一秒整體訓練就慢一拍、可觀測要能拿到 Agent 在沙箱里的完整軌跡用于訓練、可復現(xiàn)同樣的 seed 和 action 序列要能復現(xiàn)同樣的環(huán)境狀態(tài)。這四點缺一個Agentic RL 的訓練效率就會大打折扣。所以 DSec 的定位很清晰它不是又一個訓練框架而是訓練框架底下的環(huán)境執(zhí)行層。你可以把它理解成 Agentic RL 的操作系統(tǒng)——上層是 PPO/GRPO 這類算法下層是物理機/容器編排DSec 夾在中間負責把環(huán)境這個抽象變成可調度、可擴展、可觀測的實體。適合讀這篇論文的人我建議是這幾類正在做 Agent 后訓練但被環(huán)境管理拖垮的算法工程師、想搞清楚 Agentic RL 工程棧長什么樣的研究者、以及需要給內部 Agent 平臺做沙箱隔離的基礎設施同學。2. 核心設計思路為什么是彈性而不是固定池2.1 傳統(tǒng)沙箱池方案的三個死穴在 DSec 之前業(yè)界做 Agentic RL 沙箱的主流做法是預分配容器池訓練開始前先起好 N 個容器訓練過程中從池子里借、用完還回去。這個方案在小規(guī)模下能用但一上規(guī)模就暴露三個死穴。第一個死穴是資源錯配。Agentic 任務的執(zhí)行時間方差極大有的 action 就是查個表幾十毫秒返回有的 action 要跑一段 Python 做數(shù)值計算幾秒甚至幾十秒。固定池子里慢任務會把容器占死快任務排隊等GPU 在旁邊干等著 rollout 數(shù)據(jù)利用率直接掉到 30% 以下。我見過最夸張的案例一個 8 卡節(jié)點跑 Agentic PPOGPU 利用率長期在 25% 上下晃瓶頸全在環(huán)境側。第二個死穴是冷啟動稅。容器池擴容時新容器要拉鏡像、裝依賴、初始化運行時。一個帶完整 Python 科學計算棧的鏡像冷啟動動輒十幾秒。RL 訓練里 rollout 是高頻操作每個 step 都要幾千次環(huán)境交互這個冷啟動稅累積起來非常恐怖。更麻煩的是Agentic 任務往往需要帶狀態(tài)的環(huán)境比如一個持續(xù)運行的 REPL不能簡單地用完就殺。第三個死穴是故障域不隔離。固定池子里一個容器被 Agent 寫崩了比如 OOM、死循環(huán)、文件系統(tǒng)寫滿可能連帶影響同節(jié)點的其他容器。Agentic RL 里 Agent 會執(zhí)行任意代碼這種自傷概率遠高于傳統(tǒng)推理場景。池子越大故障傳播的風險越高。2.2 DSec 的彈性思路按需創(chuàng)建 分層復用DSec 的核心思路我概括成一句話把沙箱從預分配的靜態(tài)資源變成按需創(chuàng)建的彈性資源同時用分層緩存把冷啟動成本攤薄。具體拆成三個機制。機制一按需創(chuàng)建On-demand Provisioning。DSec 不再維護固定大小的容器池而是維護一個沙箱模板 快速克隆的能力。訓練側需要環(huán)境時向 DSec 發(fā)一個創(chuàng)建請求DSec 在毫秒級從模板克隆出一個新沙箱。用完即銷毀資源立刻歸還。這樣資源利用率不再受池子大小限制而是跟著實際負載走。機制二分層鏡像與寫時復制。冷啟動問題的解法是分層基礎層OS 運行時預烘焙在節(jié)點本地中間層Python 依賴、常用庫做節(jié)點級緩存最上層任務特定代碼才在創(chuàng)建時注入。配合寫時復制Copy-on-Write克隆一個沙箱只需要復制最上層的差異部分啟動時間從十幾秒壓到百毫秒級。這個思路其實借鑒了容器鏡像分層的經(jīng)典做法但 DSec 把它用在了 RL 訓練的高頻創(chuàng)建場景里。機制三狀態(tài)快照與恢復。Agentic 任務經(jīng)常需要回滾——比如 Agent 走錯一步訓練算法想從某個中間狀態(tài)重新 rollout。DSec 支持對沙箱做輕量快照記錄文件系統(tǒng)差異和進程狀態(tài)需要時快速恢復。這對tree search 類 RL 算法比如 MCTS 增強的 Agent 訓練是剛需沒有快照能力樹搜索根本沒法高效實現(xiàn)。2.3 為什么這個設計對 Agentic RL 特別關鍵我想強調一點DSec 的彈性設計不是為了彈性而彈性而是被 Agentic RL 的訓練特性逼出來的。Agentic RL 的 rollout 有兩個鮮明特點高并發(fā)同時幾千個環(huán)境在跑和高異構每個環(huán)境的執(zhí)行時間、資源需求、狀態(tài)復雜度都不一樣。固定池方案在這兩個特點面前必然低效只有彈性方案才能讓環(huán)境側跟上 GPU 側的節(jié)奏。從影響范圍看DSec 這類基礎設施一旦成熟會直接改變 Agentic RL 的訓練經(jīng)濟學。現(xiàn)在很多團隊不敢上大規(guī)模 Agentic RL不是因為算法不會而是因為環(huán)境成本太高——環(huán)境側的開銷經(jīng)常是 GPU 開銷的 2 到 3 倍。DSec 把環(huán)境成本壓下來之后Agentic RL 的規(guī)模天花板會被顯著抬高。這也是為什么我覺得這篇論文值得細讀它講的不是某個 trick而是整個訓練棧的底座。3. 核心細節(jié)解析沙箱隔離、調度與可觀測性3.1 隔離級別怎么選從 namespace 到 microVM沙箱隔離是 DSec 最底層的技術選擇也是最能體現(xiàn)工程權衡的地方。隔離級別從弱到強大致有這么幾檔進程級隔離namespace cgroup、容器級隔離Docker/containerd、microVM 級隔離Firecracker/Kata、硬件級隔離獨立物理機。每一檔的隔離強度、啟動延遲、資源開銷都不一樣。DSec 的選擇我理解是分層策略默認用容器級隔離對高風險任務比如 Agent 要執(zhí)行不可信代碼升級到 microVM。為什么不全用 microVM因為 microVM 啟動雖然比虛擬機快但相比容器還是有幾十毫秒到百毫秒的額外開銷在萬級并發(fā)下這個開銷會被放大。而容器級隔離對大多數(shù) Agentic 任務Agent 執(zhí)行的是訓練側自己寫的工具代碼已經(jīng)夠用。這里有個實操細節(jié)值得說namespace 的粒度選擇。DSec 給每個沙箱獨立的 PID namespace、mount namespace、network namespace但共享內核。共享內核意味著如果 Agent 觸發(fā)了內核漏洞理論上可以逃逸。所以 DSec 在容器層之上加了 seccomp 過濾和 capability 裁剪把危險系統(tǒng)調用比如ptrace、mount、reboot直接禁掉。這個組合在隔離強度和性能之間取得了不錯的平衡。提示如果你自己在搭 Agent 沙箱別一上來就追求最強隔離。先問清楚 Agent 執(zhí)行的代碼來源——如果是訓練側可控的代碼容器級隔離 seccomp 足夠如果是用戶提交的不可信代碼才需要上 microVM。隔離強度和性能是直接 trade-off 的過度隔離會讓 rollout 吞吐掉一大截。3.2 調度器設計怎么讓環(huán)境側不拖 GPU 后腿DSec 的調度器要解決的核心問題是讓環(huán)境創(chuàng)建/銷毀的延遲對訓練循環(huán)透明。理想情況下訓練側發(fā)一個我要 N 個環(huán)境的請求DSec 應該在訓練側還沒意識到等待的時候就把環(huán)境準備好了。這需要調度器做幾件事。第一是預測性預熱。RL 訓練的 rollout 請求有很強的周期性——每個 training step 開始時集中爆發(fā)一批環(huán)境需求。DSec 的調度器會根據(jù)歷史負載預測下一個 step 的環(huán)境需求提前把模板預熱到節(jié)點本地。這樣真正創(chuàng)建時只需要做最上層的克隆延遲極低。第二是親和性調度。沙箱創(chuàng)建請求會盡量調度到已經(jīng)緩存了對應鏡像層的節(jié)點上避免跨節(jié)點拉鏡像。這個思路跟 K8s 的 image locality 調度類似但 DSec 做得更激進它會把鏡像層緩存作為調度的第一優(yōu)先級甚至高于 CPU/內存的負載均衡。因為對 RL 訓練來說環(huán)境啟動延遲比節(jié)點負載均衡重要得多。第三是批量創(chuàng)建與批量銷毀。單個創(chuàng)建請求的開銷網(wǎng)絡往返、調度決策在萬級并發(fā)下不可忽略。DSec 支持批量 API一次請求創(chuàng)建幾百個沙箱調度器內部并行處理。銷毀同理訓練 step 結束后批量回收避免逐個銷毀的 overhead。3.3 可觀測性Agent 軌跡怎么完整落盤Agentic RL 訓練離不開軌跡數(shù)據(jù)——Agent 在沙箱里做了什么、看到了什么、reward 是多少這些都要完整記錄用于訓練。DSec 在可觀測性上做了兩層設計。第一層是系統(tǒng)級指標每個沙箱的 CPU/內存/IO 使用、生命周期事件、創(chuàng)建銷毀延遲。這些指標用于監(jiān)控和調度決策。第二層是應用級軌跡Agent 的每一步 action、環(huán)境返回的 observation、執(zhí)行的命令和輸出。這一層是訓練數(shù)據(jù)的來源必須完整、有序、可關聯(lián)。這里有個容易踩的坑軌跡落盤的 IO 開銷。如果每個 action 都同步寫盤在高并發(fā)下 IO 會成為瓶頸。DSec 的做法是異步批量落盤 內存緩沖同時保證崩潰時最多丟失一個 batch 的軌跡。這個取舍在訓練場景下是合理的——丟一個 batch 的軌跡對訓練影響很小但同步寫盤會拖垮整個 rollout 吞吐。注意軌跡的順序性比完整性更重要。Agentic RL 訓練時如果軌跡的 action 順序錯亂reward 分配就會錯位訓練直接崩。DSec 給每個沙箱的軌跡打了單調遞增的序號落盤時按序號排序確保訓練側拿到的軌跡是有序的。4. 實操視角如果我要復現(xiàn)一套類似的沙箱設施4.1 技術選型對照表假設你現(xiàn)在要從零搭一套 Agentic RL 的沙箱設施我整理了一張選型對照表把關鍵維度和常見方案列出來方便你按自己的場景取舍。維度輕量方案中等方案重量方案隔離技術namespace cgroupcontainerd seccompFirecracker microVM啟動延遲毫秒級百毫秒級百毫秒到秒級隔離強度弱中強適用場景可信代碼、快速迭代大多數(shù) Agentic RL不可信代碼、多租戶運維復雜度低中高單節(jié)點密度高高中我的建議是從中等方案起步。containerd seccomp 的組合能覆蓋 80% 的 Agentic RL 場景啟動延遲和隔離強度都夠用。等真的遇到不可信代碼或者多租戶需求再局部升級到 microVM。一上來就上 Firecracker運維成本會讓你懷疑人生。4.2 關鍵參數(shù)計算并發(fā)數(shù)怎么定沙箱并發(fā)數(shù)不是拍腦袋定的要跟 GPU 側的 rollout 吞吐匹配。給一個粗略的計算框架。假設你有 8 張 GPU 做訓練每個 training step 需要 rollout 出 B 條軌跡每條軌跡平均需要 E 次環(huán)境交互每次交互平均耗時 T 秒。那么單個 step 的環(huán)境側總工作量是B × E × T秒。如果希望環(huán)境側不成為瓶頸環(huán)境側的總并發(fā)能力 C 應該滿足C ≥ B × E × T / S其中 S 是單個 step 的期望墻鐘時間。舉個例子B1024E10T0.5 秒S30 秒。那么C ≥ 1024 × 10 × 0.5 / 30 ≈ 171。也就是說你至少需要能同時跑 171 個沙箱?？紤]到任務執(zhí)行時間的方差實際并發(fā)數(shù)建議留 1.5 到 2 倍余量也就是 250 到 350 個沙箱。這個計算的關鍵洞察是環(huán)境并發(fā)數(shù)跟 GPU 數(shù)量沒有直接關系而是跟 rollout 的工作量和時間預算有關。很多團隊按每卡配 10 個沙箱這種經(jīng)驗值來配結果要么不夠要么浪費。按工作量算才是靠譜的。4.3 一個最小可跑的沙箱創(chuàng)建流程下面給一個基于 containerd 的最小沙箱創(chuàng)建流程偽代碼級別幫你理解 DSec 這類系統(tǒng)在做什么。# 沙箱創(chuàng)建的核心步驟偽代碼 def create_sandbox(template_id, task_code): # 1. 從模板克隆基礎層節(jié)點本地緩存毫秒級 base local_cache.get(template_id) # 2. 寫時復制出可寫層 writable_layer cow_clone(base) # 3. 注入任務特定代碼 inject_code(writable_layer, task_code) # 4. 配置隔離參數(shù) config { namespaces: [pid, mount, network, ipc], seccomp_profile: agent_default, capabilities: [CAP_NET_BIND_SERVICE], # 最小權限 memory_limit: 2G, cpu_quota: 200000, # 2 核 } # 5. 啟動沙箱 sandbox runtime.start(writable_layer, config) # 6. 注冊到軌跡采集器 tracer.register(sandbox.id) return sandbox這個流程里第 1、2 步是性能關鍵路徑必須做到毫秒級。第 4 步的隔離配置是安全關鍵路徑capability 一定要按最小權限原則給別圖省事給CAP_SYS_ADMIN那等于沒隔離。4.4 實操心得三個我踩過的坑坑一別用 Docker daemon 做高頻創(chuàng)建。Docker daemon 在高頻創(chuàng)建銷毀場景下會成為單點瓶頸而且它的 API 有全局鎖。DSec 這類系統(tǒng)都是直接對接 containerd 或者更底層的 runtime繞開 daemon。我早期用 Docker SDK 做沙箱池QPS 上到幾百就開始抖換成 containerd 直連后穩(wěn)如老狗?？佣募到y(tǒng)用 overlayfs 要小心 inode 耗盡。overlayfs 的寫時復制會產(chǎn)生大量小文件高頻創(chuàng)建銷毀場景下 inode 消耗極快。我遇到過一次節(jié)點 inode 打滿所有沙箱創(chuàng)建全部失敗。解法是給 overlayfs 的 upperdir 單獨掛一塊盤并且定期清理僵尸沙箱的殘留目錄?？尤W(wǎng)絡隔離別用默認 bridge。Docker 默認的 bridge 網(wǎng)絡在幾千個容器下會有 ARP 表爆炸和 iptables 規(guī)則膨脹的問題。DSec 這類系統(tǒng)一般用獨立的 network namespace 輕量 CNI或者干脆讓沙箱共享宿主網(wǎng)絡但用 seccomp 限制網(wǎng)絡系統(tǒng)調用。具體選哪種取決于你的 Agent 是否需要真實網(wǎng)絡訪問。5. 常見問題與排查技巧實錄5.1 沙箱創(chuàng)建慢從請求到就緒的全鏈路排查沙箱創(chuàng)建慢是最常見的問題排查要按鏈路走。我整理了一張速查表?，F(xiàn)象可能原因排查方法解決方向創(chuàng)建延遲 1s鏡像層未緩存跨節(jié)點拉取看節(jié)點本地緩存命中率預熱模板、親和性調度創(chuàng)建延遲波動大節(jié)點負載不均看各節(jié)點 CPU/IO 水位調度器加負載感知批量創(chuàng)建時部分超時調度器單點瓶頸看調度器 QPS 和延遲調度器水平擴展創(chuàng)建成功但 Agent 起不來依賴缺失或權限不足看沙箱內 stderr檢查鏡像層和 capability創(chuàng)建后立即被 OOM kill內存 limit 太小看 cgroup 內存事件調大 limit 或優(yōu)化任務排查的核心思路是分段計時把創(chuàng)建過程拆成調度決策、鏡像準備、運行時啟動、代碼注入四段每段打點看時間花在哪。我見過最多的瓶頸是鏡像準備段尤其是跨節(jié)點拉取。解法就是前面說的預熱 親和性調度。5.2 軌跡丟失或錯亂數(shù)據(jù)側的排查軌跡問題比創(chuàng)建問題更隱蔽因為它不一定報錯但會悄悄毀掉訓練。典型癥狀是訓練 loss 異常波動、reward 曲線不收斂。排查要點檢查軌跡序號連續(xù)性每個沙箱的軌跡序號應該是 1、2、3……連續(xù)的。如果有跳號說明落盤丟了數(shù)據(jù)。檢查 action-observation 配對每個 action 后面應該跟一個 observation。如果配對錯位說明落盤順序亂了。檢查沙箱 ID 關聯(lián)軌跡要能正確關聯(lián)回沙箱和 training step。如果關聯(lián)錯了reward 會分配到錯誤的軌跡上。提示軌跡采集器一定要做端到端校驗——訓練側拿到的軌跡條數(shù)應該等于環(huán)境側產(chǎn)生的軌跡條數(shù)。這個校驗看起來笨但能第一時間發(fā)現(xiàn)數(shù)據(jù)丟失。我在一個項目里就是靠這個校驗發(fā)現(xiàn)落盤器在高負載下會靜默丟數(shù)據(jù)查了三天才定位到是異步隊列滿了沒做背壓。5.3 資源泄漏沙箱銷毀不干凈怎么辦沙箱銷毀不干凈會導致資源緩慢泄漏跑幾個小時節(jié)點就滿了。常見泄漏點僵尸進程、殘留的 mount point、未釋放的 network namespace、overlayfs 的 upperdir 殘留。排查方法是定期對賬節(jié)點上實際存在的沙箱資源應該等于 DSec 記錄的活躍沙箱數(shù)。如果實際多于記錄說明有泄漏。解法是加一個兜底清理器定期掃描孤兒資源并強制回收。這個清理器一定要有因為再嚴謹?shù)匿N毀邏輯也可能因為進程崩潰、網(wǎng)絡分區(qū)等原因漏掉。5.4 隔離逃逸安全側的底線檢查隔離逃逸是低頻但高危的問題。Agentic RL 里 Agent 執(zhí)行的是代碼理論上存在逃逸可能。底線檢查清單seccomp 是否禁掉了ptrace、mount、unshare等危險調用capability 是否按最小權限給有沒有多余的CAP_SYS_ADMIN是否禁用了 privileged 模式內核版本是否及時打了安全補丁是否有沙箱間的網(wǎng)絡隔離防止橫向移動這幾條是底線任何一條不滿足隔離就形同虛設。我個人的經(jīng)驗是安全配置要做成模板強制項不允許任務側覆蓋。否則總有人圖方便把隔離關掉最后出事。6. 這套設施對 Agentic RL 生態(tài)的影響6.1 訓練經(jīng)濟學的改變DSec 這類沙箱設施最直接的影響是把 Agentic RL 的環(huán)境成本從不可控變成可控。在彈性沙箱成熟之前環(huán)境側的成本模型是預分配 N 個容器無論用不用都占著資源成本是固定的、跟負載脫鉤的。彈性沙箱之后成本跟實際負載掛鉤閑時資源歸還忙時按需擴展。這個改變讓 Agentic RL 的規(guī)模天花板顯著抬高。更深遠的影響是訓練迭代速度。環(huán)境創(chuàng)建從十幾秒壓到百毫秒意味著研究者可以更快地試錯——改一版 reward 函數(shù)幾分鐘就能看到 rollout 結果而不是等半小時。這種迭代速度的提升對 Agentic RL 這種高度依賴實驗的領域價值可能比單純的成本節(jié)省更大。6.2 對算法設計的反向影響基礎設施的能力會反向塑造算法設計。DSec 支持狀態(tài)快照和快速恢復之后一些之前因為工程成本太高而沒人做的算法變得可行了。比如基于樹搜索的 Agent 訓練——MCTS 需要頻繁地前進到某狀態(tài)、探索、回滾沒有快照能力根本做不了。再比如多輪交互的 credit assignment——需要精確記錄每一步的環(huán)境狀態(tài)才能把最終 reward 合理分配到中間步驟。我甚至覺得未來 Agentic RL 的算法創(chuàng)新會越來越多地依賴基礎設施能力。算法研究者和基礎設施研究者的邊界會變模糊——你不懂沙箱怎么工作就沒法設計出高效的 Agentic 訓練算法。這個趨勢在 DSec 這類工作出現(xiàn)之后會越來越明顯。6.3 落地時的組織建議最后說點落地的組織層面建議。搭這類設施別讓算法團隊和基礎設施團隊各干各的。我見過太多案例算法團隊抱怨環(huán)境慢基礎設施團隊抱怨需求變來變去。正確的做法是讓兩邊一起定義接口——環(huán)境創(chuàng)建/銷毀的 API、軌跡數(shù)據(jù)的格式、狀態(tài)快照的語義這些接口一旦定下來兩邊就能并行推進。另外先做最小可用版本再逐步加隔離和彈性。一上來就追求 DSec 論文里的完整能力大概率會陷入過度工程的泥潭。我的建議是先用 containerd 把按需創(chuàng)建 軌跡采集跑通驗證訓練側能用起來再逐步加預熱、快照、microVM 隔離?；A設施的價值在于被用起來而不是在于功能全。我個人在實際搭這類系統(tǒng)時的體會是最難的不是某個技術點而是讓環(huán)境側和訓練側的節(jié)奏對齊。環(huán)境側追求穩(wěn)定和隔離訓練側追求吞吐和低延遲這兩個目標天然有張力。DSec 的價值就在于它把這組張力處理得比較優(yōu)雅——用彈性調度吸收負載波動用分層緩存壓低延遲用分層隔離平衡安全和性能。這套思路我覺得不只適用于 Agentic RL任何需要大規(guī)模、短生命周期、強隔離執(zhí)行環(huán)境的場景都能借鑒。