Capacity Planning na era da IA: sua infraestrutura está pronta?

O capacity planning nunca foi uma tarefa nova. O que mudou é a variável que ele precisa prever.

Até pouco tempo, bastava projetar a sazonalidade, as campanhas e o crescimento da base de usuários. A nuvem elástica resolveu a parte mecânica desse problema ao permitir provisionar e desprovisionar sob demanda.

No entanto, os agentes de IA mudam essa lógica ao gerar cadeias de decisão computacional, em que cada uma consome recursos de forma distinta da anterior.

Isso transforma o planejamento de capacidade em um exercício de rastreamento causal.

Continue a leitura para entender como a inteligência artificial (IA) afeta o capacity planning.

O que é capacity planning?

O capacity planning, ou planejamento de capacidade, consiste em planejar de forma proativa a infraestrutura, a computação, a rede, o armazenamento e o orçamento com base em projeções de demanda.

Na era da IA, o principal desafio dessa previsão deixou de ser o volume de usuários e passou a ser o comportamento autônomo dos agentes, cuja carga pode se multiplicar em cascata a partir de uma única solicitação.

Planejamento de capacidade vs. monitoramento

A diferença entre capacity planning e monitoramento não está na ferramenta usada, mas no momento que cada prática analisa.

O monitoramento mostra o que está acontecendo agora. O capacity planning antecipa o que pode ocorrer quando um componente se aproxima do limite.

O autoscaling responde parcialmente a essa segunda questão. Ele é reativo: precisa detectar a carga e, entre a decisão de escalar e a capacidade disponível, há um atraso (cold start e tempo de provisionamento). Pode escalar por CPU e memória, mas também por métricas customizadas, como profundidade de fila, requisições ou tokens por segundo. Em todos os casos, só enxerga o que está instrumentado.

Ele não identifica, por exemplo, uma API legada que satura antes da camada elástica nem um contrato de instância reservada que se torna desperdício quando o padrão de uso muda.

Por isso, o autoscaling resolve:

• Picos de tráfego não previstos, respeitado o atraso de provisionamento (os eventos conhecidos, como campanhas, são mais bem tratados com escalonamento programado, o scheduled scaling);
• Elasticidade de instâncias sob demanda sazonal.

Mas não resolve:

• Gargalos não lineares em sistemas legados e bancos de dados;
• Eficiência de custo: escalar automaticamente não é escalar de forma econômica.

Na prática, uma empresa pode ter autoscaling ativo e, ainda assim, receber uma fatura de nuvem imprevisível. Nesse contexto, o capacity planning e o FinOps deixam de ser áreas paralelas e passam a operar como uma única decisão.

Quais os benefícios do capacity planning?

Para os gestores responsáveis, o maior benefício do planejamento de capacidade está no que é possível apresentar diante da diretoria: a previsibilidade orçamentária. Com ela, é possível justificar investimentos em TI com dados concretos, e não apenas com estimativas.

Esse ganho aparece em quatro frentes:

• Redução de custos operacionais com origem claramente identificada;
• Previsibilidade orçamentária que sustenta decisões perante a liderança;
• Compliance sustentado por registros contínuos de capacidade e consumo, sem depender de auditorias reativas;
• Estabilidade operacional capaz de reduzir incidentes críticos.

Sustentar esses benefícios manualmente exige revisões constantes e não acompanha o crescimento da infraestrutura. Com isso, os ganhos passam a depender de análises automatizadas, e não de mais esforço humano.

Como a IA muda o planejamento de capacidade e o consumo da infraestrutura?

Agentes de IA são difíceis de prever pela forma como geram volumes de chamados.

Uma solicitação humana também pode acionar várias chamadas internas, mas o caminho costuma ser conhecido e limitado. Uma solicitação processada por um agente é o início de uma cadeia em que ele consulta, decide, aciona uma ferramenta e reavalia, e o número de passos não é conhecido de antemão.

A cada iteração, o contexto cresce e a chamada seguinte fica mais cara. Repetições (retries) e laços (loops) multiplicam o consumo. Cada etapa consome capacidade de forma independente das anteriores.

Essa sequência explica por que médias históricas de tráfego deixam de funcionar como base de projeção.

Por trás disso, há limites que a arquitetura de software reduz, mas não elimina sozinha. Técnicas como batching, cache de prompt e de KV, quantização e roteamento para modelos menores ajudam, mas o teto continua existindo.

Para quem consome modelos por API, o primeiro limite costuma ser a cota do provedor: tokens e requisições por minuto, disponibilidade do modelo por região e a diferença entre vazão provisionada e vazão sob demanda. Já para quem hospeda modelos próprios ou opera on-premises, entram também:

