Redis LangCache promete cortar custos de LLM em até 90% com cache semântico

Aplicações de LLM em produção raramente recebem uma pergunta que ninguém nunca fez. Assistentes de suporte e pipelines de RAG atendem as mesmas intenções milhares de vezes por dia, cada uma escrita de um jeito diferente — e a maioria das stacks trata cada variação como uma requisição nova, totalmente cobrada.

O Redis LangCache ataca exatamente esse desperdício. É um serviço gerenciado de cache semântico que fica entre a aplicação e o modelo, compara o prompt recebido com perguntas já respondidas pelo significado (e não pelo texto exato) e devolve a resposta armazenada quando há uma correspondência próxima o suficiente. A Redis reporta economia de até 90% no custo de API e respostas em cache até 15x mais rápidas.

O problema: paráfrases ainda viram chamadas completas ao LLM

Considere três pedidos a um assistente de suporte:

• “Posso pedir reembolso depois de assinar o plano mensal?”
• “A assinatura mensal é reembolsável?”
• “Posso cancelar o plano e receber meu dinheiro de volta?”

As palavras mudam, mas a pergunta e a resposta são idênticas. Sem cache semântico, cada versão dispara uma geração completa: tokens de entrada processados, tokens de saída decodificados, usuário esperando. O cache de prefixo ajuda só parcialmente — ele reutiliza os estados KV do início do prompt, mas a requisição ainda chega ao LLM e a resposta completa ainda é decodificada. Um hit de prefixo é uma geração mais barata, não uma geração evitada.

Como funciona

O LangCache move o cache para fora do modelo e guarda a própria resposta gerada. A integração é um ciclo de duas chamadas via REST API (com SDKs para Python e JavaScript):

1. Antes de chamar o modelo, a aplicação envia o prompt para POST /v1/caches/{cacheId}/entries/search. O serviço gera um embedding e roda uma busca vetorial sobre as entradas armazenadas.
2. Se houver correspondência acima do limiar de similaridade configurado, a resposta em cache é devolvida e nenhuma chamada ao LLM acontece. Em caso de miss, a aplicação chama o LLM normalmente e depois armazena o prompt e a resposta via POST /v1/caches/{cacheId}/entries.

O comportamento é controlado por limiares de similaridade, TTLs, políticas de eviction e controles adaptativos de precisão e recall. Construído sobre o banco vetorial da Redis, funciona com qualquer provedor de LLM e qualquer linguagem.

O que um hit realmente economiza

Num teste demonstrativo, a inferência direta de uma pergunta parafraseada levou 2,232 segundos e consumiu 514 tokens de entrada + 250 de saída. O LangCache devolveu a resposta anterior em 0,37 segundo, com zero tokens de LLM — cerca de 6x mais rápido naquele cenário.

A documentação é cuidadosa ao explicar de onde vem a economia: em uma resposta em cache você não paga pelos tokens de saída, enquanto o custo de tokens de entrada é geralmente compensado pelos custos de embedding e armazenamento. A fórmula sugerida é simples: economia mensal = (custo mensal de tokens de saída) × (taxa de hit). Com US$ 200 de gasto mensal, 60% em tokens de saída e 50% de taxa de hit, são US$ 60 economizados por mês.

Onde exige cuidado

Decidir quais perguntas podem compartilhar resposta com segurança é uma preocupação de produção, não um detalhe de configuração. Um limiar baixo demais devolve a política de reembolso a um cliente que perguntou sobre upgrades; alto demais e quase toda paráfrase volta ao modelo, e o cache deixa de se pagar. O LangCache cobre isso com escopos de acesso, filtragem customizada, TTL, eviction e monitoramento de correspondências incorretas — e a Redis afirma que não acessa nem usa os dados dos clientes para treinar modelos.

O serviço está disponível hoje como preview público no Redis Cloud, e a empresa avisa que recursos e comportamento podem mudar durante o período. Vale lembrar que o resultado real depende de quanta repetição “segura” existe no seu tráfego.