O cache de prompts reduz os custos de IA e mantém seus dados na memória

Um prompt inicial de 3.000 tokens seguido por cinco rodadas de conversa, cada uma adicionando 1.000 tokens. Sem cache, essa sessão custa 30 unidades. Com cache quente e TTL de 5 minutos, custa 12,2. Com cache frio, custa 37,5, mais do que se nunca tivesse ativado o cache. Mesmo prompt, mesmo modelo, e a única variável é se o prefixo correspondeu. Um prefixo é o início imutável de uma solicitação, como as instruções e material de fundo, que a IA pode reutilizar em vez de reprocessar toda vez.

Baseado nos multiplicadores de preço da Anthropic (leitura de cache 0,1x, escrita de 5 minutos 1,25x), contando apenas os tokens de entrada.

A distribuição do exemplo é razão suficiente para aprender sobre cache de prompts. O cache também guarda tudo que sua equipe e pipelines colocam no prompt, e essa parte recebe muito menos atenção.

O que é o cache de prompt e como funciona

Quando um modelo lê um prompt, ele calcula estados chave-valor (KV) para cada token para poder consultá-los enquanto escreve a resposta. Normalmente, esses estados são descartados ao final da resposta. O cache do prompt os mantém. O cache armazena os tensores KV, não os tokens brutos, e uma solicitação posterior que começa com o mesmo prefixo reutiliza esse estado salvo e processa apenas o que é novo.

A correspondência é exata e baseada em prefixos. Os provedores comparam o início do seu pedido com o que armazenaram recentemente em cache, nesta ordem: ferramentas, depois o prompt do sistema, depois as mensagens. Alterar uma data no prompt do sistema faz com que tudo que vem depois não corresponda. Uma gravação no cache salva a conversa até o momento por um tempo de vida (TTL), e cada acerto reinicia esse relógio, mantendo a sessão ativa automaticamente.

Cinco formas como o cache rápido impede de economizar dinheiro

Valores voláteis perto do topo. Uma data atual, um nome de usuário ou um ID de solicitação que alguém adicionou para registro transforma cada chamada em uma escrita. Uma equipe moveu um único campo volátil para o final do prompt, após a parte em cache, e as leituras finalmente começaram a funcionar.

Pausas mais longas que o TTL. Ao se afastar de uma sessão de 5 minutos para uma reunião, a próxima vez paga o preço cheio por toda a conversa. A linha de todos os erros na tabela acima mostra como é isso.

Compactação. Cada compactação é um início a frio, uma rodada a preço cheio em um histórico resumido que o provedor nunca viu. Execute /compact antes de uma pausa enquanto o cache ainda está quente. Após expirar, compactar custa mais do que continuar.

Alterações no meio da sessão. Alterar o modelo, o nível de esforço, plugins ou servidores MCP pode modificar o prompt do sistema e invalidar o cache. Verifique a documentação do provedor antes de alterar configurações durante uma tarefa longa.

Escalonamento e roteamento. Em alto volume, os pedidos chegam a máquinas sem sua entrada em cache. A verificação automática de prefixo do Bedrock analisa apenas cerca de 20 blocos de conteúdo a partir de um ponto de verificação, então uma seção estática longa precisa de mais de um.

Como verificar se o cache de prompts está funcionando

Compare os tokens de gravação em cache com os tokens de leitura em cache para cada recurso. Se as gravações acompanham sua contagem de solicitações, nada está sendo reutilizado. Confirme que cache_read_input_tokens esteja acima de zero na primeira vez após um período ocioso. Na API Converse do Bedrock, leia cacheReadInputTokens e cacheWriteInputTokens, e lembre-se que inputTokens conta apenas tokens não armazenados em cache, então a entrada total é inputTokens mais ambos os campos de cache. No GPT-5.6 e posteriores, uma resposta com cached_tokens acima de zero e cache_write_tokens em zero significa uma correspondência completa.

Para manter uma sessão longa ativa, envie uma pequena solicitação útil a cada 20 a 25 minutos. Um temporizador baseado em inatividade funciona melhor que um ping fixo, pois o trabalho real o reinicia de qualquer forma.

Cache de prompts e dados sensíveis

A regra de ouro do cache é conteúdo estático primeiro e a pergunta do usuário por último. Leia essa regra como um inventário de dados. As partes que podem ser armazenadas em cache são definições de ferramentas, prompts do sistema, exemplos few-shot, grandes documentos de referência e turnos antigos da conversa. Em uma configuração RAG, os documentos de referência são os mesmos arquivos inseridos em cada solicitação. Em um chat, o histórico da conversa é o que as pessoas digitam.

