Autoscaling de workers para agentes de IA

A fila cresceu e o autoscaler adicionou o problema

Um agente processa documentos recebidos por uma fila. O volume sobe, o número de workers aumenta e a fila começa a cair. Ao mesmo tempo, o sistema de origem passa a responder com limite de taxa, o banco acumula conexões e a equipe recebe mais exceções do que consegue revisar.

A infraestrutura fez o que a métrica pediu. A política escolheu um sinal incompleto.

O autoscaling de workers ajusta a quantidade de instâncias que consomem trabalho. Para agentes de IA, essa decisão precisa considerar backlog, idade, prazo, duração das tarefas, partições, dependências externas, custo e capacidade humana. CPU isolada raramente representa o risco operacional.

Este guia trata a política de escala. O planejamento de capacidade estima demanda e gargalos. O consumer lag mostra a distância entre produção e consumo. Aqui, o objeto final é uma regra executável para subir, estabilizar e retirar workers sem perder trabalho.

Defina a unidade que a escala deve proteger

Comece pelo trabalho reconhecido pela operação:

oportunidade com próxima ação preparada;
documento conferido;
chamado triado;
pedido validado;
relatório atualizado;
cadastro revisado.

Para cada unidade, registre:

prazo útil;
tempo de serviço por classe;
quantidade de chamadas externas;
necessidade de revisão humana;
condição de conclusão;
custo permitido;
consequência de expirar;
chave de partição ou ordenação.

Vinte mensagens podem representar vinte tarefas curtas ou vinte arquivos que ocupam o worker por uma hora. A política precisa enxergar peso e prazo, além da contagem.

Separe escala técnica de capacidade operacional

Mais réplicas ampliam apenas a etapa executada pelos workers. Elas ajudam quando o processamento local limita a conclusão e quando os componentes seguintes aceitam a concorrência adicional.

A escala encontra um teto real em recursos como:

cota do modelo;
limite do CRM ou ERP;
conexões do banco;
throughput da fila;
quantidade de partições;
armazenamento de estado;
orçamento por período;
revisores disponíveis;
alçada para aprovações;
canal usado para entregar o resultado.

Se o CRM aceita dez escritas simultâneas, subir de dez para cinquenta workers pode aumentar timeout e retentativa sem concluir mais unidades. O teto do autoscaler deve refletir a dependência mais restritiva para aquela classe de trabalho.

Escolha sinais ligados à fila e ao prazo

O Kubernetes Horizontal Pod Autoscaler, ou HPA, ajusta réplicas a partir de métricas observadas. A documentação oficial permite métricas de recurso, por pod, por objeto e externas. Isso abre espaço para usar sinais da fila em vez de depender apenas de CPU.

Uma política para agentes pode combinar:

Backlog elegível

Conte unidades que ainda podem ser processadas. Itens expirados, bloqueados por aprovação ou retidos para investigação devem aparecer em estados próprios.

Idade da unidade mais antiga

Mostra quando a espera se aproxima do prazo. Uma fila pequena com um caso antigo pode exigir ação antes de uma fila grande de tarefas sem urgência.

Taxa de entrada e conclusão

A diferença indica se a capacidade atual reduz ou amplia o backlog. Use conclusão válida e confirmada, não somente mensagens retiradas da fila.

Duração por classe

Tarefas curtas e longas pedem fatores diferentes. Uma média única pode esconder documentos pesados ou integrações lentas.

Concorrência permitida no destino

Registre o limite seguro por dependência, conta e operação. Leitura e escrita podem ter tetos diferentes.

Prazo restante

A política deve proteger a janela de negócio. Um follow-up comercial e uma análise mensal podem compartilhar infraestrutura, mas não a mesma urgência.

Converta o backlog em uma meta de réplicas

Uma estimativa inicial pode usar trabalho pendente, tempo médio observado e janela de drenagem:

trabalho_total = soma(peso_da_unidade)
capacidade_por_worker = janela_de_drenagem / tempo_de_servico
replicas_desejadas = teto(trabalho_total / capacidade_por_worker)

Considere um exemplo sintético:

backlog: 240 unidades equivalentes
janela de drenagem: 30 minutos
tempo observado: 2 minutos por unidade
capacidade de um worker na janela: 15 unidades
réplicas brutas: 240 / 15 = 16

O resultado ainda precisa respeitar:

réplicas finais = mínimo(
  réplicas brutas,
  teto da integração,
  teto do banco,
  teto de custo,
  teto de revisão
)

Se a capacidade líquida continua abaixo da chegada mesmo no teto, o autoscaler sozinho perdeu a disputa. A operação precisa reduzir admissão, separar prioridades, degradar tarefas opcionais ou negociar capacidade adicional.

Use piso, teto e zona de estabilização

Três limites evitam reações erráticas.

Piso

Mantém capacidade mínima para classes que precisam começar rápido ou para situações em que a métrica externa pode desaparecer. Escalar a zero exige tempo de ativação compatível com o prazo.

Teto

Protege dependências, custo e revisão. O teto deve ser testado. Copiar um número alto para “não limitar” remove justamente a barreira que impediria uma sobrecarga em cascata.

Estabilização

Evita subir e descer réplicas a cada oscilação curta. A documentação do HPA permite configurar comportamento de scale-up e scale-down. O KEDA também expõe intervalo de consulta, período de resfriamento e limites de réplicas para workloads acionados por eventos.

Use uma janela curta o suficiente para responder ao prazo e longa o suficiente para distinguir um pico real de ruído. A escolha depende do processo, do tempo de inicialização e da duração das tarefas.

Trate métrica ausente como estado desconhecido

Fila zerada e telemetria indisponível são situações diferentes.

Quando a fonte da métrica falha:

preserve o último estado conhecido por um período limitado;
confirme atividade do consumidor;
consulte um sinal alternativo;
bloqueie redução agressiva;
alerte o dono da plataforma;
registre quanto tempo a decisão opera sem evidência atual.

Reduzir para zero diante de uma coleta quebrada pode transformar falha de observabilidade em descumprimento do processo.

Respeite partições e chaves de ordenação

Adicionar workers só aumenta throughput quando existe trabalho paralelizável.

Uma fila com cem partições ativas oferece uma fronteira diferente de outra com duas. Uma única chave muito pesada pode manter o backlog mesmo com várias instâncias ociosas. A ordem de mensagens também pode exigir processamento sequencial por pedido, oportunidade ou caso.

A política deve acompanhar:

partições ativas;
distribuição de trabalho entre chaves;
quantidade máxima de consumidores úteis;
grupos bloqueados;
eventos que exigem sequência;
rebalances provocados pela própria escala.

Se dez réplicas disputam duas partições, oito não criam capacidade. Elas criam custo e mais movimento de coordenação.

Proteja tarefas longas durante o scale-down

Reduzir réplicas pode encerrar uma instância que está perto de concluir uma tarefa longa. A documentação atual do KEDA chama atenção para esse risco em workloads acionados por fila: o HPA pode escolher uma réplica ocupada para remoção.

A política precisa trabalhar com o protocolo de desligamento seguro de workers:

parar de buscar novas unidades;
retirar a instância da entrada;
concluir etapas curtas dentro da margem;
persistir checkpoint das tarefas retomáveis;
devolver a mensagem quando necessário;
perder autoridade para novos efeitos;
consultar o destino em estados incertos;
confirmar drenagem antes do encerramento.

Defina também um período de estabilização maior para redução que para aumento quando as tarefas variam muito. A pressa para economizar uma réplica pode custar uma reexecução inteira.

Evite que a escala multiplique retentativas

Uma dependência degradada costuma reduzir conclusão e ampliar backlog. O autoscaler interpreta a fila e adiciona workers. Cada worker repete chamadas. A dependência piora.

Coordene escala com:

circuit breaker;
limites de taxa;
backoff e jitter;
orçamento de tentativas;
admissão por classe;
prioridade;
resposta degradada;
pausa de consumidores.

Quando o erro está no destino, mais concorrência pode atrasar a recuperação. O scale-up deve considerar taxa de sucesso e limite externo, além do backlog.

Inclua a fila humana

Um agente pode preparar cem análises por hora e enviar oitenta para revisão. Se duas pessoas conseguem revisar vinte, a automação apenas desloca a espera.

Registre:

revisores disponíveis por horário;
tempo por classe;
quantidade aguardando decisão;
prazo de aprovação;
alçadas;
taxa de devolução;
substitutos;
limite de casos que a equipe consegue absorver.

Quando a fila humana atinge o teto, reduza a produção de casos que dependem dela ou mantenha as unidades na etapa anterior com estado visível. Despejar saídas numa caixa de entrada não aumenta capacidade operacional.

