Ganhos:
- Explique a lógica de correspondência de prefixo do cache de prompt
- Aumenta o impacto no cache colocando o contexto fixo primeiro e o contexto variável depois
- Pode calcular a economia de gravação/leitura do cache e o ponto de equilíbrio
Um produto LLM parece barato em protótipo; Quando você sobe na balança, a conta surpreende. Na maioria das cargas de trabalho, a maior parte da fatura vem do mesmo contexto fixo que é enviado repetidamente com cada solicitação: um longo prompt do sistema, um livro de regras, documentação de referência. O cache imediato elimina exatamente esse desperdício. Nesta unidade, você aprenderá como funciona o cache, como organizar o prompt para acertar e como calcular o ponto de equilíbrio da economia do cache. Quando instalado corretamente, só ele pode reduzir sua conta pela metade ou até menos.
Como funciona o cache? A única regra imutável
O cache de prompt é uma correspondência de prefixo. O provedor armazena temporariamente os tokens que processou desde o início do seu prompt. Se o prompt começar com o mesmo prefixo na próxima solicitação, essa parte comum não será recalculada; É muito mais barato ler do que armazenar em cache.
Segue-se uma regra imutável: se um único byte for alterado em qualquer lugar do prefixo, todo o cache se tornará inválido a partir desse ponto. Ou seja, o conteúdo fixo deve estar no início e o conteúdo variável no final. Se você colocar uma linha no início do prompt do sistema que muda a cada solicitação, como “Data de hoje: 18/07/2026”, tudo que estiver atrás dela não conseguirá entrar no cache.
A ordem de processamento geralmente é: ferramentas → prompt do sistema → mensagens. Você coloca o ponto de cache (ponto de interrupção) no final da seção fixa.
Economia de Cache
Cache tem três níveis de preços:
- Escrita em cache: Armazenando pela primeira vez. ~1,25x o preço de entrada normal (para armazenamento de 5 minutos).
- Leitura de cache: leitura em solicitações subsequentes. ~0,1 vezes o preço normal dos insumos – ou seja, um décimo.
- Entrada normal: A parte que não entra no cache e é processada sempre com custo total.
Ponto de equilíbrio: a primeira solicitação paga prêmio de gravação (1,25×). A partir da segunda solicitação, entra em jogo a leitura (0,1×). Aproximadamente, você estará lado a lado em dois pedidos; Depois disso, é poupança líquida. Quanto maior o contexto fixo e quanto mais solicitações ele for reutilizado, maior será o ganho.
Cenário
O cache funciona?
Grande prompt de sistema fixo, milhares de solicitações
Sim – ganhos mais altos
Muitas perguntas nos mesmos documentos de referência
Sim
Texto curto completamente diferente para cada solicitação
Não – o bônus de gravação é desperdiçado
Solicitação única
Não - nenhuma leitura
Data/ID mudando a cada solicitação no prompt do sistema
Não – o prefixo está quebrado, o acerto é zero
Passo a passo: como configurar um prompt de hit?
- Separe constante e variável. Qual conteúdo nunca muda (prompt do sistema, livro de regras, documentação)? O que muda com cada solicitação (pergunta do usuário, data, ID)?
- Coloque a constante no início. Durante o processamento, a parte que vem primeiro (ferramentas, sistema) deve estar estável.
- Coloque a variável no final. Pergunta atual do usuário, por último.
- Coloque a placa no final da fronteira. Coloque o ponto de cache no último bloco da parte fixa.
- Verifique o acerto. Verifique se cache_read_input_tokens é maior que zero no campo de uso da resposta. Se for zero, há um disruptor oculto no prefixo.
{ "sistema": [ { "tipo": "texto", "texto": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efêmero" } } ], "mensagens": [ { "role": "usuário", "conteúdo": "{{user_current_question}}" } ]}
Dica: não adivinhe os acessos ao cache, meça-os. Se uso.cache_read_input_tokens ainda for zero em solicitações consecutivas, um disjuntor silencioso (datetime.now() no prompt do sistema, JSON não ordenado, lista de ferramentas que mudam a cada solicitação) estará em execução. Compare o prompt bruto das duas solicitações byte por byte e encontre a diferença.
Disruptores Silenciosos
Padrões típicos que corrompem o cache sem saber:
# BREAKER: incorporação de informações no prompt do sistema que muda a cada solicitação "Data de hoje: {{agora}}. Você é um assistente..." ← o prefixo muda a cada solicitação, o acerto é zero# TRUE: move a variável para o sistema de mensagens: "Você é um assistente..." ← constante entra nas mensagens de cache: [{role: usuário, content: "Hoje é {{agora}}. Pergunta: ..."}] ← variável no final
Outros disjuntores: JSON classificado de forma diferente em cada solicitação (mantenha as chaves em ordem fixa), lista de ferramentas variando de acordo com o usuário (as ferramentas são processadas primeiro; nada entra no cache se forem alteradas), alteração do modelo no meio da conversa (os caches são específicos do modelo).
Prompt fraco / Prompt forte (estrutura compatível com cache)
# Sistema FRACO (construção de bloqueio de cache): "Data: 18.07.2026 14:32. Usuário: Ahmet (id 8842). Você é um bot de suporte. Regras: ...(2.000 tokens)..."
# Sistema FORTE (estrutura amigável ao cache): "Você é um bot de suporte. Regras: ...(2.000 tokens, nunca muda)..." [sinal de cache]mensagens: [ { role: user, content: "Data: 18.07.2026 14:32. ID do usuário: 8842. Pergunta: como faço para iniciar meu reembolso?" }]
Na versão fraca, o bloco de regras de 2.000 tokens é processado com custo total em cada solicitação. Na versão forte, o mesmo bloco é escrito uma vez e lido em todas as solicitações subsequentes por um décimo do preço.
Três Mini Estojos
Caso 1 — Armazenando o livro de regras em cache. Uma automação contábil estava adicionando o livro de regras de 12.000 tokens a cada fatura; 5.000 solicitações por dia. A entrada sem cache custa aproximadamente US$ 180 por dia. Eles mantiveram o livro de regras constante e o armazenaram em cache: as primeiras solicitações pagaram um prêmio de gravação, as leituras subsequentes 0,1×. O custo dos insumos caiu cerca de 90%, para cerca de US$ 18 por dia.
Caso 2 — Custo da linha de data oculta. Uma equipe configurou um cache, mas não obteve resultados; cache_read_input_tokens sempre foi zero. Motivo: havia datetime.now() na primeira linha do prompt do sistema, o prefixo mudava a cada solicitação. Quando mudamos a data para a mensagem do usuário, a taxa de acerto aumentou repentinamente de 0% para 94%.
Caso 3 — Cache mal colocado. Um aplicativo de pesquisa enviava consultas curtas completamente diferentes a cada solicitação; Eles adicionaram ansiosamente um sinal de cache. Sem prefixo comum, cada solicitação pagava apenas um prêmio de gravação, sem leituras – aumentando o custo. Eles removeram a placa. Lição: o cache só compensa se houver um prefixo grande e constante que seja reutilizado.
Erros comuns
- Misturando constante e variável: Quando o conteúdo da variável está no prefixo, o hit é redefinido.
- Incorporação de data/ID no prompt do sistema: O disruptor silencioso mais comum.
- Não medir o acerto: Se cache_read_input_tokens não estiver marcado, o desperdício não será percebido.
- Adicionando cache quando não há prefixo público: você paga apenas o prêmio de gravação, o custo aumenta.
- Alteração da lista ou modelo do veículo: O prefixo está quebrado desde o início; tudo é reescrito.
- Esquecendo o tamanho mínimo do cache: caches muito curtos (abaixo de aproximadamente 1–4k tokens, dependendo do modelo) não entrarão no cache silenciosamente.
Mais profundo: projetando cache por tipo de carga de trabalho
A recompensa real do armazenamento em cache varia dependendo da natureza da sua carga de trabalho; então conheça seu tráfego primeiro. Três padrões típicos e instalação correta:
Prompt comum do sistema, perguntas diferentes. Padrão empresarial mais comum: um grande prompt do sistema (função, regras, talvez documento de referência) com centenas de perguntas diferentes do usuário. Aqui a parte fixa (sistema) é armazenada inicialmente em cache; cada nova pergunta paga o preço total apenas por sua pequena parcela. O ganho é muito alto porque a grande porção é recitada repetidamente por um décimo do preço.
Monólogo multi-redondo. À medida que a conversa avança, cada nova rodada se baseia em toda a história anterior. Se você colocar o sinalizador de cache no final da última rodada, cada solicitação reutilizará o prefixo da conversa anterior; os acessos se acumulam à medida que a conversa cresce. Isso reduz drasticamente o custo de longas sessões de assistente.
O prefixo compartilhado é o último bit a ser alterado. Múltiplas solicitações compartilham um grande conjunto de anteriores fixas (conjunto de amostras, instruções), mas são separadas por uma única pergunta no final. Você coloca o ponteiro do cache no final da parte compartilhada; Caso contrário, cada solicitação gravaria seu próprio cache separado e nada seria lido.
Uma ressalva: o cache depende do modelo e de um determinado tamanho mínimo. Prefixos muito pequenos (menos de alguns milhares de tokens, dependendo do modelo) não entrarão silenciosamente no cache, mesmo se você os sinalizar — cache_creation_input_tokens permanece zero. Além disso, alterar o modelo no meio da conversa invalida todo o cache; Se uma tarefa diferente exigir um modelo barato, mantenha o fluxo principal em um modelo e coloque o trabalho secundário em uma chamada separada.
Em resumo
O cache de prompt é uma correspondência de prefixo: o conteúdo fixo deve estar no início, o conteúdo variável deve estar no final. Para um contexto grande e reutilizado, o custo de leitura é um décimo do preço total, atingindo aproximadamente o ponto de equilíbrio em duas solicitações. O erro mais comum é corromper o prefixo incorporando dados variáveis no prompt do sistema; Você verifica o acerto medindo-o no campo de uso.
Tarefa de aplicativo
Escolha uma carga de trabalho. (1) Divida o conteúdo em duas colunas: “nunca muda” e “muda a cada solicitação”. (2) Redesenhe a estrutura do prompt, colocando a parte constante no início e a parte variável no final. (3) Estime o tamanho do token da parte fixa e compare o custo mensal com/sem cache. (4) Observe de qual campo (cache_read_input_tokens) você verificará o hit.
lista de verificação
- [] Posso explicar que o cache é a correspondência de prefixo e a única regra imutável.
- [] Posso aumentar a precisão colocando o conteúdo fixo no início e a variável no final.
- [] Eu sei escrever/ler economia e o ponto de equilíbrio de duas solicitações.
- [] Consigo reconhecer disruptores silenciosos (data, JSON não ordenado, alteração da lista de veículos).
- [] Posso verificar o hit com uso.cache_read_input_tokens.