The GPU Isolation Fault Line: gVisor, Kata, and Edera Face Off Over Your Sandbox Pool

In June 2026, an engineer training models on rented H100s chased a cluster of crashes for days and landed on two clean findings: the crashes were a KV-cache memory floor, and CUDA MPS — the feature meant to let multiple processes share one GPU — could not work on that platform at all. Every MPS call failed silently through the sandbox runtime and fell back to time-slicing. The platform was Modal. The runtime was gVisor, proxying CUDA through nvproxy.

That is the GPU isolation fault line in one story. The moment two tenants' untrusted code shares one graphics card, the sandbox runtime — not the scheduler, not the orchestrator — decides the blast radius. And in 2026 the industry has settled on three distinct answers: gVisor intercepts CUDA calls in a user-space kernel, Kata Containers hands the whole GPU to a lightweight virtual machine, and Edera isolates every workload behind its own Type-1 hypervisor while still sharing the card. If you run — or plan to run — a GPU node pool for AI-agent sandboxes on machines you own, here is the verdict up front:

The one-line recommendation: default a small owned-GPU sandbox pool to gVisor and nvproxy for density, reach for Kata passthrough when a workload needs the CUDA features nvproxy cannot proxy, and keep Edera in a pilot until it earns production trust. The rest of this post prices each of those three lines.

gVisor and nvproxy: share the card, proxy the calls​

gVisor's runsc runtime replaces the host kernel with a user-space kernel that speaks Linux to the container and a narrow set of host syscalls to the machine. GPUs break that model — CUDA drivers need ioctls gVisor never implemented — so the nvproxy sub-component forwards the GPU's kernel-mode driver calls to the host driver. The sandboxed application runs unmodified and talks to what looks like a normal NVIDIA device. Modal's engineering blog describes exactly this architecture carrying its serverless GPUs, noting that the narrowed syscall surface automatically blunted exploits like CVE-2026-31431 ("CopyFail"), and upstream gVisor documents GPU support via nvproxy front and center. Google's GKE agent-sandbox offering is built on the same foundation, which is about as strong a production signal as a sandbox runtime gets.

The price list for that density is specific and worth reading twice, because every item is a workload that will page you:

• No CUDA MPS. The June 2026 Modal investigation proved MPS hits "operation not supported" under nvproxy (CUDA error 805) and degrades silently to time-slicing. If your sharing plan assumed MPS, it does not survive contact with gVisor.
• No MIG, and a narrow card list. Practitioners report nvproxy covering T4, A100, A10G, L4, and H100-class cards with no multi-instance-GPU partitioning — sharing is time-slicing or nothing.
• Exact host-driver match. The installed runsc must match the host NVIDIA driver version, which turns every driver upgrade into a lockstep runtime upgrade across the node pool.
• No profiler interface. Profiling tools that need the driver interface (ncu, for example) see the same card differently on every Modal GPU because the runtime — identical everywhere — simply does not expose it.

None of that disqualifies nvproxy for its best workload: untrusted inference code packed densely onto a few owned cards, where sub-second cold starts matter more than profiler access. The ecosystem keeps investing in exactly that shape — Beam Cloud's Beta9 wires nvproxy together with cuda-checkpoint for GPU checkpoint and restore, and gVisor's August 2026 release added CUDA coredump support plus a new supported driver (610.57.04), a sign the proxy is still gaining, not losing, coverage.

Kata Containers: own the card, keep the VM boundary​

Kata answers the same problem from the opposite end. Instead of emulating the kernel, it puts the workload in a real lightweight virtual machine and passes the entire physical GPU into that VM over VFIO, bypassing the NVIDIA vGPU manager altogether. The project's reference documentation validates both passthrough and mediated-vGPU modes in CI, and NVIDIA's GPU Operator treats Kata as a first-class citizen: label a node nvidia.com/gpu.workload.config=vm-passthrough and the operator deploys the VFIO manager, sandbox device plugin, and kata-qemu-nvidia-gpu runtime classes for you, including confidential-computing variants. A Rust rewrite of the Kata device plugin targeting IOMMUFD-only passthrough and cold-plug CDI device attachment landed in 2026, so the plumbing is modernizing, not stagnating.

What you buy is the smallest shared surface of the three: a VM boundary plus exclusive device ownership, with the complete CUDA feature set — MPS, MIG semantics, profilers — intact inside the guest. What you pay:

