A AWS anunciou em 6 de novembro de 2026 que o Amazon SageMaker Inference passou a suportar particionamento de GPU com o NVIDIA Multi-Instance GPU (MIG). A tecnologia divide um acelerador físico em partições independentes, cada uma com uma parcela fixa das unidades de computação e um bloco dedicado de memória, com isolamento aplicado em hardware.
Na prática, deixa de valer a regra que obrigava todo endpoint de modelo a consumir um acelerador inteiro como menor unidade possível.
O problema que a mudança ataca é conhecido por quem opera inferência em escala. Uma instância ml.p4d.24xlarge carrega oito A100 e, portanto, hospeda no máximo oito modelos — independentemente de cada um precisar de 40 GB ou de apenas 14 GB de memória.
Qualquer implantação virava uma escolha entre gerações de GPU: à medida que a concorrência e o tamanho dos prompts crescem, uma GPU inteira em uma instância mais antiga deixa de bastar, enquanto uma GPU inteira em uma instância mais nova sobra para o que o modelo consegue usar. O resultado era capacidade subutilizada ou custo por potência que nunca se aproveita.
O que muda na prática
Com o MIG, cada partição recebe computação, cache, memória e largura de banda próprios. Isso permite colocar um modelo diferente em cada fatia e escolher uma fração de um acelerador mais recente em vez de um dispositivo inteiro de qualquer geração.
O recurso é construído sobre as inference components, o mecanismo usado para publicar vários modelos em um mesmo endpoint e definir a computação de cada um. A partição é solicitada como um recurso, no mesmo lugar onde o componente já pede CPU e memória.
A limitação é importante: endpoints de modelo único, endpoints serverless e pools de instâncias heterogêneas não podem ser particionados. Modelos que exigem mais de uma GPU continuam precisando de dispositivos inteiros.
Isolamento em hardware, não em software
Segundo a AWS, o MIG divide uma GPU em até sete instâncias, dependendo do acelerador, e a separação acontece no hardware. A empresa lista as garantias que isso traz: latência previsível, porque cada partição tem largura de banda de memória dedicada e o pico de tráfego de um modelo não aparece no p99 de outro; isolamento de falhas, mantendo travamentos e erros de memória dentro da partição afetada; capacidade dimensionada, com fatias menores para modelos pequenos e médios e a possibilidade de misturar tamanhos em um mesmo dispositivo; ausência de cold start, já que cada modelo permanece carregado em sua partição, sem penalidade de carga ou despejo; e isolamento entre inquilinos, com proteção de memória aplicada em hardware, o que simplifica revisões de segurança e conformidade.
Há também um efeito colateral útil para planejamento: uma partição se comporta da mesma forma independentemente dos vizinhos, o que torna testes de carga mais próximos da produção. O custo de GPU passa a ser mapeado com clareza para um modelo, um time ou um inquilino.
Alternativas que já existiam
Antes do anúncio, quem tinha mais modelos do que aceleradores dispunha de três caminhos. Rodar menos endpoints e maiores, com batching mais agressivo, aumenta a utilização, mas só funciona quando os modelos são intercambiáveis, o que não é o caso de uma carteira de variantes ajustadas por fine-tuning ou de modelos por cliente.
Usar multi-model endpoints carrega e descarrega modelos de uma GPU compartilhada sob demanda, o que serve para tráfego esparso e em picos, mas sem isolamento: uma requisição pesada em um modelo afeta os demais, e o modelo não carregado paga penalidade na primeira chamada. A terceira saída era migrar para Kubernetes autogerenciado, onde o MIG funciona, mas às custas de versionamento de drivers, configuração de partições, plugin de dispositivo, escalonamento e consistência em toda a frota.
O particionamento tem fronteiras claras. O número máximo de partições depende do acelerador e nunca passa de sete.
O MIG só permite alterar o layout enquanto as partições estão ociosas e, no SageMaker AI, isso significa escolher o layout no momento da criação do endpoint. Dentro desses limites, o cliente obtém o isolamento de GPUs separadas sem dedicar uma GPU a cada modelo.
Por que isso importa
Para equipes que servem muitos modelos, variantes de fine-tuning, modelos por tenant, pipelines com modelos especializados,, o anúncio reduz a distância entre o que a GPU oferece e o que o modelo consome. A AWS afirma ter medido o desempenho das partições contra uma GPU inteira de geração anterior para demonstrar o ganho de granularidade, argumento que interessa diretamente a quem discute custo por inferência.
O ponto central, porém, é operacional: recursos que antes exigiam uma plataforma de orquestração própria passam a ser solicitados dentro do próprio endpoint, sem driver, plugin ou escalonador intermediário.
