Platform engineering para workloads de IA: rate limits, custo de inferência e guardrails
Quando IA vira infraestrutura, os problemas de plataforma ficam diferentes. O que aprendi gerenciando workloads de IA em escala: throttling, custo por token, fallbacks e como construir guardrails que funcionam.
Quando um time de produto começa a usar IA, o primeiro problema é de produto: o que construir? O segundo problema é de engenharia: como construir? O terceiro problema — o que o time de plataforma vê primeiro — é de infraestrutura: como rodar isso de forma confiável, previsível e com custo controlado?
É o terceiro problema que me ocupa agora.
O problema mais comum que encontrei em workloads de IA é a confusão entre latência de inferência e latência de serviço. Na maioria dos sistemas que opero, latência é determinística dentro de uma margem: se o banco responde em 5ms e o código não tem bug, o request retorna em <100ms. Em workloads de LLM, a latência é altamente variável — de 500ms a 30 segundos dependendo do modelo, do tamanho do prompt e do provider. Times que não calibram expectativas de latência para IA criam SLOs impossíveis de cumprir.
A primeira coisa que faço quando um time traz um workload de IA é ajudá-los a classificar o uso por tolerância de latência: interativo (precisa de resposta em <2s, limita os modelos elegíveis), assíncrono (pode esperar, usa modelos mais potentes com janela de custo maior) ou batch (roda offline, custo otimizado, sem pressão de latência). Essa classificação muda tudo: o modelo escolhido, o padrão de retry, o circuit breaker, o orçamento de custo.
Custo de inferência é o problema que mais surpreende times que não vêm de ML. Diferente de custo de compute (onde você paga por vCPU/hora), custo de LLM é por token — por entrada e por saída, com preços que variam por modelo. Um bug de prompt que duplica o contexto enviado pode dobrar o custo de uma operação. Uma feature que parece inocente — "vamos sumarizar todos os incidentes da semana" — pode gerar uma conta inesperada se não tiver controle de volume.
O padrão que adotei: todo workload de LLM tem um orçamento explícito em tokens/mês, um alert em 80% do orçamento e um hard limit com fallback — que pode ser usar um modelo mais barato, truncar o contexto, ou desabilitar a feature. Isso não é premature optimization — é o mesmo princípio que você aplica para qualquer recurso com custo variável e potencialmente ilimitado.
Guardrails são a área onde mais erros acontecem. O erro clássico é tratar o output de LLM como confiável. Não é. Um LLM pode retornar JSON malformado numa tentativa em mil, pode alunar um campo que não existe, pode gerar output que excede o tamanho esperado. Em produção, essas condições ocorrem. O sistema precisa ser construído para lidar com elas.
Na prática isso significa: sempre fazer parse com schema validation, nunca usar string interpolation direta do output do LLM em queries ou HTML sem sanitização, definir um tamanho máximo explícito de output e tratar como erro se exceder. Esses são guardrails básicos que todo engenheiro de produto deveria implementar, mas que frequentemente só aparecem quando o primeiro incidente acontece.
O guardrail mais sofisticado que implementei é detecção de loop em agentes. Quando um agente de IA tem capacidade de chamar ferramentas e tomar ações, ele pode entrar em loop — chamando a mesma ferramenta repetidamente sem progredir. Isso queima tokens, custa dinheiro e pode ter efeitos colaterais reais. O padrão é: log de cada ação, detecção de repetição no mesmo contexto, interrupção automática com alert.
Rate limits são o problema mais visível porque são os que aparecem como erro explícito. Providers de LLM têm limits por minuto, por dia e por tier de conta. O pattern de retry com exponential backoff é necessário mas não suficiente: você precisa de queue com prioridade para não deixar requests interativos esperando atrás de batch jobs.
O que funcionou no nosso caso: um proxy de LLM interno que absorve os detalhes de provider, faz rate limiting centralizado com filas por prioridade, e expõe uma API uniforme para os times. Isso desacopla os times dos limites específicos do provider e permite trocar de provider ou adicionar fallback sem mudar o código de produto.
É mais trabalho de plataforma, mas é o tipo de trabalho que paga dividendos quando o volume cresce.
Essa semana: Se você opera workloads de IA, verifique se tem resposta para estas três perguntas: qual é o custo mensal atual em tokens? Qual é o plano de fallback se o provider ficar fora por 30 minutos? O output do LLM é validado com schema antes de ser usado? Se uma das respostas for "não sei" ou "não", esse é o ponto de partida.