LLMの性能向上は、単にモデルを大きくするだけでは進みません。いまは、コードリポジトリを読み、ツールを呼び出し、コマンドを実行し、外部サービスとやり取りするような「agentic training」が重要になってきています。今回のarXiv論文は、その学習と評価を支える基盤を、かなり本気で作り込んだ話です。DeepSeekが公開した「DSec」は、そうした用途に向いた実運用のサンドボックス基盤で、単なる実験用の仕組みではなく、かなり大規模な現場を前提に設計されています。
論文が最初に言っているのは、LLMの大規模なagentic trainingやevaluationでは、モデルが安全な隔離環境の中でリポジトリを見たり、ツールを呼んだり、コマンドを実行したり、専用サービスと対話したりする必要がある、ということだ。問題は、こうした作業が毎回似た形にはならない点にある。あるときは軽いFnCallで足りるが、別のときはcontainerが必要で、さらに重い隔離が必要ならmicroVMやfull-VMが要る。しかも長い対話のあいだ状態を保たなければならず、画像データも巨大なコーパスから必要な分だけ引くことになる。つまり、ひとつの固定的なsandbox runtimeではなく、状況に応じて形を変えられる実行基盤が要る、というのが出発点だ。
DSecはそのために作られたproduction sandbox platformで、FnCall、container、microVM、full-VMを共通のSDKから扱えるようにしている。単に複数の実行方式を並べただけではなく、クラスタ全体での配置とライフサイクル管理を調停し、環境を独立にバージョン管理されたlayerの組み合わせとして構成する。さらに、memory sharing、reclamation、CPU schedulingを組み合わせて高密度に詰め込み、画像データはクラスタ全体の分散ファイルシステムであるFire-Flyer File System、つまり3FSから必要なときに読み込む。
論文で特に目を引くのは、これがRL frameworkと共同設計されている点だ。stateful rollout executionをpreemptible GPU trainingから切り離し、学習とsandboxの寿命を連動させて、rolloutの状態を保ったまま idle な資源だけを回収する。加えて、reward hackingのようなエージェントの不正挙動も抑える設計だという。規模感もかなり大きく、1つのproduction-scale unitは約160ノードにまたがり、1日あたり約300万個のsandboxを処理する。productionでは38万以上の同時sandboxを支え、1秒あたり5000件超のsandbox作成を維持している。評価と運用の経験としては、環境セットアップと画像配布のオーバーヘッドを減らし、メモリ効率を上げ、高密度なovercommit下でも遅延に敏感な性能を保てたとしている。
この論文で面白いのは、AIモデルの話なのに、主役がモデルではなくインフラになっていることだと思う。昔なら、sandboxは脇役だった。今は違う。エージェント型の学習では、モデルが1回応答するだけでは終わらず、何十回も環境を触り、そのたびに状態が残り、ツール実行のたびに隔離レベルも変わる。すると、学習精度の勝負が、モデルのアーキテクチャだけでなく、どれだけ速く安全に環境を立ち上げ、どれだけ無駄なく回せるかに移っていく。DSecはそこを真正面から取りにいっている。
ここで重要なのは、柔らかい抽象化と硬い制御を同時にやっている点だ。SDKから見ると統一されていて使いやすい。一方で裏側では、FnCallからfull-VMまでを並べ、しかも状態を持つ長時間実行を壊さないようにする。普通、抽象化を強くすると性能か安全性のどちらかが削れやすい。DSecは、その両方を落としにくくするために、レイヤー化、memory sharing、reclamation、CPU scheduling、3FSからのオンデマンド読込をまとめて使っている。これは単なる「便利なプラットフォーム」ではなく、性能要求と隔離要求がぶつかる場所を設計でならした例だと思う。
300万 sandbox/日、38万同時、5000件/秒という数値は、派手さを狙った飾りではないはずだ。agentic trainingが本当に大規模化すると、ボトルネックはGPUそのものより、周辺で発生する小さな実行単位の洪水になる。1回の学習ステップの裏で、コードを取りに行く、コンテナを立てる、権限の違う環境を切り替える、画像を引く、といった処理が雪崩のように起きる。そこで遅いのは困るし、メモリを食うだけでも困る。DSecの数字は、そういう世界で初めて「このくらいの密度で回せる」と言える水準を示している。
ただし、ここで気をつけたいのは、こうした基盤は一度作れば終わりではないことだと思う。状態を保持しながら idle 資源を回収する、というのは理屈ではきれいでも、実際には例外が多い。長時間のrolloutが途中で止まったり、エージェントが想定外の挙動をしたり、隔離レベルの違うworkloadが混在したりすると、運用はすぐ複雑になる。DSecがproduction向けとして語られているのは、その複雑さに耐える必要があるからだろう。研究用のデモではなく、毎日300万 sandboxをさばく現場で使う前提だからこそ、設計の細部が効いてくる。
論文がreward hackingへの対策に触れているのも、地味だが重要だ。agentic trainingでは、モデルが「タスクを解く」より先に「報酬を抜け道で稼ぐ」方向へ寄ることがある。しかもサンドボックスは、自由度が高いほどそうした抜け道が生まれやすい。つまり、環境を柔軟にすると学習は回しやすくなるが、同時に不正も起きやすくなる。ここに、ただの実行基盤ではない難しさがある。
DSecがRL frameworkとco-designされているのは、その問題をインフラ側から抑えるためだと読める。訓練と実行を別々に最適化するのではなく、sandboxの生存期間、rolloutの状態、GPUのプリエンプションを一体で扱うことで、うまくいけば資源効率と学習の整合性を両立できる。逆に言えば、この領域では「速い」「安い」だけでは足りない。正しく学習できること、途中状態を壊さないこと、異常なふるまいを広げないことまで含めて基盤の仕事になる。今後、エージェントがより自律的になるほど、この手の仕組みは前面に出てくるはずだ。モデルの能力向上を支える裏方としてではなく、能力の出方そのものを決める土台として。
参考: DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale
