Cost Control & Routing
O custo de um agente não depende apenas do preço de um modelo. Um fluxo pode usar muitos documentos, repetir chamadas, gerar respostas longas e executar ferramentas caras. O controle começa por identificar a tarefa e seus requisitos, limitar trabalho desnecessário e medir se uma alternativa preserva a qualidade. Nesta aula, orçamento e roteamento deixam de ser uma escolha informal de “modelo barato” e viram políticas verificáveis.
A entrega será um roteador por classe de tarefa com baseline de qualidade, cache isolado por identidade e tratamento explícito de quotas. Os exemplos usam créditos fictícios para exercitar decisões sem depender de preços atuais. Ao conectar um provedor, você deve substituir essa unidade por medições de uso e tarifas verificadas, preservando as diferenças entre estimativa, reserva e cobrança real.
JavaScriptIA & MLAo terminar esta aula
- Orçamento cobre a execução e suas tentativas.
- Cache exige identidade, versão e validade.
- Roteamento precisa preservar qualidade mensurada por classe.
Antes de continuar: Laboratório: Guardrails & Security
Token budget: limitar a execução inteira
IA & MLToken budget define quanto trabalho de modelo uma execução ou identidade pode consumir. Ele inclui entrada, saída e tentativas adicionais conforme o contrato de contagem. Limitar somente a resposta final não impede que um agente faça vinte chamadas intermediárias. Defina limites por chamada, número de passos, documentos recuperados e execução completa. Um orçamento deve ser verificado antes de iniciar a operação e reconciliado depois que o uso real estiver disponível.
Considere duas chamadas concorrentes que consultam o saldo de 100 e reservam 80 cada. Se a verificação e a reserva forem separadas, ambas podem entrar e gastar mais que o saldo. A reserva precisa ser atômica em um armazenamento compartilhado. O exemplo desta aula é síncrono em memória e não resolve concorrência distribuída. Defina também como liberar reserva após erro e como reconciliar respostas sem uso reportado. Um limite interno é controle da aplicação; não assuma que coincide com a cobrança ou os limites do provedor.
Cache: chave, validade e isolamento
FundamentosCache armazena um resultado para reutilização e reduzir recomputação. Em cache-aside, a aplicação procura no cache, consulta a fonte quando necessário e preenche a entrada. A chave precisa representar todas as condições que alteram a resposta: identidade ou escopo, versão da política, documentos, prompt, modelo e parâmetros relevantes. Se duas contas compartilham a mesma pergunta textual, suas respostas privadas não devem compartilhar uma entrada apenas porque o texto é igual.
TTL limita o tempo de retenção, mas não garante atualidade imediatamente após uma mudança. Para uma política nova, inclua versão na chave ou invalide entradas afetadas. Cache de resposta também é diferente de caching de prompt no provedor; uma técnica reaproveita resultado, a outra pode reduzir processamento de prefixos conforme capacidades específicas. Nem toda tarefa é cacheável: ações de escrita, informações sensíveis voláteis e respostas dependentes do estado atual exigem outra estratégia. Cache hit deve aparecer na telemetria e na avaliação de correção.
Routing por custo, latência e qualidade
FundamentosUm roteador escolhe uma rota conforme classe de tarefa e restrições. Extração de campos com esquema conhecido pode ter uma rota diferente de análise com documentos conflitantes. A decisão deve considerar uma baseline medida por classe, não uma reputação genérica do modelo. Um modelo menor pode ser adequado para uma tarefa estruturada e insuficiente para outra que exige manejo de ambiguidade. Antes de ativar a rota, compare sua qualidade nos casos congelados da semana 36.
↗ Router - Load Balancing↗ Model selection↗ Evaluation best practices
Uma política simples escolhe uma rota econômica para tarefas que atendem critérios determinísticos e uma rota mais capaz quando há ambiguidade ou contexto complexo. Isso não garante melhora: classificação de tarefa pode errar e a rota alternativa pode ter latência maior. Registre class, route, reason e resultado funcional. Um fallback não pode ultrapassar orçamento ou enviar dados a um provedor sem autorização. Se nenhuma rota cumpre as condições, a ação correta pode ser recusar ou encaminhar, em vez de comprar uma resposta a qualquer custo.
↗ Router - Load Balancing↗ Model selection↗ Evaluation best practices
Quotas, rate limits e carga concorrente
FundamentosQuota limita uso acumulado em um período; rate limit restringe a frequência ou volume por janela. Um tenant pode ter saldo mensal e ainda ultrapassar requisições por minuto. Faça distinção entre limites da aplicação e limites de provedores. Uma resposta 429 exige entender a condição e, quando disponível, a orientação de espera. Repetir imediatamente centenas de pedidos aumenta a pressão e consome a capacidade que já está restrita.
Defina filas ou rejeição explícita para excesso de carga, tempo máximo de espera e limite de tentativas. Backoff com jitter evita sincronizar retries, mas não torna qualquer erro recuperável. Erro de autenticação e requisição inválida precisam de correção, não de insistência. Limite também concorrência em ferramentas e bancos: um roteador que distribui chamadas de modelo pode concentrar a carga em uma única dependência. A qualidade observada sob baixa carga não descreve necessariamente o sistema quando há filas e timeouts.
Demonstrar economia sem comprometer critérios
FundamentosA comparação econômica precisa declarar o objetivo: custo por chamada, por usuário, por tarefa concluída ou por período. Reduzir custo por chamada pode aumentar custo por sucesso se houver mais tentativas ou abandono. Calcule gasto total, sucessos e falhas por classe, preservando os denominadores. Inclua cache hits e misses em grupos separados, porque uma taxa média elevada de acerto no cache pode esconder uma rota ruim quando a entrada é nova.
Defina previamente o piso de qualidade e as falhas intoleráveis. Em um conjunto pequeno, apresente contagens e exemplos, sem prometer equivalência estatística. Repita casos estocásticos e examine perdas críticas. Se a economia depender de cache, teste invalidação e isolamento; se depender de classificação, teste casos ambíguos. Uma decisão de produção deve registrar as tarifas consultadas, a carga do experimento e o alcance da conclusão. Os números de crédito abaixo apenas demonstram a lógica de política.
Uma política local que não ignora saldo e identidade
FundamentosExecute node routing.cjs. Há duas rotas fictícias: curta consome dois créditos e analítica consome oito. Não representam preços reais. A chave de cache inclui tenant e policyVersion, e o orçamento é debitado somente no miss. A função roda sequencialmente para tornar o contrato fácil de examinar.
const assert=require('node:assert/strict');
const cache=new Map();
const balances=new Map([['t1',10],['t2',1]]);
function route({tenant,policyVersion,text,kind}){
const key=JSON.stringify([tenant,policyVersion,text,kind]);
if(cache.has(key)) return {...cache.get(key),cached:true};
const selected=kind==='extract'?'short':'analysis';
const credits=selected==='short'?2:8;
const balance=balances.get(tenant)||0;
if(balance<credits) return {ok:false,reason:'budget'};
balances.set(tenant,balance-credits);
const result={ok:true,route:selected,credits,cached:false};
cache.set(key,result);return result;
}
const request={tenant:'t1',policyVersion:'v1',text:'prazo?',kind:'extract'};
assert.equal(route(request).cached,false);
assert.equal(route(request).cached,true);
assert.equal(route({...request,tenant:'t2'}).ok,false);
assert.equal(balances.get('t1'),8);
console.log('Cache isolado e orçamento verificados.');O segundo pedido de t1 usa cache e não debita novamente. O pedido igual de t2 não recebe a entrada de t1 e falha por saldo. O exemplo armazena apenas metadados de rota; uma implementação real precisa cachear resultados com controles de dados. O orçamento em Map não é adequado para múltiplos processos, e créditos não comprovam economia de API.
Exercício aplicado
O roteador economiza metade dos créditos simulados, mas entrega política v1 após atualização para v2 e aceita uma tarefa ambígua na rota de extração. Determine o gate.
- Verifique a versão na chave de cache.
- Analise a classificação do caso ambíguo.
- Compare sucesso por classe com a baseline.
- Corrija as duas perdas e execute a regressão.
Abrir resolução comentada
A economia isolada não autoriza a versão. A resposta stale viola fundamentação atual, e a classificação pode reduzir qualidade justamente nos casos de maior risco. Inclua a versão da política na chave e critérios de ambiguidade na rota.
Após corrigir, execute casos independentes e preserve custo por sucesso. A simulação valida decisões, mas só uma medição externa com uso e tarifas permite afirmar economia monetária. Um resultado por classe é mais informativo que uma média agregada.
const assert=require('node:assert/strict');
const cache=new Map();
const balances=new Map([['t1',10],['t2',1]]);
function route({tenant,policyVersion,text,kind}){
const key=JSON.stringify([tenant,policyVersion,text,kind]);
if(cache.has(key)) return {...cache.get(key),cached:true};
const selected=kind==='extract'?'short':'analysis';
const credits=selected==='short'?2:8;
const balance=balances.get(tenant)||0;
if(balance<credits) return {ok:false,reason:'budget'};
balances.set(tenant,balance-credits);
const result={ok:true,route:selected,credits,cached:false};
cache.set(key,result);return result;
}
const request={tenant:'t1',policyVersion:'v1',text:'prazo?',kind:'extract'};
assert.equal(route(request).cached,false);
assert.equal(route(request).cached,true);
assert.equal(route({...request,tenant:'t2'}).ok,false);
assert.equal(balances.get('t1'),8);
console.log('Cache isolado e orçamento verificados.');Como conferir seu resultado
- Cache não cruza tenant nem versão de política.
- Saldo insuficiente bloqueia antes da operação.
- Quota e orçamento são condições separadas.
- Qualidade é comparada por classe e caso.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Calcular orçamento por tentativa.
- Definir chave de cache com versão/escopo.
Cache reduz créditos de100 para 50, mas devolve política v1 após v2 e rota barata aceita ambiguidade. Avalie ganho.
Conferir raciocínio e critérios de domínio
Cache inválido por versão deve ser invalidado/rechaveado; incluir escopo e configuração relevante.
Ambiguidade exige rota/revisão que cumpra qualidade; economia não compensa contrato errado.
Comparar custo por sucesso e saldo por execução, incluindo retries.
Evidências para autoavaliação ou revisão por pares
- Validade: Cache inválido por versão deve ser invalidado/rechaveado; incluir escopo e configuração relevante.
- Routing: Ambiguidade exige rota/revisão que cumpra qualidade; economia não compensa contrato errado.
- Consumo: Comparar custo por sucesso e saldo por execução, incluindo retries.
Um erro frequente
Economia demonstra otimização correta.
Economia só é válida mantendo critérios de qualidade e autorização.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. TTL garante resposta atual após mudança imediata?
2. Modelo barato sempre reduz custo por sucesso?
Não.
Retries e falhas podem aumentar o gasto por tarefa concluída.
3. Por que a reserva de orçamento precisa ser atômica?
Para impedir gasto concorrente acima do saldo.
Verificar e debitar em etapas separadas permite que dois workers usem o mesmo saldo.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Budgets, Rate Limits
LiteLLM • consulta: 2026-10-06
FundamentosOrçamentos e limites de requisições/tokens por usuário, chave e equipe.
Limites: Configuração e persistência importam; não citar valores de preço como permanentes.
- Spend Tracking
LiteLLM • consulta: 2026-10-06
FundamentosRegistro de uso e gasto, atribuição a chaves/usuários e consulta de custos.
Limites: Estimativa de custo depende das tarifas e dos metadados de uso; reconciliar com faturamento do provedor.
- Caching
LiteLLM • consulta: 2026-10-06
FundamentosCache de respostas, backends, cache exato e semântico, compartilhamento entre workers.
Limites: Cache de resposta difere de prompt caching; cache semântico pode retornar resposta inadequada em tráfego de agentes.
- Cache-Aside Pattern
Microsoft • consulta: 2026-10-06
FundamentosCarregamento sob demanda, invalidação e expiração de cache.
Limites: Cache pode ficar desatualizado; não garante consistência entre origem e cópia.
- Router - Load Balancing
LiteLLM • consulta: 2026-10-06
FundamentosBalanceamento, estratégias por uso/latência/custo, retries, cooldowns e fallbacks entre deployments.
Limites: Routing operacional não garante qualidade sem evals por classe de tarefa; fallback pode mudar comportamento e recursos.
- Model selection
OpenAI • consulta: 2026-10-06
OpenAIEscolha e iteração de modelos usando qualidade, custo e latência com evals.
Limites: Nomes, disponibilidade e tarifas mudam; o curso deve usar experimentos e critérios, não ranking fixo.
- Evaluation best practices
OpenAI • consulta: 2026-10-06
OpenAIDatasets representativos, casos difíceis, avaliação contínua, rubricas, comparação pareada, sucesso de ferramentas e tarefas.
Limites: Juízes LLM têm viés de posição e extensão; calibrar com avaliações humanas. Um score não garante verdade factual.