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