Otimizando custos do agente de IA: uso de token e armazenamento em cache

Os custos operacionais do agente de IA podem passar de gerenciáveis ​​a alarmantes com uma rapidez surpreendente. Um agente que processa 10 transações por dia é barato. O mesmo agente processando 5.000 transações por dia, com cada transação exigindo de 3 a 4 chamadas LLM com grandes janelas de contexto, pode gerar milhares de dólares em custos mensais de API — custos que não estavam no modelo de ROI original.

A otimização de custos não é opcional para implantações de IA em escala de produção. É a diferença entre um agente que proporciona um ROI positivo e outro que o destrói. Este guia aborda estratégias práticas que reduzem custos em 40-70% em implantações típicas do OpenClaw sem comprometer a qualidade da saída.

Principais conclusões

• A otimização de token (compactação de prompt, remoção de contexto) reduz os custos de API de 25 a 40% sem perda de qualidade
• O cache semântico elimina chamadas LLM para solicitações repetidas ou semelhantes, reduzindo custos de 30 a 60% em muitas cargas de trabalho
• O roteamento de modelo usa modelos baratos para tarefas simples e modelos caros somente quando necessário
• O cache de prompts (quando disponível nos provedores) reduz os custos de token de entrada para prompts repetitivos do sistema
• O processamento em lote reduz a sobrecarga por chamada para cargas de trabalho de alto volume e não sensíveis ao tempo
• O monitoramento de custos com atribuição por fluxo de trabalho identifica os comportamentos mais caros dos agentes
• O streaming reduz a latência do tempo até o primeiro token para agentes voltados ao usuário sem aumentar o custo total
• Uma estratégia abrangente de otimização de custos normalmente reduz o gasto total de LLM em 45-65% em comparação com implantações não otimizadas

---

Compreendendo os fatores de custo do agente de IA

Antes de otimizar custos, entenda o que os motiva. Os custos da API LLM são baseados principalmente no consumo de token:

Tokens de entrada: Cada token enviado ao modelo custa dinheiro — o prompt do sistema, a mensagem do usuário, o contexto recuperado (pedaços RAG), o histórico de conversas e quaisquer exemplos (algumas fotos). Os custos dos tokens de entrada são normalmente 2 a 5 vezes mais baixos do que os custos dos tokens de saída para os modelos de fronteira atuais.

Tokens de saída: Tokens gerados pelo modelo em sua resposta. As saídas detalhadas custam mais. As etapas de raciocínio (cadeia de pensamento) custam mais do que respostas diretas. As saídas JSON estruturadas custam mais do que prosa se o JSON tiver muitos campos.

Volume de chamadas: Cada chamada LLM tem um custo mínimo. Agentes de várias etapas que fazem cinco chamadas LLM por tarefa custam 5 vezes mais do que agentes de chamada única, mas podem produzir resultados muito melhores. A chave é eliminar chamadas desnecessárias.

Seleção de modelos: A diferença de custo entre os modelos é enorme. Claude 3 Haiku custa ~50x menos que Claude 3 Opus por token. O GPT-4o custa cerca de 15x mais que o GPT-4o mini. Usar um modelo de fronteira para cada tarefa é a fonte mais comum de custos desnecessários.

Um cenário de custos realista:

O agente processa 1.000 tickets de atendimento ao cliente por dia. Cada ingresso requer:

• Prompt do sistema: 800 tokens
• Contexto recuperado: 1.200 tokens
• Conteúdo do ingresso: 400 tokens
• Entrada total: 2.400 tokens
• Resposta: 600 tokens

Usando o Soneto Claude 3.5 (entrada de US$ 3/m, saída de US$ 15/m):

• Custo diário: 1.000 × [(2.400 × $ 3/M) + (600 × $ 15/M)] = $ 16,20/dia = $ 486/mês

Com a otimização (mostrada neste guia), isso cai para US$ 150 a US$ 200/mês – uma redução de 60%.

