Cache é uma correspondência de prefixo, e esse único fato decide tudo. O primeiro byte que muda invalida todos os que vêm depois, então uma linha volátil — um carimbo de tempo, um id de requisição, a pergunta do usuário — colocada à frente de vinte e cinco mil tokens estáveis significa que nenhum deles é cacheado. A correção tem sempre o mesmo formato: estável primeiro, volátil por último. O que não é óbvio é o custo de errar, e por isso aqui se coloca um número nisso. Informe os blocos da sua requisição com a frequência com que cada um muda, e eles são ordenados, o prefixo é medido e a diferença é precificada ao longo de quantas requisições você fizer.
Recursos
Blocos ordenados para maximizar o prefixo
Nomeia quais blocos estáveis ficam encalhados atrás dos voláteis
Mede o prefixo cacheável e a parte paga toda vez
Avisa quando o prefixo fica abaixo do mínimo e não será cacheado em silêncio
Precifica a diferença ao longo de uma série de requisições
Aponta blocos de mudança ocasional, que invalidam tudo depois deles
Taxas de leitura de cache por modelo, com a data em que foram conferidas
Tamanhos de bloco editáveis, para bater com sua requisição
Como usar Planejador de cache
Liste os blocos da sua requisição com os tamanhos
Marque com que frequência cada um muda
Leia a ordem recomendada e o que ela economiza
Mova seu ponto de cache para o fim do prefixo estável
Exemplo
Entrada
User question (300) sent first
Saída
29,500 stable tokens cannot be cached
Um bloco volátil na frente invalida tudo que está atrás dele.
Erros comuns e solução de problemas
Minha taxa de acerto é zero. — Algo volátil está dentro do prefixo. Um carimbo de tempo, um id de requisição ou uma lista de ferramentas sem ordem estável já bastam sozinhos.
O prefixo fica abaixo do mínimo. — Prefixos curtos não são cacheados de jeito nenhum, e nada avisa. Ou você aumenta o prefixo, ou aceita que o cache não vai valer.
Às vezes cacheia, às vezes não. — Costuma ser um bloco de mudança ocasional posicionado cedo. Toda mudança invalida tudo depois, então uma mudança ocasional é uma requisição ocasional a preço cheio.
Reordenar mudaria o sentido. — Então é um trade-off real. O que precisa ficar onde está é uma restrição; a ferramenta mostra o custo para a decisão ser informada e não acidental.
Perguntas frequentes
Como o cache de prompt funciona de verdade?
A requisição é comparada por prefixo com o que foi cacheado. Tudo até a primeira diferença é servido do cache por uma fração do preço; tudo depois é cobrado cheio. Por isso a ordem é o jogo inteiro.
O que invalida um cache em silêncio?
Qualquer coisa que mude bytes cedo: um carimbo de tempo no prompt de sistema, um id de requisição, uma lista de ferramentas montada de um mapa sem ordem, um campo por usuário. Nenhum gera erro: a taxa de acerto simplesmente cai.
Por que existe um prefixo mínimo?
Abaixo de um tamanho que depende do modelo, o cache não é aplicado. Ele falha em silêncio, então um prompt de sistema pequeno que você achava cacheado pode nunca ter sido.
Onde vai o ponto de cache?
No fim do último bloco estável. Tudo antes é reutilizado; tudo depois é novo toda vez, que é exatamente o corte que a ordenação daqui produz.
Cachear sempre compensa?
Quando há um prefixo grande realmente reutilizado, sim: a taxa de leitura é uma fração da de entrada. Não compensa torcer uma requisição que não tem prefixo estável nenhum, que é o que o erro daqui informa.