1. 從標(biāo)題拆解DSec 到底想解決什么問題第一次看到 DeepSeek Elastic Compute (DSec) A Sandbox Infrastructure for Effective Agentic Training at Scale 這個標(biāo)題我腦子里蹦出來的第一個念頭是終于有人把 Agentic RL 訓(xùn)練里最臟最累的那塊活兒單獨(dú)拎出來講了。標(biāo)題里三個關(guān)鍵詞——Elastic Compute、Sandbox Infrastructure、Agentic Training at Scale——每一個都踩在當(dāng)前大模型后訓(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 往往是稀疏的、延遲的、甚至帶隨機(jī)性的。這就意味著訓(xùn)練框架必須能同時跑幾千上萬個環(huán)境實例每個實例都是一個獨(dú)立的、隔離的、可執(zhí)行代碼的沙箱。再說 at Scale。小規(guī)模玩 Agentic RL你開幾個 Docker 容器手動管管就行了。但一旦上到千卡集群、上萬并發(fā)環(huán)境問題就爆炸了容器生命周期管理、資源碎片、冷啟動延遲、狀態(tài)回收、故障隔離、安全邊界……這些在傳統(tǒng)訓(xùn)練框架里根本不是一等公民。DSec 這個標(biāo)題里的 Elastic Compute 就是在說算力要能像橡皮筋一樣隨訓(xùn)練負(fù)載伸縮環(huán)境要能按需創(chuàng)建、用完即焚。最后是 Sandbox Infrastructure。這個詞是整篇論文的題眼。Sandbox 不是簡單的 Docker 容器它要滿足幾個硬性條件強(qiáng)隔離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)。這四點(diǎn)缺一個Agentic RL 的訓(xùn)練效率就會大打折扣。所以 DSec 的定位很清晰它不是又一個訓(xùn)練框架而是訓(xùn)練框架底下的環(huán)境執(zhí)行層。你可以把它理解成 Agentic RL 的操作系統(tǒng)——上層是 PPO/GRPO 這類算法下層是物理機(jī)/容器編排DSec 夾在中間負(fù)責(zé)把環(huán)境這個抽象變成可調(diào)度、可擴(kuò)展、可觀測的實體。適合讀這篇論文的人我建議是這幾類正在做 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é)點(diǎn)跑 Agentic PPOGPU 利用率長期在 25% 上下晃瓶頸全在環(huán)境側(cè)。第二個死穴是冷啟動稅。容器池擴(kuò)容時新容器要拉鏡像、裝依賴、初始化運(yùn)行時。一個帶完整 Python 科學(xué)計算棧的鏡像冷啟動動輒十幾秒。RL 訓(xùn)練里 rollout 是高頻操作每個 step 都要幾千次環(huán)境交互這個冷啟動稅累積起來非?？植馈８闊┑氖茿gentic 任務(wù)往往需要帶狀態(tài)的環(huán)境比如一個持續(xù)運(yùn)行的 REPL不能簡單地用完就殺。第三個死穴是故障域不隔離。固定池子里一個容器被 Agent 寫崩了比如 OOM、死循環(huán)、文件系統(tǒng)寫滿可能連帶影響同節(jié)點(diǎn)的其他容器。Agentic RL 里 Agent 會執(zhí)行任意代碼這種自傷概率遠(yuǎn)高于傳統(tǒng)推理場景。池子越大故障傳播的風(fēng)險越高。2.2 DSec 的彈性思路按需創(chuàng)建 分層復(fù)用DSec 的核心思路我概括成一句話把沙箱從預(yù)分配的靜態(tài)資源變成按需創(chuàng)建的彈性資源同時用分層緩存把冷啟動成本攤薄。具體拆成三個機(jī)制。機(jī)制一按需創(chuàng)建On-demand Provisioning。DSec 不再維護(hù)固定大小的容器池而是維護(hù)一個沙箱模板 快速克隆的能力。訓(xùn)練側(cè)需要環(huán)境時向 DSec 發(fā)一個創(chuàng)建請求DSec 在毫秒級從模板克隆出一個新沙箱。用完即銷毀資源立刻歸還。這樣資源利用率不再受池子大小限制而是跟著實際負(fù)載走。機(jī)制二分層鏡像與寫時復(fù)制。冷啟動問題的解法是分層基礎(chǔ)層OS 運(yùn)行時預(yù)烘焙在節(jié)點(diǎn)本地中間層Python 依賴、常用庫做節(jié)點(diǎn)級緩存最上層任務(wù)特定代碼才在創(chuàng)建時注入。配合寫時復(fù)制Copy-on-Write克隆一個沙箱只需要復(fù)制最上層的差異部分啟動時間從十幾秒壓到百毫秒級。這個思路其實借鑒了容器鏡像分層的經(jīng)典做法但 DSec 把它用在了 RL 訓(xùn)練的高頻創(chuàng)建場景里。機(jī)制三狀態(tài)快照與恢復(fù)。Agentic 任務(wù)經(jīng)常需要回滾——比如 Agent 走錯一步訓(xùn)練算法想從某個中間狀態(tài)重新 rollout。DSec 支持對沙箱做輕量快照記錄文件系統(tǒng)差異和進(jìn)程狀態(tài)需要時快速恢復(fù)。這對tree search 類 RL 算法比如 MCTS 增強(qiáng)的 Agent 訓(xùn)練是剛需沒有快照能力樹搜索根本沒法高效實現(xiàn)。2.3 為什么這個設(shè)計對 Agentic RL 特別關(guān)鍵我想強(qiáng)調(diào)一點(diǎn)DSec 的彈性設(shè)計不是為了彈性而彈性而是被 Agentic RL 的訓(xùn)練特性逼出來的。Agentic RL 的 rollout 有兩個鮮明特點(diǎn)高并發(fā)同時幾千個環(huán)境在跑和高異構(gòu)每個環(huán)境的執(zhí)行時間、資源需求、狀態(tài)復(fù)雜度都不一樣。固定池方案在這兩個特點(diǎn)面前必然低效只有彈性方案才能讓環(huán)境側(cè)跟上 GPU 側(cè)的節(jié)奏。從影響范圍看DSec 這類基礎(chǔ)設(shè)施一旦成熟會直接改變 Agentic RL 的訓(xùn)練經(jīng)濟(jì)學(xué)?，F(xiàn)在很多團(tuán)隊不敢上大規(guī)模 Agentic RL不是因為算法不會而是因為環(huán)境成本太高——環(huán)境側(cè)的開銷經(jīng)常是 GPU 開銷的 2 到 3 倍。DSec 把環(huán)境成本壓下來之后Agentic RL 的規(guī)模天花板會被顯著抬高。這也是為什么我覺得這篇論文值得細(xì)讀它講的不是某個 trick而是整個訓(xùn)練棧的底座。3. 核心細(xì)節(jié)解析沙箱隔離、調(diào)度與可觀測性3.1 隔離級別怎么選從 namespace 到 microVM沙箱隔離是 DSec 最底層的技術(shù)選擇也是最能體現(xiàn)工程權(quán)衡的地方。隔離級別從弱到強(qiáng)大致有這么幾檔進(jìn)程級隔離namespace cgroup、容器級隔離Docker/containerd、microVM 級隔離Firecracker/Kata、硬件級隔離獨(dú)立物理機(jī)。每一檔的隔離強(qiáng)度、啟動延遲、資源開銷都不一樣。DSec 的選擇我理解是分層策略默認(rèn)用容器級隔離對高風(fēng)險任務(wù)比如 Agent 要執(zhí)行不可信代碼升級到 microVM。為什么不全用 microVM因為 microVM 啟動雖然比虛擬機(jī)快但相比容器還是有幾十毫秒到百毫秒的額外開銷在萬級并發(fā)下這個開銷會被放大。而容器級隔離對大多數(shù) Agentic 任務(wù)Agent 執(zhí)行的是訓(xùn)練側(cè)自己寫的工具代碼已經(jīng)夠用。這里有個實操細(xì)節(jié)值得說namespace 的粒度選擇。DSec 給每個沙箱獨(dú)立的 PID namespace、mount namespace、network namespace但共享內(nèi)核。共享內(nèi)核意味著如果 Agent 觸發(fā)了內(nèi)核漏洞理論上可以逃逸。所以 DSec 在容器層之上加了 seccomp 過濾和 capability 裁剪把危險系統(tǒng)調(diào)用比如ptrace、mount、reboot直接禁掉。這個組合在隔離強(qiáng)度和性能之間取得了不錯的平衡。提示如果你自己在搭 Agent 沙箱別一上來就追求最強(qiáng)隔離。先問清楚 Agent 執(zhí)行的代碼來源——如果是訓(xùn)練側(cè)可控的代碼容器級隔離 seccomp 足夠如果是用戶提交的不可信代碼才需要上 microVM。隔離強(qiáng)度和性能是直接 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)境準(zhǔn)備好了。這需要調(diào)度器做幾件事。第一是預(yù)測性預(yù)熱。RL 訓(xùn)練的 rollout 請求有很強(qiáng)的周期性——每個 training step 開始時集中爆發(fā)一批環(huán)境需求。DSec 的調(diào)度器會根據(jù)歷史負(fù)載預(yù)測下一個 step 的環(huán)境需求提前把模板預(yù)熱到節(jié)點(diǎn)本地。這樣真正創(chuàng)建時只需要做最上層的克隆延遲極低。第二是親和性調(diào)度。沙箱創(chuàng)建請求會盡量調(diào)度到已經(jīng)緩存了對應(yīng)鏡像層的節(jié)點(diǎn)上避免跨節(jié)點(diǎn)拉鏡像。這個思路跟 K8s 的 image locality 調(diào)度類似但 DSec 做得更激進(jìn)它會把鏡像層緩存作為調(diào)度的第一優(yōu)先級甚至高于 CPU/內(nèi)存的負(fù)載均衡。因為對 RL 訓(xùn)練來說環(huán)境啟動延遲比節(jié)點(diǎn)負(fù)載均衡重要得多。第三是批量創(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)級指標(biāo)每個沙箱的 CPU/內(nèi)存/IO 使用、生命周期事件、創(chuàng)建銷毀延遲。這些指標(biāo)用于監(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啟動延遲毫秒級百毫秒級百毫秒到秒級隔離強(qiáng)度弱中強(qiáng)適用場景可信代碼、快速迭代大多數(shù) Agentic RL不可信代碼、多租戶運(yùn)維復(fù)雜度低中高單節(jié)點(diǎn)密度高高中我的建議是從中等方案起步。containerd seccomp 的組合能覆蓋 80% 的 Agentic RL 場景啟動延遲和隔離強(qiáng)度都夠用。等真的遇到不可信代碼或者多租戶需求再局部升級到 microVM。一上來就上 Firecracker運(yùn)維成本會讓你懷疑人生。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)。很多團(tuán)隊按每卡配 10 個沙箱這種經(jīng)驗值來配結(jié)果要么不夠要么浪費(fèi)。按工作量算才是靠譜的。4.3 一個最小可跑的沙箱創(chuàng)建流程下面給一個基于 containerd 的最小沙箱創(chuàng)建流程偽代碼級別幫你理解 DSec 這類系統(tǒng)在做什么。# 沙箱創(chuàng)建的核心步驟偽代碼 def create_sandbox(template_id, task_code): # 1. 從模板克隆基礎(chǔ)層節(jié)點(diǎn)本地緩存毫秒級 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)建銷毀場景下會成為單點(diǎn)瓶頸而且它的 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é)點(diǎn) inode 打滿所有沙箱創(chuàng)建全部失敗。解法是給 overlayfs 的 upperdir 單獨(dú)掛一塊盤并且定期清理僵尸沙箱的殘留目錄。坑三網(wǎng)絡(luò)隔離別用默認(rèn) bridge。Docker 默認(rèn)的 bridge 網(wǎng)絡(luò)在幾千個容器下會有 ARP 表爆炸和 iptables 規(guī)則膨脹的問題。DSec 這類系統(tǒng)一般用獨(dú)立的 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)建慢是最常見的問題排查要按鏈路走。我整理了一張速查表?，F(xiàn)象可能原因排查方法解決方向創(chuàng)建延遲 1s鏡像層未緩存跨節(jié)點(diǎn)拉取看節(jié)點(diǎn)本地緩存命中率預(yù)熱模板、親和性調(diào)度創(chuàng)建延遲波動大節(jié)點(diǎn)負(fù)載不均看各節(jié)點(diǎn) CPU/IO 水位調(diào)度器加負(fù)載感知批量創(chuàng)建時部分超時調(diào)度器單點(diǎn)瓶頸看調(diào)度器 QPS 和延遲調(diào)度器水平擴(kuò)展創(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)度決策、鏡像準(zhǔn)備、運(yùn)行時啟動、代碼注入四段每段打點(diǎn)看時間花在哪。我見過最多的瓶頸是鏡像準(zhǔn)備段尤其是跨節(jié)點(diǎn)拉取。解法就是前面說的預(yù)熱 親和性調(diào)度。5.2 軌跡丟失或錯亂數(shù)據(jù)側(cè)的排查軌跡問題比創(chuàng)建問題更隱蔽因為它不一定報錯但會悄悄毀掉訓(xùn)練。典型癥狀是訓(xùn)練 loss 異常波動、reward 曲線不收斂。排查要點(diǎn)檢查軌跡序號連續(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)落盤器在高負(fù)載下會靜默丟數(shù)據(jù)查了三天才定位到是異步隊列滿了沒做背壓。5.3 資源泄漏沙箱銷毀不干凈怎么辦沙箱銷毀不干凈會導(dǎo)致資源緩慢泄漏跑幾個小時節(jié)點(diǎn)就滿了。常見泄漏點(diǎn)僵尸進(jìn)程、殘留的 mount point、未釋放的 network namespace、overlayfs 的 upperdir 殘留。排查方法是定期對賬節(jié)點(diǎn)上實際存在的沙箱資源應(yīng)該等于 DSec 記錄的活躍沙箱數(shù)。如果實際多于記錄說明有泄漏。解法是加一個兜底清理器定期掃描孤兒資源并強(qiáng)制回收。這個清理器一定要有因為再嚴(yán)謹(jǐn)?shù)匿N毀邏輯也可能因為進(jì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)核版本是否及時打了安全補(bǔ)丁是否有沙箱間的網(wǎng)絡(luò)隔離防止橫向移動這幾條是底線任何一條不滿足隔離就形同虛設(shè)。我個人的經(jīng)驗是安全配置要做成模板強(qiáng)制項不允許任務(wù)側(cè)覆蓋。否則總有人圖方便把隔離關(guān)掉最后出事。6. 這套設(shè)施對 Agentic RL 生態(tài)的影響6.1 訓(xùn)練經(jīng)濟(jì)學(xué)的改變DSec 這類沙箱設(shè)施最直接的影響是把 Agentic RL 的環(huán)境成本從不可控變成可控。在彈性沙箱成熟之前環(huán)境側(cè)的成本模型是預(yù)分配 N 個容器無論用不用都占著資源成本是固定的、跟負(fù)載脫鉤的。彈性沙箱之后成本跟實際負(fù)載掛鉤閑時資源歸還忙時按需擴(kuò)展。這個改變讓 Agentic RL 的規(guī)模天花板顯著抬高。更深遠(yuǎn)的影響是訓(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 需要頻繁地前進(jìn)到某狀態(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 落地時的組織建議最后說點(diǎn)落地的組織層面建議。搭這類設(shè)施別讓算法團(tuán)隊和基礎(chǔ)設(shè)施團(tuán)隊各干各的。我見過太多案例算法團(tuán)隊抱怨環(huán)境慢基礎(chǔ)設(shè)施團(tuán)隊抱怨需求變來變?nèi)ァＵ_的做法是讓兩邊一起定義接口——環(huán)境創(chuàng)建/銷毀的 API、軌跡數(shù)據(jù)的格式、狀態(tài)快照的語義這些接口一旦定下來兩邊就能并行推進(jìn)。另外先做最小可用版本再逐步加隔離和彈性。一上來就追求 DSec 論文里的完整能力大概率會陷入過度工程的泥潭。我的建議是先用 containerd 把按需創(chuàng)建 軌跡采集跑通驗證訓(xùn)練側(cè)能用起來再逐步加預(yù)熱、快照、microVM 隔離?；A(chǔ)設(shè)施的價值在于被用起來而不是在于功能全。我個人在實際搭這類系統(tǒng)時的體會是最難的不是某個技術(shù)點(diǎn)而是讓環(huán)境側(cè)和訓(xùn)練側(cè)的節(jié)奏對齊。環(huán)境側(cè)追求穩(wěn)定和隔離訓(xùn)練側(cè)追求吞吐和低延遲這兩個目標(biāo)天然有張力。DSec 的價值就在于它把這組張力處理得比較優(yōu)雅——用彈性調(diào)度吸收負(fù)載波動用分層緩存壓低延遲用分層隔離平衡安全和性能。這套思路我覺得不只適用于 Agentic RL任何需要大規(guī)模、短生命周期、強(qiáng)隔離執(zhí)行環(huán)境的場景都能借鑒。