DeepSeek、1日300万個運用のサンドボックス公開

DeepSeekはarXivで技術報告を公開した。タイトルは「DeepSeek Elastic Compute(DSec):大規模エージェント訓練のためのサンドボックス基盤」で、9月19日提出。報告が扱うのは、DeepSeekがエージェントを訓練・評価する際に、モデルにコードを書かせ、コマンドを実行させ、コンピューターを操作させるための実行環境層だ。著者リストは100人を超え、主体はDeepSeek-AI。清華大学の博士課程学生もインターンとして名を連ねる。

モデル訓練に関する報告はDeepSeekがこれまでも数多く出してきた。だが強化学習を支えるこの「訓練場」だけを取り出して論文化するのは今回が初めてだ。

4種類のサンドボックス、1つのインターフェース

DSecは統一SDKを通じて4種類のバックエンドを提供する。隔離強度とオーバーヘッドの軽い順に並べると次のようになる。

  • FnCall:ステートレスなタスク、例えばオンラインジャッジ(OJ)
  • コンテナ:ソフトウェアエンジニアリングやツール呼び出し系のタスク
  • Firecracker microVM:より強い隔離が必要なセキュリティ侵入系タスク
  • フル仮想マシン(QEMU):Android開発やグラフィックス負荷の高いタスク

対象となる負荷にはSWE-benchのようなリポジトリレベルのコーディングタスク、セキュリティ脆弱性の悪用、コンピューター操作、モバイル開発が含まれる。訓練フレームワーク側は同じインターフェースを呼び出すだけで、どのサンドボックスを使うかはスケジューリング層がタスクごとに割り当てる。

いくつかの技術的な数字

報告でもっとも紙幅を割いているのがイメージのロードだ。DSecはイメージをEROFS形式で保存し、DeepSeek独自の分散ファイルシステム3FS上でオンデマンドに読み込む。Dockerイメージ全体を先にローカルへ引っ張ってくる従来のやり方と比べ、同じバッチのタスク完了時間は60分台から約35分に短縮され、報告が示す倍率は1.71倍。累積ディスク書き込みは57%減少した。

メモリ面では、virtio-pmemとDAXを組み合わせ、同一マシン上の複数の仮想マシンが1つのページキャッシュを共有できるようにした。各VMが個別に保持する必要がなくなり、ホストのピークメモリは40.2%減少。さらにDAMONとバルーンドライバーによるアイドルページ回収を加えると、時間累積のメモリ使用量はもう21.2%下がった。

訓練と直接関わる設計がもう1つある。rolloutの実行をDSec側に移し、2つのコンポーネントに分割。エージェントのサンドボックスとワーカーコンテナが完全なrollout状態を共同で保持する。GPU訓練タスクはプリエンプト可能だが、プリエンプトされても進行中の複数ステップのやり取りが失われることはない。

海外の同業と並べてみると

エージェント向けサンドボックスというビジネスは、海外にはすでに専業企業が何社も存在する。OpenAIは今年4月、Agents SDKにサンドボックスを追加した際、E2B、Modal、Daytona、Cloudflareといったサードパーティのサービスを組み込んだ。Anthropicはその後セルフホスト型サンドボックスを投入し、CursorはOSレベルのコードサンドボックスを作った。これらの製品が想定するのは本番環境でエージェントを動かす開発者で、重視するのはセキュリティ境界と従量課金だ。

DSecの出発点は異なる。狙うのはDeepSeek自身の強化学習訓練であり、解決すべきは1日に数百万の環境を起動・破棄しながらGPUを止めないことだ。報告にある同時実行数や密度の数字は、対外販売されるサンドボックス製品ではめったに公開されない水準で、1対1の比較はできない。

海外の主要研究機関にも社内では同種のシステムがおそらくあるが、アーキテクチャと数字を論文にすることは少ない。DeepSeekが今回、4種類のバックエンドの取捨選択、イメージとメモリの最適化手法をすべて開示したことで、中国国内でエージェント訓練に取り組むチームには参照できる工学的な材料が1つ増えた。DSecのコードをオープンソース化するか、クラウドサービスとして提供するかについて、報告は言及していない。

参考資料:CocoLoop、arXiv論文DeepSeek Elastic Compute(DSec)、OpenAI Agents SDK公式ドキュメント。同時実行数、密度、イメージロード高速化の数字は論文本文の記載に基づき確認した。