
Cache de Prompts LLM: Reduza Custos da API em 90% (Todos os 3 Fornecedores)
O cache de prompts LLM permite reutilizar tokens previamente processados entre chamadas de API, reduzindo os custos de entrada em até 90% e o tempo até ao primeiro token (TTFT) em até 85%. Se está a enviar o mesmo prompt de sistema, definições de ferramentas ou exemplos few-shot em cada pedido, está a pagar o preço total por trabalho que a GPU já realizou.
Este guia abrange a OpenAI, a Anthropic e a Gemini com o mesmo chatbot implementado nos três SDKs, algo que nenhum outro guia faz. Abordaremos também a atualização de cache automático da Anthropic de fevereiro de 2026, cenários de custo de produção com valores reais em dólares e os anti-padrões que destroem silenciosamente a sua taxa de acerto do cache.
<!-- IMAGE: Diagrama do fluxo de reutilização do cache KV mostrando correspondência de prefixo do prompt, caminho de acerto do cache (rápido, barato) e caminho de falha do cache (processamento padrão) -->Resumo Rápido: Os Três Fornecedores de Relance
Antes de mergulhar nos detalhes de implementação, aqui está a comparação completa. Se já sabe qual fornecedor está a utilizar, salte para a respetiva secção. Se está a avaliar opções, esta tabela diz-lhe tudo em 10 segundos.
| Funcionalidade | OpenAI | Anthropic | Gemini |
|---|---|---|---|
| Tipo de Cache | Automático | Automático + Explícito | Implícito + Explícito |
| Tokens Mínimos | 1.024 | 1.024 (maioria dos modelos) | 1.024 (Flash) / 4.096 (Pro) |
| TTL | 5-10 min (até 24h estendido) | 5 min ou 1 hora | Configurável (padrão 1 hora) |
| Custo de Escrita no Cache | 1x (sem custo extra) | 1,25x (5 min) / 2x (1 hora) | 1x (sem custo extra) |
| Desconto na Leitura em Cache | 50% de desconto na entrada | 90% de desconto na entrada | ~90% de desconto na entrada |
| Isolamento do Cache | Organização | Espaço de Trabalho | Projeto |
| Suporte a Streaming | Sim | Sim | Sim |
| Campo de Resposta de Acerto | cached_tokens | cache_read_input_tokens | cachedContentTokenCount |
| Controlo Explícito | Não | Sim (cache_control) | Sim (objetos de cache nomeados) |
| Última Atualização Principal | Out 2024 | Fev 2026 (cache auto) | 2026 (cache implícito) |
Conclusão principal: A OpenAI é a mais simples (zero configuração, 50% de desconto). A Anthropic oferece o desconto mais profundo (90%) com o maior controlo. A Gemini oferece TTL configurável e cache implícito em modelos 2.5+ com descontos comparáveis aos da Anthropic.
Como Funciona o Cache de Prompts LLM?
Não precisa de compreender os internals dos transformadores para usar o cache de prompts eficazmente. Mas precisa de entender um conceito: correspondência de prefixo.
O Cache KV em 60 Segundos
Quando um LLM processa o seu prompt, calcula estados de atenção (pares chave-valor) para cada token. Estas entradas do cache KV são a parte dispendiosa; são elas que consomem memória da GPU e tempo de computação. O cache de prompts armazena estes estados computados para que o próximo pedido com o mesmo prefixo salte completamente a recomputação.
A palavra crítica é prefixo. O cache corresponde desde o início do seu prompt para a frente. Se os primeiros 2.000 tokens corresponderem a uma entrada em cache, mas o token 2.001 for diferente, esses primeiros 2.000 tokens são servidos a partir do cache. Tudo após o ponto de divergência é computado de novo.
É por isso que a ordenação do prompt importa. Estruture os seus prompts assim:
- Definições de ferramentas (mais estáticas)
- Prompt de sistema
- Exemplos few-shot estáticos
- Contexto recuperado (semi-dinâmico)
- Histórico de conversação (cresce por turno)
- Consulta do utilizador (sempre diferente)
Conteúdo estático primeiro, conteúdo dinâmico no final. Quanto mais tokens corresponderem ao prefixo em cache, maiores serão as suas poupanças.
Cache de Prompts vs Cache Semântico vs Cache de Respostas
Estes três termos são frequentemente confundidos. O cache de prompts (o que este guia aborda) reutiliza estados KV computados ao nível da GPU para prefixos de tokens idênticos, sem perda de precisão, produzindo a mesma saída que sem cache. O cache semântico usa similaridade de embeddings para devolver respostas geradas anteriormente para consultas "suficientemente semelhantes", sendo mais rápido, mas podendo devolver respostas erradas. O cache de respostas armazena pares exatos de entrada-saída e devolve a resposta em cache textualmente, funcionando apenas para pedidos verdadeiramente idênticos.
O cache de prompts é a única "otimização gratuita"; reduz o custo e a latência sem qualquer compromisso na precisão. Para a matemática profunda dos transformadores por trás do cache KV, o explicador técnico da Hugging Face mediu uma aceleração de ~5,21x em GPUs T4.
Como é que a OpenAI Trata o Cache de Prompts?
O cache de prompts da OpenAI é totalmente automático. Desde outubro de 2024, cada chamada de API com 1.024 ou mais tokens de entrada beneficia automaticamente do cache. Não precisa de aderir, não adiciona cabeçalhos, não altera o seu código.
Como Funciona o Cache Automático da OpenAI
Quando envia um pedido com pelo menos 1.024 tokens, a OpenAI verifica se o prefixo corresponde a um pedido recente da sua organização. Os acertos no cache custam 50% do preço padrão dos tokens de entrada. Após o limiar inicial de 1.024 tokens, o cache corresponde em incrementos de 128 tokens.
O cache permanece ativo durante 5-10 minutos durante o uso normal e pode persistir até 24 horas com retenção estendida durante períodos de menor atividade. Tem âmbito por organização, por isso diferentes projetos dentro da mesma org beneficiam de caches partilhados.
Os modelos suportados incluem GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini e todos os modelos mais recentes.
Exemplo do SDK Python da OpenAI
from openai import OpenAI
client = OpenAI()
# This system prompt is ~2,000 tokens -- well above the 1,024 minimum
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
def chat(user_message: str) -> str:
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": user_message},
],
)
# Check if caching kicked in
usage = response.usage
cached = usage.prompt_tokens_details.cached_tokens
total_input = usage.prompt_tokens
print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")
return response.choices[0].message.content
# First call: cache miss (full price)
chat("Review this async function for race conditions...")
# Second call within 5-10 min: cache hit (50% off on cached tokens)
chat("Now optimize the same function for throughput...")A primeira chamada processa tudo ao preço total e preenche o cache. A segunda chamada reutiliza os tokens do prompt de sistema em cache a metade do preço. Verá algo como Cached: 1920/2048 tokens (94%) na saída.
Veredito: A OpenAI é a mais fácil para começar, zero configuração, o cache acontece simplesmente. O desconto de 50% é o mais baixo dos três fornecedores, mas não se pode bater a simplicidade.
Como é que a Anthropic/Claude Trata o Cache de Prompts?
A Anthropic oferece dois modos: cache automático (ativado por defeito desde fevereiro de 2026) e cache explícito com pontos de rutura cache_control. O número de destaque é difícil de ignorar: as leituras em cache custam apenas 10% do preço padrão de entrada, um desconto de 90%.
Cache Automático vs Explícito (Atualização 2026)
A partir de 5 de fevereiro de 2026, a Anthropic ativa o cache automático por defeito para todos os prompts elegíveis. Já não precisa do antigo cabeçalho beta. O sistema determina os pontos de rutura do cache ideais automaticamente.
O cache explícito ainda está disponível quando deseja um controlo fino. Coloca cache_control: {"type": "ephemeral"} em blocos de conteúdo específicos para marcar exatamente onde o limite do cache deve estar. Isto é útil quando o seu prompt tem uma estrutura específica e quer garantir que certas secções estão em cache.
Existem duas opções de TTL:
- Cache de 5 minutos (padrão): as escritas custam 1,25x o preço base de entrada, as leituras custam 0,1x. Paga-se a si próprio após 1 acerto no cache.
- Cache de 1 hora: as escritas custam 2x o preço base de entrada, as leituras custam 0,1x. Paga-se a si próprio após 2 acertos no cache. Disponível em modelos Claude 4.5+.
O isolamento do cache mudou do nível de organização para o nível de espaço de trabalho em 5 de fevereiro de 2026. Isto significa que diferentes espaços de trabalho dentro da mesma organização mantêm caches separados.
Ao trabalhar com o cache da Anthropic, ajuda estruturar o seu prompt para um cache ótimo, colocar conteúdo estático antes do dinâmico é ainda mais importante aqui, pois está a pagar um prémio de escrita.
Exemplo do SDK Python da Anthropic
import anthropic
client = anthropic.Anthropic()
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
def chat(user_message: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[
{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}, # Explicit breakpoint
}
],
messages=[
{"role": "user", "content": user_message},
],
)
# Read cache metrics from the response
usage = response.usage
created = usage.cache_creation_input_tokens
read = usage.cache_read_input_tokens
standard = usage.input_tokens
print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")
return response.content[0].text
# First call: cache_creation_input_tokens = ~1920 (write at 1.25x)
chat("Review this async function for race conditions...")
# Second call: cache_read_input_tokens = ~1920 (read at 0.1x -- 90% off!)
chat("Now optimize the same function for throughput...")Compreender a Precificação de Escrita vs Leitura no Cache
É aqui que a precificação da Anthropic se torna interessante. Usando o Claude Sonnet 4.5 ($3/MTok entrada base) como exemplo:
- Entrada padrão: $3,00 por milhão de tokens
- Escrita no cache (5 min): $3,75 por milhão de tokens (1,25x), paga mais na primeira vez
- Leitura no cache: $0,30 por milhão de tokens (0,1x) -- 90% mais barato em cada acerto subsequente
O cache de 5 minutos paga-se a si próprio após apenas 1 leitura. O cache de 1 hora ($6,00/MTok escrita) paga-se a si próprio após 2 leituras. Se estiver a fazer mais do que alguns pedidos por minuto com o mesmo prefixo, a matemática esmagadoramente joga a seu favor.
Veredito: A Anthropic oferece o desconto mais profundo (90%) e o maior controlo. Melhor para cargas de trabalho de alto volume e sensíveis ao custo.
Como é que a Google Gemini Trata o Cache de Prompts?
A Gemini adota uma abordagem diferente com dois mecanismos de cache distintos: cache de contexto explícito (objetos de cache nomeados que cria e referencia) e cache implícito (automático, zero-configuração, adicionado em 2026 para modelos Gemini 2.5+).
Cache de Contexto Explícito (Caches Nomeados)
Ao contrário da OpenAI e da Anthropic, onde o cache é transparente, o cache explícito da Gemini exige que crie primeiro um objeto de cache nomeado e depois o referencie em pedidos subsequentes. O limiar mínimo de tokens é de 1.024 tokens para modelos Gemini Flash e 4.096 tokens para modelos Pro. O TTL é configurável, o padrão é 1 hora, mas pode defini-lo conforme necessário.
Os tokens em cache no Gemini 2.5 Pro têm um preço de $0,125/MTok contra o preço padrão de entrada de $1,25/MTok, um desconto de 90%. Existe também um custo de armazenamento de $4,50 por milhão de tokens por hora para Pro e $1,00 para Flash.
Cache Implícito no Gemini 2.5 (2026)
Começando com o Gemini 2.5 Pro e Flash, a Google adicionou cache implícito, um cache automático que funciona como a abordagem da OpenAI. Sem necessidade de configuração. Coloque conteúdo grande e comum no início do seu prompt e envie pedidos com prefixos semelhantes em rápida sucessão. O sistema deteta automaticamente conteúdo elegível para cache e transmite as poupanças.
Exemplo do SDK Python da Gemini
from google import genai
from google.genai import types
client = genai.Client()
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
# Step 1: Create a named cache object
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
display_name="python-review-guidelines",
system_instruction=SYSTEM_PROMPT,
ttl="3600s", # 1 hour
),
)
print(f"Cache created: {cache.name}, expires: {cache.expire_time}")
# Step 2: Use the cache in requests
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Review this async function for race conditions...",
config=types.GenerateContentConfig(
cached_content=cache.name,
),
)
# Check cache usage in the response
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")A abordagem explícita tem uma grande vantagem: controla o TTL com precisão. Se sabe que o seu trabalho em lote dura 4 horas, defina um TTL de 4 horas e evite a expiração do cache a meio do processamento.
Veredito: O TTL configurável da Gemini e os modos duplos de cache (explícito + implícito) tornam-na versátil. O limiar mínimo é agora comparável ao de outros fornecedores, e o desconto de 90% nas leituras em cache iguala a Anthropic.
Comparação de Código Lado a Lado: Mesmo Caso de Uso, Todos os 3 Fornecedores
Aqui está o mesmo chatbot com um prompt de sistema em cache, implementado nos três SDKs. Compare a experiência do desenvolvedor diretamente.
# --- OpenAI: Zero config, just call the API ---
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": SYSTEM_PROMPT}, # Cached automatically
{"role": "user", "content": user_message},
],
)
cached = response.usage.prompt_tokens_details.cached_tokens# --- Anthropic: Explicit cache_control breakpoint ---
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}, # Mark cache boundary
}],
messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens# --- Gemini: Named cache object ---
from google import genai
from google.genai import types
client = genai.Client()
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
system_instruction=SYSTEM_PROMPT,
ttl="3600s",
),
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=user_message,
config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count| Aspeto | OpenAI | Anthropic | Gemini |
|---|---|---|---|
| Complexidade de Configuração | Nenhuma | Adicionar bloco cache_control | Criar objeto de cache primeiro |
| Controlo do Cache | Apenas automático | Automático ou explícito | Implícito ou explícito |
| Desconto na Leitura em Cache | 50% | 90% | ~90% |
| Tokens Mínimos | 1.024 | 1.024 | 1.024 (Flash) / 4.096 (Pro) |
| Veredito DX | Mais simples | Maior controlo | TTL mais flexível |
Se quiser poupanças sem esforço, opte pela OpenAI. Se quiser o desconto mais profundo e controlo fino, escolha a Anthropic. Se precisar de tempos de vida de cache configuráveis ou já estiver na Google Cloud, escolha a Gemini.
Calculadora de Custos de Produção: Poupanças Reais à Escala
Percentagens abstratas não impulsionam decisões. Valores em dólares sim. Aqui estão três cenários de produção com estimativas de custo reais usando Claude Sonnet 4.5 ($3/MTok entrada), GPT-4o ($2,50/MTok entrada) e Gemini 2.5 Pro ($1,25/MTok entrada).
Preços verificados em março de 2026. Consulte preços da Anthropic, preços da OpenAI e preços da Gemini para taxas atuais.
Pressupostos: Taxa de acerto do cache de 80% (realista para prompts bem estruturados), tokens de saída excluídos, pois o cache afeta apenas os custos de entrada.
| Cenário | Sem Cache (Mensal) | Com Cache OpenAI | Com Cache Anthropic | Com Cache Gemini |
|---|---|---|---|---|
| Chatbot Hobby: 100 ped/dia, 2K prompt sistema | OpenAI: $15 / Anthropic: $18 / Gemini: $7,50 | $12 (poupa $3) | $5,40 (poupa $12,60) | $2,25 (poupa $5,25) |
| API Crescimento: 10K ped/dia, 8K prefixo cache | OpenAI: $600 / Anthropic: $720 / Gemini: $300 | $360 (poupa $240) | $144 (poupa $576) | $60 (poupa $240) |
| Pipeline Enterprise: 100K ped/dia, 10K prefixo cache | OpenAI: $7.500 / Anthropic: $9.000 / Gemini: $3.750 | $4.500 (poupa $3.000) | $1.800 (poupa $7.200) | $750 (poupa $3.000) |
No nível de Crescimento, o cache da Anthropic poupa $576/mês apesar de ter um preço base mais alto que a OpenAI. À escala Enterprise, estamos a falar de $7.200/mês em poupanças com a Anthropic, ou $86.400 por ano. Isso equivale ao salário de um engenheiro sénior poupado apenas com uma mudança de configuração.
O padrão é claro: quanto maior o volume de pedidos e mais longo o prefixo estático, mais o cache poupa. O desconto de 90% da Anthropic domina à escala, mas o preço base mais baixo da Gemini torna-a competitiva quando se considera o custo total.
Anti-Padrões de Cache de Prompts: Quando NÃO Usar Cache
O cache parece simples até a sua taxa de acerto misteriosamente ficar em 0%. Aqui estão os erros que quebram silenciosamente o cache de prompts e como corrigi-los.
Erros que Quebram o Cache (Com Correções)
Carimbos de data/hora em prompts de sistema: O erro mais comum. Se o seu prompt de sistema inclui datetime.now(), a chave do cache muda a cada segundo.
# BAD: Cache misses every single request
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""
# GOOD: Move the timestamp to the user message
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""
user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"Conteúdo específico do utilizador antes do conteúdo estático: Se colocar session_id ou preferências do utilizador no início, cada utilizador obtém um prefixo único.
# BAD: Unique prefix per user = zero cache reuse
messages = [
{"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
{"role": "user", "content": query},
]
# GOOD: Static content first, user context at the end
messages = [
{"role": "system", "content": GUIDELINES}, # Same for all users -> cached
{"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]| Anti-Padrão | Por Que Quebra o Cache | Correção |
|---|---|---|
| Carimbos de data/hora no prompt de sistema | Prefixo muda a cada segundo | Mover carimbo para mensagem do utilizador |
| IDs de sessão/utilizador no prefixo | Prefixo único por utilizador | Mover contexto do utilizador após conteúdo estático |
| Exemplos few-shot rotativos | Exemplos diferentes = prefixo diferente | Usar um conjunto fixo de exemplos |
| Definições de ferramentas dinâmicas | Ferramentas a mudar = incompatibilidade de prefixo | Manter esquemas de ferramentas estáticos |
| Prompts curtos (abaixo do mínimo) | Cache simplesmente não dispara | Consolidar contexto para exceder 1.024 tokens |
| Personalização por pedido no prompt de sistema | Prompt de sistema muda a cada chamada | Usar prompt de sistema partilhado + mensagens de utilizador específicas |
Quando o Cache de Prompts Realmente Não Ajuda
Alguns cenários não beneficiarão do cache, mesmo que estruture os seus prompts perfeitamente:
- Prompts de uso único: Se cada pedido tiver um contexto completamente único e nenhum prefixo partilhado, não há nada para armazenar em cache.
- Prompts muito curtos: Abaixo de 1.024 tokens (OpenAI/Anthropic) ou 4.096 tokens (Gemini Pro), o cache não ativa.
- Pedidos infrequentes: Se os pedidos forem feitos com horas de intervalo, o cache expira antes de chegar um segundo pedido. A janela de 5-10 minutos da OpenAI e o TTL padrão de 5 minutos da Anthropic significam que precisa de tráfego consistente.
O Cache de Prompts Funciona Com Streaming?
Sim. O cache de prompts e o streaming são independentes; o cache opera sobre tokens de entrada, o streaming afeta a entrega da saída. Eles resolvem problemas diferentes em fases distintas do ciclo de vida do pedido.
O cache lida com a fase de prefill (processamento do seu prompt de entrada). O streaming lida com a fase de decode (geração e envio incremental de tokens de saída). Obtém ambos os benefícios simultaneamente: prefill mais rápido graças ao acerto no cache, mais entrega progressiva da saída via streaming.
Aqui está um exemplo de streaming com cache ativado:
import anthropic
client = anthropic.Anthropic()
with client.messages.stream(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}],
messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)
# After streaming completes, check cache metrics
usage = stream.get_final_message().usage
print(f"\nCache read: {usage.cache_read_input_tokens} tokens")A melhoria no TTFT proveniente do cache é na verdade mais notória com streaming. Sem cache, espera pelo prefill completo antes que o primeiro token seja transmitido. Com cache, o prefill é quase instantâneo, por isso os tokens começam a fluir quase imediatamente.
Como Monitorizar Taxas de Acerto do Cache em Produção
Configurar o cache é metade da batalha. Saber se está realmente a funcionar é a outra metade. Se a sua taxa de acerto do cache cair abaixo de 50%, algo mudou na estrutura do seu prompt e está a deixar dinheiro na mesa.
Métricas de Cache Específicas do Fornecedor
| Fornecedor | Campo de Leitura Cache | Campo de Escrita Cache | Campo Total Entrada |
|---|---|---|---|
| OpenAI | usage.prompt_tokens_details.cached_tokens | N/A (automático) | usage.prompt_tokens |
| Anthropic | usage.cache_read_input_tokens | usage.cache_creation_input_tokens | usage.input_tokens |
| Gemini | usageMetadata.cachedContentTokenCount | N/A (objeto cache explícito) | usageMetadata.promptTokenCount |
Um Registador Simples de Taxa de Acerto do Cache
Aqui está uma função utilitária que pode integrar em qualquer projeto para monitorizar taxas de acerto do cache via campos de resposta da API:
import logging
logger = logging.getLogger("cache_monitor")
def log_cache_metrics(provider: str, usage: dict) -> float:
"""Extract and log cache metrics from any provider's response. Returns hit rate."""
if provider == "openai":
cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
total = usage.prompt_tokens
elif provider == "anthropic":
cached = usage.cache_read_input_tokens
created = usage.cache_creation_input_tokens
total = cached + created + usage.input_tokens
elif provider == "gemini":
cached = getattr(usage, "cached_content_token_count", 0)
total = usage.prompt_token_count
else:
raise ValueError(f"Unknown provider: {provider}")
hit_rate = (cached / total * 100) if total > 0 else 0
logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")
if hit_rate < 50:
logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")
return hit_rateUm sistema de produção saudável deve sustentar taxas de acerto do cache de 70-90%. Se estiver abaixo de 50%, reveja a secção de anti-padrões. Também pode integrar isto com métricas de avaliação automatizadas para detetar regressões no seu pipeline de prompts.
Cache de Prompts em Casos de Uso do Mundo Real
Os exemplos de chatbot acima ilustram a mecânica, mas o cache de prompts brilha realmente em padrões arquiteturais específicos.
Pipelines RAG
Numa configuração RAG, o seu prompt de sistema e exemplos few-shot são estáticos em todas as consultas. Os documentos recuperados mudam sempre. Estruture o seu prompt para maximizar o prefixo em cache:
- Prompt de sistema (em cache)
- Exemplos few-shot (em cache)
- Documentos recuperados (dinâmico, vai no final)
- Consulta do utilizador (sempre única)
Com um prompt de sistema de 5.000 tokens e 3.000 tokens de exemplos few-shot, são 8.000 tokens em cache em cada pedido. A 1.000 pedidos/dia na Anthropic, pouparia cerca de $6,50/dia apenas no prefixo em cache. Quando recuperar e armazenar blocos de contexto em cache, certifique-se de que a saída da recuperação vem após o prefixo estático.
Chatbots Multi-Turno
Conversas multi-turno são um ponto ideal para o cache de prompts. Cada turno adiciona ao histórico da conversação, mas toda a conversação anterior já está em cache dos turnos anteriores. O benefício do cache compõe-se; no turno 10, pode ter 15.000 tokens de histórico em cache com apenas 200 tokens novos da última mensagem do utilizador.
Sistemas Agentes e Definições de Ferramentas MCP
Se está a construir agentes com uso de ferramentas, as suas definições de ferramentas são esquemas JSON estáticos repetidos em cada chamada de API. Um agente típico pode ter 20+ ferramentas totalizando 3.000-5.000 tokens de definições. Isso é material primo para cache.
Isto é especialmente relevante para arquiteturas baseadas em MCP, onde as definições de ferramentas do servidor são enviadas em cada chamada. Com o cache_control explícito da Anthropic, pode marcar a matriz tools para cache e garantir que esses tokens são reutilizados.
Qual Fornecedor Deve Escolher?
| Se Precisa de... | Melhor Escolha | Porquê |
|---|---|---|
| Zero-configuração, apenas poupanças | OpenAI | Cache automático, sem alterações de código necessárias |
| Máxima redução de custos (90%) | Anthropic | Preço de leitura em cache 0,1x, desconto mais profundo |
| Controlo fino do cache | Anthropic | Pontos de rutura explícitos + TTL configurável (5 min ou 1 hora) |
| Análise de documentos longos | Gemini | TTL configurável com caches nomeados explícitos |
| Simplicidade em chat multi-turno | OpenAI | Correspondência automática de prefixo no histórico de conversação crescente |
| Sistemas agentes com definições de ferramentas | Anthropic | Armazenar definições de ferramentas explicitamente com cache_control |
| Flexibilidade multi-fornecedor | LiteLLM | Sintaxe de cache unificada em todos os fornecedores |
Se já está a usar um fornecedor, comece por aí; o cache de prompts não exige mudança. O LiteLLM atua como uma camada de proxy que normaliza parâmetros de cache entre fornecedores, o que é útil se estiver a encaminhar pedidos para múltiplos modelos.
Perguntas Frequentes: Cache de Prompts LLM
O que é o cache de prompts em LLMs?
O cache de prompts armazena os estados de atenção computados (cache KV) de prefixos de prompt processados anteriormente. Quando um pedido subsequente começa com a mesma sequência de tokens, o fornecedor reutiliza esses estados armazenados em vez de os recomputar, reduzindo tanto o custo como a latência sem impacto na qualidade da saída.
Quanto poupa o cache de prompts nos custos da API?
As poupanças variam de 50% a 90% dependendo do fornecedor. A OpenAI oferece um desconto de 50% nos tokens de entrada em cache. A Anthropic oferece até 90% de desconto (leituras em cache a 0,1x do preço base). A Gemini oferece cerca de 90% de desconto nas leituras em cache. As poupanças reais dependem da sua taxa de acerto do cache, comprimento do prompt e frequência de pedidos.
O cache de prompts da OpenAI acontece automaticamente?
Sim, desde outubro de 2024. Qualquer chamada de API com 1.024 ou mais tokens de entrada beneficia automaticamente do cache. Sem adesão, sem cabeçalhos, sem alterações de código necessárias. O cache corresponde a prefixos de tokens desde o início do prompt.
Qual é a diferença entre cache de prompts e cache semântico?
O cache de prompts corresponde a prefixos de tokens exatos ao nível da GPU; não há perda de precisão e as saídas são idênticas aos pedidos sem cache. O cache semântico usa similaridade de embeddings para encontrar consultas anteriores "suficientemente próximas" e devolve respostas em cache; é mais rápido, mas pode devolver respostas incorretas ou desatualizadas. Eles resolvem problemas fundamentalmente diferentes.
Quanto tempo dura o cache de prompts?
Varia por fornecedor. OpenAI: 5-10 minutos (até 24 horas com retenção estendida). Anthropic: 5 minutos (padrão) ou 1 hora (disponível em modelos Claude 4.5+, custa 2x na escrita). Gemini: configurável, padrão de 1 hora para caches explícitos. O TTL do cache implícito é gerido automaticamente pela Google.
Qual é o comprimento mínimo de tokens para o cache de prompts?
OpenAI: 1.024 tokens. Anthropic: 1.024 tokens para a maioria dos modelos atuais. Gemini: 1.024 tokens para modelos Flash, 4.096 para modelos Pro. Prompts abaixo destes limiares não ativam o cache; esta é a armadilha mais comum do tipo "não está a funcionar".
O cache de prompts funciona com respostas em streaming?
Sim. O cache e o streaming operam em fases diferentes do pedido. O cache acelera a fase de prefill da entrada; o streaming entrega tokens de saída incrementalmente. Ambos funcionam simultaneamente e notará a melhoria no TTFT ainda mais com o streaming ativado.
Quando NÃO devo usar cache de prompts?
Evite depender do cache quando os seus prompts estiverem abaixo do limiar mínimo de tokens, quando incluir carimbos de data/hora ou IDs de sessão no prompt de sistema, quando rodar exemplos few-shot entre chamadas ou quando os pedidos forem demasiado infrequentes para atingir o cache antes de expirar (janela de 5-10 minutos para OpenAI/Anthropic).
Posso usar cache de prompts com LangChain ou LiteLLM?
Sim. O LangChain passa parâmetros de cache específicos do fornecedor através dos seus wrappers de API. O LiteLLM fornece uma sintaxe de cache unificada que normaliza o cache_control entre Anthropic, OpenAI, Gemini, Vertex AI e Bedrock, particularmente útil para configurações multi-fornecedor.
O que é um acerto no cache vs falha no cache?
Um acerto no cache significa que o fornecedor encontrou um prefixo correspondente na memória e reutilizou os estados KV armazenados; paga a taxa descontada de tokens em cache e obtém um TTFT mais rápido. Uma falha no cache significa que não foi encontrada correspondência, por isso o prompt completo é processado do zero ao preço padrão. Verifique os campos cached_tokens (OpenAI), cache_read_input_tokens (Anthropic) ou cachedContentTokenCount (Gemini) na resposta da API para ver qual ocorreu.
Veredito Final
| Categoria | Vencedor | Razão Chave |
|---|---|---|
| Configuração Mais Fácil | OpenAI | Automático, zero configuração |
| Desconto Mais Profundo | Anthropic | 90% de desconto em leituras em cache (0,1x base) |
| Maior Controlo | Anthropic | Pontos de rutura explícitos + TTL de 5 min ou 1 hora |
| Melhor para Documentos Longos | Gemini | TTL configurável com objetos de cache nomeados |
| Melhor para Chat Multi-Turno | OpenAI | Correspondência automática de prefixo no histórico de conversação |
| Melhor para Agentes/MCP | Anthropic | Armazenar definições de ferramentas explicitamente |
O cache de prompts é a otimização de menor esforço e maior retorno na pilha de APIs LLM. Não altera o seu modelo, não sacrifica qualidade e a implementação varia de "não fazer nada" (OpenAI) a "adicionar um campo" (Anthropic) a "criar um objeto de cache" (Gemini).
Comece com o cache automático do seu fornecedor atual. Meça a sua taxa de acerto do cache com o utilitário de registo acima. Se estiver abaixo de 70%, reestruture os seus prompts (estático primeiro, dinâmico no final) e elimine os anti-padrões. A maioria das equipas vê uma redução de custos de 50-80% dentro de um dia após implementar estas mudanças.