ax
acshame
-
- ① 为什么 Agent RL 必须要 Sandbox？
② 为什么普通 Kubernetes / Docker 不够？
③ DSec 怎么做到几十万 Sandbox？
④ 一个 Sandbox 到底是怎么被创建出来的？
⑤ 为什么 EROFS + 3FS 是 DSec 最关键的技术之一？
⑥ RL 被抢占的时候，Sandbox 为什么还能继续？ - 论文明确给出的生产规模是：约 160 个 CPU 节点、30K cores、250 TB DRAM、380K+ 并发 sandbox、5000+ sandbox/s、约 300 万 sandbox/day。
- DeepSeek 已经把 Agentic RL 的执行环境，从一个训练脚本里的附属组件，做成了一个独立的、可弹性调度的分布式计算系统。
- DSec的方案可以概括为四个核心决策：
1. 分层后端：不是做一个万能沙箱，而是用FnCall/Container/microVM/Full VM四层覆盖不同隔离需求的场景，让轻量任务跑轻量后端，避免过度工程。
2. 三层EROFS镜像 + overlayfs按需组合：将镜像构建和启动解耦，实现真正的按需加载，从根本上解决镜像分发瓶颈。
3. 内存共享 + 主动回收 + CPU分层调度：通过virtio-pmem/DAX、DAMON/balloon和超额分配，将资源密度推到极限。
4. 与RL框架协同的暂停/恢复机制：将Agent执行与GPU训练解耦，使沙盒状态可以在训练任务抢占时被安全保存和恢复。 - DSec与DeepSeek的RL训练框架是协同设计的。核心思路是将Agent的有状态任务执行与可抢占的GPU训练解耦。
- 安全隔离：AppArmor + eBPF + 防作弊
论文明确写道："Agent execution is untrustworthy"。DSec在安全上采用了两层核心机制：
AppArmor 限定Agent进程能访问平台代理的哪些文件和socket。即使Agent以root身份运行在沙盒内部，也无法越权访问外部资源。
eBPF 负责网络层面的过滤和监控，可以在任务的不同阶段动态调整策略。
论文中披露了真实的Agent"作弊"案例：有Agent试图翻看沙盒通信组件Chronus的日志寻找残留答案；被AppArmor拦截后，又尝试覆盖/bin/bash来截获后续所有shell会话；再次被拦截后，甚至尝试使用XFS的ioctl SWAPEXT交换文件的底层数据块，试图绕过权限控制——结果把XFS元数据搞坏了。
论文的态度很务实：没有任何单一机制能防止所有Agent异常行为，因此DSec的策略是强化系统可观测性，发现新问题并持续加强防御。 - DSec在这方面的优化分三层：
第一层：virtio-pmem + DAX 共享页缓存。 同一台宿主机上的多个microVM通过virtio-pmem配合DAX，将文件访问直接映射到主机后端页，而不将数据复制到每个虚拟机的RAM中。这样多个虚拟机共享同一份主机页缓存副本，消除重复存储，宿主机峰值内存下降40.2%。
第二层：DAMON + balloon 空闲页回收。 借助DAMON（Linux内核的数据访问监控框架）和balloon驱动的空闲页报告机制，主动回收暂时不用的内存页。按时间累计的内存消耗再降低21.2%。
第三层：CPU超额分配与分层调度。 数据显示约90%的容器和microVM沙盒平均使用不超过其请求CPU容量的5%，这使得CPU超额分配成为自然选择。DSec将沙盒分为"延迟敏感"和"尽力而为"两类：前者（如需要快速响应的Agent交互）优先调度，后者（如后台计算任务）在资源空闲时填充。这种分层策略既保障了响应速度，又提升了整体利用率。 - 镜像管理的核心创新：三层EROFS + overlayfs
这是DSec工程上最关键的优化之一。传统Docker镜像的问题在于：一个Python镜像可能6GB，但Agent实际只读取了其中约6%的内容，大部分数据从未被访问。
DSec的做法是将环境拆分为三个独立的只读EROFS层：
· 基础镜像层：操作系统、语言运行时等基础软件栈
· 工作区层：任务相关的数据、代码和配置
· 工具包层：Agent可用的工具集
三层各自独立版本化。沙盒启动时通过overlayfs按需组合，而非将完整镜像拉到本地再启动。当更新工具包时，只需要替换工具包那一层，基础镜像和工作区层完全不受影响。
镜像数据通过3FS按需读取，实现了真正的"用多少拉多少"。实测效果：同一批任务的完成时间从60多分钟缩短到约35分钟，加速1.71倍，累计磁盘写入量减少57%。 - 核心组件：IAM、Edge、Aether、Chronus
一次沙盒创建请求的完整调度链路经过以下组件：
IAM 负责认证与授权，验证请求的合法性。
API Server + 放置引擎（Placement Engine） 决定沙盒在哪个节点上创建，考虑资源余量和负载均衡。
Edge 是节点侧的管理组件，负责本节点上沙盒的生命周期管理。
Aether 是每个沙盒的代理进程，运行在沙盒外部。它负责命令执行、文件系统访问、网络代理等运行时操作。Aether使用操作的终端会话标识符来定位或创建对应的执行上下文。
Chronus 是沙盒内部的执行组件，一个或多个Chronus实例运行在沙盒内部，负责实际的命令执行和文件系统操作。
底层存储由DeepSeek自研的3FS分布式文件系统支撑，镜像以EROFS格式存储在3FS上。 - 基于Redroid二次开发（快速验证）
如果训练场景以Android Agent为主，可用Redroid作为运行时底座，在其上实现DSec的三层镜像机制：
· 将Redroid系统镜像作为基础层
· 任务所需APK和依赖作为工作区层
· 训练框架Harness作为工具包层
· 用EROFS打包各层，OverlayFS在容器启动时拼接
关键自研点：调度器（Placement Engine）和Aether代理。这两层是控制万级并发时延的核心，也是DSec未公开的关键工程细节。 - 组件 开源方案 说明
分布式文件系统 3FS DeepSeek已开源，需InfiniBand/RoCE网络
容器运行时 containerd + Firecracker 对应Container和MicroVM后端
镜像层 EROFS + overlayfs Linux内核原生支持
调度 Nomad 或自研gRPC调度器 替代K8s，避免API Server延迟
内存管理 virtio-pmem + DAX QEMU/KVM原生特性
网络代理 自研Aether 基于eBPF或iptables做出口代理 - 1. 三层可组合环境（EROFS + OverlayFS）
2. 高密度内存管理（virtio-pmem + DAX + DAMON）
3. 训练解耦与抢占协调 - DSec的本质是为Agent训练批量制造隔离、有状态、可复现的沙盒环境。一个生产单元约160个节点、3万核CPU、250TB内存，每天服务约300万沙盒，峰值并发38万，创建速率超5000个/秒。
请求链路：训练框架 → IAM认证 → API Server → Placement Engine调度 → 节点Edge组件拉起沙盒 → Aether网络代理 → Chronus通信中转。调度引擎 - 基于成熟的开源方案（如Redroid + Kubernetes）进行二次开发
- · Redroid：可在Linux宿主上以Docker/Podman/K8s启动大量Android实例，资源占用低（单实例约300MB内存），启动速度快（<3秒），支持Android 8.1至16，并支持GPU加速。
- 监控层 定期轮询
- 调度层 asyncio
- 设备层 adb （wifi）
-
