> Agent 本身也是一个不完全可信的 compute tenant

6 hours ago

> Agent 本身也是一个不完全可信的 compute tenant。

---

# 3. API Server

它不是传统的 application server。

它最重要的职责是：

> 成为 trusted training world 和 untrusted sandbox world 之间的唯一入口。

也就是说：


GPU Training Cluster
        │
        │ trusted
        ▼
    API Server
        │
        │ untrusted
        ▼
     Sandbox

论文明确要求两侧 network isolation。

而且：

> API Server 本身不保存 per-sandbox state。

这是一个非常重要的 distributed-system design。

因为：


API Server 1
API Server 2
API Server 3
API Server 4

任何一个都可以处理 request。

Sandbox ID 中已经编码了 owner edge，所以可以直接路由过去。([arXiv][1])

---

# 4. Placement Engine

这个其实很像：


Kubernetes Scheduler

但 DSec 没有直接照搬 Kubernetes。

它使用：

> Power-of-k Choices

比如：


1000 nodes

随机挑 5 个：

Node 17
Node 291
Node 438
Node 721
Node 901

load:

17  → 91%
291 → 72%
438 → 65%
721 → 81%
901 → 55%

选择 Node 901

而不是维护一个巨大的全局精确排序。

原因是：

> Agent rollout 的 burst 太大。

论文还做了一个非常聪明的补偿：


Watcher snapshot
      +
local recent placement
      ↓
local placement view

因为 Watcher 的状态是周期更新的。

否则：


Watcher:
Node A = 50%

Placement 1 → A
Placement 2 → A
Placement 3 → A
...

就会产生 herd。

所以：


global approximate state
+
local recent decisions
+
Edge final admission

三层共同保证。

([arXiv][1])

---

# 5. Watcher

Watcher 是：


Cluster → telemetry

它不断收集：


node health
sandbox count
backend type
user
task
resource state

然后 Placement Engine 使用。

但它有一个非常重要的设计：

> Watcher 不保存真正的 execution state。

所以：


Watcher crash
   ↓
重新 poll Edge
   ↓
重新构建 fleet view

无需恢复复杂状态。([arXiv][1])

这是一种非常典型的：

> control plane statelessness

---

# 第四课：四种 Sandbox 为什么一定要同时存在？

这是 DSec 第二个非常重要的思想。

不是：


Container = Sandbox

而是：


                  isolation
                     ↑
                     │
             Full VM │
                     │
             MicroVM │
                     │
             Container
                     │
              FnCall │
                     │
                     └────────────→ speed

---

## FnCall

适合：


OJ
compile
utility code
serverless
GPU kernel

特点：


最快
最轻
最低 isolation

甚至不是每次创建 sandbox。

而是：


pre-created container
      │
      ├── task 1
      ├── task 2
      ├── task 3
      └── task 4

论文甚至支持 GPU FnCall。

---

# Container

主要：


SWE
tool use
general coding

优点：


fast startup
high density
Linux compatibility

问题：

> shared host kernel。

所以安全边界没有 VM 强。([arXiv][1])

---

# MicroVM

这里主要用：

Firecracker

适合：


security
computer use
stronger isolation

它拥有独立 kernel：


Host
 │
 ├── VM1
 │    └── kernel1
 │
 ├── VM2
 │    └── kernel2
 │
 └── VM3
      └── kernel3

代价是：


memory ↑
startup ↑

---

# Full VM

例如：


Android
GUI
graphics
COTS OS

需要完整操作系统的时候才上。

论文明确举了 Android VM / QEMU、GUI、graphics rendering 这些场景。([arXiv][1])

---

# 于是 DSec 的核心抽象就出来了

它不是：

> “把所有任务都 containerize。”

而是：

> 根据 workload 在 isolation / performance / OS functionality / resource overhead 之间动态选择执行后端。

这也是为什么叫：

Elastic Compute

而不是：

Container Service

---

# 第五课：现在来到 DSec 最漂亮的地方——Composable Environment

这个我建议你重点理解。

传统方式：


Ubuntu
+
Python
+
repo-A
+
DeepSeek Harness
+
toolkit

打成：


BIG_IMAGE_A

另一个：


Ubuntu
+
Python
+
repo-B
+
DeepSeek Harness

再打成：


BIG_IMAGE_B

问题：


repo-A changed
      ↓
rebuild image A

repo-B unchanged
      ↓
still has to rebuild B

---

# DSec 把环境拆成 Layer


             Sandbox
                │
        ┌───────┴───────┐
        │               │
     read-only        writable
        │               │
        ▼               ▼
     Toolkit 2       upperdir
        │
     Toolkit 1
        │
     Workspace
        │
     Base OS

也就是：


Base Image
    +
Workspace
    +
Toolkit
    +
Writable layer

每一层独立 version。

例如：


ubuntu:v1
python:v3
repo-A:v17
harness:v42

可以组合：


ubuntu:v1
+
python:v3
+
repo-A:v17
+
harness:v42

另一个 task：