O HotKV reduziu o uso de tokens do Claude em 70% no nosso benchmark Banking77

Um cache semântico promete reduzir o gasto com LLMs ao responder perguntas repetidas e semelhantes a partir da memória, em vez de chamar o modelo. Medimos isso de ponta a ponta: as mesmas 3.000 requisições de suporte ao cliente, enviadas duas vezes a cada um de quatro modelos Claude, uma vez direto ao modelo e outra com o HotKV na frente, com o próprio cache de prompts da Anthropic ativado nas duas execuções. Aqui está exatamente o que executamos e o que encontramos, inclusive onde o resultado deixa a desejar.

Em resumo. O HotKV reduziu as chamadas ao modelo, os tokens de entrada mais saída e o custo da API em cerca de 70% em cada um dos quatro modelos. A maior parte disso vem de perguntas que se repetem exatamente. A camada semântica acrescenta cerca de 12 pontos por cima. No limiar de similaridade padrão de 0,81, as respostas em cache foram consideradas adequadas à pergunta exata de 5,8 a 10,7 pontos percentuais menos vezes do que as respostas novas. No único modelo em que variamos o limiar (Sonnet 5.5), um limiar de 0,88 ou maior não mostrou essa diferença.

Atualizado em 12 de outubro de 2026: este artigo agora relata a nossa execução maior com quatro modelos Claude atuais. Ele substitui uma execução anterior de 1.500 requisições com GPT e Claude Sonnet 5, que mediu cerca de 60% menos tokens e que deixamos de apresentar.

O que testamos

A carga de trabalho

Reproduzimos perguntas de suporte ao cliente da divisão de teste do Banking77 (PolyAI, CC BY 4.0), um conjunto de dados público de perguntas bancárias curtas rotuladas com 77 intenções. Ele foi apresentado em Casanueva et al., 2020. As 3.000 requisições foram sorteadas com uma seed fixa. A popularidade das intenções segue uma distribuição de Zipf com expoente 1,0, uma assimetria sintética em que poucas intenções aparecem muito mais do que as demais, e a pergunta dentro de uma intenção é escolhida de forma uniforme, com repetições. Todas as 77 intenções aparecem, e 1.264 das 3.000 requisições são perguntas distintas (contadas reexecutando o gerador de requisições com a mesma seed). O banco e a política de suporte dele são fictícios. Escrevemos uma política de cerca de 2.200 tokens, enviada como prompt de sistema em toda requisição, que pede de duas a quatro frases curtas.

Modelos e configurações

Executamos claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5 e claude-haiku-5-5. O Fable 5.1 e o Opus 5.5 rodaram no menor esforço, porque o thinking deles não pode ser desativado. O Sonnet 5.5 rodou com o thinking antecipado desativado, a configuração mais baixa dele, e o Haiku 5.5 com o thinking desativado. A saída máxima foi de 2.000 tokens para o Fable e o Opus e de 400 para o Sonnet e o Haiku, e toda resposta terminou normalmente, sem ser cortada. Oito requisições rodaram por vez nos dois modos, as chamadas não usaram streaming e cada condição rodou uma vez.

As duas execuções

• Baseline: toda requisição vai direto ao modelo, com o cache de prompts da Anthropic ativado (cache_control no prompt de sistema, tempo de vida padrão de cinco minutos). Esta é a baseline configurada usada aqui, não uma afirmação de que toda otimização do lado do provedor foi esgotada.
• Com o HotKV: o HotKV fica na frente do mesmo tráfego e do mesmo prompt de sistema, com o cache começando vazio.

O que contamos

Toda contagem de tokens vem do bloco usage da resposta da API: entrada sem cache, leituras e gravações de cache, e saída (thinking incluído). Os tokens de embedding são separados. Os custos usam os preços de tabela da Anthropic de 11 de outubro de 2026, incluem as chamadas de embedding das consultas semânticas e excluem a hospedagem e a operação do HotKV. Eles não são uma cotação dos preços atuais.

Como o cache funciona

Para cada pergunta, o HotKV tenta duas consultas antes de o modelo ser chamado:

1. Correspondência exata: um GET em uma chave SHA-256 construída a partir do modelo, da versão do prompt de sistema e da pergunta normalizada (em minúsculas, com espaços em branco colapsados). Ela captura uma pergunta feita com as mesmas palavras.
2. Correspondência semântica: uma chamada SCACHE.GET com um embedding da pergunta (text-embedding-3-small da OpenAI, similaridade de cosseno). Ela procura uma pergunta semelhante. Uma pontuação de similaridade sozinha não garante que a resposta em cache seja adequada.

