Virtualização de GPU: exemplos práticos de passthrough, vGPU, MIG e time-slicing

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

Uma GPU de datacenter custa o mesmo parada ou em carga total, ainda que só a segunda condição gere retorno. A Cast AI mediu dezenas de milhares de clusters na AWS, no Azure e no GCP. Entre 2025 e abril de 2026, a utilização média ficou em 5%.

O gargalo quase nunca é a placa, mas o modo como ela foi entregue. Quando o hypervisor atribui a placa inteira a uma máquina virtual, quem roda inferência por dez minutos a cada hora deixa os outros cinquenta parados. Ninguém aproveita a sobra.

Antes da compra vem a decisão que quase nunca é documentada: qual modo de compartilhamento cada carga pede. Passthrough, vGPU mediado, MIG e time-slicing repartem a mesma placa de maneiras diferentes, com isolamento, densidade e custo de licença distintos. A escolha errada só aparece meses depois, no custo por hora de GPU.

O que é virtualização de GPU

A virtualização de GPU é o conjunto de técnicas que faz uma placa física atender mais de uma máquina virtual ou container ao mesmo tempo. Em vez da relação de uma GPU para um consumidor, o hypervisor ou o kernel entrega frações da placa. Cada fração carrega sua própria memória e sua fatia de processamento.

Comparado ao que já se faz com CPU e memória em máquinas virtuais, o ponto sensível é o isolamento. Um vCPU é abstração de escalonamento pura. A GPU, por muito tempo, foi um dispositivo PCIe indivisível, de modo que o compartilhamento precisou de suporte no próprio silício.

Isso muda o que a infraestrutura consegue prometer. Passthrough entrega desempenho de placa dedicada sem densidade nenhuma; o time-slicing entrega densidade sem garantia de memória. Entre os dois extremos ficam os modos que particionam a placa de verdade, porque a fronteira vem do próprio hardware.

Os quatro modos de dividir uma GPU

Cada modo resolve um problema diferente, porque a pergunta que os separa é sempre a mesma: o que exatamente fica isolado entre os consumidores? Memória, tempo de processamento e domínio de falha respondem de formas distintas em cada um deles.

Entre os quatro, o MIG é o único que corta a placa dentro do silício. A NVIDIA documenta até sete instâncias por placa a partir da arquitetura Ampere. Cada instância recebe caminho próprio de cache L2, controlador de memória e barramento de DRAM.

Nada impede a combinação entre eles. O MIG-backed vGPU coloca a camada de software da vGPU sobre uma partição MIG, de modo que o isolamento vem do hardware. Dentro da máquina virtual, o driver continua sendo o do fabricante.

Exemplos práticos: qual modo cada carga pede

Na teoria a tabela acima resolve. Na prática, quem decide é o formato do consumo ao longo do dia. Rajada curta com muita ociosidade pede um modo, enquanto ocupação contínua de horas pede outro.

VDI e estações gráficas de CAD

Aqui o padrão de uso é rajada curta e previsível. Dezenas de projetistas giram um modelo no SolidWorks por alguns segundos, depois passam minutos lendo a tela ou escrevendo. O vGPU mediado é o encaixe natural para esse padrão. O perfil fixa a memória de vídeo por sessão, enquanto o escalonador reparte o tempo de processamento entre usuários ociosos.

Com esse arranjo, uma placa de médio porte sustenta de oito a dezesseis sessões de CAD, dependendo do perfil escolhido. O consumo real de memória de vídeo da aplicação decide o perfil, porque um perfil apertado derruba a sessão em vez de degradá-la.

Treinamento de modelo

Treinamento é o caso em que dividir a placa piora tudo. Um job que satura memória e barramento por horas não deixa sobra útil para ninguém. A camada de mediação ainda cobra seu pedaço de desempenho no caminho.

Passthrough resolve, já que a máquina virtual recebe o dispositivo PCIe inteiro, carrega o driver nativo e enxerga a placa como se fosse física. O preço é a densidade, que cai para uma VM por GPU. Somado a isso, a migração ao vivo deixa de funcionar na maioria dos hypervisors.

Inferência multi-tenant

Inferência inverte o problema do treinamento: modelos pequenos, memória previsível, muitas requisições curtas. É onde o MIG paga a conta, porque cada instância carrega sua fatia garantida de memória. O pico de um cliente não derruba a latência do vizinho.

Esse isolamento tem valor contratual. Quando o SLA promete percentil de latência por cliente, a garantia precisa vir do hardware. Isso acontece porque escalonamento por tempo não sustenta a promessa sob carga concorrente.

Laboratório, CI e sala de aula

Quando o requisito é caber, não garantir, o time-slicing resolve com poucas linhas de configuração. Aluno compilando exemplo de CUDA, pipeline de CI rodando teste de inferência, cientista de dados explorando um notebook. Nenhum deles precisa de garantia, embora todos precisem de acesso.

Sem isolamento de memória, um notebook esquecido com um tensor grande derruba os outros consumidores da mesma placa. O risco é conhecido, embora só apareça quando alguém deixa o processo rodando à noite.

O que cada plataforma entrega hoje

Entre os hypervisors o suporte varia bastante, de modo que essa diferença costuma pesar mais na decisão do que a preferência técnica. Antes de fechar o desenho, confira a matriz de compatibilidade da placa contra a versão exata do hypervisor em produção.

VMware vSphere

O vSphere cobre os três modos de máquina virtual. Passthrough sai via DirectPath I/O, vGPU mediado exige o driver da NVIDIA instalado no host e MIG chega pelos perfis MIG-backed. Além disso, é a plataforma com mais tempo de estrada em vGPU, o que aparece na maturidade das ferramentas de operação.

