Galahad-kv salva o KV-cache em NVMe e carrega um bloco 2,8–4,3 vezes mais rápido que recalcular

Pesquisadores testaram uma camada de memória para LLMs que não recalcula o prompt do zero: ela busca no disco o estado KV já pronto. O pacote galahad-kv foi executado sobre 50 milhões de tokens de texto público real, via vLLM, em uma única NVIDIA H100, com os modelos Gemma 4 12B e Gemma 4 31B. Todos os 100 de 100 blocos verificados voltaram do armazenamento sem recálculo. A carga foi 2,8–4,3 vezes mais rápida, e a GPU gastou 8,8–12,3 vezes menos energia.

Como funciona a camada de memória

O modelo só usa o texto que cabe na janela de contexto. Além disso, a cada envio de prompt ele recalcula o estado interno KV (key-value), mesmo que o texto possa não ter mudado. Em contextos longos, esse recálculo consome tempo e energia.

O galahad-kv divide o fluxo em blocos de cerca de 16 000 tokens. O estado KV de cada bloco é gravado em um disco NVMe local criptografado e, quando solicitado, volta byte a byte idêntico. Numa conta aproximada, 50 milhões de tokens dão cerca de 3 100 blocos. O armazenamento, nesse cenário, chega à casa dos terabytes.

Os autores já deixam claro: trata-se de reaproveitar um estado salvo. A janela de atenção continua a mesma, só um bloco é carregado por vez, e a qualidade da resposta depende do próprio modelo.

O que as medições mostraram

O teste rodou em uma única H100 sob vLLM, com blocos verificados em profundidades de até 50 milhões de tokens. As principais métricas:

• 100 de 100 blocos verificados foram carregados do armazenamento criptografado sem recálculo, nos dois modelos, em profundidades de 0 a 50 milhões de tokens;
• carregar um bloco foi 2,8–4,3 vezes mais rápido que recalcular;
• o consumo de energia da GPU foi 8,8–12,3 vezes menor;
• a memória da GPU ficou estável ao longo de todo o fluxo de 50 milhões de tokens;
• o Gemma 4 12B respondeu corretamente a 82 de 100 perguntas, e o Gemma 4 31B, a 98 de 100;
• nenhum dos modelos inventou uma resposta.

O último ponto importa tanto quanto a velocidade. Em perguntas sobre fatos plantados milhões de tokens antes da consulta, o modelo costuma falhar respondendo com confiança algo fora de propósito. Aqui, os erros se resumiram à ausência da resposta correta, e não a alucinações. A diferença entre 82 e 98 por cento mostra que a camada de memória entrega o estado, mas quem precisa lê-lo corretamente é o próprio modelo. O maior se sai visivelmente melhor.

Onde estão os limites e para quem isso serve

A abordagem tem três limitações. A gravação da memória tem custo único: cada bloco precisa ser calculado e salvo uma vez. O armazenamento exige terabytes de NVMe local. E apenas um bloco é carregado por vez, então perguntas que exigem cruzar fatos de vários pontos do corpus ao mesmo tempo não são cobertas por esse teste. É um preprint da primeira versão, e ainda não há reproduções independentes à vista. Por outro lado, os autores descrevem um protocolo pensado para proteger contra as formas típicas de driblar benchmarks de contexto longo, e oferecem uma reprodução em uma única GPU, com software público e licença gratuita para o pacote.

A conclusão prática para engenheiros é esta: a abordagem faz sentido onde o mesmo grande volume de texto é lido repetidamente, como repositórios de código, documentação, arquivos e o longo histórico de um agente. Nesses casos, o recálculo do prefixo consome a maior parte do tempo de GPU. Antes de adotar, vale calcular três coisas: quantos terabytes de NVMe seu corpus vai exigir, se a gravação única se paga na sua frequência de acesso e se o seu modelo é bom o bastante para ler com precisão o bloco carregado.

Para testar, bastam uma H100 e a stack pública do artigo. Rodar com os seus próprios dados mostra rápido se os números de 2,8–4,3 vezes em velocidade e 8,8–12,3 vezes em energia se repetem.