---

Compactação imediata e redução de token

Otimização do prompt do sistema

Os prompts do sistema são enviados com cada solicitação. Um prompt de sistema inchado de 2.000 tokens que poderia ser compactado para 800 tokens sem perda de informações está pagando 2,5 vezes mais do que o necessário em tokens de entrada.

Técnicas:

Remover redundância: revise os prompts do sistema para obter informações reformuladas em vários locais. Consolidar.

Use linguagem compactada: Evite preâmbulos de conversação. Comparar:

Verbose (47 tokens): "Você é um assistente prestativo e hábil na revisão de contratos. Seu trabalho é ler atentamente o contrato e identificar quaisquer cláusulas que possam representar um risco para nossa empresa."

Comprimido (23 tokens): "Você é um analista de risco de contrato. Identifique cláusulas que representam risco para a empresa cliente."

A versão compactada transmite instruções idênticas. LLMs respondem ao conteúdo semântico, não à contagem de palavras.

Use formatação estruturada: listas numeradas e marcadores transmitem informações de forma mais densa do que parágrafos.

Remova exemplos do prompt do sistema ao usar algumas fotos: Se você tiver exemplos no prompt do sistema e na mensagem do usuário, você estará pagando por eles duas vezes. Consolidar em um local.

Audite a duração dos prompts do sistema regularmente: Os prompts do sistema tendem a aumentar à medida que as equipes adicionam instruções ao longo do tempo, sem remover as desatualizadas. Uma revisão trimestral normalmente revela que 20 a 30% do conteúdo do prompt do sistema pode ser removido ou compactado.

Gerenciamento de janelas de contexto

As recuperações RAG (Retrieval Augmented Generation) são um dos maiores geradores de custos para agentes intensivos em conhecimento. Cada pedaço recuperado são tokens de entrada. O RAG não otimizado frequentemente recupera mais contexto do que o necessário.

Otimização do tamanho dos pedaços: Pedaços menores (256-512 tokens) recuperados em quantidades maiores geralmente superam pedaços grandes (mais de 1.000 tokens) para respostas a perguntas factuais. Pedaços menores também são mais baratos porque passagens irrelevantes dentro de um pedaço grande não são recuperadas.

Ajuste da contagem de recuperação: se o seu agente recuperar 10 blocos por consulta, mas usar consistentemente informações apenas dos 2 a 3 principais, reduza a contagem de recuperação. Monitore quais partes recuperadas são realmente referenciadas nas saídas do agente.

Filtragem de relevância: aplique um limite de pontuação de relevância – inclua apenas pedaços recuperados acima do limite no contexto. Pedaços com baixa relevância agregam custos sem melhorar a qualidade.

Remoção do histórico de conversas: para agentes com vários turnos, o histórico de conversas aumenta a cada turno. Turnos mais antigos costumam ser menos relevantes. Implemente uma estratégia de resumo: após 8 a 10 turnos, resuma a conversa inicial em um resumo compactado (200 a 300 tokens) em vez de reter o histórico completo passo a passo.

def manage_conversation_history(messages: list, max_tokens: int = 2000) -> list:
    """Prune conversation history to stay within token budget"""
    # Always keep system message and last N user/assistant turns
    if count_tokens(messages) <= max_tokens:
        return messages

    # Summarize early conversation if too long
    early_messages = messages[1:-6]  # Exclude system + recent 3 turns
    summary = summarize_conversation(early_messages)

    return [
        messages[0],  # System message
        {"role": "user", "content": f"[Earlier conversation summary: {summary}]"},
        *messages[-6:]  # Recent 3 turns
    ]

---

Cache Semântico

O cache semântico é a otimização de custos de maior impacto para agentes que lidam com consultas repetitivas. Ele armazena o resultado de chamadas LLM e retorna resultados armazenados em cache para solicitações subsequentes que são semanticamente semelhantes, mesmo que não sejam idênticas.

Como funciona o cache semântico

