GPU deixa de ser indivisível: SageMaker fatia em até 7 e Kinference roteia por KV cache

GPU deixa de ser indivisível: SageMaker fatia em até 7 e Kinference roteia por KV cache

Duas mudanças anunciadas nos últimos dias atacam o mesmo desperdício, por lados opostos. A AWS passou a vender GPU em frações de hardware isolado no SageMaker. A Buoyant abriu um plano de controle que manda cada requisição para o servidor vLLM que já tem o cache daquele prompt. Nos dois casos, o gargalo deixa de ser "tenho GPU suficiente?" e passa a ser "estou usando os bytes e os ciclos que já paguei?".

Na AWS: uma GPU, até sete modelos, isolamento em silício

O anúncio é de 6 de novembro. O SageMaker Inference agora suporta NVIDIA Multi-Instance GPU (MIG), que corta um acelerador em partições com fração fixa de compute e bloco próprio de memória, com isolamento imposto no hardware — não é fatiamento por software como time-slicing.

O teto de partições depende do chip: até 7 em P4d (A100 40 GB) e P5 (H100 80 GB), até 4 em G7e e até 2 em G7. Só endpoints baseados em inference components se qualificam — endpoint de modelo único fica de fora. Disponibilidade inicial em regiões dos EUA, Europa e Ásia-Pacífico.

O número que importa vem do teste da própria AWS com Llama-3.1-8B-Instruct: uma partição de H100 (a AWS descreve o caso como metade de um H100) superou uma A100-40GB inteira em throughput e saiu de 18% a 34% mais barata por milhão de tokens de saída em cargas mais altas. A leitura correta é a da palavra "mais altas": existe um ponto de cruzamento. Abaixo dele, uma fatia pequena com pouca concorrência perde para a GPU inteira. Acima, a densidade ganha.

Um detalhe operacional que costuma passar batido: um ml.p4d.24xlarge tem oito A100 de 40 GB. No layout de exemplo da AWS, cada uma comporta três partições de 1g — 24 partições num único endpoint, em vez de oito modelos no máximo. É a diferença entre um cluster de 30 modelos pequenos e 30 GPUs ociosas.

Kinference: o cache vira critério de roteamento

O Kinference saiu em 4 de novembro, no blog do vLLM, sob Apache 2.0 (build atual v0.1.0-alpha.7). Ele não substitui o vLLM: senta na frente de uma frota de workers e decide o destino de cada requisição, considerando três sinais — ocupação de cache KV por prefixo, profundidade da fila e políticas declarativas (limite de tokens por tenant, roteamento por modelo).

O problema que ele resolve é chato e caro. Em sessões de agente e de código, o mesmo contexto de projeto volta a cada turno. Se o segundo request cai em outro worker, o cluster refaz o prefill daquele prefixo do zero. Pior: o cache antigo continua ocupando memória sem servir a ninguém. O Kinference faz o worker publicar eventos de cache via ZMQ e usa isso para prever qual máquina devolve o primeiro token mais rápido.

Os números são da Buoyant, em benchmark interno: 95% de redução no time to first token mediano em tráfego com prefixo compartilhado e 7,4x o throughput de pico de um Kubernetes Service simples. Condições de medição não estão publicadas em detalhe, e o próprio time rotula a implementação como alpha. Trate como direção, não como promessa — e note que o ganho é de prefill e de ocupação, não de decode. Se o seu tráfego é one-shot, com prompts distintos a cada chamada, você tende a ver pouco.

O contraponto: agentes projetam serving, mas tropeçam na validação

Dois papers do CMU publicados no arXiv em 4 de novembro dão o tom de ceticismo que esse tipo de ganho merece.

O ServerBench coloca agentes de código para projetar sistemas de serving de LLM sob carga real. O melhor resultado, com Claude Sonnet 5.5, entregou 4,87x o valor por dólar do baseline em vLLM rodando Gemma 4 E4B. Só que apenas 22 dos 33 sistemas construídos pelos agentes passaram na validação — ou seja, um terço dos "ganhos" não sobreviveu à checagem.

O CompressionBench segue o mesmo roteiro com compressão de modelo: seis modelos via Claude Code, oito horas e uma H200 NVL cada, 36 entregas e 29 aprovadas. Nas tarefas aprovadas, a perplexidade média ficou 3,4% acima do BF16 e a acurácia em três provas de conhecimento caiu de 79,56% para 77,33%. Um dos casos registra perplexidade melhor com GSM8K despencando de 88% para 72%. Tradução: métrica de compressão melhor não garante modelo melhor.

O que muda, em uma tabela

Leitura prática

Se você roda muitos modelos pequenos ou multi-tenant no SageMaker , vale recalcular com MIG: o ganho aparece quando cada modelo ocupa menos de uma GPU inteira. Antes, meça seu ponto de cruzamento com a concorrência real do endpoint, não com a média do dia.

Se você serve modelos abertos com sessões longas de agente , cache-aware routing é hoje a otimização com melhor relação esforço/resultado. Mas só depois de medir a fração de tráfego com prefixo repetido — sem isso, o roteamento não tem o que rotear.

Não adote versão alpha como camada crítica sem plano de rollback: o Kinference é v0.1.0-alpha.7 e depende de eventos de cache do vLLM.

Desconfie de multiplicador sem pilha declarada. Os papers do CMU mostram que a taxa de sistemas que sobrevivem à validação é o número mais importante do benchmark, não o pico.

Próximos passos

Acompanhe a documentação de preço por partição do SageMaker e as próximas releases do Kinference: os dois mudam a mesma conta, e quem medir primeiro negocia melhor.

Se você já roda vLLM, SGLang ou endpoint gerenciado, conte nos comentários qual stack e qual hardware estão no ar — e onde o custo por token dói mais hoje.

Fontes