Esta semana em cloud (10–16/ago): o Kubernetes ganhou a inferência antes de aprender a contar GPU

Q: O DRA já resolve o compartilhamento de GPU no meu cluster?

Resolve a parte da alocação, não a parte da densidade. O Dynamic Resource Allocation chegou a disponibilidade geral no Kubernetes v1.34, lançado em setembro de 2025, e substituiu o modelo de device plugin estático por uma API neutra de fornecedor, em que o cluster entende topologia e restrições de hardware em vez de apenas contar dispositivos. O que ele ainda não entrega são os controles finos de fracionamento que serving denso de LLM exige. Na prática, quem precisa colocar vários modelos pequenos na mesma placa continua dependendo dos mecanismos da NVIDIA: time-slicing para cargas de baixa criticidade, MPS para throughput entre workloads confiáveis e MIG quando é necessário isolamento em hardware. A recomendação é tratar DRA como a base de agendamento que você quer adotar agora, e a estratégia de fracionamento como decisão separada, guiada pelo perfil de carga — não como consequência automática do upgrade de versão.

Q: Devo migrar meus jobs de GPU do Slurm para Kubernetes?

Só se o seu problema for o de plataforma, não o de fila. A comparação publicada pela Oracle nesta semana entre OKE e Slurm chega a uma conclusão que vale além da OCI: não existe escolha universal. Kubernetes atende melhor quem já tem plataforma cloud-native, precisa de inferência como serviço e quer MLOps no mesmo modelo de deploy do resto da empresa. Slurm continua mais adequado a HPC, processamento em lote e filas compartilhadas entre times de pesquisa, onde a disciplina de fila e a contabilidade de horas de GPU são o produto. O padrão que mais aparece em operação real é híbrido: cada escalonador governa o que faz melhor, com a fronteira desenhada por tipo de carga em vez de por preferência de time. Migrar batch consolidado para Kubernetes só para reduzir o número de ferramentas costuma trocar um problema resolvido por um problema novo.

Q: Como descubro quanto custa cada modelo que estou servindo?

Rastreando por inferência, não por nó. O OpenCost 1.121.0, publicado no início de agosto, introduziu métricas que atacam exatamente essa lacuna: llm_total_hourly_cost, com o custo horário por modelo, e llm_cost_per_million_tokens, que separa custo de entrada e de saída. Mais importante que as métricas é a distinção conceitual que elas carregam. Custo por alocação inclui tudo que se gasta para manter o modelo disponível, memória de GPU e infraestrutura compartilhada inclusas; custo por uso considera apenas a inferência ativa, e é esse o número comparável com o preço de uma API externa. Confundir os dois é como uma decisão de build versus buy termina errada: compara-se o custo total de manter capacidade reservada com o preço marginal de quem só cobra o que você consome. A integração se apoia em métricas de throughput de tokens do vLLM, e a implementação foi testada com 109 GPUs e 30 modelos.

Q: Os novos cabos submarinos do Google reduzem a latência da minha inferência no Brasil?

Não diretamente, e vale ser preciso sobre isso. Os três sistemas anunciados em 11 de agosto — Alisios, Canoa e OlaLuz — convergem na República Dominicana e ligam Chile, Panamá, Bermudas e Flórida, com interconexão às regiões de cloud na Carolina do Sul e na Virgínia. Nenhum deles aterra no Brasil. O que muda é a malha: junto com um novo ramo do Firmina e com os sistemas Curie, Nuvem e Sol já existentes, eles formam a iniciativa Americas Connect e adicionam rotas alternativas na região. O ganho para uma operação brasileira é de resiliência, não de milissegundos: mais caminhos independentes reduzem o impacto de um rompimento ou de uma manutenção em um trecho específico. Para latência de inferência, o que decide continua sendo a distância até a região onde a GPU está, e essa conta não mudou nesta semana.

Q: Vale rodar GPU em spot para reduzir custo?

