Virtio-nvgpu, an open-source project on GitHub from Nestri Labs, forwards NVIDIA kernel driver ioctls between a Linux guest and the host at the driver ABI level rather than translating graphics API calls, letting a KVM guest run NVIDIA's own unmodified user-mode drivers against a shared card. The project's documentation reports that a guest renders within 2% of the machine it runs on and costs the same CPU — a claim architects evaluating multi-tenant GPU setups will want to test against their own workloads before trusting it wholesale.
The mechanism is a driver-level proxy, not an API translator. A guest kernel module (the driver/ component, GPL-2.0) registers /dev/nvidiactl, /dev/nvidia0…N and /dev/nvidia-uvm, serializing ioctl() calls onto a control virtqueue and mapping shared-memory regions on mmap(). It makes no ABI decisions itself. A separate device crate (Apache-2.0, no VMM dependency) maps guest handles to host file descriptors, rewrites embedded pointers and FDs, and issues the translated calls against the host's real devices. The documentation contrasts this with Venus, the virtio-gpu API-translation approach, where games issuing 1,000–5,000 draw calls per frame each get serialized, transported and replayed — an approach the project's writeup says produces per-frame boundary crossings numbering around 2,000, versus roughly 5–20 for virtio-nvgpu.
The intended use case is headless streaming: a Wayland compositor inside the guest renders, composites and encodes frames via NVENC, and only the compressed H.264 or H.265 bitstream leaves the VM — there is no monitor, and the host retains the card. The project's documentation states this requires guest-side buffer ownership, which Venus-style host-owned buffers cannot provide without a full CPU readback and copy, making guest-side NVENC "not viable" under that architecture by the project's own comparison table.
On the numbers: measured on an RTX 3060 running driver 595.99.02, guest frame times against bare metal came in at 39 ms (−0.4%), 9.9 ms (−0.7%), 2.0 ms (+1.7%) and 0.5 ms (+7.1%) — the documentation notes that above roughly 2 ms a frame, which it says covers every frame a game draws, the guest stays within 2% of bare metal, while very light frames below that threshold show the cost of a GPU wake, put at about 0.02 ms, becoming visible against a frame that "barely exists." CPU cost for one guest running unpaced at roughly 100 fps for 12 seconds was measured at 0.40 s on bare metal versus 0.37 s in the guest. Across 813,691 frames the backend served 13,792 messages — about one host crossing per 59 frames, nearly all of it device setup rather than per-frame traffic. With four guests sharing a single RTX 3060 under identical loads, the project reports combined throughput of 103.7 fps against 102.9 fps for one guest alone, with per-guest frame rates of 25.84, 26.49, 25.57 and 25.79 fps and p50 frame times matching to within four decimal places (39.165, 39.164, 39.168 and 39.165 ms).
The limits are explicit in the project's own documentation. Only two cards and two driver versions have been run: the RTX 3060 on 595.99.02 is where every benchmark number comes from, while an RTX A2000 on 615.71.09 renders and enumerates but has not been benchmarked. Driver ABI support is pinned to three explicit profiles — 535.129.03, 580.178.04 and 595.71.05 — matched by version range, with anything older than 535.129.03 refused outright rather than guessed at; the documentation warns that a driver newer than the last known profile is accepted on the assumption nothing relevant changed, which is "the first thing to suspect when a new driver misbehaves." Four concurrent guests is the most tested, not a discovered ceiling — eight has not been tried. CUDA is forwarded but only tested through enumeration, not compute workloads. The sandboxed per-guest isolation process meant to hold device file descriptors safely — described in the isolate/ directory — is design-only; today the backend holds those descriptors itself inside the VMM's own process, which the documentation flags as the gap standing between this and a real multi-tenant deployment. There is also no comparison against any other hypervisor or passthrough scheme in the published numbers, only against bare metal on the same box.
For teams weighing this against standard PCIe passthrough or vendor vGPU licensing, the takeaway is narrow but real: the architecture solves API-translation overhead and enables guest-side NVENC in a way Venus cannot, but it is a single-card, four-guest, two-driver-version proof of concept without a security-hardened isolation layer — evaluate it for headless streaming pilots, not as a drop-in replacement for a production multi-tenant GPU fleet.