A Tensormesh lança uma plataforma para reduzir os custos de inferência de LLMs com a reutilização do cache KV

Sempre que um assistente de IA recebe um documento extenso, precisa processar esse material antes de começar a responder. Quando os mesmos documentos, instruções ou histórico de conversa aparecem novamente, boa parte desse processamento pode se repetir. Em escala empresarial, essa repetição pode consumir recursos caros de GPU sem acrescentar trabalho útil.

A Tensormesh busca resolver esse problema com a Tensormesh Platform, anunciada em 14 de outubro de 2026. A empresa, cuja equipe criou o projeto de código aberto LMCache, está levando uma camada de gerenciamento empresarial ao cache de valores-chave, ou cache KV, para organizações que executam grandes modelos de linguagem em sua própria infraestrutura.

A plataforma gerencia estados de inferência reutilizáveis entre a memória da GPU, a memória da CPU e o armazenamento. O benefício pretendido é simples: reduzir o processamento de prompts que uma frota de GPUs precisa repetir, oferecendo aos operadores controles sobre como esse estado em cache é mantido, compartilhado e monitorado.

Por que o cache KV é importante

A inferência de LLMs tem duas etapas importantes. Durante o pré-preenchimento, o modelo processa o prompt de entrada. Durante a decodificação, ele gera a resposta token por token. O cache KV armazena estados intermediários relacionados à atenção, que permitem ao modelo consultar os tokens já processados sem recalcular tudo desde o início.

Reutilizar esse estado entre solicitações pode reduzir o trabalho de pré-preenchimento quando o contexto de entrada se repete. Por exemplo, um assistente de suporte pode consultar o mesmo manual de produto para responder a centenas de perguntas diferentes. Um agente pode incluir repetidamente as mesmas instruções ou ferramentas junto a uma tarefa que muda.

Isso é diferente de armazenar em cache uma resposta pronta. O sistema pode reutilizar a computação associada ao contexto compartilhado e, ao mesmo tempo, gerar uma nova resposta para uma nova pergunta.

A documentação do cache automático de prefixos do vLLM descreve esse benefício em consultas repetidas a documentos e conversas com várias interações. Ela também estabelece uma limitação importante: o cache de prefixos acelera o processamento de prompts, não a geração de novos tokens de saída. Cargas de trabalho dominadas por respostas longas ou entradas em grande parte únicas podem obter menos benefícios.

Para compradores empresariais, a pergunta relevante é quanto da carga de trabalho real contém contexto reutilizável — e se esse contexto pode ser recuperado com mais rapidez e a um custo menor do que o necessário para recalculá-lo.

Transformando um cache em infraestrutura gerenciada

O anúncio da Tensormesh identifica cinco prioridades operacionais: segurança, observabilidade, resiliência, gerenciamento de políticas e multilocação. Elas abrangem as tarefas práticas de proteger dados em cache, acompanhar o desempenho, se recuperar de falhas, controlar a retenção e a remoção de entradas e manter equipes ou clientes separados em uma infraestrutura compartilhada.

A empresa também descreve APIs de controle para fixar, localizar, mover, compactar e limpar entradas do cache. Assim, o gerenciamento do ciclo de vida do cache se torna uma preocupação operacional explícita, em vez de ficar inteiramente a cargo de cada processo de inferência.

O projeto LMCache, que está na base da plataforma, separa o gerenciamento do cache do mecanismo de atendimento e permite descarregar e recuperar dados entre várias camadas de armazenamento. Sua documentação descreve a reutilização entre solicitações, sessões e instâncias do mecanismo, com back-ends de armazenamento e transporte conectáveis.

A plataforma empresarial se baseia nessa estrutura. De acordo com seu guia de instalação, um operador do Kubernetes gerencia os componentes do mecanismo de cache, com servidores de cache nos nós de GPU e um coordenador responsável pela coordenação em nível de frota. O Helm oferece o método de implantação, enquanto uma interface web e ferramentas de linha de comando dão suporte à operação.

Essa arquitetura é importante porque a memória da GPU é um recurso limitado. Manter ali todos os prompts potencialmente reutilizáveis concorreria com outras necessidades de inferência. Transferir estados menos úteis de imediato para a memória do host ou para o armazenamento pode aumentar a quantidade retida, embora a recuperação introduza custos próprios de largura de banda e latência.

Além de prefixos de prompt idênticos

O cache de prefixos funciona bem quando dois prompts começam com os mesmos tokens. A geração aumentada por recuperação, ou RAG, pode ser mais difícil: um aplicativo recupera documentos relevantes, mas eles podem aparecer em ordens diferentes ou após textos diferentes.

Considere duas solicitações hipotéticas que usam os mesmos documentos. Uma inclui o documento A seguido do B; a outra inclui o B seguido do A. Ambas contêm material reutilizável, mas o trecho inicial compartilhado pode ser curto.

A Tensormesh usa o CacheBlend para ampliar a reutilização para além do início de um prompt. A documentação do LMCache explica que ele recalcula seletivamente uma fração dos tokens e reutiliza blocos em cache. Esse recálculo é importante porque o contexto ao redor de um bloco pode afetar o estado interno do modelo.