Só uma falha nas duas chega ao modelo, e a resposta dele é gravada de volta com SET e SCACHE.SET. O limiar de similaridade para um acerto semântico foi fixado em 0,81 antes da execução. Nós o escolhemos em uma divisão de treino separada do Banking77 como o menor valor, em passos de 0,01, cujos acertos semânticos apontavam para a mesma intenção em pelo menos 98% das vezes (98,2% ali). Nesta execução, na divisão de teste intocada, 96,7% a 96,8% dos acertos semânticos corresponderam à intenção da pergunta feita: 30 ou 31 acertos de intenção errada por modelo, de 926 a 936.

Resultados

Chamadas, tokens e custo

Nos quatro modelos, as chamadas caíram de 12.000 para 3.588, os tokens em 70,1% e o custo em 69,6%. Cerca de 70% das requisições foram respondidas pelo cache em todos os modelos: aproximadamente 39% por correspondência exata e 31% por correspondência semântica.

Chamadas, tokens e dólares caem juntos porque o HotKV remove chamadas inteiras. Leia o número de tokens com cuidado: de 90% a 93% dos tokens contados são leituras de cache do mesmo prompt de política de 2.200 tokens, que a Anthropic cobra por uma pequena fração do preço normal de entrada. Os tokens de saída são apenas de 6% a 9% dos tokens, mas de 73% a 92% do custo da baseline.

Velocidade

O tempo mediano de resposta ao longo de toda a execução caiu de 2,7 segundos para 127 ms no Fable 5.1, de 2,9 segundos para 126 ms no Opus 5.5, de 1,8 segundo para 128 ms no Sonnet 5.5 e de 1,4 segundo para 125 ms no Haiku 5.5, o que é de 11 a 23 vezes mais rápido. Uma pergunta repetida voltou em uma mediana de cerca de 0,05 ms, medida por um cliente Python via loopback na mesma máquina do HotKV, então é um valor local, não de rede. Uma pergunta reformulada, atendida pelo cache semântico, levou cerca de 130 ms, quase tudo da chamada à API de embedding.

A mediana da execução inteira fica dentro dessa faixa de acertos semânticos porque os acertos exatos (cerca de 39% das requisições) são poucos demais para sustentar a mediana sozinhos, enquanto os acertos exatos e semânticos juntos (70%) passam da metade. A ponta lenta se move menos: 30% das requisições ainda chamam o modelo. O percentil 99 foi de cerca de 6,4 segundos com o HotKV contra 6,6 segundos sem ele no Fable 5.1, e cerca do mesmo no Haiku 5.5. Foi menor no Opus 5.5 (4,7 segundos contra cerca de 6) e no Sonnet 5.5 (2,7 segundos contra 3,3). As chamadas não usaram streaming, então esses são tempos até a resposta completa, não até o primeiro token.

Aquecimento

O cache começa vazio, então as primeiras requisições ainda chegam ao modelo. A parcela de requisições servidas pelo cache foi de cerca de 52% nas primeiras mil requisições e de cerca de 81% nas últimas mil.

De onde vem a economia

A maior parte da economia é simples repetição. Um cache de correspondência exata sozinho teria precisado de no máximo 1.264 chamadas ao modelo em 3.000, uma para cada pergunta distinta, o que dá cerca de 58% menos. A camada semântica levou isso a cerca de 70%, então contribui com aproximadamente 12 pontos nesta carga de trabalho. Também é a parte que carrega o risco para a qualidade das respostas, como a próxima seção mostra. Isso é derivado da sequência de requisições e dos logs, não de uma execução medida à parte.

Qualidade das respostas

Um acerto semântico significa a mesma intenção, não a mesma resposta correta. Para medir a correção, fizemos um modelo Claude diferente avaliar cada acerto semântico. O avaliador via a pergunta do cliente e duas respostas em ordem aleatória: a resposta em cache que o HotKV serviu e a resposta nova que o mesmo modelo deu a essa pergunta exata na execução baseline. Ele dizia se cada resposta respondia corretamente àquela pergunta exata. O Opus 5.5 avaliou as respostas do Fable 5.1, do Sonnet 5.5 e do Haiku 5.5, e o Fable 5.1 avaliou o Opus 5.5, de modo que nenhum modelo avaliou a própria saída.

No limiar padrão

Com 0,81, uma resposta em cache se adequou à pergunta exata de 5,8 a 10,7 pontos percentuais menos vezes do que uma resposta nova do mesmo modelo. Os acertos semânticos são cerca de 31% das requisições, então, considerando todas as respostas e contando os acertos exatos como neutros, isso dá aproximadamente 2 a 3 pontos (1,8 a 3,3). Os avaliadores diferem em rigor, então compare resposta em cache e resposta nova apenas dentro de um mesmo modelo.

Aumentando o limiar

Executamos de novo o Sonnet 5.5 com mais quatro limiares, cada um a partir de um cache vazio, com o mesmo avaliador. O custo da baseline foi de US$ 5,51.