Vale avaliar, e o dado mais interessante é o de quanto pouca gente faz isso: a adoção de spot para cargas de GPU foi praticamente inexistente ao longo de 2025, com menos de 2% das GPUs rodando nessa modalidade. A resistência tem uma razão legítima — interrupção no meio de um treinamento longo, ou de uma requisição de inferência, custa mais do que o desconto economiza. Só que essa razão vale para uma parte das cargas, não para todas. Inferência com réplicas suficientes, processamento em lote com checkpoint e ambientes de avaliação toleram bem a interrupção, desde que o tempo de recuperação seja curto. É aí que a discussão de spot encontra a de cold start: se subir uma réplica nova leva minutos porque o modelo precisa ser baixado de novo, spot é inviável; se o carregamento vem de cache compartilhado em segundos, a conta muda de sinal. Ataque o cold start primeiro, o desconto vem depois.

Banner - Esta semana em cloud (10–16/ago): o Kubernetes ganhou a inferência antes de aprender a contar GPU

TL;DR — A CNCF revelou a programação do KubeCon North America com uma trilha inédita de AI Inference + Agentic, ancorada no dado de que 66% das organizações com IA generativa já dependem do Kubernetes. Na mesma semana veio o contraponto: a plataforma conta GPU inteira e trata pod como descartável. Oracle comparou OKE e Slurm, Microsoft mostrou cold start 4,6x menor com KV cache no storage. A inferência deixou de ser problema de modelo.

A semana passada foi sobre onde você resolve a sua rede. Esta foi sobre onde a sua inferência mora — e a resposta chegou em duas partes que se contradizem de propósito.

Na segunda-feira, a CNCF publicou a programação do KubeCon + CloudNativeCon North America com uma trilha nova em folha: AI Inference + Agentic. Na sexta, a comunidade cloud-native respondeu com um texto de título honesto: o Kubernetes não foi construído para GPUs.

As duas coisas são verdadeiras ao mesmo tempo, e é exatamente aí que está a pauta desta semana. O Kubernetes venceu a disputa por ser o substrato onde a IA roda em produção — antes de resolver como contar, dividir e cobrar o recurso mais caro do datacenter.

Por que o Kubernetes virou o substrato da inferência?

Os números do anúncio da CNCF explicam a trilha: 82% dos usuários de containers rodam Kubernetes em produção, e 66% das organizações com cargas de IA generativa dependem da plataforma. A trilha reúne o que já virou stack padrão de serving — vLLM, KServe, Ray, OpenTelemetry — mais Cilium e eBPF do lado da rede e do isolamento. O evento acontece de 9 a 12 de novembro, em Salt Lake City.

Não é uma trilha sobre modelos. É sobre agendamento de GPU, observabilidade de inferência e workflows de agentes: a lista de problemas de quem já passou da POC e precisa manter aquilo de pé com orçamento previsível.

O contraponto publicado na sexta é o outro lado da mesma moeda. O modelo de recursos do Kubernetes trata a GPU como unidade indivisível: um pod que pede nvidia.com/gpu: 1 ocupa o acelerador inteiro, mesmo consumindo uma fração da memória e do processamento. Somado à premissa de que pod é descartável — perfeita para um serviço web, hostil para um processo que carrega dezenas de gigabytes de pesos antes de responder a primeira requisição —, isso produz o padrão que aparece em toda fatura de cluster de IA: GPU ociosa que continua sendo cobrada.

O caminho de saída existe e está em andamento. O DRA chegou a GA no Kubernetes v1.34, em setembro de 2025, e substituiu o device plugin estático por uma API neutra que entende topologia de hardware. O que ele ainda não cobre é o fracionamento fino que serving denso exige — para isso, continuam valendo time-slicing, MPS e MIG, cada um com um compromisso diferente entre densidade e isolamento.

