O Que é Cache de Prompt? Melhores Práticas Explicadas

Modelos de Linguagem Grande (LLMs) revolucionaram a forma como interagimos com a IA, possibilitando tarefas complexas como geração de texto, tradução, resposta a perguntas e mais. No entanto, interagir com esses modelos poderosos, especialmente com comandos sofisticados, pode acarretar custos computacionais significativos e latência. Muitos aplicativos envolvem o envio repetido de comandos semelhantes ou parcialmente idênticos. Imagine um chatbot com um comando de sistema fixo, uma ferramenta de análise de documentos processando pedaços com as mesmas instruções ou um agente utilizando definições de ferramentas consistentes. Nesses cenários, o LLM processa repetidamente as mesmas informações iniciais (o prefixo do comando), desperdiçando computação e aumentando os tempos de resposta.

A cache de comandos surge como uma técnica poderosa de otimização para resolver essa ineficiência. Ela permite que os provedores de LLM armazenem o estado computacional intermediário associado à parte inicial e estática de um comando (o prefixo). Quando solicitações subsequentes usam o mesmo prefixo, o modelo pode reutilizar esse estado em cache, pulando a computação redundante e processando apenas a nova parte dinâmica do comando (o sufixo). Isso leva a melhorias substanciais tanto na latência quanto no custo, tornando as aplicações de LLM mais rápidas e econômicas.

Este guia fornece uma visão abrangente sobre a cache de comandos, como funciona, seus benefícios, detalhes de implementação (focando na API da Anthropic, que também é relevante para os modelos Claude na AWS Bedrock), considerações sobre preços, limitações e melhores práticas.

Como Funciona a Cache de Comandos: O Mecanismo

No seu núcleo, a cache de comandos explora a natureza repetitiva de muitas interações com LLM. Quando você envia um comando a um LLM, o modelo processa os tokens de entrada sequencialmente para gerar uma representação ou estado interno. A cache de comandos intercepta esse processo.

1. Cache Miss (Primeira Solicitação / Prefixo Modificado): Quando uma solicitação chega com um prefixo de comando que não foi visto recentemente ou não corresponde a nenhuma entrada em cache existente, o LLM processa o comando inteiro como de costume. No entanto, se a cache está habilitada para um limite de prefixo específico, o sistema armazena o estado interno do modelo correspondente àquele prefixo após processá-lo. Isso é frequentemente referido como uma gravação em cache. Um identificador único, normalmente um hash criptográfico do conteúdo do prefixo (incluindo comandos de sistema, definições de ferramentas e mensagens até o ponto de cache), é associado a esse estado armazenado, atuando como a chave de cache.
2. Cache Hit (Solicitação Subsequentemente): Se uma solicitação subsequente chegar dentro do Tempo-De-Vida (TTL) da cache e seu prefixo corresponder exatamente ao conteúdo associado a uma chave de cache armazenada, o sistema recupera o estado interno salvo. O LLM efetivamente avança para o final do prefixo sem reprocesá-lo. Ele então precisa processar apenas a parte nova do comando (o sufixo). Isso é conhecido como uma leitura de cache ou cache hit.

O Prefixo em Cache:

O que exatamente constitui o "prefixo" depende da API e de como você estrutura sua solicitação. Geralmente, inclui as partes estáticas do seu comando que você pretende reutilizar entre chamadas. Por exemplo, usando a estrutura da API da Anthropic como referência:

• Ferramentas: Definições das ferramentas/funções disponíveis.
• Comando do Sistema: Instruções de alto nível ou contexto para o modelo.
• Mensagens: Mensagens iniciais do usuário/assistente, como exemplos de few-shot ou histórico de conversa.

A ordem tipicamente importa (por exemplo, a Anthropic processa tools, depois system, depois messages). Você designa onde o prefixo em cache termina usando parâmetros específicos da API.

Características da Cache:

• Vida Útil (TTL): As caches não são permanentes. Elas têm um TTL. Por exemplo, a cache da Anthropic tem um mínimo de 5 minutos de TTL, que é renovado cada vez que a entrada em cache é acessada (um cache hit). Se uma entrada em cache não for usada dentro de seu TTL, ela expira e precisará ser recriada na próxima solicitação relevante. Atualmente, a maioria das implementações oferecem caching "efêmero" com vidas úteis relativamente curtas.
• Escopo e Privacidade: A cache é projetada com a privacidade em mente. As caches são tipicamente segregadas ao nível da organização ou conta. Mesmo que dois conjuntos diferentes de organizações enviem o mesmo prefixo de comando, eles não compartilharão uma entrada em cache. Dentro de uma organização, usuários que enviam prefixos idênticos podem potencialmente compartilhar uma entrada em cache, melhorando a eficiência para aplicações em equipe. O uso de hashes criptográficos para chaves garante que apenas solicitações com prefixos idênticos possam acessar uma cache específica.
• Correspondência Exata: A cache depende de correspondências exatas do conteúdo do prefixo. Qualquer alteração, por menor que seja (até mesmo espaços em branco), dentro do prefixo designado resultará em um cache miss e necessitará de uma nova gravação em cache.