1. Quando uma chamada LLM é feita, calcule um vetor de incorporação para a entrada (prompt + contexto)
2. Pesquise no cache por resultados armazenados com alta similaridade vetorial com a entrada atual
3. Se a similaridade exceder o limite, retorne o resultado armazenado em cache (sem chamada LLM)
4. Caso contrário, faça a chamada LLM e armazene o resultado com sua incorporação

O insight crítico: muitas solicitações do mundo real são semanticamente semelhantes, mesmo quando não são textualmente idênticas. “Qual é a política de devolução de pedidos feitos nos últimos 30 dias?” e "Posso devolver algo que encomendei há 3 semanas?" são palavras diferentes, mas a mesma questão - o cache semântico pode servir o segundo a partir do cache do primeiro.

Taxa de acertos do cache por tipo de agente

Para agentes de suporte ao cliente com taxa de acerto de cache de 65%, o cache semântico reduz o volume de chamadas LLM — e, portanto, o custo do LLM — em 65%.

Configuração de cache

Limite de similaridade: O limite para declarar duas solicitações "suficientemente semelhantes" para reutilização de cache. Limite mais alto = menos acessos ao cache, mas maior precisão. Limite inferior = mais acessos ao cache, mas risco de retornar respostas sutilmente erradas para solicitações diferentes.

Para consultas factuais, um limite de similaridade de 0,92-0,95 é normalmente seguro. Para tarefas analíticas ou de raciocínio, use um limite mais alto (0,97+) para evitar o retorno de análises incorretas para questões sutilmente diferentes.

TTL do cache: Diferentes tipos de entrada de cache devem ter diferentes períodos de expiração:

• Preços do produto: 1-4 horas (alteração de preços)
• Informações sobre políticas: 24 a 48 horas (as políticas raramente mudam)
• Conhecimentos gerais: 7 dias (informação muito estável)
• Relatórios gerados: cache até que os dados subjacentes sejam alterados (invalidação acionada por evento)

Escopo do cache: configure se o cache é por usuário, por organização ou global. Os agentes de suporte ao cliente devem ter caches no escopo da organização (uma resposta apropriada para sua organização pode não ser apropriada para outra). Os agentes de conhecimento geral podem compartilhar um cache global.

---

Roteamento de modelo e seleção de LLM em camadas

Nem toda tarefa requer um modelo de fronteira. Usar GPT-4o ou Claude 3.5 Sonnet para uma tarefa de classificação simples que o GPT-4o mini realiza corretamente está pagando 15-50x mais do que o necessário.

Estratégia de roteamento

Classificação de complexidade de tarefas: implemente um classificador leve que categoriza cada solicitação recebida por complexidade:

• Simples: Pesquisa, classificação com poucas categorias, geração curta com modelo claro
• Moderado: Raciocínio em várias etapas, extração de documentos complexos, lógica condicional
• Complexo: Análise aberta, síntese criativa, julgamento diferenciado

Atribuição de modelo:

• Simples → GPT-4o mini, Claude 3 Haiku (custo: ~$0,15-0,30/M tokens)
• Moderado → Claude 3.5 Sonnet, GPT-4o (custo: ~$3-5/M tokens)
• Complexo → Claude 3.5 Sonnet, GPT-4o (ou o1 para tarefas de raciocínio profundo) (custo: $5-15/M tokens)

Roteamento substituto: se o modelo mais barato produzir resultados abaixo do limite de qualidade (detectado pela avaliação automatizada), tente novamente com o modelo mais caro. Esta abordagem em “cascata” utiliza modelos baratos de forma optimista e só aumenta quando necessário.

def route_to_model(task: AgentTask) -> str:
    complexity = classify_task_complexity(task)

    model_map = {
        "simple": "claude-haiku-3",
        "moderate": "claude-3-5-sonnet",
        "complex": "claude-3-5-sonnet"
    }
    return model_map[complexity]

