Esse é o primeiro post de uma série onde vou traduzir o mundo de AI pra linguagem que engenheiros de infraestrutura já falam. Se você é o tipo de profissional que configura VMs, monta pipelines de CI/CD e acorda de madrugada quando o Nagios dispara, esse conteúdo é pra você.
A série é baseada no meu livro open-source AI for Infrastructure Professionals, adaptada e expandida aqui em português.
tl;dr: AI não pede que você vire data scientist. Pede que você aplique o que já sabe de compute, rede, segurança, observabilidade e custos num workload novo. O jargão muda. Os fundamentos continuam.
A mensagem de segunda-feira de manhã
São 8:47 da manhã de uma segunda-feira. Você está no meio do seu café, revisando um plano de Terraform pra um redesign de rede, quando uma mensagem no Slack acende sua tela. É do líder do time de data science:
“Fala, precisamos de 8 VMs com GPU provisionadas até quarta pra um job de fine-tuning. Também precisamos de um private endpoint pra API de inferência do modelo, e você consegue configurar monitoramento de TPM? Valeu!”
Você lê duas vezes. VMs com GPU? Fine-tuning? Você sabe o que é um private endpoint, já configurou centenas. Monitoramento? É seu pão de cada dia. Mas o que diabos é “TPM” nesse contexto? Não é Trusted Platform Module. É Tokens Per Minute, uma métrica de throughput pra modelos de linguagem. Você não sabe disso ainda, mas tudo bem.
Mas repara: todo o resto naquele pedido é pura infraestrutura.
Provisionar compute. Configurar segurança de rede. Montar observabilidade. Você faz isso há anos. A única diferença é o tipo de workload.
AI ainda é só mais um workload
Vou ser direto. Se você tirar os buzzwords, AI é um workload. Consome compute, storage e rede, igual a qualquer outro workload que você já gerenciou. O que muda é a forma desse consumo: mais paralelismo, datasets maiores e métricas de performance diferentes.
A pilha de AI continua cabendo em três camadas que você já conhece:
| Camada AI | O que faz | Seu equivalente em infra |
|---|---|---|
| Dados | Alimenta o modelo com exemplos | Storage: Blob, Data Lake, NFS, bancos de dados |
| Modelo | Aprende padrões e faz predições | A aplicação, seu binário compilado rodando em compute |
| Infraestrutura | Sustenta tudo por baixo | Seu domínio: compute, rede, segurança, observabilidade |
O modelo é a aplicação. Os dados são o que ele consome e produz. A infraestrutura é o que faz isso rodar com segurança, previsibilidade e escala. Essa parte é sua.
Como traduzir AI pra linguagem de infra
Em 2014, quando eu comecei a escrever sobre Docker aqui neste blog, a primeira coisa que fiz foi traduzir os conceitos pra algo que sysadmins já entendiam. Vou fazer a mesma coisa agora com AI.
Quando alguém do time de AI usar um jargão que você não conhece, mapeia de volta pro que você já sabe:
| Conceito de AI | Equivalente em infra | Por que funciona |
|---|---|---|
| Modelo treinado | Binário compilado | É um artefato estático produzido por um processo de build, depois publicado pra servir requisições |
| Treinar um modelo | Job batch | Processo longo, intensivo em compute, que lê dados e produz um artefato de saída |
| Inferência | Uma chamada de API | Requisição entra, o modelo processa, resposta sai. Igual a qualquer microserviço |
| Fine-tuning | Patch de um binário | Você pega um artefato existente e ajusta pro seu ambiente |
| Dataset | Banco de dados / Data Lake | Input estruturado do qual o workload depende |
| Pipeline de treinamento | Pipeline de CI/CD | Workflow automatizado: ingestão → processamento → build → validação → deploy |
| Model registry | Repositório de artefatos | Armazenamento versionado pra artefatos deployáveis, tipo ACR, mas pra modelos |
| Cluster GPU | Compute de alta performance | Hardware especializado alocado pra workloads pesados |
Dica de reunião: quando o time de data science começar a falar de “epochs”, “hyperparameters” e “loss functions”, não entra em pânico. Esses são os knobs de tuning deles, o equivalente dos seus connection pool sizes, cache TTLs e thresholds de autoscale. Você não precisa dominar os knobs deles. Precisa entender o que esses knobs pedem da sua infraestrutura.
O que muda e o que permanece
A boa notícia é simples: infraestrutura de AI não fica em outro planeta. É mais pra um bairro novo numa cidade que você já conhece. As ruas seguem o mesmo grid, os serviços continuam parecidos, mas os prédios são diferentes e os moradores gastam bem mais energia.
O que muda
| Dimensão | Infra tradicional | Infra de AI |
|---|---|---|
| Compute | CPUs, VMs de propósito geral | GPUs (NVIDIA T4, A100, H100), nós multi-GPU |
| Storage | SSD/HDD, managed disks | Data Lakes, Blob com alta taxa de leitura, NVMe local pra scratch |
| Rede | 1 a 25 GbE Ethernet | InfiniBand (até 400 Gb/s), RDMA, comunicação GPU-to-GPU |
| Deploy | VMs, App Services, containers | Endpoints de inferência, model-as-a-service, containers com GPU |
| Observabilidade | CPU %, memória, disk I/O | GPU utilization, VRAM, tokens por segundo, time-to-first-token |
| Custo | $/hora por VM | $/hora por GPU, além de PTUs em serviços gerenciados |
O que não muda
E isso importa muito. Os fundamentos abaixo não mudam só porque o workload roda em GPU:
- Segurança: segmentação de rede, private endpoints, identity management, criptografia. Uma VM com GPU ainda precisa de NSG. Uma API de inferência ainda precisa de autenticação.
- Rede: VNets, subnets, DNS, load balancing. Os pacotes continuam fluindo do mesmo jeito.
- Infrastructure as Code: Bicep, Terraform, ARM templates. VMs com GPU ainda são recursos Azure com propriedades e parâmetros.
- Monitoramento: você ainda vai setar thresholds, construir dashboards e responder a incidentes. As métricas só mudam de nome.
- Gestão de custos: budgets, tagging, right-sizing. Em AI, cost governance costuma ficar ainda mais importante.
Alerta de produção: as falhas mais comuns em sistemas de AI em produção raramente são problemas de acurácia do modelo. São os mesmos vilões de sempre: disco cheio, timeout de rede, certificado expirado, permissão RBAC faltando. Seus instintos continuam valendo.
Por que AI precisa de você (e não o contrário)
A indústria de AI tem um problema de pessoal, e não é o que muita gente imagina. Data scientist que sabe montar um modelo em notebook existe aos montes. O gargalo está em pegar esse modelo e fazer ele rodar de forma confiável em produção.
Na minha experiência trabalhando com startups e enterprises na Microsoft, eu vejo esse padrão o tempo todo:
GPU sprawl desgovernado. Um data scientist pede 4 VMs Standard_NC96ads_A100_v4 pra um experimento de treinamento. Sem resource locks, sem alertas de orçamento, sem tagging. Três semanas depois, as VMs ainda estão rodando. Ninguém lembra quem provisionou ou se o experimento terminou. Custo mensal: dezenas de milhares de dólares, dependendo da região e do tipo de contrato.
Endpoints de inferência expostos. O time de ML publica um modelo num managed endpoint com IP público. Sem private endpoint, sem WAF, sem API Management. O modelo acaba respondendo com lógica proprietária de negócio pra quem não deveria nem chegar perto dele.
Observabilidade cega. O time monitora acurácia do modelo, mas não a saúde da infraestrutura. Quando a latência de inferência sobe de 200 ms pra 8 segundos, ninguém consegue dizer se é o modelo, o compute, a rede ou um noisy neighbor.
O fim de semana de quase $50K em GPU: um time provisionou 8 VMs
Standard_ND96isr_H100_v5numa sexta à tarde pra um training run que deveria terminar no sábado de manhã. O job caiu às 3 da manhã por erro de configuração no storage de checkpoints, mas as VMs continuaram rodando. Ninguém tinha configurado auto-shutdown nem alerta de budget. Surpresa na segunda: $47.000+ em compute (8 × preço-hora da VM × 60 horas de cluster ocioso). Um engenheiro de infraestrutura teria colocado auto-shutdown, alerta de budget e uma política simples pros checkpoints. Quinze minutos de trabalho de infra teriam evitado quase todo o prejuízo.
Mãos na massa: seu primeiro reconhecimento de AI
Você não precisa treinar um modelo nem escrever Python. Precisa descobrir que compute GPU está disponível pra você e quais são os limites da sua subscription. Isso é reconhecimento. É o mesmo primeiro passo que você faria antes de arquitetar qualquer workload novo.
Descubra as VMs com GPU na sua região
az vm list-skus \
--location eastus2 \
--resource-type virtualMachines \
--query "[?starts_with(name, 'Standard_N')].{SKU:name}" \
-o table
Isso lista a família Standard_N, que inclui as VMs aceleradas por GPU no Azure. Preste atenção em três prefixos:
- NC: GPUs otimizadas pra compute, treinamento e inferência
- ND: GPUs high-end pra deep learning distribuído com InfiniBand
- NV: GPUs pra visualização e inferência leve
Verifique sua quota de GPU
az vm list-usage --location eastus2 --output table | grep -E "NC|ND|NV"
No Windows/PowerShell, troque
grep -E "NC|ND|NV"porSelect-String -Pattern "NC|ND|NV".
Se sua quota é zero pra tudo, você vai precisar solicitar aumento antes de qualquer provisionamento. Esse é exatamente o tipo de trabalho de infra que o time de data science não sabe, e nem quer saber, fazer.
Fechando o loop
Quando aquela mensagem chegar na segunda-feira de manhã, você não precisa fingir que virou cientista de dados no fim de semana. Você só precisa traduzir o pedido: GPU é compute, private endpoint é rede, TPM é observabilidade e custo. O workload é novo. O trabalho de infra continua sendo o mesmo.
Leitura complementar
- Use GPUs on Azure Kubernetes Service (AKS)
- NVIDIA GPU Driver Extension para Linux
- Cost management alerts no Azure
No próximo post
Vou falar sobre dados e storage pra workloads de AI, que é a peça que quase todo mundo ignora e que vira gargalo de performance em boa parte dos projetos de AI que eu vejo.
O livro completo está disponível de graça em ai4infra.com.
Esse post faz parte da série AI para Engenheiros de Infraestrutura, baseada no livro AI for Infrastructure Professionals. Novos posts toda semana.