Mecanismo	O que entrega	Quando faz sentido
DRA (GA no v1.34)	Alocação declarativa com consciência de topologia, sem device plugin	Base de agendamento para qualquer cluster novo com GPU
Time-slicing	Várias cargas alternando na mesma GPU, sem isolamento	Desenvolvimento, avaliação, cargas de baixa criticidade
MPS	Execução concorrente com throughput maior	Workloads confiáveis do mesmo time, sem exigência de isolamento
MIG	Partições isoladas em hardware	Multi-tenant real, onde vazamento de desempenho é inaceitável

A pergunta a levar para a sua arquitetura não é qual deles é melhor, e sim quantas GPUs inteiras você está pagando hoje para servir modelos que caberiam em metade de uma.

OKE ou Slurm: quem escalona a fila de GPU?

A Oracle publicou nesta semana uma comparação direta entre OKE e Slurm para cargas de GPU, e o mérito do texto é não fingir que existe resposta universal.

Kubernetes ganha quando o problema é de plataforma: inferência exposta como serviço, MLOps no mesmo modelo de deploy do resto da empresa, times de produto consumindo GPU por self-service. Slurm ganha quando o problema é de fila: HPC, processamento em lote, contabilidade de horas de GPU entre times de pesquisa que disputam o mesmo pool.

O desenho híbrido — cada escalonador governando o que faz melhor — costuma ser a configuração honesta, e não a indecisão que parece. A fronteira se desenha por tipo de carga, não por preferência de ferramenta.

Vale notar o que isso tem em comum com um debate que já é velho no Kubernetes: escalar pela métrica errada custa caro. É a mesma armadilha que discutimos em HPA por CPU não basta: autoscaling por sinal com KEDA — com o agravante de que, com GPU, o erro não desperdiça centavos de CPU, e sim a linha mais cara da fatura.

Quer saber quanto da sua GPU está sendo paga sem ser usada? Podemos medir isso com você.

Onde o custo da inferência se esconde?

Não está no preço do token. Está no tempo em que a placa fica reservada sem produzir nada.

A Microsoft mostrou a magnitude do problema ao integrar o Azure Blob Storage ao NVIDIA Dynamo no AKS: com o ModelExpress servindo os pesos a partir do Blob, o cold start caiu até 4,6x, e o offloading de KV cache via NIXL melhorou o TTFT em até 2,8x. Traduzindo para a operação: o gargalo de subir uma réplica nova deixou de ser a GPU e passou a ser o caminho até o modelo.

Isso muda três decisões de uma vez. Autoscaling de inferência vira viável, porque a réplica nova entra em serviço em tempo aceitável. Spot deixa de ser proibido por definição — e vale lembrar que menos de 2% das GPUs rodaram em spot ao longo de 2025, um número que diz mais sobre medo de interrupção do que sobre inviabilidade técnica. E o rateio de custo por time finalmente encontra uma unidade que faz sentido.

Sobre rateio, a peça complementar é a que citamos na edição passada e que ganha outro significado agora: o OpenCost 1.121.0 trouxe llm_total_hourly_cost e llm_cost_per_million_tokens, separando custo de entrada e de saída. O conceito que importa é a distinção entre custo por alocação — tudo que se gasta para manter o modelo disponível — e custo por uso, que considera apenas a inferência ativa e é o único número comparável com o preço de uma API externa.

Quem compara o custo total de capacidade reservada com o preço marginal de um provedor de API chega sempre à mesma conclusão equivocada, e ela custa uma migração inteira para ser desfeita.

A inferência tem endereço?

Tem, e a semana insistiu nisso por dois caminhos diferentes.

O primeiro é de rede. Um texto da Equinix argumentou que a localização da infraestrutura de IA pesa tanto quanto a escolha de hardware ou de modelo: agente que consulta ferramentas, memória e serviços externos multiplica idas e vindas, e cada milissegundo de distância é cobrado várias vezes na mesma tarefa.

O segundo é físico. O Google anunciou a iniciativa Americas Connect, com três sistemas de cabos submarinos novos — Alisios, Canoa e OlaLuz — mais um ramo do Firmina. Eles convergem na República Dominicana e ligam Chile, Panamá, Bermudas e Flórida, com interconexão às regiões de cloud na Carolina do Sul e na Virgínia.