def execute_with_fallback(task: AgentTask):
    primary_model = route_to_model(task)
    result = execute_with_model(task, primary_model)

    if not meets_quality_threshold(result):
        # Escalate to more capable model
        result = execute_with_model(task, "claude-3-5-sonnet")

    return result

Economias realistas com o roteamento de modelo: Em uma frota de agentes com carga de trabalho mista, 60-70% das tarefas normalmente são qualificadas como "simples". Encaminhá-los para modelos baratos alcança uma redução de custos de 50 a 70% nesse segmento, traduzindo-se em uma redução geral de custos de 30 a 50%.

---

Cache de prompt (nível do provedor)

Anthropic e OpenAI oferecem recursos de cache de prompt que reduzem o custo de prompts repetidos do sistema. Quando o prompt do sistema (ou qualquer prefixo do prompt) é idêntico em diversas solicitações, os tokens armazenados em cache custam significativamente menos do que os tokens novos.

Preço do cache antrópico: Os tokens de entrada armazenados em cache custam aproximadamente 10% do preço do token de entrada padrão (US$ 0,30/m vs. US$ 3/m para Sonnet). O custo de gravação em cache é de US$ 3,75/m (escrito uma vez e depois lido a US$ 0,30/m).

Estratégia eficaz: A estrutura solicita que a parte estável (prompt do sistema, exemplos, instruções) venha primeiro e a parte variável (entrada do usuário, contexto recuperado) venha por último. O provedor armazena em cache o prefixo estável automaticamente.

Cálculo do ponto de equilíbrio: A gravação em cache custa 1,25x o preço do token de entrada padrão; a leitura do cache custa 0,1x. O ponto de equilíbrio ocorre em 2 solicitações que compartilham o prefixo. Cada solicitação além da segunda é 90% mais barata para a parte armazenada em cache.

Para um agente com um prompt do sistema de 1.000 tokens executando 1.000 solicitações por dia:

• Sem cache: 1.000 × 1.000 tokens × US$ 3/M = custo de entrada de US$ 3/dia somente para prompt do sistema
• Com cache: US$ 3,75 (uma gravação) + 999 × 1.000 × US$ 0,30/M = US$ 0,30/dia
• Economia diária: $2,70 (redução de 90% neste componente)

---

Processamento em lote

Para cargas de trabalho não urgentes (geração de relatórios noturnos, processamento de documentos em lote, análise de dados programada), as chamadas de API em lote oferecem reduções de custos significativas.

API OpenAI Batch: redução de custos de 50% para solicitações enviadas em lotes com janelas de conclusão de 24 horas. Para a geração de relatórios noturnos, isso por si só reduz pela metade o custo da API LLM.

Lotes de mensagens antrópicas: Preços de lote semelhantes para cargas de trabalho não urgentes.

Padrões de agendamento em lote:

• Colete solicitações de geração de relatórios ao longo do dia e envie em lote no final do negócio
• Processar a ingestão de documentos para RAG fora dos horários de pico como trabalhos em lote
• Execute verificações de monitoramento de conformidade todas as noites em lotes

---

Monitoramento e atribuição de custos

A otimização requer saber de onde vêm os custos. Implemente o monitoramento de custos desde o primeiro dia de produção:

Acompanhamento de custos por fluxo de trabalho: Marque cada chamada LLM com o fluxo de trabalho ao qual ela pertence. Calcule o custo total por fluxo de trabalho por dia. Isso revela quais comportamentos dos agentes são mais caros e prioriza o esforço de otimização.

Atribuição por token: Divida os custos por tokens de entrada x saída, por componente de prompt (prompt do sistema x contexto x entrada do usuário) e por modelo. A atribuição de custos nesta granularidade permite uma otimização direcionada.

Detecção de anomalias de custos: alerta quando os custos diários aumentam mais de 20% acima da média móvel de 7 dias. Os picos indicam aumentos de volume legítimos (esperados) ou bugs (loops infinitos, janelas de contexto descontroladas, injeção imediata causando conclusões excepcionalmente longas).

