DeepSeek擴招！彈性計算團隊大量HC，尤其需要資深工程師

彈性計算團隊大量HC招人！尤其需要資深工程師。三週前不是剛招過一輪嗎？咋又缺人了。這次沒發崗位JD，直接甩了一篇DeepSeek技術分享： 《DeepSeek彈性計算（DSec）：面向大規模Agent訓練的沙盒基礎設施》 現在DeepSeek的一套DSec擴展分片，大約有160臺服務器、3萬個CPU核心和250TB內存，每天要服務約300萬個沙盒。高峰期，同時在線的沙盒超過38萬個，每秒還能創建5000多個。DeepSeek已經在生產環境裡部署了多個這樣的分片，能夠支持數百萬個沙盒同時運行。接下來，要把Agent運行環境的數量和種類擴充成百上千倍。

這麼一看，確實得招人…… 38萬個沙盒同時在線 DSec是支撐DeepSeek-V4全部訓練、評測和數據預處理流程的沙盒基礎設施。從DeepSeek-V3.2一路到V4.1，Agent訓練、評測和數據預處理產生的全部沙盒負載，都已經運行在DSec上。它面對的工作負載和普通雲計算還有點不一樣。Agent訓練過程中，模型需要不斷進入真實環境執行任務。讀代碼、改文件、安裝依賴、執行測試、運行服務，每一步都會改變當前環境；下一輪交互又要接著前面的狀態繼續。因此這些沙盒既要能夠快速、大批量創建，又不能每執行一步就銷燬重來。

DeepSeek總結下來，這類負載有幾個很明顯的特點： 創建請求會突然集中湧入； CPU大部分時間處於空閒狀態，但為了保存文件和進程，內存又得一直留著； 不同Agent任務需要的執行環境差異很大； 基礎鏡像複用率不高； 訓練過程還可能因為GPU資源被搶佔而中斷。DSec現在做的大量工作，就是圍繞這些特點，把Agent環境的供給成本往下壓。首先是環境本身。DeepSeek拿2026年某一週的生產數據統計了一下，僅Container後端就用到了11266個基礎鏡像、102171個工作區，以及數百個工具包。

如果按照傳統方法，每種組合都做成一份完整鏡像，代碼倉庫或者工具包稍微更新一次，就可能跟著重建一大批鏡像。所以DSec直接把環境拆成了三層。操作系統和基礎軟件放進base image，任務代碼和依賴放進workspace，DeepSeek Harness這類工具則單獨做成toolkit。三部分分別管理版本，真正創建沙盒的時候再組合起來。這樣工具更新，只需要重建工具所在的那一層，不必把整個環境從頭再做一次。但環境拆開之後，還有另一個問題： 這麼多鏡像，要不要提前全部拉到服務器上？DeepSeek看了一遍真實生產數據，發現根本沒必要。Agent實際運行時，真正訪問到的數據只佔整個鏡像的4.

2%到13.3%。也就是說，一個幾十GB的環境提前完整下載下來，其中絕大多數內容可能從頭到尾都不會被Agent碰到。DSec於是把鏡像數據統一放到DeepSeek自己的3FS分佈式文件系統裡，本地主要保存鏡像元數據，真正需要某塊數據時再按需讀取。DeepSeek集中創建8192個Container做過一次測試。如果先把完整鏡像拉到本地，整個任務需要60多分鐘；換成按需加載之後，時間縮短到了大約35分鐘，速度提升約1.71倍，磁盤寫入量同時減少約57%。另一個工作區實驗裡，原本每創建一個沙盒，都需要單獨解壓一份tar.gz文件。

改成直接掛載EROFS層之後，整個任務從79分鐘縮短到45分鐘，磁盤寫入總量只剩原來的大約1/5.5。環境供給解決之後，接下來就是怎麼把CPU和內存儘可能利用起來。DeepSeek統計發現，Agent沙盒其實相當“稀疏”。大約90%的沙盒，平均CPU使用量都不到申請資源的5%。原因在於Agent完成一次操作後，通常需要等待模型生成下一步動作。等待期間CPU基本閒置，但文件、進程等環境狀態仍然需要保存，所以內存又不能直接釋放。這給DSec留下了很大的資源調度空間。DeepSeek現在生產環境裡的資源超賣率已經超過50倍。不過，單純往一臺機器裡塞更多沙盒還不夠。

MicroVM之間大量相同的只讀內容如果各存一份，內存很快就會成為瓶頸。DSec通過virtio-pmem和DAX，讓同一臺宿主機上的MicroVM共享宿主頁緩存。單獨啟用這項機制，實驗中的宿主機峰值內存佔用相比基線下降了40.2%。另一邊，藉助DAMON和balloon空閒頁報告回收暫時不用的內存，按時間累計的內存消耗還能再降低21.2%。CPU也不能簡單一視同仁。有些Agent任務對響應時間比較敏感，有些則晚一點完成也沒關係。DSec會優先保證前一類任務，再讓時延要求較低的任務利用剩餘CPU。

