AI Agent 沙箱基礎設施怎麼撐？DeepSeek DSec 論文拆解｜AIRUN

DSec 是 DeepSeek 自建的 AI Agent 沙箱平台，實際撐到 38 萬個沙箱同時運行。

DeepSeek 在 2026 年 9 月 19 日把這套系統寫成 31 頁的技術報告放上 arXiv。本文發稿日是 2026 年 9 月 27 日，當天這篇在 Hacker News 拿到 168 分、55 則留言。報告講清楚一件多數人忽略的事：agent 跑多了以後，最先卡住的往往是「環境」，模型算力反而排在後面。

我們自己也在跑多 agent 的產線，讀完這份報告的判斷很直接：完整平台小團隊抄不來，但裡面至少有三個設計，十個 agent 的規模就用得上。下面逐題拆。

DeepSeek 的 DSec 是什麼？

DSec 全名 DeepSeek Elastic Compute，是讓大量 AI agent 各自在隔離環境裡讀程式、跑指令、呼叫工具的生產級平台。訓練時要同時開成千上萬個環境，單一沙箱工具撐不住。

先講「沙箱」：一個與外界隔開的小型執行環境，agent 在裡面亂跑指令也不會弄壞主機或碰到別人的資料。

為什麼訓練 AI agent 需要這種沙箱系統？

因為 agent 訓練的工作負載有四個特性同時成立，傳統「開一台虛擬機跑一個任務」的做法會垮掉，必須改用能彈性調度的整套平台。

DSec 論文摘要點出 agent 工作負載的四個特性：沙箱會大批瞬間湧現、不同任務要的功能與隔離等級各不相同、一次互動可能拉很長所以狀態要一直保留、要用的系統映像檔數量龐大但重複使用率低。這四件事同時成立，傳統「開一台虛擬機跑一個任務」的做法就會垮掉。

摘要的結論寫得很乾脆：支撐這類工作負載需要的是一個彈性執行平台，單一沙箱執行環境不夠用。

DSec 的規模到底有多大？

根據 arXiv 摘要，DSec 一個生產單位約 160 台節點，每天服務約 300 萬個沙箱；生產環境同時運行的沙箱超過 38 萬個，每秒可新建超過 5,000 個。

幾個數字放在一起看比較有感：

指標	數值	來源
單一生產單位節點數	約 160 台	arXiv 摘要
每日服務沙箱數	約 300 萬個	arXiv 摘要
同時運行沙箱數	超過 38 萬個	arXiv 摘要
每秒新建沙箱數	超過 5,000 個	arXiv 摘要
報告篇幅	31 頁、13 張圖	arXiv 摘要

HN 上有網友 vblanco 留言說這些節點是 Epyc 伺服器，另一位網友 dangoodmanUT 推算下來「每個 CPU 核心約 12 個沙箱」（HN 討論串）。這兩個說法都來自網友，論文摘要本身沒有寫 CPU 型號，引用時要分清楚。

另一位網友 r_lee 的解釋比較有參考價值：agent 大部分時間在等模型回應，核心並沒有一直被吃滿，所以能塞這麼密。以下是我們依這則留言做的推論：這段閒置時間，正是 DSec 想榨的效率。摘要提到的「回收閒置資源」和高密度 overcommit 指向同一個方向，但摘要本身沒有直接下這個結論。

DSec 用了哪幾招解開環境瓶頸？

DSec 的核心做法有五個：統一 SDK 下提供四種沙箱後端、全叢集統一調度、環境用分層版本組裝、記憶體共享加回收提高密度、映像檔按需從分散式檔案系統讀取。以下逐一說明。

第一招：四種後端，一個 SDK。 摘要列出 FnCall（函式呼叫）、container（容器）、microVM（微型虛擬機）、full-VM（完整虛擬機）四種後端。microVM 可以理解成「開得像容器一樣快、隔離卻接近虛擬機」的輕量虛擬機。任務要多嚴的隔離，就挑對應的後端，開發端只寫一套程式碼。

第二招：環境分層組裝。 摘要說 DSec 用「各自獨立版本控管的層」拼出執行環境。白話講，作業系統、語言執行環境、專案程式碼各自是一層，換一層不必整包重做。

