#V2EX
### [分享创造] 做了一个 DeepSeek DSec sandbox platform 的开源实现： OpenDsec
这段时间按照 DeepSeek 的 DSec 论文，做了一个 sandbox platform 的开源、自托管实现：OpenDsec。
项目地址： <https://github.com/Kernflux/opendsec>;
先说明一下：这是独立项目，不包含 DeepSeek 代码，也不是 DeepSeek 官方发布或维护的项目。架构和主要设计来自论文；论文没有明确说明、或者我们采用不同方案的地方，都在 SPEC 里单独标注了。
整体架构分为控制面和节点运行时。
控制面里，stateless apiserver 负责认证、配额、调度和请求转发；IAM 用 Raft 保存身份、项目和配额状态；watcher 汇总各节点的健康与负载；每台计算节点运行一个 edge，负责最终准入和 sandbox 生命周期。组件之间走 gRPC + mTLS，sandbox id 里编码所在 edge，因此 apiserver 不需要维护 per-sandbox 路由表。
节点侧目前支持三种后端：
* Firecracker microVM
* Linux container
* 完整 QEMU VM
sandbox 内运行 Aether，负责和 edge 通信；Chronus 维护持久 shell session。exec、文件、HTTP、process、PTY 使用同一套 runtime API。
目前实现的一些能力：
* microVM 冷启动约 0.1 秒，内存快照恢复约 55 ms
* 可以 pause 成内存快照，也可以 fork 正在运行的 VM，并保留内存状态
* 同节点 fork 共享内存页；跨节点时从源节点拉取快照
* 从 OCI registry 导入镜像，不复制数据即可组合 image layers，并支持把 sandbox 修改 pack 成新镜像
* 网络默认拒绝，可按 domain、CIDR、port 放行
* 多级 project、quota、审计日志和短期可撤销 token
* 批量 pause/resume、节点重启后重新接管运行中的 sandbox
* 提供 E2B-compatible gateway，已有 E2B SDK 客户端可以直接接入
* 支持离线安装，适合内网或 air-gapped 环境
在我们的硬件上，一台 384 线程节点做过单批 5,120 个 microVM；两节点集群做过单批 8,192 个 container，未出现创建失败。这些都是 OpenDsec 在自有硬件上的实测，不是论文中的数字。
项目目前在一个小型生产集群上运行。代码、quickstart、架构文档和各项测量都放在仓库里。欢迎对 sandbox、Firecracker、agentic RL 基础设施感兴趣的朋友试用，也很想听听大家对架构和实现取舍的意见。
https://www.v2ex.com/t/1252637#reply0
资讯同步
npub195…pwpxu
2026-10-28 12:14:20 UTC
Author Public Key
npub195q4fc2qx05y3dzg49cny2lm7nsy52wrwuqjac844dnqnx6k7xks3pwpxuPublished at
2026-10-28 12:14:20 UTCEvent JSON
{
"id": "140d385966c1b72342920cb4a3edeaf52690965e8f2787ce61daebb81edae9a7",
"pubkey": "2d0154e14033e848b448a971322bfbf4e04a29c377012ee0f5ab66099b56f1ad",
"created_at": 1793189660,
"kind": 1,
"tags": [
[
"t",
"v2ex"
]
],
"content": "#V2EX\n### [分享创造] 做了一个 DeepSeek DSec sandbox platform 的开源实现： OpenDsec\n\n这段时间按照 DeepSeek 的 DSec 论文，做了一个 sandbox platform 的开源、自托管实现：OpenDsec。\n\n项目地址： \u003chttps://github.com/Kernflux/opendsec\u003e\n\n先说明一下：这是独立项目，不包含 DeepSeek 代码，也不是 DeepSeek 官方发布或维护的项目。架构和主要设计来自论文；论文没有明确说明、或者我们采用不同方案的地方，都在 SPEC 里单独标注了。\n\n整体架构分为控制面和节点运行时。\n\n控制面里，stateless apiserver 负责认证、配额、调度和请求转发；IAM 用 Raft 保存身份、项目和配额状态；watcher 汇总各节点的健康与负载；每台计算节点运行一个 edge，负责最终准入和 sandbox 生命周期。组件之间走 gRPC + mTLS，sandbox id 里编码所在 edge，因此 apiserver 不需要维护 per-sandbox 路由表。\n\n节点侧目前支持三种后端：\n\n* Firecracker microVM\n* Linux container\n* 完整 QEMU VM\n\nsandbox 内运行 Aether，负责和 edge 通信；Chronus 维护持久 shell session。exec、文件、HTTP、process、PTY 使用同一套 runtime API。\n\n目前实现的一些能力：\n\n* microVM 冷启动约 0.1 秒，内存快照恢复约 55 ms\n* 可以 pause 成内存快照，也可以 fork 正在运行的 VM，并保留内存状态\n* 同节点 fork 共享内存页；跨节点时从源节点拉取快照\n* 从 OCI registry 导入镜像，不复制数据即可组合 image layers，并支持把 sandbox 修改 pack 成新镜像\n* 网络默认拒绝，可按 domain、CIDR、port 放行\n* 多级 project、quota、审计日志和短期可撤销 token\n* 批量 pause/resume、节点重启后重新接管运行中的 sandbox\n* 提供 E2B-compatible gateway，已有 E2B SDK 客户端可以直接接入\n* 支持离线安装，适合内网或 air-gapped 环境\n\n在我们的硬件上，一台 384 线程节点做过单批 5,120 个 microVM；两节点集群做过单批 8,192 个 container，未出现创建失败。这些都是 OpenDsec 在自有硬件上的实测，不是论文中的数字。\n\n项目目前在一个小型生产集群上运行。代码、quickstart、架构文档和各项测量都放在仓库里。欢迎对 sandbox、Firecracker、agentic RL 基础设施感兴趣的朋友试用，也很想听听大家对架构和实现取舍的意见。\nhttps://www.v2ex.com/t/1252637#reply0",
"sig": "117957c6c6f8a423bfb0c697db6c27215e1d31b35fddbefc23dfc1dedf7354e6281ca2f772c999de86ca1cd69cf6d4275128a9eba27e9ccb00c49d2ee3942b8b"
}