DeepSeek的實驗裡，當同一臺機器上的其他任務已經佔掉節點50%的CPU容量時，經過調度優化，時延敏感任務受到的延遲影響從45.2%降到了17.3%。鏡像按需加載、內存共享、CPU調度……DSec前面這些優化，目的其實都很一致： 儘可能壓低每個Agent環境佔用的資源，把同一批機器撐出更大的併發規模。但資源省下來之後，DeepSeek接下來還準備把Agent能訓練的環境也一起鋪開。用Agent給Agent造環境 不同Agent任務對運行環境的要求完全不同。DSec現在已經統一支持四種執行後端：FnCall、Container、MicroVM和Full VM。

FnCall適合在線評測等短任務； Container主要承擔軟件工程和工具調用； MicroVM提供更強的隔離能力； 到了Full VM，則可以提供完整操作系統，支持GUI、圖形渲染甚至Android應用。隨著Agent能力繼續往外擴，環境也會越來越複雜。一個Coding Agent可能只需要代碼倉庫、Shell和測試工具，但如果以後要讓Agent操作更多真實軟件、系統和服務，訓練階段就得先把這些環境構建出來。而DeepSeek現在的做法已經有點Agent套Agent了： 直接用Agent構建運行Agent的環境。

傳統方式下，可能需要一套平臺負責Agent訓練，再單獨搭一套平臺生產Agent所需的環境。DeepSeek發現，負責構建環境的Agent本身就已經運行在環境裡面。於是乾脆把兩件事都塞回DSec。DSec為此做了一個叫packdiff的機制。Agent在沙盒裡把環境配置好之後，可以直接生成增量快照，把當前狀態保存下來。以後需要同樣的環境，就可以從這個快照重新恢復。甚至Agent每執行一步，都可以把當前狀態保存成一個新的可複用環境。這還帶來了一個挺重要的能力，軌跡分叉。比如Agent執行到第k步，接下來有三種不同方案可以嘗試。

系統可以先在第k步保存一次快照，然後從完全相同的狀態恢復出多個沙盒，讓不同分支分別繼續探索。前面的環境和數據可以共享，只有後續發生的變化需要單獨記錄，不需要把前k步重新執行一遍。對於大規模強化學習來說，這相當於把同一條Agent軌跡上的環境狀態也變成了可以複用的數據。與此同時，DSec還在把Agent執行和GPU訓練進一步拆開。以前Agent執行循環和GPU訓練任務放在同一個Pod裡。一旦GPU訓練任務被搶佔，Agent執行循環也會跟著中斷。恢復之後，還得重新播放之前的命令記錄，把訓練進度和沙盒裡的真實狀態重新對齊。從DeepSeek-V4.1開始，這部分執行邏輯被遷進了DSec。

Agent沙盒和負責推進交互的worker container都運行在可搶佔GPU資源池之外。這樣即使GPU任務中斷，Agent執行到哪一步、環境變成了什麼樣，都還能繼續保存。而環境狀態能夠被獨立保存之後，Agent執行就不必再和GPU訓練綁死。GPU重新回來之後，訓練可以直接從中斷的位置繼續。不過，當Agent真的可以在環境裡自由操作以後，另一個問題也來了： 模型開始自己找環境漏洞了。DeepSeek說，他們已經在真實生產環境裡觀察到Agent嘗試各種非常具體的操作： 讀取環境裡殘留的答案、偽造RPC請求，甚至直接覆蓋/bin/bash來注入命令。

甚至還有Agent嘗試調用XFSIOC_SWAPEXT繞過訪問控制。背後的邏輯很簡單，強化學習給模型的是獎勵，只要環境裡存在一條比正常完成任務更容易拿到獎勵的路徑，能力足夠強的Agent就可能把它找出來。但這會直接汙染訓練和評測結果。所以DSec現在又得負責給Agent劃安全邊界。文件和Socket訪問通過AppArmor限制，即使Agent拿到了管理員權限，相應規則依然有效；網絡側則利用eBPF給每個沙盒設置白名單，限定它能夠連接的地址、端口和協議。但DeepSeek也明確承認，這些辦法還解決不了所有問題。比如Agent如果進一步找到內核漏洞，目前依然缺少一套通用的防禦機制。

他們對此的判斷是： 隨著模型能力繼續提高，和Agent之間的攻防還會一直持續下去。活兒有億點多，所以DeepSeek需要更多開發夥伴，團隊需要繼續Scaling。我問你，招到人之後是不是能把V4.1 Pro也抬上來了…… 參考鏈接：[1] https://x.com/tianyi/status/2104881693706653733[2] https://zhuanlan.zhihu.com/p/2088265189233779592 版權所有，未經授權不得以任何形式轉載及使用，違者必究。