Virtio-nvgpu, un proyecto de código abierto en GitHub de Nestri Labs, reenvía las ioctls del driver del kernel de NVIDIA entre un invitado Linux y el host a nivel de la ABI del driver en lugar de traducir llamadas a la API gráfica, permitiendo que un invitado KVM ejecute los propios drivers de modo usuario sin modificar de NVIDIA contra una tarjeta compartida. La documentación del proyecto reporta que un invitado renderiza dentro del 2% de la máquina en la que se ejecuta y cuesta el mismo CPU — una afirmación que los arquitectos que evalúan configuraciones de GPU multiinquilino querrán poner a prueba contra sus propias cargas de trabajo antes de confiar en ella por completo.

El mecanismo es un proxy a nivel de driver, no un traductor de API. Un módulo del kernel del invitado (el componente driver/, GPL-2.0) registra /dev/nvidiactl, /dev/nvidia0…N y /dev/nvidia-uvm, serializando las llamadas ioctl() en una virtqueue de control y mapeando regiones de memoria compartida mediante mmap(). No toma ninguna decisión de ABI por sí mismo. Un crate de dispositivo independiente (Apache-2.0, sin dependencia de VMM) mapea los handles del invitado a descriptores de archivo del host, reescribe punteros y FDs embebidos, y emite las llamadas traducidas contra los dispositivos reales del host. La documentación contrasta esto con Venus, el enfoque de traducción de API de virtio-gpu, donde los juegos que emiten entre 1,000 y 5,000 draw calls por frame se serializan, transportan y reproducen cada uno — un enfoque que, según el informe del proyecto, produce cruces de frontera por frame que rondan los 2,000, frente a aproximadamente 5–20 para virtio-nvgpu.

El caso de uso previsto es streaming sin cabeza (headless): un compositor Wayland dentro del invitado renderiza, compone y codifica frames mediante NVENC, y solo el bitstream comprimido H.264 o H.265 sale de la VM — no hay monitor, y el host conserva la tarjeta. La documentación del proyecto establece que esto requiere propiedad del búfer del lado del invitado, algo que los búferes propiedad del host al estilo Venus no pueden proporcionar sin una lectura y copia completa por CPU, lo que hace que el NVENC del lado del invitado sea "no viable" bajo esa arquitectura según la propia tabla comparativa del proyecto.

En cuanto a los números: medido en una RTX 3060 con el driver 595.99.02, los tiempos de frame del invitado frente a bare metal fueron de 39 ms (−0.4%), 9.9 ms (−0.7%), 2.0 ms (+1.7%) y 0.5 ms (+7.1%) — la documentación señala que por encima de aproximadamente 2 ms por frame, lo que según indica cubre cada frame que dibuja un juego, el invitado se mantiene dentro del 2% de bare metal, mientras que los frames muy ligeros por debajo de ese umbral muestran el costo de un despertar de GPU, estimado en unos 0.02 ms, que se vuelve visible frente a un frame que "apenas existe". El costo de CPU para un invitado ejecutándose sin límite de ritmo a aproximadamente 100 fps durante 12 segundos se midió en 0.40 s en bare metal frente a 0.37 s en el invitado. A lo largo de 813,691 frames el backend sirvió 13,792 mensajes — aproximadamente un cruce hacia el host cada 59 frames, casi todo configuración de dispositivo en lugar de tráfico por frame. Con cuatro invitados compartiendo una única RTX 3060 bajo cargas idénticas, el proyecto reporta un throughput combinado de 103.7 fps frente a 102.9 fps para un solo invitado, con tasas de frames por invitado de 25.84, 26.49, 25.57 y 25.79 fps y tiempos de frame p50 que coinciden hasta cuatro decimales (39.165, 39.164, 39.168 y 39.165 ms).

Los límites son explícitos en la propia documentación del proyecto. Solo se han probado dos tarjetas y dos versiones de driver: la RTX 3060 con 595.99.02 es de donde provienen todos los números de benchmark, mientras que una RTX A2000 con 615.71.09 renderiza y enumera pero no ha sido sometida a benchmark. El soporte de la ABI del driver está fijado a tres perfiles explícitos — 535.129.03, 580.178.04 y 595.71.05 — emparejados por rango de versión, y cualquier versión anterior a 535.129.03 se rechaza de plano en lugar de suponerse compatible; la documentación advierte que un driver más nuevo que el último perfil conocido se acepta bajo la suposición de que nada relevante cambió, lo cual es "lo primero que hay que sospechar cuando un driver nuevo se comporta mal". Cuatro invitados concurrentes es lo más probado, no un techo descubierto — ocho no se ha intentado. CUDA se reenvía pero solo se ha probado mediante enumeración, no con cargas de trabajo de cómputo. El proceso de aislamiento por invitado en sandbox destinado a mantener de forma segura los descriptores de archivo de dispositivo — descrito en el directorio isolate/ — es solo diseño; hoy el backend mantiene esos descriptores él mismo dentro del propio proceso del VMM, algo que la documentación señala como la brecha que separa esto de un despliegue multiinquilino real. Tampoco hay comparación con ningún otro hipervisor o esquema de passthrough en los números publicados, solo frente a bare metal en la misma máquina.

Para los equipos que sopesan esto frente al passthrough PCIe estándar o el licenciamiento vGPU de un proveedor, la conclusión es acotada pero real: la arquitectura resuelve la sobrecarga de traducción de API y habilita NVENC del lado del invitado de una manera que Venus no puede, pero es una prueba de concepto de una sola tarjeta, cuatro invitados y dos versiones de driver, sin una capa de aislamiento reforzada en seguridad — evalúenla para pilotos de streaming sin cabeza, no como un reemplazo directo para una flota de GPU multiinquilino en producción.