Custo por tarefa bem-sucedida: divida os custos totais pelas conclusões de tarefas bem-sucedidas para obter o custo por unidade de valor. Esta é a métrica que importa para o ROI – se o custo por tarefa diminuir enquanto o volume e a qualidade da tarefa se mantiverem, a otimização está funcionando.

---

Perguntas frequentes

Quanto a otimização de custos pode reduzir realisticamente os custos da API LLM?

Em implantações típicas do OpenClaw, um esforço sistemático de otimização abordando compactação imediata, cache semântico e roteamento de modelo atinge uma redução de custos de 45 a 65% em comparação com implantações não otimizadas. As economias específicas dependem muito das características da carga de trabalho — os agentes com consultas altamente repetitivas são os que mais se beneficiam do cache; agentes com consultas diversas e exclusivas se beneficiam mais do roteamento de modelo.

O cache semântico compromete a precisão da resposta?

Com a configuração de limite adequada, o impacto na precisão é insignificante — normalmente menos de 0,5% de degradação em tarefas factuais. A chave é definir o limite de similaridade de forma adequada para o tipo de tarefa. Para tarefas em que diferenças sutis na pergunta levam a respostas corretas diferentes, use limites de similaridade mais altos (0,96+) para garantir que apenas consultas verdadeiramente equivalentes sejam atendidas no cache.

Qual é o impacto da latência do cache semântico?

Pesquisas de cache (pesquisa de similaridade de vetor) adicionam latência de 5 a 15 ms. Os acessos ao cache eliminam a latência da chamada LLM (normalmente 500ms-3s). Resultado líquido: as respostas armazenadas em cache são 20 a 200 vezes mais rápidas do que as respostas não armazenadas em cache. Esta é uma melhoria de latência, não uma degradação.

Como podemos implementar o monitoramento de custos sem um esforço significativo de engenharia?

A camada de observabilidade do OpenClaw captura contagens de tokens e seleções de modelos para cada execução automaticamente. ECOSIRE configura um painel de custos durante a implementação que mostra os custos por fluxo de trabalho, modelo e período de tempo. Nenhuma engenharia personalizada é necessária — a infraestrutura de monitoramento faz parte da implementação padrão.

Em que escala as medidas de otimização de custos valem a pena?

A maioria das medidas de otimização valem mais de US$ 500/mês em custos de API LLM. Abaixo desse limite, o esforço de engenharia normalmente excede as economias. Acima de US$ 2.000/mês, a otimização sistemática é fortemente recomendada — o ROI sobre o tempo de engenharia investido na otimização é muito alto nessa escala.

A mudança para modelos mais baratos compromete a qualidade dos resultados dos agentes?

Para tarefas em que modelos mais baratos oferecem qualidade genuinamente equivalente, mudar para eles representa pura economia. Para tarefas que exigem raciocínio profundo, julgamento matizado ou síntese complexa, modelos mais baratos produzem resultados visivelmente piores. O padrão de roteamento de modelo aborda isso usando modelos mais baratos somente onde eles são apropriados e roteando para modelos premium para tarefas que os exigem. A chave é a validação empírica – teste o modelo mais barato em sua tarefa específica antes de direcionar o tráfego de produção para ele.

---

Próximas etapas

A otimização de custos para agentes de IA é uma disciplina contínua, não um projeto único. As implementações OpenClaw da ECOSIRE incluem uma camada de otimização de custos desde o primeiro dia – cache semântico, roteamento de modelo e otimização imediata são incorporados à arquitetura de implantação, em vez de serem adicionados posteriormente.

Explore os serviços ECOSIRE OpenClaw para discutir seus requisitos de otimização de custos ou revise nossas opções de retenção de manutenção e otimização para entender como o ECOSIRE gerencia a eficiência de custos contínua para implantações de produção do OpenClaw.