Projeto open source dá GPU Nvidia quase nativa a máquinas virtuais KVM

O virtio-nvgpu é um dispositivo virtio experimental, publicado pela nestrilabs no GitHub, que dá a uma máquina virtual KVM acesso ao driver da Nvidia praticamente no mesmo nível que o host tem. Em vez de traduzir chamadas de API gráfica (o caminho de projetos como Venus), ele forwarda os ioctls do driver Nvidia direto para /dev/nvidia*, na camada do ABI do kernel. O guest roda as bibliotecas de user-mode da própria Nvidia, sem modificação: mesma Vulkan, mesmo NVENC, mesma placa.

O caso de uso que o projeto mira é streaming headless: um compositor Wayland dentro da VM renderiza, compõe e codifica frames na própria GPU, e só o vídeo comprimido sai. A VM não tem monitor, e a GPU física continua sendo do host.

Por que não traduzir a API

O caminho mais comum hoje para GPU em VM sem passthrough dedicado é o virtio-gpu com Venus, que serializa cada chamada Vulkan ou OpenGL no guest, transporta pelo virtio e reproduz no host. O README do projeto lista três problemas práticos disso: jogos emitem de 1.000 a 5.000 draw calls por frame, cada uma serializada e reproduzida individualmente, o que come de 6% a 18% do orçamento de 16,6 ms de um frame a 60 fps só em overhead de serialização; a CPU do host gasta ciclos com serialização e replay que poderiam ir para a aplicação; e como os buffers de GPU pertencem ao host, o compositor do guest nem consegue enxergá-los, então não há caminho prático para codificar em NVENC sem um round-trip de leitura via CPU.

O virtio-nvgpu ataca isso na raiz: como o guest roda o driver de user-mode real da Nvidia, ele mesmo monta os comandos de GPU localmente. Por frame, o projeto reporta de 5 a 20 mensagens cruzando a fronteira da VM, contra cerca de 2.000 no modelo Venus. Passthrough via VFIO resolve o mesmo problema com desempenho nativo, mas dedica a placa inteira a uma única VM, o que não serve para ambientes multi-tenant.

Os números medidos

O teste de referência, descrito em detalhe no arquivo BENCHMARKS.md do repositório, rodou numa RTX 3060 com driver 595.99.02, comparando um guest contra o mesmo host em bare metal, com uma carga Vulkan headless idêntica dos dois lados. Para frames que o host bare metal leva 39 ms, 9,9 ms e 2,0 ms para renderizar, o guest ficou entre 0,4% mais rápido e 1,7% mais lento, dentro do ruído de medição. É só abaixo de 2 ms por frame, uma faixa mais leve que qualquer jogo real desenha, que a diferença cresce: 7,1% a mais em frames de 0,5 ms e 40,8% em frames de 0,05 ms. A explicação do próprio projeto é que, nesse ponto, o que domina não é mais o forwarding, e sim a espera: o guest dorme esperando a GPU, e o custo de acordar (cerca de 0,02 ms) passa a pesar num frame que dura menos que isso.

Do lado da CPU, um guest rodando sem cap a ~100 fps por 12 segundos consumiu 0,37 s de CPU contra 0,40 s do host em bare metal para a mesma carga. O motivo é estrutural: como o driver de user-mode da Nvidia submete comandos escrevendo em memória já mapeada, não há nada para o backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → forwardar durante o loop de renderização. Em 813.691 frames, o backend só precisou trocar 13.792 mensagens com o guest, uma travessia a cada 59 frames, quase todas de setup de dispositivo, não de submissão de frame.

Quatro VMs dividindo uma única placa

O teste mais relevante para quem pensa em infraestrutura compartilhada rodou quatro guests simultâneos na mesma RTX 3060, cada um com a mesma carga: 25,84, 26,49, 25,57 e 25,79 fps, somando 103,7 fps contra 102,9 fps de um único guest sozinho. Os tempos de frame no percentil 50 ficaram em 39,165, 39,164, 39,168 e 39,165 ms, praticamente idênticos. Todos os quatro guests renderizaram corretamente ao mesmo tempo e codificaram H.264 simultaneamente, cada um a 60 Hz exatos, sem esbarrar em limite de sessão do NVENC. O projeto é claro que quatro foi o que rodou, não um limite encontrado: oito guests ainda não foi testado.

O que isso não isola