第三招：高密度 overcommit。 overcommit 指分配出去的資源總量超過實體資源，賭大家不會同時用滿。DSec 結合記憶體共享、記憶體回收與 CPU 排程來做這件事，摘要說在高密度 overcommit 下仍能維持對延遲敏感的效能。

第四招：映像檔按需載入。 映像檔資料從 3FS（Fire-Flyer File System，DeepSeek 的全叢集分散式檔案系統）按需讀取，用到哪一塊才抓哪一塊，不必每台機器先把整包映像檔下載完。

第五招：與強化學習框架一起設計。 這是 DSec 最有意思的地方，下一題專門講。

為什麼沙箱系統要跟強化學習訓練綁在一起設計？

因為 agent 訓練的強化學習流程裡，沙箱狀態和 GPU 訓練的生命週期不同步。DSec 把兩者拆開再協調，GPU 被搶走時 agent 的工作進度不會跟著消失，閒置資源也能即時收回。

先解釋兩個詞。強化學習（RL）的 rollout，指讓模型實際去做一輪任務、記錄過程與結果，拿來當訓練材料。可搶占 GPU（preemptible GPU）則是隨時可能被調去做別的事的算力，便宜但不穩。

摘要寫到 DSec「將有狀態的 rollout 執行與可搶占的 GPU 訓練解耦」，並「協調沙箱生命週期與訓練，在保留 rollout 狀態的同時回收閒置資源」。翻成工程語言：跑任務的環境和算模型的機器分家，一邊掛了另一邊不必重來。

摘要也提到 DSec 能減緩 agent 的不當行為，例如 reward hacking。reward hacking 指 agent 找到評分規則的漏洞拿高分，實際上沒有完成任務。

舉個常見情境：agent 直接改掉測試檔，讓測試通過。此為常見情境舉例，非本論文案例。

沙箱層是擋這類行為的第一道關卡，具體怎麼擋，摘要沒有細講，要看全文。

大實驗室的做法和小團隊自建，差在哪裡？

差距主要在規模化機制：小團隊多半一個 agent 開一個完整容器、整包下載映像檔、狀態跟著機器走；DSec 則在每個卡點都有專門機制。下表左欄的卡點來自論文摘要，中欄是我們對小團隊常見做法的實務判斷。

卡點（論文摘要點名）	小團隊常見做法（我們的判斷）	DSec 的對應機制（摘要）
沙箱大批瞬間湧現	腳本逐一開容器，排隊等	全叢集統一調度放置與生命週期
隔離需求各不相同	全部用同一種容器	FnCall／容器／microVM／完整 VM 四種後端
長互動要保留狀態	狀態寫在容器裡，機器掛了就沒了	rollout 狀態與 GPU 訓練解耦
映像檔量大、重複用得少	每台機器先整包拉映像檔	從 3FS 按需載入
記憶體不夠塞	加機器	記憶體共享、回收加 CPU 排程
agent 鑽評分漏洞	事後人工抽查	沙箱層減緩 reward hacking

表格看完就知道，小團隊的痛點其實和大實驗室一模一樣，差別只在量級。量級小了好幾個數量級，解法可以簡化，但方向相同。

這對台灣中小企業意味著什麼？

意思是：你的 agent 專案卡住時，先查環境層，再考慮換更貴的模型。DSec 的完整平台不必抄，也抄不來，但其中三個設計在十個 agent 的規模就該做，而且不用多花錢。

我們的立場分成「該抄」和「別碰」兩類。

該抄的三件事：

1. 環境分層。 把基礎系統、工具鏈、專案程式碼拆成不同層，各自管版本。最常見的狀況是一改套件版本，所有 agent 環境全部整包重建一次。分層後只重建變動那一層。
2. 狀態與算力分家。 agent 做到一半的進度寫到外部儲存，不要只存在容器裡。雲端的便宜可中斷機器被收回時，工作可以接續，這就是 DSec「解耦 rollout 與 GPU」的小型版。
3. 按任務挑隔離等級。 只查資料的 agent 用輕量函式呼叫就夠；要執行陌生程式碼的，才開有完整隔離的環境。全部一視同仁地開重型環境，錢和記憶體都是這樣燒掉的。

別碰的兩件事：

• 自建分散式檔案系統（像 3FS）。這是百台節點以上才划算的投資，小團隊用現成的物件儲存即可。
• 自寫叢集調度器。同時跑幾十個 agent 的規模，現成的容器編排工具綽綽有餘。