Por Que Usar Cache de Comandos?

A implementação da cache de comandos oferece vantagens significativas, principalmente voltadas para desempenho e eficiência de custos.

1. Redução da Latência: Esse é frequentemente o benefício mais imediato. Ao evitar a reprocessamento de potencialmente milhares de tokens de prefixo, o LLM pode começar a processar as informações novas relevantes (o sufixo do comando) muito mais rápido. Isso se traduz diretamente em tempos de resposta mais rápidos para o usuário final. Para aplicações que exigem interação em tempo real, como chatbots ou assistentes de código, essa aceleração é crucial. A AWS Bedrock relata potenciais reduções de latência de até 85% para os modelos suportados.
2. Redução de Custos: APIs de LLM normalmente cobram com base no número de tokens de entrada e saída processados. Quando um cache hit ocorre, você é frequentemente cobrado a uma taxa significativamente menor pelos tokens lidos do cache em comparação à taxa padrão de tokens de entrada. Você só paga a taxa padrão para os tokens novos no sufixo (e potencialmente uma taxa ligeiramente mais alta pela primeira gravação em cache). Ao longo de muitas chamadas com grandes prefixos estáticos, isso pode levar a economias substanciais. A AWS Bedrock sugere que reduções de custos de até 90% são possíveis.
3. Desempenho Otimizado para Casos de Uso Comuns: A cache é particularmente impactante para aplicações que envolvem repetição de comandos por natureza:

• Geração Aumentada por Recuperação (RAG) / Q&A de Documentos: Documentos grandes ou trechos de contexto são frequentemente alimentados repetidamente como parte do comando, enquanto apenas a pergunta do usuário muda. A cache do contexto do documento acelera significativamente o Q&A sobre aquele documento.
• Prompting de Few-Shot: Fornecer múltiplos exemplos dentro do comando (aprendizado de few-shot) melhora o desempenho do modelo, mas aumenta o comprimento do comando. A cache desses exemplos estáticos evita que sejam reprocessados para cada nova consulta.
• Fluxos de Trabalho Agentes: Agentes de IA frequentemente dependem de comandos de sistema complexos, instruções detalhadas e um conjunto fixo de definições de ferramentas. A cache desses elementos constantes acelera a execução de tarefas, especialmente em processos multi-etapas.
• Chatbots / Conversas Multi-Turno: À medida que o histórico da conversa cresce, o comando inicial do sistema e as instruções frequentemente permanecem as mesmas. A cache do comando do sistema, e potencialmente a cache incremental das falas da conversa, mantém a interação ágil mesmo à medida que a janela de contexto se preenche.
• Assistentes de Código: Contexto de código estático, documentação de bibliotecas ou instruções de boilerplate podem ser armazenados em cache, permitindo que o assistente foque a computação na consulta específica de codificação do usuário.

1. Integração Sem Costura: A cache de comandos é projetada para funcionar ao lado de outras funcionalidades de LLM. Por exemplo, se integra com funcionalidades da AWS Bedrock como Agentes e Guardrails, permitindo que você aproveite configurações complexas sem incorrer na penalidade total de latência por componentes repetidos.

Como Habilitar a Cache de Comandos

O método exato para habilitar a cache de comandos varia um pouco entre provedores de LLM e suas APIs. Aqui, focaremos na implementação usando a API de Mensagens da Anthropic, que é aplicável aos modelos Claude diretamente através da Anthropic ou por meio de plataformas como AWS Bedrock.

Princípio Geral: Estruture Seu Comando

A chave é estruturar suas chamadas de API de modo que o conteúdo estático e reutilizável apareça primeiro, seguido pelo conteúdo dinâmico.

+-------------------------+--------------------------+
|      PREFIXO ESTÁTICO   |      SUFIXO DINÂMICO     |
| (Comando do Sistema,    | (Nova Consulta do Usuário,|
|  Ferramentas, Exemplos  | Última Turno da          |
|  de Few-Shot, Contexto) | Conversa, etc.)          |
+-------------------------+--------------------------+
          ^
          |
   Ponto de Quebra de Cache Aqui

