Passar uma GPU física para dentro de uma VM é um dos recursos mais úteis e mais frustrantes do Proxmox. Útil porque destrava cargas que sem aceleração não rodam: inferência de modelos de IA, transcodificação de vídeo, desktops remotos com gráfico pesado, CAD. Frustrante porque a lista de coisas que precisam estar certas é longa, e a maioria delas não está no software — está na placa-mãe, na topologia de PCIe e no modelo da placa. Vale conhecer as armadilhas antes de comprar hardware.

O que passthrough faz e o que ele custa

Passthrough entrega o dispositivo PCIe inteiro para uma VM. O host deixa de usar a placa e a VM passa a falar direto com o hardware, com o driver original do fabricante, sem camada de emulação. A performance fica próxima do nativo.

O custo está na palavra "inteiro". A GPU passa a pertencer a uma VM só. Não há compartilhamento entre VMs, e o host não pode mais usá-la. Se você tem uma placa e três VMs que precisam de GPU, passthrough não resolve — você precisa de três placas, ou de outra abordagem.

Os requisitos, em ordem de reprovação

A maioria das tentativas falha em um destes pontos, quase sempre nos dois primeiros:

1. IOMMU no processador e no chipset. Intel chama de VT-d, AMD de AMD-Vi. É o mecanismo que permite isolar dispositivos com segurança. Processador de servidor e a maioria dos processadores de desktop atuais têm; vale confirmar o modelo específico, e também o chipset da placa-mãe.
2. IOMMU habilitado na BIOS. Vem desativado com frequência, com nomes pouco óbvios. Este é o item que mais consome tempo em diagnóstico, porque tudo no sistema operacional parece correto.
3. Parâmetros no boot do kernel para ativar IOMMU e o mapeamento de dispositivo.
4. O driver do host afastado da placa. Se o kernel do Proxmox carrega o driver de vídeo, o dispositivo já está ocupado. É preciso vinculá-lo ao vfio-pci e impedir o carregamento do driver original no host.
5. VM em modo UEFI com máquina moderna. GPU atual espera firmware UEFI. Configuração de máquina antiga tende a falhar de formas difíceis de interpretar.

Grupos de IOMMU: a armadilha estrutural

Este é o obstáculo que não se resolve com configuração, e é o que mais decepciona.

O IOMMU organiza os dispositivos em grupos, definidos pela topologia física de PCIe da placa-mãe. A unidade de passthrough é o grupo inteiro, não o dispositivo. Se a sua GPU está num grupo junto com a controladora USB e uma placa de rede, você precisaria entregar os três à VM — o que normalmente é inviável, porque o host precisa deles.

Em placas de servidor, com PCIe bem segmentado, os grupos costumam ser limpos. Em placas de desktop, é comum encontrar meio barramento num único grupo.

Existe uma solução de contorno conhecida, que força a separação dos grupos. Ela funciona com frequência, e é importante ser honesto sobre o que ela é: uma quebra deliberada do isolamento que o IOMMU deveria garantir. Em laboratório e em ambiente que você controla inteiramente, é uma escolha defensável. Em host que roda carga de cliente, não é — o isolamento entre VMs deixa de ser confiável, e esse é justamente o motivo pelo qual você usaria VM em vez de container.

Verifique os grupos antes de comprar. É uma consulta de um comando e evita descobrir a limitação com o hardware já pago.

Placa de consumo e placa de datacenter

Dois pontos merecem destaque. O primeiro: compartilhar uma GPU entre várias VMs exige placa de datacenter e licenciamento — não é um recurso que se habilita numa placa de consumo. Se o seu plano é vender GPU fracionada para vários clientes, o hardware precisa ser o adequado desde o início.

O segundo é físico e subestimado: placa de consumo em servidor de rack é um problema de refrigeração. O servidor gera fluxo de ar frontal para trás esperando dissipadores passivos; a placa de consumo tem ventilador próprio e formato pensado para gabinete de desktop. A combinação resulta em placa aquecendo, reduzindo desempenho ou desligando sob carga sustentada — depois de funcionar bem no teste curto.

O que você perde ao usar passthrough

Aqui estão as consequências operacionais que costumam ser descobertas tarde:

• Migração ao vivo deixa de existir para aquela VM. O estado interno da GPU não é transferível. Manutenção no host passa a exigir parada da VM.
• Alta disponibilidade fica limitada. A VM só sobe em nó que tenha uma GPU equivalente livre. Em cluster com uma placa em um único nó, não há para onde ir.
• Snapshot com estado de memória deixa de funcionar de forma confiável.
• O host perde a placa — inclusive para console de vídeo, se for a única.
• Reinício da VM pode falhar. Algumas placas, principalmente de consumo, não reinicializam corretamente ao serem devolvidas e reatribuídas. O sintoma é a VM não subir na segunda vez, exigindo reinício do host. É um comportamento dependente do modelo, e é o principal motivo para testar a placa específica antes de colocá-la em produção.

Quando passthrough não é a resposta

Sendo direto: para uma parcela grande dos casos de IA que nos chegam, passthrough numa VM não é o melhor desenho. Alternativas que costumam sair melhor:

• Host dedicado sem virtualização para a carga de GPU. Se a placa vai ser usada por um serviço só, a virtualização adiciona restrição — sem migração, sem HA — e não adiciona benefício.
• Servir o modelo pela rede. Uma máquina com GPU expõe uma API, e as VMs consomem. Uma placa atende muitos consumidores, o que é bem mais eficiente que dedicá-la a uma VM.
• API de terceiros, quando o volume não justifica hardware próprio. A conta de comprar e operar GPU só fecha a partir de um certo uso sustentado.
• CPU, para cargas menores do que se imagina. Modelos pequenos quantizados rodam de forma aceitável sem GPU, e vale medir antes de comprar.

Como testar antes de prometer

Um roteiro curto que evita compromisso com o que não funciona:

1. Confirme IOMMU habilitado e veja como os grupos ficaram, com a placa no slot definitivo — mudar de slot muda o grupo.
2. Faça o passthrough e valide que a VM vê a placa e carrega o driver do fabricante.
3. Rode a carga real, não um teste sintético curto, e observe temperatura e desempenho ao longo de pelo menos uma hora.
4. Reinicie a VM três vezes seguidas. É o teste que revela o problema de reinicialização da placa.
5. Reinicie o host e confirme que tudo volta sozinho, sem intervenção manual.
6. Documente o desenho e a restrição — sem migração ao vivo, VM presa a este nó — para quem for operar depois.

Erros comuns

• IOMMU desativado na BIOS, com horas gastas depurando o sistema operacional.
• Comprar hardware sem verificar os grupos de IOMMU.
• Usar a quebra de isolamento de grupos em host com carga de cliente.
• Contar com migração ao vivo ou HA numa VM com placa dedicada.
• GPU de consumo em servidor de rack, com problema térmico sob carga sustentada.
• Esperar compartilhar uma placa de consumo entre várias VMs.
• Não testar reinício repetido da VM antes de ir para produção.
• Virtualizar uma carga de GPU que ficaria melhor em host dedicado.

Onde a Solvefy/Cloud entra

Ajudamos a decidir isso antes da compra: avaliamos se o seu caso pede passthrough, host dedicado ou modelo servido pela rede, verificamos a viabilidade do hardware — incluindo grupos de IOMMU e refrigeração — e implantamos com a restrição documentada, para que a operação saiba o que pode e o que não pode ser feito naquele nó. Como parceiros oficiais Proxmox, também ajustamos o desenho de HA para conviver com VMs presas a um nó específico.

Quer avaliar se GPU em VM faz sentido no seu ambiente? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.