O artigo de pesquisa do CacheBlend, apresentado no EuroSys 2025, relata um tempo até o primeiro token de 2,2 a 3,3 vezes mais rápido e uma vazão de 2,8 a 5 vezes maior em comparação com o recálculo completo do KV nas cargas de trabalho avaliadas. Os autores avaliaram três modelos de código aberto e quatro conjuntos de dados de referência.

Esses são resultados de pesquisa obtidos em condições específicas, não uma economia garantida para toda implantação da Tensormesh. Ainda assim, demonstram por que a reutilização além de um prefixo compartilhado é tecnicamente interessante: ela pode recuperar computação útil que a correspondência convencional de prefixos não detectaria.

Reutilização entre nós e a importância do suporte específico para cada versão

O anúncio de lançamento descreve transferências de KV ponto a ponto, que permitem a um nó buscar o estado armazenado em cache em outro, e os materiais de produto da empresa descrevem a desagregação entre pré-preenchimento e decodificação. A desagregação separa o processamento do prompt da geração da resposta, permitindo que as duas etapas sejam executadas em workers diferentes.

Essas são formas complementares de organizar a inferência. Compartilhar estados compatíveis pode evitar que sejam recalculados em outro nó; separar as etapas pode permitir que as equipes de infraestrutura aloquem recursos de maneira diferente, de acordo com as demandas de processamento.

No entanto, os materiais públicos não estão totalmente alinhados quanto ao status de lançamento. A apresentação do lançamento descreve o compartilhamento entre nós e a desagregação, enquanto a matriz de compatibilidade por versão, datada de 17 de setembro, inclui a transferência ponto a ponto e a desagregação no roteiro. A documentação de recursos também inclui páginas de prévia.

A mesma matriz distingue os recursos verificados nos testes da Tensormesh daqueles que têm suporte upstream, mas exigem testes adicionais antes de serem usados em produção. Ela lista vLLM e NVIDIA Dynamo como mecanismos de inferência verificados, e SGLang e TensorRT-LLM como previstos no roteiro.

Isso significa que a ampla declaração de compatibilidade do lançamento indica uma direção de projeto, mas não comprova que todas as combinações de modelos e infraestrutura tenham sido validadas. As equipes devem confirmar a versão exata, o mecanismo de inferência, o modelo e o modo de cache que pretendem implantar.

A apresentação do lançamento descreve especificamente o vLLM no Kubernetes com GPUs NVIDIA ou AMD Instinct compatíveis por meio do ROCm, além de armazenamento baseado em sistema de arquivos. Ela apresenta o cache que não se limita a prefixos para modelos densos e o suporte ao SGLang como recursos previstos. Também esclarece que o cache funciona junto com modelos auto-hospedados; não é um complemento que possa ser conectado a uma API arbitrária de modelos hospedados.

Onde a economia pode fazer sentido

Os candidatos mais promissores são aplicações que processam repetidamente um contexto compartilhado substancial: assistentes de conhecimento interno, serviços de análise de documentos e agentes que retomam um conjunto estável de instruções ou materiais de referência.

Uma avaliação útil compararia o comportamento com o cache frio e com o cache aquecido, usando tráfego representativo. Os operadores devem medir o tempo até o primeiro token, a taxa de transferência, o tempo de recuperação do cache, a utilização da GPU e os custos de memória, armazenamento e rede para manter o estado.

A taxa de acertos do cache, por si só, não basta. Uma taxa alta só é útil se o trabalho recuperado gerar um benefício líquido após os custos de transferência e gerenciamento. Da mesma forma, obter o primeiro token mais rapidamente não significa necessariamente que a resposta inteira será concluída em um tempo proporcionalmente menor.

A qualidade das respostas merece uma avaliação à parte, especialmente quando trechos em cache são combinados em contextos diferentes. O recálculo seletivo do CacheBlend foi projetado para lidar com esse problema, mas os testes em produção devem abranger os documentos, formatos de prompt e configurações de modelo da própria organização.

A retenção e o isolamento entre locatários também se tornam mais importantes quando o cache deixa de se limitar a um único processo. Entre as questões operacionais relevantes estão quem pode reutilizar uma entrada, por quanto tempo ela permanece disponível e como alterações nas políticas ou solicitações de exclusão afetam o estado armazenado. Os recursos de gerenciamento anunciados pela Tensormesh têm o objetivo de permitir o controle dessas decisões.

Uma aposta prática em repetir menos trabalho

Segundo o anúncio da empresa, a Tensormesh Platform está disponível desde o lançamento. Sua importância está em tratar o estado da inferência como um recurso que pode ser gerenciado em toda uma frota, mantendo a computação reutilizável além do tempo de vida imediato de uma solicitação.

Para empresas que executam sua própria infraestrutura de LLMs, isso oferece uma alavanca concreta de eficiência: reutilizar mais do trabalho de processamento de prompts já realizado. O resultado dependerá da repetição das cargas de trabalho, da compatibilidade do cache e do custo de movimentação dos dados — mas essas são questões de engenharia mensuráveis, que as equipes podem testar com o próprio tráfego.