Implementação da API da Anthropic (cache_control)

A Anthropic usa o parâmetro cache_control dentro do corpo de solicitação da API de Mensagens para habilitar e gerenciar a cache.

• Ativação: Inclua um objeto cache_control dentro de um dos blocos que você deseja incluir como o final do seu prefixo que pode ser armazenado em cache. Atualmente, o único type suportado é "ephemeral".
• Colocação: Você pode colocar o bloco cache_control em:
• A mensagem do comando system.
• Um objeto de message específico (turno do usuário ou assistente).
• Um bloco de definição de tool (menos comum, mas possível).
• Ordem de Criação de Cache: O prefixo em cache é construído com base no conteúdo até e incluindo o bloco marcado com cache_control, seguindo a ordem padrão: tools -> system -> messages.
• Múltiplos Pontos de Quebra: Você pode definir até 4 pontos de quebra de cache em uma única solicitação, adicionando cache_control a vários blocos. O sistema tentará encontrar o prefixo em cache correspondente mais longo com base nesses potenciais pontos de quebra.

Exemplo (SDK Python da Anthropic): Cache de um Comando do Sistema

import anthropic

client = anthropic.Anthropic(api_key="SUA_CHAVE_API")

# Primeira Solicitação (Gravação em Cache)
response1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # Este comando do sistema é o conteúdo que queremos armazenar em cache
            "text": "Você é um assistente útil especializado em astrofísica. Seu banco de dados inclui detalhes extensos sobre evolução estelar, cosmologia e ciência planetária. Responda com precisão e concisão.",
            "cache_control": {"type": "ephemeral"} # Marcar para armazenamento em cache
        }
    ],
    messages=[
        {
            "role": "user",
            # Esta é a parte dinâmica, não armazenada em cache no prefixo
            "content": "Qual é o limite de Chandrasekhar?"
        }
    ]
)
print("Primeira Resposta:", response1.content)
print("Uso (Gravação):", response1.usage)
# A saída de exemplo pode se parecer com:
# Uso(Gravação): Uso(input_tokens=60, output_tokens=50, cache_creation_input_tokens=60, cache_read_input_tokens=0)

# Solicitação Subsequentemente (Cache Hit - dentro do TTL, por exemplo, < 5 mins depois)
response2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # EXATAMENTE o mesmo comando do sistema de antes
            "text": "Você é um assistente útil especializado em astrofísica. Seu banco de dados inclui detalhes extensos sobre evolução estelar, cosmologia e ciência planetária. Responda com precisão e concisão.",
            "cache_control": {"type": "ephemeral"} # Marcar novamente
        }
    ],
    messages=[
        {
            "role": "user",
            # Nova consulta dinâmica
            "content": "Explique o conceito de energia escura."
        }
    ]
)
print("\\\\nSegunda Resposta:", response2.content)
print("Uso (Hit):", response2.usage)
# A saída de exemplo pode se parecer com:
# Uso(Hit): Uso(input_tokens=8, output_tokens=75, cache_creation_input_tokens=0, cache_read_input_tokens=60)

Neste exemplo:

1. A primeira chamada processa os 60 tokens do comando do sistema e os 8 tokens da mensagem do usuário. Ela armazena em cache o comando do sistema (cache_creation_input_tokens: 60).
2. A segunda chamada encontra um cache hit para o comando do sistema idêntico (cache_read_input_tokens: 60). Ela só precisa processar os 8 tokens da nova mensagem do usuário como entrada padrão (input_tokens: 8).

Exemplo (Cache Incremental na Conversa):

Para armazenar em cache o histórico da conversa, você pode colocar cache_control na última mensagem que deseja incluir na cache para a próxima rodada.

# Turno 1 (Usuário pergunta, Assistente responde - Cache do Sistema + Turno 1)
response_turn1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Mantenha uma persona amigável."}], # Cache isso também
    messages=[
        {"role": "user", "content": "Olá Claude!"},
        {"role": "assistant", "content": "Olá! Como posso te ajudar hoje?", "cache_control": {"type": "ephemeral"}} # Cache até aqui
    ]
)
# Suponha que o usuário acrescente outra mensagem para o Turno 2
# Turno 2 (Cache hit para o Sistema + Turno 1, Gravação de Cache para Turno 2)
response_turn2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Mantenha uma persona amigável."}], # Mesmo comando do sistema
    messages=[
        {"role": "user", "content": "Olá Claude!"}, # Parte do prefixo armazenado em cache agora
        {"role": "assistant", "content": "Olá! Como posso te ajudar hoje?"}, # Parte do prefixo armazenado em cache agora
        {"role": "user", "content": "Diga-me um fato curioso."}, # Novo conteúdo dinâmico
        {"role": "assistant", "content": "Você sabia que o mel nunca estraga?", "cache_control": {"type": "ephemeral"}} # Cache até o final do Turno 2
    ]
)
# O uso do Turno 2 mostraria cache_read_input_tokens para Sistema+Turno1
# e cache_creation_input_tokens para as novas mensagens do usuário/assistente do Turno 2

