Amazon Bedrock lança cache de prompts para reduzir custos e latência em até 90%
A Amazon Bedrock, plataforma da AWS para execução de modelos de inteligência artificial generativa, disponibilizou um novo recurso de cache de prompts capaz de reduzir em até 90% os custos com tokens de entrada em aplicações que enviam o mesmo contexto repetidamente aos modelos de linguagem. A funcionalidade opera no nível da infraestrutura e permite reaproveitar partes processadas de instruções, documentos e definições de ferramentas entre chamadas consecutivas, diminuindo também o tempo até a primeira resposta do modelo.
O problema central que a novidade busca resolver é o reprocessamento contínuo de grandes blocos de texto. Quando um contrato de dez mil tokens, por exemplo, é enviado junto a cinquenta perguntas diferentes, o modelo é obrigado a processar quinhentos mil tokens de entrada, mesmo já tendo tratado aquele conteúdo nas requisições anteriores. O usuário paga o preço integral por esse retrabalho. Estratégias anteriores, como encurtar prompts, reduzir janelas de contexto ou implementar cache de respostas no nível da aplicação, ofereciam alívio parcial, porém implicavam perda de qualidade, limitação da capacidade de raciocínio ou ineficiência quando o mesmo contexto era combinado com perguntas distintas.
Com o cache de prompts, o desenvolvedor marca pontos específicos na requisição por meio de um bloco chamado cachePoint, e a Amazon Bedrock verifica se o conteúdo anterior àquele marcador já foi processado. Em caso afirmativo, ocorre um cache hit, e o modelo pula o reprocessamento, partindo direto do estado salvo. Quando não há correspondência, é registrado um cache miss, o conteúdo é processado normalmente e o resultado fica disponível para chamadas futuras. O impacto aparece tanto na redução de latência quanto no custo, já que os tokens lidos do cache são cobrados com desconto de aproximadamente 90% em relação ao preço padrão de entrada.
O funcionamento prático depende de quatro conceitos centrais. O escopo do cache é limitado a cada conta e região da AWS, garantindo isolamento natural. Cada ponto de checagem precisa atingir um limite mínimo de tokens para ser ativado: 1.024 tokens para os modelos Anthropic Claude Sonnet 4.5 e 4.6, e 4.096 tokens para os modelos Opus. O tempo de vida do cache, chamado TTL, tem como padrão cinco minutos, com alguns modelos oferecendo suporte a até uma hora. Por fim, a sintaxe do cachePoint é idêntica entre as famílias de modelos compatíveis, incluindo Anthropic Claude e Amazon Nova, o que facilita a portabilidade do código.
No aspecto financeiro, a documentação técnica da AWS descreve dois novos tipos de token. Os cacheWriteInputTokens, cobrados na primeira escrita, ficam 25% mais caros que os tokens de entrada padrão. Já os cacheReadInputTokens, lidos nas requisições seguintes, custam 90% menos. Em um cenário com um documento de dez mil tokens enviado junto a dez perguntas, a primeira chamada paga a escrita no cache, enquanto as nove seguintes leem o conteúdo armazenado, resultando em economia líquida de cerca de 75% sobre os custos de entrada.
A publicação técnica da AWS apresenta seis cenários práticos de uso, variando do básico ao avançado. O primeiro é o cache do conteúdo de mensagens, útil em sistemas de perguntas e respostas sobre documentos extensos, como aplicações de geração aumentada por recuperação. O segundo aborda o cache do prompt de sistema, que define a persona do assistente e permanece constante ao longo das conversas. O terceiro trata do cache das definições de ferramentas, indicado para fluxos agênticos que precisam consultar dezenas de esquemas a cada turno.
O quarto cenário demonstra o cache com TTL misto, no qual diferentes blocos de conteúdo recebem tempos de expiração distintos conforme a frequência de atualização. Conteúdos estáveis, como catálogos e regras de compliance, podem ser configurados para uma hora, enquanto contextos de sessão recebem cinco minutos, com a restrição de que os pontos de cache mais longos devem aparecer antes dos mais curtos. O quinto cenário trata do isolamento entre inquilinos em aplicações multi-tenant, solucionado com o acréscimo de um hash SHA-256 do identificador do cliente ao conteúdo, o que cria entradas de cache separadas sem exigir contas AWS distintas. Por fim, o sexto cenário mostra a integração com o framework LangChain por meio do método create_cache_point() da classe ChatBedrockConverse.
A AWS também destaca que a API Converse, usada nos exemplos, oferece sintaxe unificada de cache entre os modelos suportados, ao contrário da API InvokeModel, que possui variações por família. A recomendação para novos projetos é adotar a Converse, pois a mesma marca de cachePoint funciona tanto com Claude quanto com Nova, permitindo trocar de modelo sem reescrever o código de cache. Como boas práticas, a publicação sugere monitorar métricas como cacheWriteInputTokens e cacheReadInputTokens, ajustar TTLs conforme a taxa de mudança do conteúdo e aplicar mecanismos de guardrails para filtragem e validação em ambientes de produção.