• One GPU per VM. Passthrough means the card belongs to exactly one tenant at a time. Density comes only from the vGPU/MIG escape hatch, which reintroduces shared-driver machinery you chose Kata to avoid.
• A dedicated node pool. A node runs one container runtime at a time, so Kata GPU nodes serve only Kata GPU workloads — no mixing ordinary tenant pods onto spare capacity.
• VM-shaped operations. Boot latency instead of sub-second starts, per-VM memory overhead, and patch discipline with teeth: operators track Kata >= v3.27.0 following CVE-2026-24834, a reminder that the hypervisor is now in your CVE feed.

Kata is the right default when the workload, not the fleet, dictates terms: training jobs that need MPS or MIG, tenants whose compliance story requires a hardware-virtualized boundary, or any agent loop that shells out to profilers and debuggers nvproxy cannot see.

Edera: hardware isolation that still shares the card​

Edera's pitch is the row the other two leave empty: hypervisor-grade isolation with card sharing. Its runtime is a Rust-rewritten Type-1 hypervisor with no shared kernel state between workloads, and its Protect AI product auto-configures GPUs while isolating drivers and virtualizing resources so tenants cannot move laterally through the shared card. The company raised a $15M Series A in February 2025 led by M12, Microsoft's venture fund, with Mantis VC and In-Q-Tel participating — $20M total after a $5M seed three months earlier — explicitly to consolidate GPU workloads onto shared instances that previously needed separate clusters.

Reported overhead sits around 0.9% of CPU with faster boots from low-level IOMMU control, and in summer 2026 the same zone-based isolation started running on KVM, meeting teams where their infrastructure already is instead of demanding a bespoke hypervisor everywhere.

Take the numbers as vendor-quoted until you reproduce them, because the caveat is the company, not the architecture. Edera is a young startup selling the most ambitious row in the table: the isolation model of Kata with the sharing model of gVisor. That combination has no Modal-scale public deployment to point at yet, and adopting it means putting a venture-backed runtime — not just a configuration — in the blast-radius path of every tenant. The honest posture is a pilot: one node pool, non-critical sandboxes, measured overhead and escape testing, while the default fleet stays on boring, proven runtimes. Revisit the day a reference customer runs untrusted multi-tenant inference on it at a scale you can verify.

The orthogonal axis: the scheduler does not set the blast radius​

One confusion to kill before the recommendation, because Kubernetes spent 2026 inviting it. Dynamic Resource Allocation — with the NVIDIA DRA driver now living in kubernetes-sigs and a CNCF field guide walking through GPU time-slicing as Scenario IV — decides who gets which slice of GPU. Time-slicing replicas and MIG-backed claims are still beta-to-alpha surface: custom intervals sit behind alpha feature gates, queue schedulers like Kueue do not yet support time-slicing or MPS sharing modes, and operators report that cross-pod GPU sharing does not work under DRA — same-pod only, with device-plugin time-slicing the remaining cross-pod path.

That is all scheduling. None of it isolates. Whether a tenant's slice was carved by DRA claims, a device plugin, or a static limit, the question "what happens when this tenant's code is malicious" is answered one layer down, by runsc, QEMU, or a hypervisor. Budget for both layers, evaluate them separately, and never let a scheduler demo convince you the isolation problem is solved.

The default, with conditions​

For a self-hosted PaaS bringing up its first GPU node pool for agent sandboxes on owned hardware — a handful of cards, untrusted code, inference-heavy loops:

• Few cards, inference sandboxes: default to gVisor and nvproxy. Density per dollar is the binding constraint, the production precedent (Modal, GKE) is real, and the missing features (MPS, MIG, profilers) rarely bite inference loops. Automate the driver/runsc lockstep upgrade so the exact-match requirement cannot drift.
• Training, full CUDA features, or regulated tenants: default to Kata passthrough on a dedicated node pool. Accept one GPU per tenant as the price of a VM boundary and a complete CUDA surface, and keep the CVE feed wired to the runtime version.
• Edera: pilot pool only. Define the promotion criteria in advance — reproduced overhead numbers, escape-test results, a reference deployment at meaningful scale — and let it earn the default.
• Regardless of runtime: track DRA's graduation (time-slicing stability, cross-pod sharing, Kueue support) as the scheduler upgrade, not the isolation upgrade.

Sensitivity check: the gVisor default weakens as cards get plentiful — at some fleet size the density advantage stops paying for the proxied feature set, and per-tenant passthrough becomes affordable. It also flips per workload: the first tenant that needs MPS or a profiler is a Kata tenant, not a gVisor support ticket. Revisit the default when either variable moves, not on a calendar.

The fault line is not going away. Agent sandboxes keep getting more untrusted and GPUs keep getting more shared, which means the runtime layer keeps absorbing the risk the scheduler cannot price. Pick the isolation model whose price list you have actually read — and can afford — before the second tenant lands on the first card.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.