判斷門檻可以這樣抓：同時運行的 agent 低於 50 個，把力氣放在上面三件「該抄」的事；超過數百個且每天大量開關，才值得評估專門的沙箱平台。這兩個數字是我們的經驗抓法，非論文建議，DSec 報告摘要沒有給出這類門檻。

還有一點常被忽略：DSec 花不少篇幅處理 reward hacking。企業把 agent 放進實際流程後，同樣會遇到 agent 為了「看起來完成任務」而走捷徑。沙箱裡要留執行紀錄，驗收要看結果本身，不能只看 agent 自己回報的狀態。

這篇論文可以全信嗎？還有哪些沒公開？

這是一份 DeepSeek 自家的技術報告，數字來自其生產環境自述，尚未經第三方重現。早期的兩頁版本投到 ACM SIGOPS ATC 2026 營運系統軌，摘要寫的是「經歷第一輪審查」，沒有說已經錄取。

幾件目前查不到的事，我們直接列出來：

• 是否開源：摘要沒有提到開源計畫。
• 單一沙箱的記憶體配置：摘要沒有寫，HN 網友 r_lee 也在問同一個問題（HN 討論串）。
• 各後端的啟動時間比較：官方摘要未公布具體數字，需看全文圖表。
• 成本數字：官方未公布。

HN 上另有網友 erulabs 認為這和 Google 正在做的 ax 專案方向相近（HN 討論串）。大型實驗室各自在做 agent 沙箱平台，說明這層基礎設施已經成為 agent 競賽的必要條件。

讀原文建議從 arXiv 頁面下載 PDF，DOI 為 10.48550/arXiv.2609.22978（註冊中）。

DSec 給 agent 團隊最重要的一課是什麼？

agent 規模化的瓶頸在環境，DSec 用生產數字證明了這件事。38 萬個同時運行的沙箱、每秒 5,000 個新建，這些數字的意義是：模型再強，環境開不起來、狀態留不住、資源回收不了，agent 產線就跑不動。

台灣中小團隊現在就該做的事很明確：環境分層、狀態外存、隔離分級。這三件做完，十個 agent 到一百個 agent 的路會平順很多。至於分散式檔案系統和自建調度器，等你真的每天要開上萬個沙箱再說。

如果你想知道自家品牌在 ChatGPT、Perplexity 這類 AI 答案裡被提到的狀況，可以到 AIRUN AEO 看我們怎麼做。

常見問題

DeepSeek DSec 是什麼？

DSec（DeepSeek Elastic Compute）是 DeepSeek 在 2026 年 9 月 19 日於 arXiv 公開的 AI Agent 沙箱基礎設施。它透過統一 SDK 提供函式呼叫、容器、微型虛擬機、完整虛擬機四種沙箱，讓大量 agent 在隔離環境裡讀程式、跑指令、呼叫工具。

DSec 能同時跑多少個沙箱？

根據論文摘要，DSec 一個生產單位約 160 台節點，每天服務約 300 萬個沙箱；生產環境同時運行的沙箱超過 38 萬個，每秒可新建超過 5,000 個。這些是 DeepSeek 自述的生產數字，尚未經第三方重現。

為什麼訓練 AI agent 需要專門的沙箱系統？

agent 訓練時沙箱會大批瞬間湧現、隔離需求各不相同、一次互動要保留很久的狀態，映像檔又多又少重複使用。這四個特性同時成立，一般一任務一台虛擬機的做法會卡在開機速度、記憶體與成本，所以需要能彈性調度的整套平台。

DSec 有開源嗎？

截至 2026 年 9 月 27 日，DSec 論文摘要沒有提到開源計畫，目前公開的是 31 頁技術報告。想參考它的做法，可以從報告裡的設計原則下手，例如環境分層組裝、映像檔按需載入、把 agent 狀態和算力分開管理。

台灣中小企業跑 AI agent 可以從 DSec 學什麼？

三件事在十個 agent 的規模就能做：環境分層管理版本、把 agent 的工作進度寫到外部儲存、依任務風險挑選隔離等級。自建分散式檔案系統和叢集調度器則不必碰，同時運行數百個 agent 以上再評估專門平台。