Exemplo: documentos recebidos em um fechamento

Uma operação recebe documentos ao longo do dia e concentra volume no fechamento mensal.

Classes

urgente: bloqueia uma decisão no mesmo dia;
normal: precisa concluir até a manhã seguinte;
incompleto: aguarda documento ou correção;
sensivel: sempre exige revisão especializada.

Sinais de escala

unidades elegíveis por classe;
idade mais antiga;
taxa de chegada;
tempo de serviço por tamanho;
conexões disponíveis no sistema de destino;
revisões especializadas restantes;
prazo até o corte.

Política

A escala aumenta primeiro para proteger urgente e normal. Itens incompletos não pressionam workers. A classe sensível respeita a capacidade dos revisores. O teto técnico mantém folga no sistema de destino.

Redução

Depois do pico, novas entradas param de ser atribuídas às réplicas candidatas. Unidades em andamento concluem ou gravam checkpoint. A escala só diminui quando idade, backlog elegível e tarefas ativas permanecem na faixa definida durante a estabilização.

Teste a política antes da produção

Use entradas sintéticas e um destino controlado. Inclua:

pico curto com tarefas leves;
aumento sustentado;
mistura de tarefas leves e pesadas;
partição concentrada;
fila grande com itens expirados;
métrica externa indisponível;
dependência respondendo com limite de taxa;
custo chegando ao teto;
revisores sem capacidade;
scale-down com tarefa longa em andamento;
confirmação perdida durante a drenagem;
reativação depois de escala a zero;
backlog acima da capacidade máxima;
retorno gradual da dependência.

Confira quantidade de réplicas, unidades válidas concluídas, idade da fila, chamadas ao destino, custo, checkpoints, duplicidades e trabalho enviado à revisão.

Métricas da política de escala

Acompanhe:

réplicas desejadas e disponíveis;
motivo de cada decisão de escala;
backlog elegível por classe;
idade da unidade mais antiga;
taxa de entrada e conclusão válida;
tempo estimado de drenagem;
utilização por dependência;
respostas de limite de taxa;
tarefas ativas durante redução;
checkpoints e retomadas;
reexecuções provocadas por encerramento;
custo por unidade válida;
fila de revisão;
prazo cumprido;
tempo no piso e no teto;
períodos com métrica desconhecida.

O painel deve permitir responder por que a escala mudou e qual limite impediu novas réplicas. Um gráfico de CPU sem o estado da fila explica pouco sobre a operação.

Checklist de autoscaling

[ ] A unidade de trabalho e o prazo estão definidos?
[ ] O backlog exclui itens bloqueados e expirados?
[ ] Peso e duração variam por classe?
[ ] A conclusão usada na métrica foi confirmada?
[ ] Partições e chaves permitem o paralelismo esperado?
[ ] O teto respeita modelo, banco, integrações, custo e revisão?
[ ] Existe piso para ativação e falha de telemetria?
[ ] Scale-up e scale-down possuem estabilização própria?
[ ] Tarefas longas conseguem drenar ou retomar?
[ ] Workers antigos perdem autoridade depois da transferência?
[ ] Falhas externas bloqueiam tempestades de retentativa?
[ ] A fila humana entra na política?
[ ] Cenários acima do teto possuem modo degradado?
[ ] Cada limite tem dono e ação operacional?

A política precisa escalar conclusão, não movimento

Autoscaling ajuda quando transforma uma fila real em mais unidades válidas dentro do prazo. A decisão começa no backlog elegível, passa pelo tempo de serviço e termina nos limites de todo o percurso.

Use métricas externas ligadas ao trabalho, defina piso e teto, respeite partições, coordene falhas e drene workers antes de removê-los. Quando o gargalo está no destino ou na revisão humana, novas réplicas só produzem pressão adicional.

Fontes oficiais verificadas em 30 de setembro de 2026:

Kubernetes: Horizontal Pod Autoscaling, para tipos de métricas, cálculo e comportamento de escala.
Kubernetes: walkthrough do HPA, para métricas por pod, por objeto e métricas externas.
KEDA: scaling de workloads, para acionamento por eventos, limites, resfriamento e cuidado com tarefas longas durante redução.

As fontes descrevem mecanismos das plataformas. Piso, teto, métrica e prazo precisam ser testados contra a operação e as dependências da empresa.