Suponha que um funcionário envie uma entrada de evento do sistema incluindo um ID interno de usuário, um carimbo de data/hora e um código de rastreamento da transação. Em uma sessão em cache, esse texto aparece no prefixo a cada turno seguinte, e cada turno atualiza seu relógio.

Os provedores tratam disso. Os caches não são compartilhados entre organizações, mesmo para prompts idênticos em bytes. Anthropic e OpenAI descrevem o cache como elegível para retenção zero de dados: o texto bruto do prompt não é armazenado em repouso, e apenas o estado KV calculado fica na memória ou é brevemente descarregado para retenção estendida, até o fim do TTL. O cache explícito do Google suporta controles de serviço VPC em sua plataforma empresarial. São controles reais.

Eles também deixam uma janela, e você escolhe a duração. De 5 minutos a 1 hora nos modelos Anthropic, de 30 minutos a 12 horas no GPT-5.6 da OpenAI e posteriores, e até 24 horas nos modelos OpenAI anteriores com retenção estendida. Os pings heartbeat a estendem enquanto alguém os enviar. Leia os termos atuais de tratamento de dados de cada provedor antes de armazenar informações sensíveis.

O ajuste de custos também pode ir na direção errada. Um prefixo estável maior faz cache melhor, então uma equipe que busca 50% de repetição tem motivo para carregar mais documentos. Os cálculos de economia não dizem nada sobre o conteúdo desses documentos.

Injeção de prompt eleva a aposta. A injeção indireta esconde instruções em arquivos que um assistente provavelmente lerá, como um PDF rotineiro ou um convite de calendário, e a exploração EchoLeak teve uma pontuação CVSS de 9,3. Um arquivo contaminado em um conjunto de referência em cache é relido a cada solicitação até que alguém o remova.

Shadow AI adiciona a parte que o TI não consegue ver. A maioria das equipes vê apenas uma pequena parte das ferramentas de IA usadas por seus colaboradores, desde Claude.ai e Perplexity até Gemini e extensões de navegador. Proibi-las leva os funcionários a usar dispositivos pessoais, onde as ferramentas de segurança não alcançam. Líderes de segurança estão adotando limites específicos por grupo: scanners para chaves de API vazadas e segredos codificados para engenharia, e bloqueios de uploads ou credenciais tokenizadas para jurídico e financeiro.

A tokenização é uma resposta no lado da entrada. Um gateway substitui o nome do paciente por um token lógico como [PERSON_01] em menos de 300 milissegundos, para que o modelo ainda siga a narrativa sem ver a identidade. Um scanner só pode mascarar o que reconhece, por isso a classificação deve ser o primeiro passo.

Auditores exigem o mesmo rastreamento. SOX, PCI DSS 4.0 e o Artigo 25 da Lei Europeia de IA indicam a necessidade de registro e rastreabilidade nas interações com IA, incluindo um ID único por solicitação e uma razão registrada para cada bloqueio. O cache é mais um local onde os dados residem, e a duração da retenção também é uma questão.

Antes de ativar o cache de prompts

• Coloque o conteúdo estático primeiro e a pergunta do usuário por último.
• Decida quais fontes podem entrar em um prefixo em cache e mantenha registros de clientes, credenciais e dados regulados fora.
• Escolha o TTL mais curto que ainda produza acertos.
• Acompanhe as leituras e gravações de cache para cada recurso.
• Audite o conteúdo dos seus documentos de referência antes de adicioná-los ao prompt.

Classifique o que entra no prompt antes de ser armazenado em cache

Cada controle acima depende de saber quais arquivos são sensíveis. Netwrix Data Classification responde a isso na fonte. Ele descobre e classifica continuamente dados sensíveis e regulados em servidores de arquivos Windows, NetApp, Dell EMC, Nutanix Files, SharePoint, Microsoft 365, Exchange, SQL Server, Oracle, MySQL, Box, Dropbox e Google Drive. Regras pré-definidas cobrem GDPR, HIPAA e PCI DSS, e taxonomias personalizadas cuidam do restante.

Etiquetas de classificação incorporadas em arquivos alimentam ferramentas DLP e IRM, para que um documento marcado como sensível possa ser mantido fora de um fluxo de trabalho de IA antes que alguém o carregue em um prefixo. Detecção ROT encontra arquivos redundantes, obsoletos e triviais, reduzindo o conteúdo desatualizado nos seus conjuntos de referência. A remediação automatizada move dados sensíveis para locais seguros, remove permissões excessivas e oculta conteúdo confidencial.