AI-translated from English; not yet reviewed by a fluent editor. # DeepSeek、エージェント学習用サンドボックス基盤「DSec」を詳述 > 9月の技術報告書は、エージェント学習用サンドボックス基盤であるDeepSeekのDSecについて、複数の実行基盤、組み合わせ可能な環境、著者が報告した導入規模などを説明している。 By BIG CHANGE Editorial Published: 2026-09-27T06:48:31.966Z Updated: 2026-09-27T06:48:31.966Z Canonical: https://bigchange.ai/blog/deepseek-dsec-agent-training-sandbox-platform ![Conceptual charcoal illustration of an open, unbranded equipment cabinet with connected cables entering a floor channel; two closed cabinets recede behind it.](https://bigchange.ai/api/media/file/dsec-cabinet-hero-v2.png) AI-generated conceptual illustration by BIG CHANGE. AIエージェントがリポジトリを編集するには、コマンドを実行し、複数のやり取りをまたいで結果を保持できる環境が要る。学習規模では、数千の環境を同時に起動し、モデルが次の行動を決めるまで待機させる場合もある。DeepSeekの[DeepSeek Elastic Compute（DSec）に関する9月19日付技術報告書](https://arxiv.org/html/2609.22978)は、その負荷を処理すると同社が説明するサンドボックス基盤を紹介している。 著者らは、要求が処理される経路、イメージの保存方法、学習ジョブが中断された際の動作を説明している。性能と導入規模の数値は、著者ら自身が測定したものだ。拡張版の報告書はarXivへの投稿論文で、要旨によると、先行する2ページの拡張抄録は学会の第1段階審査を受けた。 ## 大きな変化 - **変わったこと：**DeepSeekは、エージェントの学習と評価に共用する基盤としてDSecを文書化した。関数呼び出し、コンテナ、マイクロVM、フルVMを、1つの社内クライアントライブラリから利用できる。 - **なぜ重要か：**この報告書は、エージェントの学習を、多数のタスク環境を同時に稼働させるインフラと結びつけて説明している。要求は認可、配置、ノード上での受け入れ確認を経て処理され、起動時に複数の環境レイヤーを組み合わせ、必要に応じてイメージデータを取得する。GPUジョブがプリエンプトされたとき、学習を一時停止し、状態を持つサンドボックスを待機させることもできる。 - **今後の注目点：**どの実行基盤を使うかは呼び出し側が選ぶ。論文の本番負荷の測定対象はコンテナとマイクロVMで、両者はストレージ経路もリソースコストも異なる。報告された規模の数値は、DSecの1つの運用単位についてのものだ。 ## 1つの要求、4種類のサンドボックス 論文によると、DeepSeekの学習フレームワーク、評価フレームワーク、データパイプラインは、Pythonライブラリ「`libdsec`」を呼び出す。通常の作成要求では、実行基盤と環境イメージを選び、CPUとメモリの上限、存続時間、ネットワーク規則を設定し、初期ユーザーコンテキストを渡す。サンドボックスの準備ができると、呼び出し側はコマンドやツールを実行し、出力と状態を受け取り、セッションを停止できる。論文のサンプルセッションではコンテナ、メモリ上限、アイドル時のタイムアウト、PyPIを許可してNPMを拒否するネットワーク規則を使う。これはDeepSeek社内の基盤で使われるインターフェースの説明であり、外部から利用できる経路ではない。 4種類の実行基盤は、それぞれ異なる作業に対応する。FnCallは、あらかじめ作成した再利用可能なコンテナで短時間かつ状態を持たない処理を行い、呼び出しのたびに新しいサンドボックスを作る手間を省く。コンテナはリポジトリ作業や一般的なツール利用に対応し、起動が速く高密度に配置できる一方、同じホストVM上の他コンテナとカーネルを共有する。FirecrackerマイクロVMは、より強い分離が必要な作業にVM境界を提供するが、起動時間とメモリの負担が増える。フルVMは、軽量な実行基盤では提供できない機能を必要とするOSやグラフィックス処理を扱う。著者らは、本番環境のインスタンス数とリソース使用量の大半をコンテナとマイクロVMが占めるとしている。これらは論文に記載された設計上の選択肢であり、測定済みのセキュリティ比較ではない。 クライアントの背後では、DSecが管理要求を認証し、健全性と負荷を定期更新した情報を使ってノードを選び、そのノードの`edge`サービスに要求を送る。エッジ側はサンドボックス作成前にローカルの空き容量を確認し、古いクラスタ情報に基づく配置を拒否できる。稼働中のコンテナとVMサンドボックスは「`aether`」というプロキシと、「`chronus`」というシェルセッション用プロセスを使い、コマンド、ファイル操作、出力のストリーミングを行う。FnCallは、あらかじめ作成されたコンテナを通る別経路を使う。クライアントの入口が共通でも、実行方法や障害時の処理の違いがなくなるわけではない。 ## 環境全体を複製せずに構築する 論文は、一般的なエージェント環境を、ベースイメージ、タスク用ワークスペース、独立して更新できるツールキットの3要素に分けている。すべての組み合わせを1つのイメージに焼き込むと、ツールキットを更新するたびに多数のイメージを作り直す必要がある。そこでDSecは、読み取り専用レイヤーを積み重ね、その上に書き込み可能なレイヤーを置く。コンテナでは、改変したDockerランタイムがoverlayfsを使ってこれらを合成する。マイクロVMでは読み取り専用のEROFSレイヤーと書き込み可能なディスクを使い、ファイルシステムとの互換性が必要な場合は異なるブロックストレージ経路を用いる。 著者らは、本番環境のある1週間に、コンテナのベースイメージ11,266種類とコンテナのワークスペース102,171種類を使ったと報告している。こうした多様さがあると、各ノードにイメージ全体を保管しておく利点は小さくなる。DSecは読み取り専用のイメージデータをDeepSeekの分散ファイルシステム3FSに置き、書き込みはローカルストレージに保存し、サンドボックスがイメージを読むときに必要な内容を取得する。コンテナのイメージメタデータはローカルにコピーし、通常のパス検索でリモート読み出しが起きないようにする。マイクロVMではOverlayBDと`ublk`を使い、ローカルキャッシュとともにブロック読み出しや段階的なスナップショットに対応する。 別の10ノード評価では、エージェント評価の負荷の下で8,192個のコンテナを起動した。著者らの報告によると、オンデマンドのEROFS経路は約35分で処理を完了し、イメージをキャッシュなしで事前にすべて取得する方式では60分超かかった。すべてをキャッシュした比較基準も約35分で完了した。ディスク書き込み量は、オンデマンド読み込みで1ノードあたり約700GB、先行取得方式では1,600GB超だった。これらは著者らの試験で比べた構成間の数値であり、別のイメージ群やストレージシステムで同じ効果が得られると示すものではない。 ## アイドル状態のセッションと中断されたロールアウトを利用可能に保つ エージェントのサンドボックスは、ファイル、プロセス、メモリを保持したままコマンド間で待機することがある。著者らが示した1週間のサンプルでは、コンテナとマイクロVMの約90％で、平均CPU使用率が要求容量の5％以下だった。そこでDSecは、メモリの無駄や競合を抑えながら、多数の稼働中セッションを各ノードに配置する。マイクロVMでは読み取り専用ファイルキャッシュを`virtio-pmem`とDAXを使って共有し、DAMONとバルーンによる空きページ報告を使ってゲスト内の利用頻度が低いページを回収する方法を論文で説明している。またLinuxのスケジューリング制御により、遅延に敏感なタスクとベストエフォートの処理を分ける。論文は自らの評価でこれらの仕組みの効果を報告する一方、トレードオフも記載している。たとえば、`virtio-pmem`ではCPU使用量が一時的に増える。 学習の中断にも別の課題がある。GPUジョブがプリエンプトされたとき、ロールアウトには有用な状態が残っている場合がある。著者らによると、DeepSeek-V4.1以降、DSecはエージェントのループをプリエンプト対象のGPUプールの外にあるワーカーコンテナとエージェント用サンドボックスで実行する。学習ジョブはその状態に再接続できる。学習を一時停止するとき、フレームワークからDSecに関連サンドボックスの停止とメモリの回収を要求できる。コンテナは凍結してメモリを回収し、マイクロVMはFirecrackerプロセスの停止前に実行状態をスナップショットへ保存する。その後の操作でサンドボックスを再開する。これはDeepSeekの学習統合について論文が説明する内容であり、一般的な復旧保証を示すものではない。 ## 報告された規模から分かること、分からないこと DeepSeekによると、DSecの1運用単位はCPUノード約160台、約3万コア、約250TBのDRAMで構成される。通常の1日にサンドボックスのインスタンスを約300万件作成し、同時実行数のピークは約38万件、作成速度はこの単位で毎秒5,000件超に達すると報告している。これらは1運用単位について著者が報告した本番環境の数値で、DeepSeek全体の稼働環境を独立に監査した合計値ではない。論文の評価実験は、別の10ノードクラスタで行われた。 報告書は、障害や悪用への対処範囲についても説明している。エージェントが想定外の経路で回答を探す事例や、通常のコマンドがカーネルをクラッシュさせたり、大量の出力でストレージを使い切ったりした事例を著者らが挙げている。緩和策としてAppArmorによるファイル・ソケット制御とサンドボックスごとのネットワーク規則を説明する一方、これらの制御ですべての有害な動作を防げるわけではないと明記している。DSecの公開サービスエンドポイント、外部向けSDKの配布、利用条件、料金は示されていない。論文はシステム設計と著者らの試験条件を記載しているが、サンプルコードを実行する外部向けのアクセス経路は提供していない。 ## 出典・関連資料 - [Huangほか、*DeepSeek Elastic Compute（DSec）：大規模なエージェント学習を支えるサンドボックス基盤*、arXiv:2609.22978v1、2026年9月19日](https://arxiv.org/html/2609.22978)。SDK、実行基盤、アーキテクチャ、環境ストレージ、学習との統合、制約、著者らが行った評価についての主要な技術報告書。第2・3節で要求処理経路、第5・6節で各機構、第8節で試験条件と結果を説明している。運用数値はこの記事で独立検証していない。 - [arXivバージョン1の要旨と投稿記録](https://arxiv.org/abs/2609.22978)。投稿日、31ページの報告書であること、先行する2ページの拡張抄録に限られた審査歴があることを記録している。拡張版論文自体が査読済みであることを示すものではない。 ## Sources - [Huangほか「DeepSeek Elastic Compute（DSec）：大規模なエージェント学習を支えるサンドボックス基盤」、arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — 主要な技術報告書であり、システム設計と運用数値は著者らによる報告である。拡張版v1が査読済みであるとは明記されていない。