Sejamos precisos, porque a manchete se presta a leitura otimista: nenhum dos três novos cabos aterra no Brasil. Junto com Curie, Nuvem e Sol, eles adensam a malha regional, e o ganho para uma operação brasileira é de resiliência — mais rotas independentes, menos exposição a um rompimento único. Latência até a GPU continua sendo função da distância até a região onde ela está.

Do lado do datacenter, a Microsoft publicou sua leitura full-stack do problema: co-design de silício, software, racks, refrigeração, energia e rede, com 800 VDC e resfriamento líquido no centro da conversa. É um lembrete de que a restrição da próxima geração de IA não é o chip, e sim o que se consegue entregar de energia e dissipação por rack — algo que, no Brasil, entra na conta de qualquer projeto de colocation antes de entrar na de arquitetura.

Fecha a semana a pergunta de governança, publicada pela CNCF: quem deve ser dono do pipeline de IA? A tese é que a disputa entre LLMOps e platform engineering é menos produtiva que definir camadas de responsabilidade, e que o risco real é o shadow AI — times montando pipelines paralelos sem governança. A saída proposta é tratar LLMOps como mais uma capability da plataforma, exposta via self-service com política, custo e auditoria embutidos. É a mesma lógica que defendemos em IA agêntica deixou de ser POC: governança que não é self-service vira contorno.

O que mais mereceu atenção

Cloud native. O Cloud Native Buildpacks graduou na CNCF, o que estabelece um padrão maduro para transformar código em imagem de container sem Dockerfile escrito à mão — e, com ele, uma base mais defensável de supply chain. Também na CNCF, um relato de pipeline de upgrade auto-curativa de Kubernetes com Kairos, GitOps e Renovate, com janela de onze minutos sem intervenção humana, e um guia de Dragonfly em modo leve, distribuição P2P de imagens sem a stack de banco de dados — útil justamente para quem sofre com imagens gigantes de IA.

Observabilidade. A coleta de métricas do control plane do AKS via Managed Prometheus chegou a GA. Métrica de control plane é a peça que costuma faltar no diagnóstico de cluster gerenciado, quando o sintoma aparece no workload mas a causa está na API server.

Storage e ciclo de vida. O Azure colocou em GA o live resize para Premium SSD v2 e Ultra Disks compartilhados, expansão sem downtime. Na direção oposta, o Databricks Runtime 10.4 LTS chegou ao fim da vida, e a Oracle publicou autoscaling para OpenShift no OCI — três lembretes de que ciclo de vida é trabalho contínuo, não evento.

Segurança. O Google detalhou seu roadmap de criptografia pós-quântica, com o cronograma de migração dos serviços gerenciados. Não é urgência para este trimestre, mas é a informação que deveria estar no seu inventário de criptografia antes de a urgência chegar.

O que isso muda para quem opera infra no Brasil?

Três decisões que cabem nesta semana:

Meça a ociosidade da sua GPU antes de comprar a próxima. Se você não consegue responder quanto da placa está sendo usada por modelo, a resposta padrão do Kubernetes é "uma inteira por pod" — e é isso que está na fatura. Rastreamento por inferência e uma estratégia explícita de fracionamento costumam liberar capacidade que já foi paga.
Ataque o cold start antes de discutir spot ou autoscaling. Enquanto subir uma réplica levar minutos, nenhuma das duas conversas avança. Cache compartilhado de pesos e offloading de KV cache transformam elasticidade de promessa em operação — e é o pré-requisito de qualquer economia real.
Decida a fronteira entre plataforma e fila agora, não no primeiro conflito. Kubernetes para serving e MLOps, escalonador de batch para pesquisa e HPC é um desenho legítimo. O que não é legítimo é deixar a fronteira indefinida até que dois times disputem o mesmo pool de GPU no fim do trimestre.

