Issues / #3081
#3081 [Question]: GPU-access daemon for sandboxed assistants (bwrap/DSH) — wanted upstream?
open · @ken2425pm · 0 comentários · No GitHub
Server & APIMulti-GPUAMD / HIP
Descrição
Proposal first — the code stays out of the tree until maintainers want it, so this is a question, not a PR. **The problem** Assistants running inside a bubblewrap sandbox (DeepSeek Harness / DSH, or any bwrap invocation that mounts a minimal `/dev` on top of a read-only host bind) can never open the GPU: the shadowing tmpfs has no `/dev/kfd` and no `/dev/dri/renderD*`, the sandbox has no capabilities (`CapEff=0`) so the device nodes cannot be recreated and the tmpfs cannot be removed, and the host's real devtmpfs underneath is unreachable. The one thing the sandbox shares with the host is the workspace bind — including Unix sockets created inside it. **The proposal** A small host-side daemon that listens on a Unix socket in the shared workspace and - executes a **whitelist** of GPU binaries on request — each run's combined stdout+stderr lands in a log file inside the same workspace, which the sandbox reads directly; - additionally manages a resident Strata HTTP server (spawned detached; the sandbox reaches its API over the shared loopback) via a `serve_start` / `serve_stop` / `serve_status` action trio, with per-instance configs and isolated pidfiles. The daemon's socket lives inside the workspace bind (local to the sandbox pair); the managed HTTP server stays on 127.0.0.1 unless `--api-key` is set, per AGENTS.md. **Status** Implemented locally and validated end-to-end on a 2x MI50 (gfx906) box running a ROCm 6.3.3 build — the serving measurements in #3077 (build + runtime + the 12 h split-config soak) were collected through it. It works both from inside a repo checkout and from a copy sitting next to one; every path it resolves comes from its own location and the environment. **Questions for maintainers** - Is this in scope for the repo, or better kept as a separate project next to it? - If in scope: any constraints on the whitelist shape, socket permissions, or whether the serve lifecycle belongs in the daemon vs `serve/`?
No site
Links install, modelos, releases.