Memória de 50M tokens: mais rápida sem recomputar KV

O muro do recompute

Memória de longo prazo para IA sempre bateu no mesmo muro. O modelo só usa o que cabe na janela de contexto, e a cada prompt ele recalcula todo o estado interno de key-value, o famoso KV, como se nunca tivesse visto aquele texto antes. Quem opera RAG ou agente com histórico longo conhece a dor: latência que explode, custo de GPU que repete sem necessidade e cache que não é cache de verdade. O teste do pacote galahad-kv tenta quebrar exatamente esse ciclo, com uma ideia simples e agressiva. Em vez de recomputar, salve o KV em disco e carregue de volta quando precisar.

O fato é direto e precisa ser lido sem hype. Os pesquisadores rodaram 50 milhões de tokens de texto público real, servidos via vLLM em uma única NVIDIA H100, com Gemma 4 12B e Gemma 4 31B. O sistema salvou o estado KV de cada bloco de cerca de 16 mil tokens em NVMe local criptografado e depois carregou de volta, byte a byte, sem recomputar. Em 100 de 100 blocos testados, do início até 50M de profundidade, o load funcionou nos dois modelos. Carregar foi de 2,8x a 4,3x mais rápido que recomputar e usou de 8,8x a 12,3x menos energia de GPU, com memória de GPU estável durante todo o stream.

O fato sem enfeite

Na parte de qualidade, plantaram fatos milhões de tokens antes da pergunta. O modelo de 12B acertou 82 em 100, o de 31B acertou 98 em 100. E um detalhe importante para quem opera: nenhum dos dois inventou resposta quando não encontrou. Isso é raro e relevante, porque em RAG tradicional o modelo costuma alucinar com confiança quando o retriever falha. Aqui o comportamento foi mais contido, o que sugere que o estado restaurado preserva bem a âncora factual. Não é memória infinita mágica, é reuso de estado armazenado, com um bloco carregado por vez. A pergunta continua dependendo da capacidade do modelo de usar aquele bloco.

Como funciona na visão de quem opera

Pensa na arquitetura como uma camada entre o vLLM e o disco. Na escrita, depois do prefill de um bloco de 16k tokens, você despeja os tensores de KV para o NVMe. Na leitura, em vez de fazer o prefill de novo, você faz um load sequencial e injeta direto na atenção. Por isso o ganho de latência faz sentido. Recompute é compute bound e queima SM da H100. Load de NVMe é IO bound, e com leitura sequencial bem feita mais desserialização rápida, ele ganha fácil em blocos grandes. O número de 2,8x a 4,3x bate com o que eu esperaria para 16k tokens em um modelo de 12B a 31B, onde o prefill já começa a pesar.

O ganho de energia de 8,8x a 12,3x também é plausível. GPU parada esperando IO gasta pouco perto de GPU fazendo matmul em todos os layers. Só que tem o outro lado da conta que o paper deixa claro. Escrever é custo único, mas o store ocupa terabytes de NVMe local. Faz as contas por alto: dezenas de bilhões de parâmetros geram KV enorme por token, multiplica por 50 milhões de tokens e por dois modelos, e você entende por que precisa de disco local rápido e criptografado. Não é S3, não é rede. É NVMe na máquina, com criptografia para não vazar estado que pode conter dados sensíveis. Em termos de API, imagina algo como salvar com um ID de bloco e carregar por offset, quase um malloc de contexto em disco.

Latência, custo e onde aperta

Para latência p99, o que muda é o perfil do tail. Recompute tem variância com batch, thermal throttle e contenção. Load de disco tem variância com fila de IO e fragmentação. Em single GPU com vLLM, o load tende a ser mais previsível, desde que você faça prefetch do próximo bloco enquanto atende o atual. O custo total tem três partes: custo único de escrita, custo de armazenamento parado e custo recorrente de leitura. Se você repete o mesmo corpus muitas vezes, como base de código monolítica, prontuário longitudinal ou log de operação, a conta fecha rápido. Se você escreve uma vez e lê uma vez, não fecha. É o mesmo raciocínio de cache: hit rate manda.

O que isso muda na prática

Quem ganha primeiro é quem vive de contexto repetido e caro. Time que mantém agente sobre repositório gigante, jurídico com processo de milhões de tokens, suporte com histórico longo do cliente. Para esse pessoal, RAG virou muleta porque recomputar tudo era inviável. Com KV persistido, dá para manter continuidade real sem resumir tudo a cada turno e sem perder detalhe no chunking. Quem perde é a pilha que vendeu otimização de recompute como diferencial, além de muito pipeline de chunk, embedding e rerank que existe só para contornar janela curta. Não que RAG morra, mas parte do motivo de existir enfraquece.

A ação prática que eu faria já nesta semana é medir seu recompute desperdiçado. Pegue seu workload mais repetido, logue quantos tokens de prefixo você reenvia por dia e multiplique pelo preço do prefill na sua GPU ou API. Depois compare com o custo de 4 a 8 TB de NVMe local mais a engenharia para versionar blocos. Se seu hit rate de prefixo passa de 30 por cento, vale um piloto com blocos de 8k a 16k, um índice simples de bloco por hash e métrica de tempo de load contra prefill. E teste o recall com fatos plantados, não só com benchmark bonito. O paper diz que fez protocolo anti gaming para long context, e isso importa porque muito benchmark de 1M de tokens é agulha no palheiro fácil demais.

A tensão que fica

Aqui entra a dúvida de operador que não dá para ignorar. Isso escala ou só move o gargalo do compute para o storage? 50M de tokens com memória de GPU estável é ótimo, mas terabytes por corpus não escala se você tem mil clientes com corpus diferentes. Vira um problema de lifecycle: quando invalidar um bloco, como fazer merge quando o documento muda no meio, como criptografar e rotacionar chave sem recorromper tudo. E tem o limite conceitual: é reuso de estado, não janela de atenção mais larga. Você carrega um bloco por vez, então raciocinar cruzando blocos distantes ainda depende de orquestração e do modelo. O salto de 82 para 98 entre 12B e 31B mostra isso. O store entrega o passado intacto, mas quem entende o passado continua sendo o modelo.

Também fico pensando no custo operacional escondido. NVMe local é rápido, mas não é elástico. Se sua inferência roda em autoscaling ou serverless, amarrar estado a disco local quebra a portabilidade. Você vai precisar de replicação, warmup de cache em nova máquina, ou aceitar o primeiro load frio mais lento. E a promessa de byte-exact é ótima para reprodutibilidade, mas cobra precisão em versão de modelo, layout de KV e kernel de atenção. Mudou o checkpoint, o store inteiro pode virar lixo. Isso é gerenciável, só não é de graça.

Conclusão

No fim, o galahad-kv prova o ponto mais importante: memória de longo prazo real pode ser mais rápida e mais barata que recomputar, se você aceitar pagar em disco e engenharia. Não resolve contexto infinito, resolve o desperdício de recalcular o que já foi visto. A pergunta que fica para quem constrói é simples. Qual parte do seu contexto vale a pena nunca mais recomputar?