Virtio-nvgpu, um projeto de código aberto no GitHub da Nestri Labs, encaminha as ioctls do driver de kernel da NVIDIA entre um guest Linux e o host no nível da ABI do driver, em vez de traduzir chamadas de API gráfica, permitindo que um guest KVM execute os próprios drivers de modo usuário não modificados da NVIDIA contra uma placa compartilhada. A documentação do projeto relata que um guest renderiza a 2% da máquina em que roda e custa a mesma CPU — uma afirmação que arquitetos avaliando configurações de GPU multi-tenant vão querer testar contra suas próprias cargas de trabalho antes de confiar nela integralmente.

O mecanismo é um proxy no nível de driver, não um tradutor de API. Um módulo de kernel do guest (o componente driver/, GPL-2.0) registra /dev/nvidiactl, /dev/nvidia0…N e /dev/nvidia-uvm, serializando chamadas ioctl() em uma virtqueue de controle e mapeando regiões de memória compartilhada via mmap(). Ele não toma nenhuma decisão de ABI por conta própria. Um crate de dispositivo separado (Apache-2.0, sem dependência de VMM) mapeia handles do guest para descritores de arquivo do host, reescreve ponteiros e FDs embutidos, e emite as chamadas traduzidas contra os dispositivos reais do host. A documentação contrasta isso com o Venus, a abordagem de tradução de API do virtio-gpu, na qual jogos que emitem 1,000–5,000 draw calls por frame têm cada uma serializada, transportada e reproduzida — uma abordagem que, segundo o texto do projeto, produz travessias de fronteira por frame em torno de 2,000, contra aproximadamente 5–20 no virtio-nvgpu.

O caso de uso pretendido é streaming headless: um compositor Wayland dentro do guest renderiza, compõe e codifica frames via NVENC, e apenas o bitstream comprimido H.264 ou H.265 sai da VM — não há monitor, e o host retém a placa. A documentação do projeto afirma que isso requer posse de buffer do lado do guest, algo que buffers de propriedade do host no estilo Venus não conseguem fornecer sem um readback e cópia completos de CPU, tornando o NVENC do lado do guest “not viable” sob essa arquitetura, segundo a própria tabela comparativa do projeto.

Quanto aos números: medido em uma RTX 3060 rodando o driver 595.99.02, os tempos de frame do guest em relação ao bare metal ficaram em 39 ms (−0.4%), 9.9 ms (−0.7%), 2.0 ms (+1.7%) e 0.5 ms (+7.1%) — a documentação observa que acima de aproximadamente 2 ms por frame, o que segundo ela cobre todo frame que um jogo desenha, o guest permanece a 2% do bare metal, enquanto frames muito leves abaixo desse limiar mostram o custo de um wake da GPU, estimado em cerca de 0.02 ms, que se torna visível contra um frame que “mal existe”. O custo de CPU para um guest rodando sem limitação de taxa a aproximadamente 100 fps durante 12 segundos foi medido em 0.40 s no bare metal contra 0.37 s no guest. Ao longo de 813,691 frames, o backend serviu 13,792 mensagens — cerca de uma travessia para o host a cada 59 frames, quase tudo configuração de dispositivo em vez de tráfego por frame. Com quatro guests compartilhando uma única RTX 3060 sob cargas idênticas, o projeto relata throughput combinado de 103.7 fps contra 102.9 fps para um único guest sozinho, com taxas de frame por guest de 25.84, 26.49, 25.57 e 25.79 fps e tempos de frame p50 coincidindo até a quarta casa decimal (39.165, 39.164, 39.168 e 39.165 ms).

Os limites são explícitos na própria documentação do projeto. Apenas duas placas e duas versões de driver foram testadas: a RTX 3060 no 595.99.02 é de onde vêm todos os números de benchmark, enquanto uma RTX A2000 no 615.71.09 renderiza e enumera, mas não foi avaliada em benchmark. O suporte à ABI do driver está fixado em três perfis explícitos — 535.129.03, 580.178.04 e 595.71.05 — correspondidos por faixa de versão, com qualquer versão anterior a 535.129.03 recusada de imediato em vez de estimada; a documentação avisa que um driver mais novo do que o último perfil conhecido é aceito sob a suposição de que nada relevante mudou, o que é “a primeira coisa a suspeitar quando um driver novo se comporta mal”. Quatro guests simultâneos é o máximo testado, não um teto descoberto — oito ainda não foi tentado. O CUDA é encaminhado, mas testado apenas por meio de enumeração, não com cargas de trabalho de computação. O processo de isolamento em sandbox por guest destinado a manter os descritores de arquivo de dispositivo com segurança — descrito no diretório isolate/ — existe apenas em nível de projeto; hoje o backend mantém esses descritores por conta própria dentro do próprio processo do VMM, o que a documentação sinaliza como a lacuna entre isso e uma implantação multi-tenant real. Também não há comparação com nenhum outro hipervisor ou esquema de passthrough nos números publicados, apenas contra bare metal na mesma máquina.

Para equipes avaliando isso em comparação com passthrough PCIe padrão ou licenciamento de vGPU de fornecedor, a conclusão é estreita, mas real: a arquitetura resolve o overhead de tradução de API e habilita NVENC do lado do guest de um jeito que o Venus não consegue, mas é uma prova de conceito de uma única placa, quatro guests e duas versões de driver, sem uma camada de isolamento reforçada em segurança — avalie-a para pilotos de streaming headless, não como substituto direto para uma frota de GPU multi-tenant em produção.