A partir de 0,88, as respostas em cache não mostraram déficit em relação às novas, e ainda cortaram o custo em 64% com 0,88 e em 61% com 0,90. A evidência é frágil. Com 0,90, o intervalo de confiança de 95% para a diferença vai de cerca de 4 pontos pior a 7 pontos melhor, a linha de 0,95 tem apenas 50 acertos, e cada linha avalia um subconjunto diferente de acertos. É um modelo, um avaliador e uma execução por limiar, então não é prova de qualidade equivalente nem de um limiar seguro universal.

Perguntas quase idênticas

O risco real são perguntas que parecem quase idênticas, mas exigem respostas diferentes, como depositar versus sacar. Pedimos ao Opus 5.5 que escrevesse 119 pares, cada um com uma pergunta real da divisão de treino mais uma versão com um detalhe decisivo alterado, e contamos quantas perguntas alteradas superariam o limiar contra um cache que continha apenas a original. Esses pares são construídos para serem difíceis, não foram revisados por uma pessoa e mostram o pior caso, não a frequência com que isso acontece no tráfego real.

Aumentar o limiar reduz o risco, mas não o elimina. Mesmo com 0,90, 25% dos pares deliberadamente próximos corresponderiam, e menos paráfrases verdadeiras também correspondem.

O que isso significa em escala

Extrapolando o custo medido por requisição para 1 milhão de requisições por dia ao longo de um mês de 30 dias, e supondo o mesmo padrão de tráfego, obtemos estes valores mensais:

• claude-fable-5-1: cerca de US$ 303.100 sem o HotKV, US$ 91.800 com ele, aproximadamente US$ 211.300 economizados.
• claude-opus-5-5: cerca de US$ 146.000 sem o HotKV, US$ 45.000 com ele, aproximadamente US$ 101.000 economizados.
• claude-sonnet-5-5: cerca de US$ 55.100 sem o HotKV, US$ 16.600 com ele, aproximadamente US$ 38.500 economizados.
• claude-haiku-5-5: cerca de US$ 2.700 sem o HotKV, US$ 800 com ele, aproximadamente US$ 1.900 economizados.

Isto é aritmética sobre o custo medido por requisição, não outra execução medida. Exclui a hospedagem, e a capacidade necessária para esse volume não foi medida. Nas 3.000 requisições que executamos, a economia é de apenas US$ 0,19 para o Haiku 5.5 e de US$ 21,12 para o Fable 5.1. Os quatro modelos rodaram com respostas curtas, e o Fable 5.1 e o Opus 5.5 no menor esforço, então respostas mais longas ou com muito raciocínio fariam cada chamada evitada valer mais.

Limitações

Esta não é uma afirmação geral de que “o HotKV economiza 70% para você”. É o que medimos nesta carga de trabalho, e a carga de trabalho faz o trabalho pesado.

• A economia acompanha a repetição. Com todas as intenções igualmente prováveis, em vez de assimétricas por Zipf, o custo caiu 56% no Sonnet 5.5 e no Haiku 5.5. Com 3.000 perguntas todas diferentes, caiu 38%, inteiramente por correspondências semânticas entre perguntas diferentes da mesma intenção, das quais o Banking77 tem de sobra. Uma carga de trabalho sem perguntas repetidas ou semelhantes não economiza nada.
• Tráfego sintético. Os sorteios são independentes: sem picos, sessões nem contexto de vários turnos. Um conjunto de dados público de perguntas bancárias curtas, uma política fictícia escrita para este teste e um conjunto finito de cerca de 3.080 perguntas de teste.
• Um modelo avalia as respostas. Nenhum humano as revisou, não houve um segundo avaliador, e todo avaliador é um modelo Claude. As respostas novas falharam no teste de “adequada” do avaliador entre 1% e 21% das vezes, então é uma régua rigorosa.
• Mesma intenção não é mesma resposta. O limiar de 0,81 foi calibrado em rótulos de intenção, não na qualidade das respostas. A variação do limiar e o teste de perguntas quase idênticas cobrem um modelo e um modelo de embedding.
• Ambiente de teste pequeno. Uma execução por condição, um único servidor de quatro vCPUs com o cliente na mesma máquina, e um cache que não foi aquecido antes das execuções do HotKV.
• Os custos são custos de API. Eles excluem a hospedagem e a operação do HotKV. Valide a qualidade das respostas com as suas próprias perguntas e use cache exato ou respostas novas onde a reutilização semântica não for adequada.

Os números por modelo também estão na página de IA.

Experimente você mesmo

O cache de correspondência exata deste teste usa GET e SET simples, que todo plano do HotKV inclui. O cache semântico (SCACHE.*) vem com o plano Performance e superiores (preços). Comece no HotKV Cloud e aponte o seu tráfego atual para ele, ou fale com as vendas se quiser primeiro trabalhar os números para a sua própria carga de trabalho.