Agents on Call, Parte 7. Dimensionamento: A Matemática de Tokens que Ninguém Faz Antes

Uma única investigação profunda de incidente nesta plataforma, oito rodadas de chamadas de tools antes de o agente de triagem ter evidência suficiente para propor um diagnóstico, custa 32.950 tokens, e 31.600 deles são de entrada, porque a Converse API do Bedrock reenvia a transcrição inteira, sempre crescendo, a cada rodada. Multiplique isso pelo volume real de alarmes e a conta mensal on-demand de modelo da plataforma inteira sai por cerca de $14, um dos menores itens de linha num custo mensal total perto de $21. Comprar Provisioned Throughput no primeiro dia, a coisa que a Parte 1 explicitamente adiou, teria custado $15.768 por mês para uma carga rodando a aproximadamente um quatrocentos avos da utilização de que precisa para empatar. Nada disso é óbvio num diagrama. Só aparece quando alguém faz a aritmética, que é o que esta parte faz, de ponta a ponta, com todo número rastreável a uma tabela de preços do Bedrock ou a uma fórmula mostrada por inteiro.

A Parte 1 definiu o cenário, 40 pages por semana em 30 contas, e escolheu AgentCore mais Strands em vez das alternativas. A Parte 2 construiu a fronteira de conta e a fiação dos inference profiles, e nomeou a pergunta exata que esta parte responde: o ponto onde a tarifa horária do Provisioned Throughput vence a tarifa por token do on-demand. A Parte 3 entregou o loop de chamada de tools do agente de triagem, a coisa cujas rodadas são precificadas abaixo. A Parte 4 moveu essas tools para trás do AgentCore Gateway. A Parte 5 adicionou os agentes supervisor, de runbook e de custo que a conta mensal desta parte agora precisa cobrir. A Parte 6 colocou Guardrails em toda invocação, uma decisão que acaba importando mais para a conta desta parte do que o esperado. Todo número abaixo vive em docs/sizing-model.md no repositório complementar em github.com/flightlesstux/agents-on-call, junto de um checklist para rodá-lo de novo contra números reais em vez dos desta empresa fictícia.

O exemplo resolvido da matemática de tokens

A Converse API não mantém nenhum estado de conversa no servidor. Toda rodada de chamada de tools reenvia a transcrição completa até ali: system prompt, schemas de tools, toda chamada de tool anterior e seu resultado. Isso significa que os tokens de entrada não crescem linearmente com as rodadas, crescem com a soma de tudo que já foi enviado, e uma investigação mais longa paga pela própria história repetidas vezes. Os blocos de construção, declarados explicitamente em vez de presumidos: um prefixo estático de 1.800 tokens (system prompt, schemas de tools, config de guardrail) idêntico em toda chamada, um payload inicial de alarme de 400 tokens, 150 tokens de saída do assistant por rodada, e 350 tokens de resultado de tool anexados por rodada, 500 tokens de crescimento a cada rodada. O tamanho da entrada da rodada r é S + 400 + 500*(r-1).

Uma investigação rasa que se resolve em 3 rodadas fica assim:

Uma investigação profunda que precisa de 8 rodadas, mais contas, mais tools, mais idas e vindas antes de a evidência fechar, fica assim:

32.950 tokens no total, contra os 8.700 de uma investigação rasa, um custo 3,8x maior para uma contagem de rodadas 2,7x maior. Essa lacuna é a penalidade de reenvio tornada visível: total_input(N) = N*(S+400) + 500*N*(N-1)/2 cresce quadraticamente na contagem de rodadas, não linearmente, porque a rodada 8 está pagando pelas rodadas 1 a 7 tudo de novo.

Os dados de plantão da Parte 1 colocam volume real contra isso: 40 pages por semana, divididos aqui 70/30 em 28 investigações rasas e 12 profundas. São 243.600 tokens rasos e 395.400 tokens profundos por semana, 639.000 no total, cerca de 2,77 milhões de tokens por mês só para o agente de triagem. Os agentes de runbook, de varredura de custo e supervisor somam aproximadamente mais 1,1 milhão, para um total da plataforma perto de 3,87 milhões de tokens por mês. A decomposição completa por agente, incluindo as rodadas aumentadas por Knowledge Base do agente de runbook e a varredura diária do agente de custo, está no doc complementar; o número que vale carregar para a próxima seção é que nada disso, neste volume, é grande.

