Esse é o primeiro post de uma série onde vou traduzir o mundo de AI para a 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.
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 pro 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 para 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.
No fundo, AI é só mais um workload
Vou ser direto. Se tirar os buzzwords, AI é um workload. Consome compute, storage e rede, igual a qualquer outro workload que você já gerenciou na vida. A diferença está na forma desse consumo: mais compute paralelo, datasets maiores, métricas de performance diferentes.
A pilha de AI funciona 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 é tudo que faz funcionar de forma confiável, segura e em escala. Essa última parte? É você.
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 para 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, deployado 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. Igualzinho qualquer microserviço |
| Fine-tuning | Patch de um binário | Você pega um artefato existente e customiza 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 → processa → build → valida → deploy |
| Model registry | Repositório de artefatos | Armazenamento versionado para 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 exigem da sua infraestrutura.
O que muda e o que permanece
A boa notícia: infraestrutura de AI não é um planeta diferente. É mais como um bairro novo numa cidade que você já conhece. As ruas seguem o mesmo grid, os serviços funcionam da mesma forma, mas os prédios são diferentes e os moradores têm necessidades incomuns.
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 throughput, NVMe local pra scratch |
| Rede | 1–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/segundo, time-to-first-token |
| Custo | $/hora por VM | $/hora por GPU (10-30× o custo de CPU), PTUs pra serviços gerenciados |
O que não muda
E isso é igualmente importante. Talvez mais. Esses fundamentos não mudam só porque o workload roda em GPUs:
- 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 ainda fluem da mesma forma.
- 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ó têm nomes diferentes.
- Gestão de custos: Budgets, tagging, right-sizing. Se alguma coisa, cost governance é mais crítico com workloads de AI.
⚠️ Alerta de produção: As falhas mais comuns em sistemas de AI em produção não 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 estão certos.
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 você imagina. Data scientists que sabem construir modelos em Jupyter notebooks tem de sobra. O que falta de verdade são engenheiros que conseguem pegar esses modelos e 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_NC24ads_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: $35.000+.
Endpoints de inferência expostos. O time de ML deploya um modelo num managed endpoint com IP público. Sem private endpoint, sem WAF, sem API management. O modelo serve respostas que incluem lógica proprietária de negócio.
Observabilidade cega. O time monitora acurácia do modelo mas não saúde da infraestrutura. Quando a latência de inferência sobe de 200ms pra 8 segundos, ninguém consegue dizer se é o modelo, o compute, a rede ou um noisy neighbor.
⚠️ O fim de semana de $50K em GPU: Um time provisionou 8 VMs
Standard_ND96asr_v4(GPUs A100) numa sexta à tarde pra um training run que deveria terminar no sábado de manhã. O job crashou às 3 da manhã por erro de configuração no checkpoint storage, mas as VMs continuaram rodando. Ninguém tinha configurado auto-shutdown ou alertas de budget. Surpresa na segunda: $53.000 em compute por 60 horas de GPU ociosa. Um engenheiro de infraestrutura teria configuradoauto-shutdown, setado alerta de budget a $5.000 e armazenado checkpoints em Blob com lifecycle policies. Quinze minutos de trabalho de infra teriam economizado $48.000.
Mãos na massa: seu primeiro reconhecimento de AI
Você não precisa treinar um modelo nem escrever Python. Precisa entender 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 --size Standard_N --output table
Isso filtra a família Standard_N, que inclui todas as VMs aceleradas por GPU no Azure. Preste atenção em três prefixos:
- NC: GPUs otimizadas pra compute, treinamento e inferência (NVIDIA T4, A100)
- ND: GPUs high-end pra deep learning distribuído com InfiniBand (A100, H100)
- NV: GPUs pra visualização e inferência leve (AMD Radeon, NVIDIA A10)
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.
No próximo post
Vou falar sobre dados e storage para workloads de AI, que é a peça que todo mundo ignora mas que acaba sendo o gargalo escondido de performance em praticamente todo projeto de AI que já vi.
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.