on-demand image loading
composable layers
memory optimization
CPU QoS
而 **RL framework integration 本身不在第 8 节实验范围内**。论文报告的是基础设施效果；比如 8,192-container burst 中，on-demand EROFS 最终约 35 分钟完成，而 eager Docker 超过 60 分钟，约 **1.71× slowdown**；EROFS 相比 tar provisioning 约 **1.76× speedup**。([arXiv][1])
所以不要把：
> “DSEC 很强”
错误理解成：
> “论文证明 DSEC 直接让模型 IQ 提升了 X%。”
它真正证明的是：
> 没有这种 infrastructure，Agentic RL 在 DeepSeek 这种规模上很难经济、稳定地运行。
---
# 接下来我建议我们这样学
如果你真的想达到你说的 **“完全搞懂 DSec 的方案实现”**，下一步我不建议继续泛泛讲论文。
我们直接进入 **Implementation Deep Dive**。
我会从一条真实请求开始，带你逐行模拟：
libdsec.run_container()
↓
API Server
↓
IAM
↓
Placement Engine
↓
Watcher
↓
Edge
↓
Aether
↓
Chronus
↓
Docker / Firecracker
↓
OverlayFS / EROFS
↓
3FS
然后我们专门把下面 **4 条链路画透**：
### A. Sandbox Creation Path
create request
→ scheduling
→ admission
→ mount
→ process
→ ready
### B. Data Path
LLM
→ shell
→ chronus
→ filesystem
→ EROFS
→ 3FS
→ page cache
### C. Memory Path
guest RAM
→ page cache
→ DAX
→ DAMON
→ balloon
→ reclaim
### D. RL Preemption Path
GPU trainer
→ preempt
→ worker
→ sandbox pause
→ memory reclaim
→ GPU resume
→ sandbox resume
→ rollout continue
**尤其是 A + B，我认为是你现在最值得继续啃的。**因为一旦你把这两条 data/control path 真正搞懂，Dsec 的整个架构基本就“透了”。
另外，我已经找到论文中明确提到的一个很有价值的开源实现：**OverlayBD / ublk 的 storage 部分已经以 AgentENV 的形式开源**，这意味着我们下一步甚至可以从论文直接下沉到代码级别，而不是停留在 paper reading。([arXiv][1])
如果按这个路线继续，我下一轮可以直接带你做 **「DSEC 源码级架构拆解：从
libdsec.create() 到一个 sandbox 真正跑起来，中间每个 RPC、进程、mount、filesystem 和 state 到底发生了什么」**。[1]: https://arxiv.org/html/2609.22978v1 "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale"