Incidentes em rajada contra uma varredura constante

O volume do agente de custo é suave de propósito: uma execução agendada do EventBridge por dia, fora do horário comercial, nunca dividindo um minuto com um incidente. O volume do agente de triagem não é suave, e médias escondem isso. Espalhados uniformemente, 606.000 tokens semanais de entrada são cerca de 60 tokens por minuto. Incidentes reais se correlacionam: uma falha upstream se espalhando em oito alarmes dentro dos mesmos cinco minutos sobe oito sessões de triagem cujas primeiras rodadas caem na mesma janela de TPM, 8 x 2.200 = 17.600 tokens de entrada naquele único minuto só da triagem, antes de contar as próprias chamadas de despacho do supervisor. Isso é aproximadamente 290 vezes a média suavizada, exatamente nos dez minutos em que uma indisponibilidade está em curso e a capacidade da plataforma de continuar respondendo mais importa. Dimensione contra o pico, não a média; a média é o que aparece na fatura do mês que vem, o pico é o que determina se uma tempestade de alarmes recebe uma resposta ou uma `ThrottlingException`.

Quotas, throttling e alarmar antes da dor

Os dois endpoints de invocação do Bedrock aplicam quotas de formas diferentes, e a diferença muda o que uma rajada de fato atinge. O endpoint bedrock-runtime conta tokens de entrada e saída juntos contra uma única quota de TPM por modelo, e o RPM é específico do modelo: alguns modelos de topo não carregam quota de RPM nenhuma, governados por tokens apenas. O endpoint bedrock-mantle separa entrada e saída em quotas de tokens distintas e abandona o RPM por completo. De um jeito ou de outro, a quota é específica de conta e região, compartilhada entre todos os agentes que esta plataforma roda, não alocada por agente, então as chamadas de despacho do supervisor e a investigação de oito rodadas do agente de triagem estão sacando do mesmo pool durante uma tempestade de alarmes correlacionada. Pedidos self-service de aumento de quota cobrem ambos os endpoints desde uma mudança no início deste ano, antes o bedrock-mantle exigia um ticket de suporte; isso fecha uma lacuna real, mas não remove a necessidade de conhecer o teto antes que um incidente o encontre.

A lógica de retry do próprio SDK do Bedrock recua diante de uma resposta de throttling, mas isso só suaviza uma rajada, não faz folga de quota aparecer. O movimento mais útil está rio acima de qualquer retry: alarmar sobre a própria utilização da quota, não sobre a primeira ThrottlingException que um retry já absorveu. Um alarme de utilização de quota que dispara a 70% de um teto de TPM dá ao planejamento de capacidade um aviso dias antes de uma tempestade de alarmes dar ao engenheiro de plantão um agente de triagem degradado. Esperar que o erro de throttling seja o primeiro sinal significa que o incidente que mais precisa da ajuda desta plataforma é aquele em que o próprio error budget da plataforma é gasto em retries em vez de chamadas de tools.

Perfis cross-region como folga para rajadas

A Parte 2 colocou esta plataforma em inference profiles cross-region em todo lugar, por confiabilidade e sem custo adicional por token. O ângulo de dimensionamento dessa decisão: uma quota de TPM tem escopo no endpoint de uma região, e o roteamento cross-region significa que uma rajada que esgotaria o teto de uma região pode transbordar para o teto separado de uma região irmã em vez de enfileirar atrás do limite de uma única região. Não é folga ilimitada, e não substitui conhecer o teto real, mas transforma a quota de uma região na quota de uma geografia inteira ao custo de nada, uma troca melhor do que a maior parte da folga de capacidade que esta plataforma compra.

A economia do Provisioned Throughput: o ponto de equilíbrio, e por que comprá-lo agora é errado

Uma Model Unit compra uma tarifa horária fixa, sempre cobrada, em troca de um teto fixo de tokens/minuto de entrada e saída, sejam quais forem a tabela de preços do modelo e o throughput da MU para o modelo escolhido, nenhum dos dois publicado pela AWS como número fixo independente do modelo, então a fórmula abaixo usa valores placeholder declarados, não fatos da AWS, e precisa dos números do console ao vivo antes de alguém gastar dinheiro de verdade nela:

max_monthly_input  = T_in  * 60 * 730   # 730 hours in an average month
max_monthly_output = T_out * 60 * 730

on_demand_equiv_cost = (max_monthly_input  / 1000) * I
                      + (max_monthly_output / 1000) * O

pt_monthly_cost        = P * 730
break_even_utilization = pt_monthly_cost / on_demand_equiv_cost

Com placeholders ilustrativos (200.000 tokens/minuto de entrada e 100.000 de saída por MU, $0,003 e $0,015 por 1.000 tokens on-demand, $21,60/MU-hora sem compromisso): 100% de utilização do teto dessa MU vale $91.980 por mês em on-demand, o PT em si custa $15.768 por mês, e o equilíbrio cai em 17,14% de utilização sustentada. Acima dessa fração, o PT é mais barato. Abaixo dela, o on-demand vence, e a palavra que faz o trabalho é sustentada: isso é uma média mensal, e o exemplo de rajada duas seções acima mostra exatamente por que bater num teto por um minuto não é a mesma coisa que sustentá-lo.

O volume mensal real de entrada desta plataforma, cerca de 3,65 milhões de tokens, é 0,042% do teto mensal de entrada dessa MU, aproximadamente 411x abaixo do ponto de equilíbrio de 17,14%. Comprar uma MU no primeiro dia, exatamente o movimento que a Parte 1 adiou e que a Parte 2 sinalizou como dependente desta matemática, gastaria $15.768 por mês protegendo uma carga cuja conta on-demand de modelo inteira é de cerca de $14. O erro não é a aritmética, é não fazer nenhuma, e se comprometer com uma tarifa mensal antes mesmo de medir a distribuição de taxa de requisições entre quatro agentes. On-demand até medir, provisionado só depois, não é cautela por si só, é o que o cálculo de equilíbrio de fato diz.

O que o prompt caching faz com a mesma matemática

O caching transforma a penalidade de reenvio da seção de matemática de tokens num problema majoritariamente resolvido. Um prefixo em cache é lido com 90% de desconto; conteúdo novo escrito no cache custa 1,25x o preço normal de entrada, sem taxa separada além desse multiplicador. Aplicado rodada a rodada, a rodada 1 escreve sua entrada inteira no cache, e toda rodada posterior lê a entrada inteira da rodada anterior a 10% do preço normal, pagando o preço cheio mais 25% apenas sobre os 500 tokens recém-anexados:

billing_input(1) = input(1) * 1.25
billing_input(r) = input(r-1) * 0.10 + 500 * 1.25   # r >= 2

Para a investigação rasa, a entrada equivalente de cobrança com cache cai de 8.100 para 4.490 tokens, uma redução de 44,6%. Para a investigação profunda, cai de 31.600 para 9.715, uma redução de 69,3%, maior porque a penalidade de reenvio que ela está cancelando se acumula a cada rodada extra: o caching ajuda mais exatamente onde o custo sem cache dói mais. Em dólares, o custo total de um incidente profundo (entrada mais saída, com a saída inalterada pelo caching) cai de $0,1151 para $0,0494, uma redução de 57,1%. Aplicado ao mix semanal completo do agente de triagem, o custo mensal de modelo só desse agente cai de $10,02 para $5,29, uma economia de $4,73, 47,2%. O mesmo mecanismo se aplica aos loops multi-rodada dos próprios agentes de runbook e de varredura de custo numa escala absoluta menor, já que rodam com muito menos frequência; o doc complementar carrega o recálculo completo apenas para a triagem, o agente de maior volume e maior contagem de rodadas, onde o efeito é maior.

O modelo de custo mensal da plataforma inteira

Juntando todas as categorias, usando os preços documentados de AgentCore e Guardrails contra os volumes de tokens acima, com a linha de tokens de modelo mostrada com e sem o caching do agente de triagem:

Duas coisas que valem uma pausa. Runtime, Gateway e Memory são erros de arredondamento neste volume: cobrança por segundo e nenhum custo pelo tempo ocioso esperando o modelo fazem a infraestrutura gerenciada mal registrar até que concorrência e duração de sessão subam ordens de magnitude. Guardrails não é um erro de arredondamento: a aproximadamente 30% do total sem caching, custa mais que Runtime, Gateway e Memory combinados por um fator de cerca de 15x, e depois que o caching encolhe a linha de modelo, chega perto de dois terços do tamanho da conta de modelo que ele está escaneando. Um exercício de dimensionamento que para na contagem de tokens do modelo perde um terço da conta real, sentado num serviço que a maioria dimensiona por compliance, não por custo.