Hyper-V e Windows Server

No Hyper-V existem dois caminhos. O DDA dedica a placa inteira a uma máquina virtual, com todas as funcionalidades do fabricante disponíveis no convidado. O particionamento de GPU chegou no Windows Server 2025 e usa SR-IOV. A interface entrega fronteira de segurança com suporte de hardware, além de desempenho previsível por partição.

Na prática, a diferença está na densidade. O DDA rende uma VM por placa, enquanto o particionamento reparte a mesma placa entre várias. Cada partição recebe sua fração de memória de vídeo.

Proxmox VE e KVM

O passthrough em KVM é maduro, desde que o host tenha IOMMU ativo e os grupos PCIe corretamente isolados. Para quem saiu do VMware depois da mudança de licenciamento, o Proxmox VE entrega passthrough de GPU sem custo de licença adicional.

No KVM, o vGPU mediado existe através do subsistema mediated devices, embora a licença da NVIDIA continue obrigatória. MIG funciona normalmente, uma vez que o particionamento acontece abaixo do hypervisor.

Kubernetes

No Kubernetes a divisão sai do hypervisor e vai para o device plugin. Com time-slicing, o administrador declara quantas réplicas cada placa anuncia ao escalonador, para que cada réplica caia em um pod diferente.

# cada GPU do no passa a anunciar 4 recursos ao escalonador
version: v1
sharing:
  timeSlicing:
    resources:
    - name: nvidia.com/gpu
      replicas: 4

A documentação do device plugin é explícita sobre o limite: não existe isolamento de memória nem de falha entre réplicas. Pedir mais de uma réplica também não garante fatia proporcional de processamento. Quem precisa de garantia usa MIG, que o mesmo operador também expõe.

Para carga de produção, o passo seguinte é instrumentar o cluster, porque contenção de GPU aparece como latência de pod antes de aparecer como erro. As métricas que importam estão no guia de monitoramento de Kubernetes.

Licenciamento e hardware: onde o projeto trava

Nem o passthrough nem o MIG cobram licença de software. O vGPU mediado cobra, através de assinatura própria ou do pacote NVIDIA AI Enterprise: essa linha entra no orçamento separada do hardware.

Em produção aparece a armadilha que ninguém testa no laboratório. Quando a máquina virtual não consegue falar com o servidor de licenças, o desempenho cai por etapas. A NVIDIA documenta limite de 15 quadros por segundo após 20 minutos sem licença.

Depois de 24 horas o teto cai para 3 quadros por segundo, enquanto as chamadas da API CUDA passam a falhar.

Isso torna o servidor de licenças um componente de disponibilidade, não um detalhe administrativo. Ele precisa entrar no inventário monitorado junto com o hypervisor, para que o usuário não sinta a degradação antes do plantão.

Do lado do hardware, três requisitos derrubam projeto com frequência: IOMMU desligado na BIOS, grupos PCIe mal isolados no passthrough e placas de consumo fora da matriz de suporte de vGPU. Grupo mal isolado arrasta outros dispositivos junto quando a placa é atribuída à máquina virtual.

Quem revisa o desenho por causa do custo de licença do hypervisor encontra os números que faltam no comparativo de alternativas ao VMware.

Como saber que a divisão escolhida está errada

A escolha errada não dispara alarme no console de monitoramento. Ela aparece como reclamação de lentidão sem erro correspondente no log, enquanto o time perde dias procurando causa na aplicação. Dois números medidos no host resolvem a dúvida em poucos minutos.

Comece pela razão entre memória de vídeo ocupada e utilização dos multiprocessadores. Memória cheia com processamento baixo significa consumidor parado segurando recurso, que é o retrato clássico de passthrough onde caberia particionamento.

# memoria ocupada contra utilizacao, por dispositivo
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv

# quem esta segurando a memoria agora
nvidia-smi --query-compute-apps=pid,gpu_uuid,used_memory --format=csv

Depois disso, olhe a variação da latência entre consumidores da mesma placa. Se o percentil 95 de um serviço oscila conforme o vizinho trabalha, o modo escolhido não isola o suficiente. A correção passa por MIG ou por separar as cargas em placas distintas.

Nenhum dos dois sinais aparece em coleta pontual por linha de comando. Eles pedem série temporal com retenção, alerta por tendência e correlação com a fila da aplicação. Esse é o terreno do monitoramento de GPU em cargas de IA.

Por onde começar na segunda-feira

Antes de desenhar qualquer partição, meça o consumo real das cargas que já rodam. Uma semana de coleta de memória de vídeo e utilização por processo já mostra onde está o desperdício. Metade das placas costuma aparecer entregue a quem usa rajada curta, quando o perfil correto seria compartilhado.

Com o retrato na mão, a decisão de arquitetura fica direta. Carga que ocupa a placa por horas fica em passthrough, enquanto sessão gráfica interativa vai para vGPU mediado. Inferência com compromisso de latência por cliente pede MIG. Laboratório e CI cabem em time-slicing sem culpa nenhuma.

Por fim, trate o novo desenho como qualquer outro item de infraestrutura crítica. Entram no escopo o inventário, a coleta contínua, o alerta por tendência e o servidor de licenças. Sem isso, a economia conquistada na partição se perde na primeira madrugada em que o desempenho cai sem ninguém entender por quê.

Quer revisar a arquitetura de GPU do seu ambiente com quem opera infraestrutura crítica todos os dias? Fale com um especialista da OpServices.