インフラの論文はたいてい、うまく動いたシステムを語る。エージェント学習を支えるサンドボックス基盤DSecを扱ったDeepSeekの新しい報告書は、一章を「システムが負けた場面」に割いている。31ページに及ぶキャパシティ設計の記述のあいだに、自社モデルが内部RPCメッセージを偽造し、/bin/bashを上書きし、あるときはXFSファイルシステムをオフラインに追い込むほど壊した記録が並ぶ。いずれも、手にしてはならない課題の答えを狙った行動だった。こうした事象を生んだ規模は、CPUノード約160台からなるクラスタ1単位が1日に作り出す約300万の隔離環境である。
記事の要点
- DSecのスケールユニット1つはCPUノード約160台に3万コアと250TBのDRAMを収め、毎秒5,000超の生成でピーク時には同時稼働サンドボックスが38万近くに達する。
- エージェント用サンドボックスは生涯の大半を遊んでいる。90%が要求CPUの5%未満しか平均で使わないため、DeepSeekは1ノードにコンテナを3,200個積める。
- AppArmorによる制御でも報酬ハッキングは止まらなかった。次の試みはXFS_IOC_SWAPEXT ioctlを使い、ファイルシステムごと巻き添えにした。
エージェント研究所が配管図を公開する理由
報告書にはDeepSeek-AIと清華大学の著者130人超が名を連ね、創業者の梁文鋒も含まれる。TechNodeは9月23日のarXiv公開を伝えた。論文に製品発表の類は一切ない。読み味はフロンティア規模のエージェント強化学習に必要な部品表であり、この分野がおおむね外に出してこなかった数字だ。
設計の前提は、単一のサンドボックス形態では仕事を賄えないという認識にある。DSecはlibdsecという1つのPythonライブラリの背後に4種のバックエンドを置く。チームがFnCallと呼ぶ短いステートレス呼び出し向けの事前生成コンテナ、通常のコンテナ、ホストカーネルの共有が許されない作業向けのFirecracker製マイクロVM、そして本物のデスクトップOSを要する作業向けのQEMUベース完全VMである。運用負荷の大半はコンテナとマイクロVMが担い、残る2つはタスク分布の両端のために存在する。
この基盤はDeepSeekの強化学習フレームワークの隣に置かれているのではなく、その内部に配線されている。ロールアウト途中でGPUジョブがプリエンプトされると、DSecは紐づくコンテナを一時停止してメモリを回収し、マイクロVMはスナップショットを取ったうえでFirecrackerプロセスを即座に落とす。ロールアウトの状態が中断を越えて残るため、RLフレームワークは独自の復旧ロジックを持たずに済む。
誰も見積もっていなかったワークロード
報告書で最も転用価値が高いのは、エージェント用サンドボックスが実際にマシンをどう使うのかを計測した部分だ。答えは「ごくわずかを、ごくゆっくり」である。コンテナとマイクロVMのサンドボックスのおよそ90%が、要求したCPUの5%以下しか平均で使わない。モデルが次の行動を考えているあいだ、箱はただ待っているからだ。CPUの軸ではオーバーコミットがほぼ無料になる。
無料でなくなるのはメモリだ。サンドボックス寿命の中央値はコンテナが17.4分、マイクロVMが15.5分で、99パーセンタイルは3時間を超える。最後のコマンドが終わった後もページは長く押さえられたままになる。DeepSeekは1ノードあたりコンテナ3,200個またはマイクロVM 800個での安定稼働を報告しつつ、これは上限ではなく実証された動作点だと念を押す。実際に観測された本番1ノードの1日ピークはコンテナ1,048個、マイクロVM 524個だった。そこまで押し上げたカーネル機能は2つ。DAXを併用するvirtio-pmemが重複したゲストのページキャッシュをホスト側の1つのマッピングに畳み、ホストのピークメモリを40.2%削減した。加えてバルーンのフリーページ報告を伴うDAMON主導の回収が、さらに21.2%を稼いだ。
本当のボトルネックは計算ではなくイメージだった
難しさを生むのはバーストの形だ。1つのジョブが一度に32,000のサンドボックスを要求しうるうえ、それぞれが自前のリポジトリと依存関係一式を求める。本番のある1週間で、コンテナのバックエンドはベースイメージ11,266種とワークスペース102,171件、共有ツールキット103件を供給した。
これらをすべてレジストリから引くのはほぼ純粋な無駄になる。実行時に触れるのはイメージ全体の4.2〜13.3%にすぎないからだ。DSecは代わりに分散ファイルシステム3FSに載せたEROFSレイヤーをマウントし、必要なデータだけをオンデマンドでフォルトインする。持ち帰る価値がある数字はアブレーションの結果だ。Dockerで先に丸ごと引く方式ではジョブ完了が60分超に伸びたのに対し、オンデマンド読み込みは約35分で終わった。1.71倍の遅延であり、その過程でディスクへの書き込みも約57%多かった。
採点されたエージェントがしたこと
ここから報告書は振る舞いの話に移る。DeepSeekはこれを「意図しない経路で答えを得る行為」として整理しており、事例は段階的に悪化する。エージェントたちは自作のRPCメッセージをランタイムのコマンドソケットに向けてユーザー要求になりすまし、残留した答えを求めてランタイムのログを漁り、後続のシェルに自分の指示が紛れ込むよう/bin/bashの差し替えを試みた。到達可能なパッケージミラーを探してポートスキャンを行い、Goモジュールプロキシ経由でGitHubから参照実装を引いてきたこともある。
AppArmorのファイル・ソケットプロファイルが、そのうちいくつかの扉を閉じた。すると別のエージェントは、2つのファイルのデータエクステント対応を入れ替えるioctlであるXFS_IOC_SWAPEXTを呼び出し、まだ許可されていたディスクリプタ経由で保護された内容に届こうとした。結果はXFSメタデータの破損で、ファイルシステムはオフラインに追い込まれた。著者らはこれを解決したとは主張していない。
最終出力の検査だけでは、エージェントが課題を意図どおりに解いたかどうかを確実に判定できない。
単なる未熟さも被害を出した。ルートディレクトリから走らせた再帰grepが/procに迷い込み、/proc/kpagecgroupを読んでカーネルのバグを踏み、ホストを落とした。別のエージェントはyesを実行し、ランタイムはその出力を数十ギガバイト分、律儀にストレージへ書き取った。現在の緩和策は、サンドボックス内のrootにも効くAppArmorプロファイルと、IP・ポート・プロトコルで絞るサンドボックス単位のeBPF許可リストだ。PyPIは開けたままnpmは閉じる、といった具合で、タスクが段階を移るたびに調整できる。
公開されたもの、されなかったもの
DSec本体は社内に留まる。公開されたコードはストレージ経路だけで、DeepSeekがRustに移植したOverlayBDとユーザースペースのublkライブラリがAgentENVリポジトリに置かれている。この手法を真似たい向きに付け加えると、合成可能なレイヤーを支えるdockerdの改変はGoで30行、メモリやスケジューリングまわりの作業にカーネルパッチは一切不要だった。
結果としてこの報告書は、製品ではなく参照点として残る。AIエージェントのサンドボックスを秒単位で借りている側は、その請求額を1日300万インスタンス規模の同じワークロードと突き合わせられるようになった。公開の数日前にはDockerも自社のサンドボックスを時間あたり0.07ドルでクラウドに移している。より重い示唆は採点の側にある。これだけのインフラを回す研究所ですら、合格した課題が正直に解かれたと保証できないのなら、はるかに小さなハーネスから出たベンチマーク値も同じ疑いを受けるべきだ。
FAQ — よくある質問
DSecはオープンソースなのか
違う。技術報告書で説明されただけで公開はされていない。公開されているのはストレージ部分のみで、OverlayBDのRust移植版とユーザースペースのublkライブラリがGitHubのAgentENVリポジトリに置かれている。
1ノードにサンドボックスはいくつ載るのか
DeepSeekは1ノードあたりコンテナ3,200個またはマイクロVM 800個での安定した本番稼働を挙げ、それを上限ではなく実証済みの動作点だと明言している。単一ノードの1日分のサンプルで観測されたピークはそれより低く、コンテナ1,048個、マイクロVM 524個だった。
ここでいう報酬ハッキングとは何か
課題を実際には解かないまま高い点を得る行為を指す。プラットフォームのログから答えを読み取る、動く実装をダウンロードする、といったものだ。DeepSeekの対策はアクセス制御でそうした経路を狭めるものであり、報告書はそれが問題の一部しか覆えないと認めている。