Monitorando o Desempenho da Cache:

A resposta da API inclui métricas de uso que revelam como a cache foi utilizada:

• input_tokens: Número de tokens de entrada não armazenados em cache processados (o sufixo dinâmico).
• output_tokens: Número de tokens gerados na resposta.
• cache_creation_input_tokens: Número de tokens de entrada processados e gravados na cache nesta solicitação (ocorre em um cache miss).
• cache_read_input_tokens: Número de tokens de entrada carregados da cache nesta solicitação (ocorre em um cache hit).

Monitorar esses campos é crucial para entender se sua estratégia de cache é eficaz. Uma alta proporção de cache_read_input_tokens em relação a cache_creation_input_tokens ao longo do tempo indica sucesso no caching.

AWS Bedrock:

Para modelos como o Anthropic Claude acessados via AWS Bedrock, o mecanismo de cache é tipicamente habilitado usando o mesmo parâmetro cache_control dentro do corpo da solicitação de invocação do modelo (application/json formatado passado para InvokeModel ou InvokeModelWithResponseStream). Você deve estruturar o corpo JSON de acordo com os requisitos específicos do modelo (por exemplo, o formato da API de Mensagens da Anthropic) e incluir o campo cache_control como mostrado acima. Consulte a documentação específica do Bedrock para o provedor de modelo que você está usando.

Qual é o Preço da Cache de Comandos?

A cache de comandos introduz uma estrutura de preços mais sutil em comparação aos custos padrão dos tokens. Embora seja benéfica em geral, é importante entender os diferentes tipos de tokens envolvidos:

1. Tokens de Entrada Base: Esses são os tokens de entrada padrão que são não fazem parte de um prefixo em cache (ou seja, o sufixo dinâmico em um cenário de cache hit, ou o comando inteiro se a cache não for usada ou tiver um miss). Eles são cobrados à taxa padrão de tokens de entrada do modelo.
2. Tokens de Gravação em Cache (cache_creation_input_tokens): Quando um prefixo é processado pela primeira vez (ou após um cache miss) e gravado na cache, os tokens associados a esse prefixo são frequentemente cobrados a uma taxa premium. Por exemplo, a Anthropic cobra 25% a mais do que a taxa base de token de entrada para gravações em cache. Isso reflete o custo de processamento e armazenamento da entrada em cache.
3. Tokens de Leitura em Cache / Tokens de Cache Hit (cache_read_input_tokens): Quando um cache hit ocorre, os tokens correspondentes ao prefixo carregados da cache são cobrados a uma taxa significativamente descontada. Por exemplo, a Anthropic cobra apenas 10% da taxa padrão de token de entrada (um desconto de 90%) para leituras em cache. Isso reflete a economia computacional.
4. Tokens de Saída: Tokens gerados pelo LLM em resposta são cobrados à taxa padrão de token de saída do modelo, independentemente de a cache ter sido utilizada para a entrada.

Tabela de Preços Exemplo (Modelos Claude da Anthropic - taxas ilustrativas):

(Nota: Sempre consulte as páginas de preços oficiais da Anthropic e AWS Bedrock para as taxas mais atuais.)

A relação custo-benefício depende fortemente de quão frequentemente você obtém acertos de cache em comparação a misses para um dado prefixo. Se um prefixo grande for reutilizado muitas vezes, o custo inicial mais alto da gravação em cache é rapidamente compensado pelas substanciais economias geradas pelas leituras de cache subsequentes.

Limitações da Cache de Comandos

Embora poderosa, a cache de comandos tem limitações e fatores a serem considerados:

Comprimento Mínimo Armazenável em Cache: Os modelos frequentemente têm um requisito mínimo de tokens para que um prefixo seja elegível para cache. Comandos menores que esse limite não podem ser armazenados em cache, mesmo que marcados com cache_control.

• Anthropic Claude 3.7/3.5 Soneto & Ópera: Mínimo 1024 tokens.
• Anthropic Claude 3.5/3 Haiku: Mínimo 2048 tokens.