Right-sizing de modelo por agente

A matemática de tokens acima assume um modelo para todos os agentes, que é o padrão fácil e não o estado final certo. Os quatro agentes pedem coisas genuinamente diferentes de um modelo. A triagem faz diagnóstico estruturado a partir de saída de tools, evidência entra, um conjunto limitado de causas raiz plausíveis sai, trabalho que um modelo menor e mais barato faz bem uma vez que seu system prompt e schemas de tools estejam apertados, exatamente a carga para a qual a temperatura baixa da Parte 3 já estava afinada. A varredura diária do agente de custo é majoritariamente agregação e comparação de thresholds contra números que uma tool já buscou, um encaixe ainda melhor para o menor modelo que siga o formato de saída de forma confiável. O agente de runbook é o único lugar em que um modelo mais forte ganha seu preço por token mais alto: ele está redigindo o documento SSM exato e os parâmetros que um humano está prestes a aprovar atrás do portão de aprovação da Parte 4, e um erro ali é um erro com raio de impacto real, não um erro num diagnóstico que outra pessoa confere de qualquer jeito. Casar o tamanho do modelo com o que um erro de fato custa, em vez de padronizar todo agente no mesmo modelo, é o mesmo instinto por trás do prompt caching e do PT: não gaste em capacidade de que a tarefa não precisa, e gaste onde uma resposta errada é cara. O harness de evals da Parte 8 é o que transforma "faz bem" de um palpite num número em que vale confiar.

Modos de falha a observar

Quatro coisas que vale saber antes de este modelo rodar contra uma conta real. Primeiro, todo valor em dólar acima depende de dois insumos placeholder, o preço por token on-demand e o teto de throughput da MU de Provisioned Throughput, que esta série deliberadamente nunca fixa num modelo Bedrock nomeado; troque pela página de preços ao vivo antes de confiar num total, já que um placeholder velho produz uma conta confiantemente errada, não obviamente errada. Segundo, a suposição de 350 tokens por resultado de tool é quase certamente conservadora: um dump real de métricas do CloudWatch ou um trecho de log pode ser 5 a 10x isso, e como é o termo que se acumula quadraticamente entre rodadas, uma subestimativa ali subestima todo número rio abaixo proporcionalmente, não por um deslocamento fixo. Terceiro, o cálculo de equilíbrio é uma média mensal; uma plataforma cujo tráfego real se parece com a seção de rajadas, longos trechos quietos com picos correlacionados agudos, pode estar longe do equilíbrio no papel e ainda assim sofrer throttling durante os dez minutos que importam, o que argumenta por folga cross-region e alarmes de quota em vez de uma compra de PT em qualquer caso. Quarto, a economia do prompt caching depende de os cache hits de fato acontecerem, um system prompt ou schema de tool editado no meio do mês invalida o prefixo em cache e reintroduz brevemente o custo integral sem cache até o cache repopular, algo a vigiar depois de qualquer mudança de prompt, não a presumir resolvido.

Leia isso a seguir

• Parte 6, Guardrails: A Parte que Todo Mundo Pula, para o preço por unidade dos Guardrails do qual o modelo de custo mensal desta parte depende, e o padrão de invocação que decide quanto texto de fato é escaneado.
• Parte 8, Produção: Observabilidade, Evals e o Dia em que Ela Mente, onde as decisões de right-sizing de modelo acima são testadas contra traces reais em vez de assumidas corretas.
• The AWS Well-Architected Framework: A Key to Cloud Success no ercan.cloud, para o pilar de Cost Optimization do qual esta parte é, na verdade, um longo exemplo resolvido: meça antes de se comprometer.

O docs/sizing-model.md completo, incluindo a decomposição por agente dos agentes de runbook e de varredura de custo cortada das tabelas acima e um checklist para rodar de novo cada número contra uma conta real, vive no repositório complementar em github.com/flightlesstux/agents-on-call. Para o lado de banco de dados e infraestrutura de rodar plataformas como esta em escala, as notas de campo estão em ercan.cloud, e o hub fica em ercanermis.com.