• Escassez de GPUs e TPUs, que limita a vazão (throughput) mesmo com orçamento disponível;
• Rede de baixa latência e alta largura de banda entre os nós, quando a inferência é distribuída em várias GPUs;
• Consumo energético e capacidade de refrigeração, que impõem um teto físico ao data center.

Para planejar capacidade, já não basta monitorar CPU e memória. É preciso acompanhar o comportamento das subtarefas disparadas, o consumo de cada etapa e as repetições desnecessárias. O rastreamento distribuído, com OpenTelemetry, permite seguir cada solicitação por todas as chamadas do agente e atribuir consumo e custo a cada etapa. É assim que o rastreamento causal deixa de ser uma ideia e vira prática.

Controlar a demanda também é planejar capacidade

Planejar capacidade para agentes não é só prever a demanda: é também limitá-la. Definir um número máximo de passos e um orçamento de tokens por tarefa transforma um consumo aberto em um intervalo previsível.

Para comparar cenários, vale medir o custo por tarefa concluída, e não apenas o custo por token. Dois agentes com o mesmo preço por token podem ter custos muito diferentes por tarefa, dependendo de quantos passos e repetições cada um precisa.

Do percentil 95 (P95) à observabilidade preditiva

Usar apenas a média de consumo pode ser arriscado, pois basta uma carga fora do padrão para comprometer o sistema.

Já planejar pelo maior pico possível também não é o ideal, porque a infraestrutura fica cara e ociosa na maior parte do tempo.

O percentil 95 (P95) é um bom ponto de partida para esse impasse, pois absorve a variação normal sem provisionar para a exceção. Mas, em cargas de agentes, que têm cauda pesada, os 5% acima do P95 concentram justamente os eventos que derrubam o sistema. Por isso, o dimensionamento deve considerar também o P99 e o P99.9, além de uma folga de capacidade (headroom) definida por SLO.

Ainda assim, percentis são retrospectivos: descrevem o que já aconteceu. A pergunta que interessa a quem opera a infraestrutura é: quanto tempo falta até que esse recurso específico sature?

Respondê-la exige previsão sobre métricas de saturação (fila, utilização, tokens por minuto em relação à cota), e não apenas estatística do passado. É isso que chamamos de observabilidade preditiva: usar a telemetria contínua para projetar o tempo até a saturação.

Testes não funcionais de carga e AIOps trabalham essa mesma premissa por ângulos diferentes: o primeiro simula o limite antes que ele ocorra; o segundo identifica sinais de aproximação desse limite a partir do consumo real.

Sinais de que a empresa não tem essa projeção:

• Fila de inferência que cresce sem relação direta com o número de usuários;
• Latência que varia entre chamadas do mesmo agente, sem padrão aparente;
• Custo por token que ultrapassa o orçamento sem incidente técnico correspondente.

Como a Vericode aplica IA no capacity planning?

Automatizar o diagnóstico de capacidade ajuda a ganhar velocidade, mas traz um risco: confiar em uma recomendação sem entender o motivo por trás dela.

É aí que entra a abordagem Especialista + IA da Vericode. A IA analisa grandes volumes de dados com rapidez, enquanto o especialista entende os padrões, avalia as causas e decide o melhor caminho.

A Vericode aplica esse princípio em três frentes voltadas ao diagnóstico de capacidade, consumo e custo:

• SRE e Observabilidade usa o Modelo de Maturidade de Observabilidade (OMM, do inglês Observability Maturity Model) para situar a maturidade da operação e o AIOps para identificar o que está saturando, reduzindo o MTTD (tempo médio de detecção) e o MTTR (tempo médio de resolução) de incidentes;
• FinOps e CloudOps traduz esse diagnóstico técnico em decisão de custo, com alocação previsível;
• Continuous Testing e DevSecOps / Platform Engineering aplica testes não funcionais antes da implantação (deploy), reduzindo a chance de o gargalo chegar à produção.

Do número de usuários ao número de decisões

O capacity planning não muda de propósito na era da IA.

Antes, a pergunta era: "quantos usuários vamos ter?". Agora, é: "quantas decisões um agente vai tomar antes de terminar uma tarefa, e o que cada decisão custa?".

Empresas que ainda planejam capacidade pela primeira pergunta vão continuar sendo surpreendidas pela segunda.

Quer saber em que estágio de maturidade sua infraestrutura está? Solicite o diagnóstico gratuito de observabilidade da Vericode, com devolutiva em até 72 horas, e descubra como unir todos esses elementos em uma estratégia contínua.

Perguntas frequentes sobre o planejamento de capacidade na era da inteligência artificial