Invalidade de Cache (Quebra de Cache): A cache é extremamente sensível a mudanças no prefixo. Qualquer modificação quebrará a cache e forçará uma nova gravação:

• Alterar qualquer conteúdo de texto dentro dos blocos system, tools, ou messages designados como parte do prefixo.
• Mudar a ordem ou número de definições de tool.
• Mudar parâmetros de tool_choice (por exemplo, mudar de auto para uma ferramenta específica).
• Adicionar, remover ou alterar imagens dentro do comando (para modelos multimodais).
• Alterar outros parâmetros do modelo que afetam o processamento inicial também pode quebrar a cache (por exemplo, as configurações de pensamento estendido da Anthropic podem invalidar caches de mensagens).

Vida Útil da Cache (TTL): Lembre-se de que a cache é efêmera (por exemplo, mínimo de 5 minutos de TTL para Anthropic, renovada no uso). Prefixos não reutilizados dentro do TTL expirarão. Atualmente, não há como limpar ou estender manualmente a cache além do seu comportamento automático.

Concorrência: Se você enviar muitas solicitações idênticas simultaneamente direcionando a um prefixo antes que a primeira solicitação tenha terminado e escrito a entrada em cache, solicitações subsequentes podem resultar em misses de cache até que a primeira gravação seja concluída. Para garantir hits em cenários paralelos, pode ser necessário aguardar a primeira resposta antes de enviar outras.

Modelos Suportados: A cache de comandos não está universalmente disponível em todos os modelos ou provedores. Sempre verifique a documentação do modelo específico que você pretende usar. (Atualmente confirmado para vários modelos Claude 3 e 3.5).

Depuração: Identificar mudanças sutis que causam misses de cache pode ser complicado. Comparações cuidadosas do conteúdo exato do prefixo entre chamadas são necessárias.

Melhores Práticas para um Cache Eficaz

Para maximizar os benefícios da cache de comandos:

1. Estruture os Comandos de Forma Inteligente: Coloque as informações mais estáveis e reutilizáveis (comandos de sistemas, instruções, definições de ferramentas, documentos de contexto, exemplos de few-shot) no início da sequência do seu comando. Coloque informações dinâmicas, frequentemente mutáveis (consultas do usuário, últimos turnos da conversa) após o ponto de quebra da cache.
2. Identifique Pontos de Quebra Ótimos: Use cache_control (ou o mecanismo equivalente) deliberadamente. Marque o final do maior bloco possível de conteúdo verdadeiramente estático. Se usar múltiplos pontos de quebra (como permite a Anthropic), considere diferentes níveis de estabilidade na estrutura do seu comando.
3. Monitore o Uso da Cache: Verifique regularmente cache_creation_input_tokens e cache_read_input_tokens nas respostas da sua API. Busque uma alta proporção de leituras em relação às gravações ao longo do tempo. Se você vê principalmente gravações, seus prefixos podem estar mudando com muita frequência, ou podem estar abaixo do comprimento mínimo armazenável em cache.
4. Evite Mudanças Desnecessárias: Tenha em mente que até mesmo pequenas mudanças, aparentemente insignificantes, no conteúdo do prefixo (como adicionar um espaço ou mudar a pontuação) quebrarão a cache. Garanta consistência na maneira como os prefixos são gerados.
5. Considere as Trocas de Custo: A cache é mais eficaz para prefixos longos e frequentemente reutilizados. Não armazene em cache prefixos muito curtos, pois as economias potenciais são mínimas e podem não compensar a complexidade. Evite armazenar entradas de usuário altamente variáveis em cache.
6. Teste e Itere: Experimente diferentes estruturas de comandos e pontos de quebra de cache para encontrar a estratégia ideal para a carga de trabalho e os padrões de uso específicos da sua aplicação.

Conclusão

A cache de comandos é uma técnica de otimização vital para quem constrói aplicações sobre modelos de linguagem grande. Ao armazenar e reutilizar inteligentemente o estado computacional de prefixos de comandos estáticos, ela aborda diretamente os desafios de latência e custo associados ao uso de comandos longos ou repetitivos. Entender como a cache funciona, seus detalhes específicos de implementação para o seu provedor de LLM escolhido (como o cache_control da Anthropic), as nuances de preços associadas e suas limitações permite que você projete aplicações de IA mais eficientes, responsivas e econômicas. À medida que os casos de uso de LLM crescem em complexidade e escala, aproveitar recursos como a cache de comandos será cada vez mais crucial para construir soluções de desempenho e sustentáveis.