DeepSeek, Google e Meta: 10 técnicas para comprimir o cache KV de LLMs e reduzir a memória na inferência

O cache KV deixou de ser um detalhe auxiliar e virou um dos principais gargalos da inferência de LLMs em produção. Uma nova revisão reuniu 10 técnicas que ajudam a reduzir o uso de memória sem retreinar totalmente o modelo e, em alguns casos, aceleram de forma perceptível a geração.

Onde os LLMs travam

Quanto mais longo o contexto e quanto mais requisições simultâneas o modelo atende, mais rápido o cache KV incha. Ele é o armazenamento intermediário de chaves e valores do mecanismo de atenção. A revisão traz um exemplo revelador: num modelo de 30 bilhões de parâmetros, com batch size 128 e entrada de 1024 tokens, o cache KV pode ocupar até 180 GB de memória. Mesmo num modelo de 7B, os pesos ocupam cerca de 14 GB de memória da GPU e o cache, aproximadamente 72 GB, ou seja, o próprio mecanismo de geração passa a custar mais do que armazenar os parâmetros.

Por isso, otimizar o cache KV virou uma frente própria, e não um ajuste menor. Comprimindo o cache, é possível aumentar o batch size, atender mais usuários na mesma GPU e não esbarrar nos limites de memória com prompts longos. Uma vantagem importante é que boa parte dos métodos funciona na etapa de inferência: o modelo base não precisa ser treinado de novo, e o efeito aparece imediatamente na vazão e no custo de serving.

Como ele é comprimido

Os pesquisadores usam hoje várias estratégias, que diferem não só na qualidade, mas também no ponto do pipeline em que atuam. Alguns métodos descartam os tokens menos úteis, outros reduzem a precisão da representação do cache e outros mudam a própria arquitetura de atenção. Uma classe à parte redistribui a memória entre as camadas, porque as camadas iniciais precisam de um contexto mais rico, enquanto as profundas podem trabalhar com menos chaves e valores. Na prática, a questão já não é a porcentagem de economia, mas a possibilidade de rodar contexto longo no mesmo hardware.

• Descarte de tokens: H2O, StreamingLLM e SnapKV mantêm apenas parte dos estados. O H2O guarda os tokens "pesados", com maior contribuição para a atenção, o StreamingLLM mantém os primeiros tokens e uma janela recente, e o SnapKV escolhe as posições importantes pela atenção no fim do prompt.
• Distribuição do orçamento por camada: PyramidKV e PyramidInfer partem do princípio de que as camadas profundas não precisam de um contexto tão rico quanto as iniciais, então a memória é alocada de forma desigual.
• Quantização: KIVI, KVQuant e TurboQuant reduzem a precisão da representação do cache KV, mas tentam não perder qualidade de geração.
• Mudanças de arquitetura: MQA, GQA e MLA reduzem o tamanho do cache no próprio esquema de atenção, e não sobre um modelo já pronto.
• Compressão de baixo posto: Palu, LoRC e métodos próximos cortam a dimensão oculta dos tensores KV, e não o comprimento da sequência.

Os mais simples de operar são os métodos sem ajuste fino. O H2O encontra os tokens que concentram a maior parte da atenção e descarta as posições fracas. O StreamingLLM mantém os primeiros tokens como "âncoras de atenção" mais uma janela recente, por isso serve para conversas intermináveis, mas corre o risco de perder um trecho importante do meio. O SnapKV atua na etapa de prefill e seleciona as posições importantes separadamente por cabeça de atenção, por isso costuma superar esquemas mais grosseiros com o mesmo limite de cache.

A distribuição dos pesos de atenção costuma lembrar uma lei de

potência, por isso remover tokens de baixa contribuição nem sempre prejudica muito a qualidade.

Quem entrega o maior ganho

Na quantização, destacam-se KIVI, KVQuant e TurboQuant. O KIVI converte o cache KV para uma representação de 2 bits sem fine-tuning e, segundo a revisão, reduz em até 2,6 vezes o pico de memória do conjunto pesos mais cache, além de permitir lotes até quatro vezes maiores. O KVQuant vai além: usa calibração, precisão mista e tratamento separado de outliers para manter a qualidade mesmo em contextos extremamente longos.

O resultado mais agressivo do material é atribuído ao TurboQuant, do Google Research. O método primeiro uniformiza a distribuição dos valores com uma rotação ortogonal aleatória e depois corrige o erro de quantização para que a estimativa dos produtos escalares continue não enviesada. Em uma H100, ele mostra redução de memória de pelo menos 6 vezes e atenção até 8 vezes mais rápida com precisão de 3 bits. Para as equipes de infraestrutura, isso já não é uma otimização local, mas uma candidatura a novo padrão de serving.

Outra linha é mudar a própria arquitetura do modelo. O GQA virou de fato a norma dos LLMs open-weight modernos: no Llama 2, ele era usado só na versão de 70B, enquanto no Llama 3 se espalhou tanto para o 8B quanto para o 70B. O MLA da DeepSeek vai ainda mais longe: em vez de chaves e valores de tamanho completo para cada token, ele armazena uma representação latente comprimida. A revisão afirma que o DeepSeek-V2, graças ao MLA, reduziu o cache KV em 93,3% em relação ao modelo denso anterior de 67B.

O que isso significa

O mercado de LLMs esbarra cada vez menos só no tamanho dos pesos e cada vez mais no preço da memória em contexto longo. Para as equipes que constroem serviços de inferência, a conclusão é simples: o ganho agora não vem de uma técnica mágica, mas de uma escolha criteriosa entre descarte, quantização e arquitetura, de acordo com a carga específica, o SLA e o orçamento de GPU.