O padrão da semana é conhecido de quem acompanha o cloud-native há tempo suficiente: a plataforma vence a disputa de adoção antes de resolver o problema que a tornou necessária. Foi assim com storage, foi assim com rede, e está sendo assim com GPU. Quem trata isso como defeito espera a próxima versão. Quem trata como estágio mede o desperdício hoje e escolhe o mecanismo que cabe na sua carga — porque a fatura de GPU não espera o roadmap upstream.

Perguntas Frequentes

O DRA já resolve o compartilhamento de GPU no meu cluster?
Resolve a alocação, não a densidade. O DRA chegou a GA no Kubernetes v1.34, de setembro de 2025, substituindo o device plugin estático por uma API neutra de fornecedor com consciência de topologia. O que ele ainda não entrega são os controles finos de fracionamento que serving denso de LLM exige. Quem precisa colocar vários modelos pequenos na mesma placa continua dependendo dos mecanismos da NVIDIA: time-slicing para cargas de baixa criticidade, MPS para throughput entre workloads confiáveis, MIG quando é preciso isolamento em hardware. Trate DRA como a base de agendamento a adotar agora e o fracionamento como decisão separada, guiada pelo perfil de carga — não como consequência automática do upgrade.

Devo migrar meus jobs de GPU do Slurm para Kubernetes?
Só se o seu problema for de plataforma, não de fila. A comparação da Oracle entre OKE e Slurm conclui que não existe escolha universal, e isso vale além da OCI. Kubernetes atende melhor quem já tem plataforma cloud-native, precisa de inferência como serviço e quer MLOps no mesmo modelo de deploy do resto da empresa. Slurm segue mais adequado a HPC, batch e filas compartilhadas, onde disciplina de fila e contabilidade de horas de GPU são o produto. O padrão mais comum em operação real é híbrido, com a fronteira desenhada por tipo de carga. Migrar batch consolidado só para reduzir o número de ferramentas troca um problema resolvido por um novo.

Como descubro quanto custa cada modelo que estou servindo?
Rastreando por inferência, não por nó. O OpenCost 1.121.0 introduziu llm_total_hourly_cost, com custo horário por modelo, e llm_cost_per_million_tokens, separando entrada e saída. O que importa mais que as métricas é a distinção entre custo por alocação — tudo que se gasta para manter o modelo disponível, memória de GPU inclusa — e custo por uso, que conta apenas a inferência ativa e é o número comparável com o preço de uma API externa. Confundir os dois é como uma decisão de build versus buy termina errada. A integração usa métricas de throughput de tokens do vLLM e foi testada com 109 GPUs e 30 modelos.

Os novos cabos submarinos do Google reduzem a latência da minha inferência no Brasil?
Não diretamente. Alisios, Canoa e OlaLuz convergem na República Dominicana e ligam Chile, Panamá, Bermudas e Flórida, com interconexão às regiões de cloud na Carolina do Sul e na Virgínia — nenhum deles aterra no Brasil. Junto com um novo ramo do Firmina e com Curie, Nuvem e Sol, eles formam a Americas Connect e adensam a malha regional. O ganho para uma operação brasileira é de resiliência: mais rotas independentes, menos exposição a um rompimento único. Para latência de inferência, o que decide continua sendo a distância até a região onde a GPU está.

Vale rodar GPU em spot para reduzir custo?
Vale avaliar, e o dado revelador é quão pouco isso acontece: menos de 2% das GPUs rodaram em spot ao longo de 2025. A resistência tem razão legítima — interrupção no meio de um treinamento longo custa mais que o desconto economiza —, mas ela vale para parte das cargas, não para todas. Inferência com réplicas suficientes, batch com checkpoint e ambientes de avaliação toleram bem a interrupção, desde que a recuperação seja rápida. É aí que spot encontra cold start: se subir uma réplica leva minutos porque o modelo é baixado de novo, spot é inviável; se o carregamento vem de cache compartilhado em segundos, a conta muda de sinal.

Fontes: