Cargas de IA não são apenas prompts e modelos. Elas envolvem containers, GPUs, filas, storage, secrets, roteamento, jobs em lote, rollouts, dashboards e domínios de falha. Kubernetes importa porque oferece um plano de controle compartilhado para rodar essa infraestrutura bagunçada com regras repetíveis.
A pesquisa anual Cloud Native 2025 da CNCF, publicada em janeiro de 2026, diz que Kubernetes se consolidou como o sistema operacional de fato para IA, com 82% dos usuários de containers rodando Kubernetes em produção. Um post complementar da CNCF também informa que 66% das organizações usam Kubernetes para hospedar cargas de IA generativa. Esses números mostram a infraestrutura de IA saindo do experimento e indo para plataformas compartilhadas.
Isso não significa que todo projeto de IA precise de Kubernetes no primeiro dia. Um assistente local pequeno pode rodar em uma máquina. Uma API simples pode rodar em Worker ou VM. Kubernetes fica interessante quando a carga precisa de scheduling, isolamento, GPUs, autoscaling, rollouts, ownership de múltiplos times e observabilidade entre serviços.
Cargas web tradicionais competem por CPU e memória. Cargas de IA frequentemente competem por aceleradores escassos. A documentação do Kubernetes explica que fornecedores de GPU expõem dispositivos por meio de device plugins, e os pods solicitam recursos como nvidia.com/gpu. Isso torna GPUs agendáveis, mas não as torna baratas, infinitas ou automaticamente eficientes.
A plataforma precisa responder perguntas práticas: qual modelo recebe o nó caro, quais jobs podem esperar em fila, quais workloads podem rodar em CPU, quais modelos podem escalar para zero e quais serviços precisam ficar aquecidos porque cold start é lento demais. Platform engineering para IA é parte scheduling e parte economia de produto.
Um bom cluster de IA não trata todo pod da mesma forma. Inferência online quer baixa latência e capacidade previsível. Embeddings em lote toleram filas. Treinamentos podem rodar por horas. Preparação de dados costuma pesar em CPU e IO. Serviços de observabilidade e APIs não devem ser expulsos porque um job de modelo consumiu o cluster.
Para uma implementação prática, eu desenharia uma pequena plataforma de IA em Kubernetes com três faixas: serviço de inferência online, worker de embeddings baseado em fila e API de plataforma. O sistema teria node pools separados, resource requests e limits, quotas por namespace, gestão de secrets, dashboards e gates de rollout.
O primeiro dashboard deveria mostrar os sinais chatos que mantêm sistemas de IA vivos: p95 de latência, volume de requisições, utilização de GPU, profundidade da fila, versão do modelo, taxa de erro, custo de compute ou tokens, cold starts e status de deploy.
Cargas de IA criam novos formatos de falha. Um rollout ruim de modelo pode aumentar latência sem derrubar pods. Um banco vetorial pode devolver contexto antigo. Um nó GPU pode parecer saudável para o Kubernetes enquanto o model server está saturado. Um batch job pode prejudicar inferência online se as quotas forem fracas. Uma avaliação sem limite pode queimar o orçamento mensal.
Kubernetes oferece os blocos. Platform engineering transforma esses blocos em guardrails: namespaces, quotas, admission policies, estratégias de deploy, probes, autoscaling, priority classes e dashboards alinhados ao modo como o produto de IA realmente falha.
| Falha | Sintoma | Controle de plataforma |
|---|---|---|
| Falta de GPU | Pods de inferência pendentes ou jobs atrasados. | Node pools, quotas, priority classes e política de fila. |
| Rollout ruim | Latência sobe ou qualidade cai após deploy. | Canary, métricas por versão e rollback automático. |
| Fila sobrecarregada | Embeddings atrasam e dados ficam antigos. | Alertas de fila, autoscaling de workers e backpressure. |
| Custo fora de controle | Horas de GPU ou inferências disparam. | Alertas de orçamento, rate limits e custo por namespace. |
| Gap de observabilidade | Pods verdes, mas experiência ruim. | SLIs de latência, saturação, versão de modelo e resultado de negócio. |
Kubernetes não é valioso para IA porque está na moda. Ele é valioso quando vira a camada operacional comum para workloads difíceis: serving, filas, GPUs, storage, rollouts, políticas e observabilidade. A vitória real não é rodar um modelo em um pod. É dar ao sistema inteiro de IA um plano de controle confiável.
Artigo sobre Kubernetes como sistema operacional para cargas de IA cobrindo GPU scheduling, device plugins, platform engineering, model serving, node pools, workers com fila, observabilidade, autoscaling, domínios de falha e infraestrutura cloud native para IA.