O README do projeto é direto sobre a pergunta que qualquer pessoa de segurança faria primeiro, e a resposta não é "nada": não existe fronteira de IOMMU entre o trabalho de GPU do guest e o host. A placa pertence ao driver Nvidia do host e vive no domínio IOMMU do host; o guest recebe a interface de ioctl do driver, não o dispositivo em si. O que separa a memória do guest da do host é a própria MMU da GPU, com tabelas de página programadas pelo RM (Resource Manager da Nvidia) em nome do guest, o que coloca o driver Nvidia do host dentro do TCB (trusted computing base). O guest também monta seus próprios command streams, e é exatamente por isso que não há custo por submissão.

O que reduz essa superfície hoje é filtragem por ABI: ioctls que o perfil de ABI não descreve são recusados, não forwardados (a flag --permissive-abi desliga essa checagem para diagnóstico, com aviso explícito). O que ainda não existe: classes RM_ALLOC e comandos de controle RM não são filtrados, ioctls de UVM e modeset não têm tabela equivalente, e o backend hoje segura os descritores do host dentro do próprio processo da VMM, porque o isolate, um processo sandboxed por guest planejado para segurar esses descritores sem privilégio, está desenhado mas não construído (o diretório isolate/ no repositório é uma nota de design, não código). O próprio projeto resume: isso é redução de superfície de ataque, não isolamento de hardware. VFIO com IOMMU continua sendo estritamente mais forte, e para tenants mutuamente não confiáveis, VFIO ou vGPU seguem sendo a resposta.

O que já roda e o que ainda falta

O conjunto testado: nvidia-smi reporta potência e memória reais dentro do guest, com o deviceUUID do host; vulkaninfo sai com código 0 e desenhos offscreen são corretos pixel a pixel; um cliente Wayland apresenta através de um compositor no guest; NVENC funciona via Vulkan Video, codificando no próprio dispositivo do cliente; buffers importados são memória do host, mapeada por uma janela compartilhada.

O projeto shippa três perfis de ABI, cada um cobrindo uma faixa de versões de driver: 535.129.03, 580.178.04 e 595.71.05 em diante. Versões mais antigas que a primeira faixa são recusadas, não adivinhadas, porque forwardar um ioctl com layout nunca visto é como obter uma resposta plausível e errada em vez de um erro. Os testes reais rodaram em duas placas: a RTX 3060 com driver 595.99.02, que é de onde vêm todos os números do BENCHMARKS.md, e uma RTX A2000 com driver 615.71.09, que renderiza e enumera mas não foi benchmarcada nem retestada desde então. CUDA é forwardado mas só testado além da enumeração; o jailer, compartilhamento de driver por versão e o envelope multi-tenant completo ainda não existem.

Por que isso importa para infra local no Brasil

O recorte mais óbvio é CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → e ambientes de desenvolvimento com GPU: em vez de reservar uma placa inteira via VFIO para cada runner ou dev box, e ficar limitado ao número de GPUs físicas, dá para compartilhar uma única placa entre várias VMs isoladas, o que muda a conta de hardware de quem monta esse tipo de infra localmente, sem depender de instância de nuvem com GPU dedicada. O caso de teste com quatro guests dividindo uma RTX 3060 sem perda de throughput total é justamente esse cenário: builds ou testes que precisam de aceleração gráfica ou de NVENC podem rodar em paralelo, isolados uns dos outros no nível de processo/VM, sem multiplicar o número de placas.

A ressalva de segurança, porém, vale a pena levar a sério antes de colocar isso num pipeline que roda código de terceiros ou PRs externos: como o host NVIDIA driver está dentro do TCB e o isolate ainda não foi construído, esse é hoje um projeto mais adequado a ambientes internos de confiança, como dev boxes de uma equipe ou infraestrutura de teste de streaming, do que a runners multi-tenant expostos a código não confiável. Para esse último caso, o próprio projeto recomenda seguir com VFIO ou vGPU. O código está sob três licenças diferentes por camada (GPL-2.0 no driver de kernel do guest, Apache-2.0 no crate do dispositivo, BSD-3-Clause/GPL-2.0 dual no protocolo compartilhado), o que facilita adotar a camada de dispositivo em outra VMM sem herdar GPL, algo que o próprio README aponta como decisão deliberada inspirada no layout do chromeos/virtio-media. A referência direta de arquitetura é o gVisor nvproxy, que já faz forwarding de ioctls Nvidia de containers sandboxed para o driver do host em produção, e é dali que vêm as tabelas de ABI e a lógica de tradução que o virtio-nvgpu adapta para o contexto de VMs KVM.

Fonte: Hacker News