Se você já colocou um Large Language Model (LLM) em produção, provavelmente esbarrou em um problema silencioso: o consumo de memória da GPU não para de crescer conforme a conversa avança. Em muitos cenários, o vilão tem nome e sobrenome: chama-se KV Cache. Compreender o que ele é, por que cresce e como otimizá-lo deixou de ser um detalhe de engenharia avançada para se tornar uma habilidade essencial de quem trabalha com IA Generativa em escala.

Este artigo vai ajudar você a compreender o que é o KV Cache e como otimizá-lo para produção. Estamos considerando que você sabe o que é um LLM (sabe de verdade, tecnicamente) e se esse não for o caso, então visite o capítulo sobre LLM do Deep Learning Book Brasil.

Boa leitura.

O Que é o KV Cache?

Modelos baseados em arquitetura Transformer (como a maioria dos LLMs) geram texto de forma autorregressiva, ou seja, um token de cada vez. A cada novo token, o mecanismo de atenção precisa olhar para todos os tokens anteriores da sequência. O problema é que recalcular as representações de chave (Key) e valor (Value) de todos os tokens passados a cada passo seria absurdamente caro: o custo cresceria de forma quadrática com o comprimento da sequência. Isso é visto em detalhes e na prática em Deep Learning Para Aplicações de Inteligência Artificial.

O KV Cache (Key-Value Cache) resolve isso de maneira elegante. Em vez de recalcular, o modelo armazena as matrizes de chave e valor de cada token já processado. Nas iterações seguintes, ele simplesmente reutiliza esses valores em cache e calcula apenas a atenção para o token novo. É uma das otimizações mais fundamentais da inferência de LLMs e, sem ela, gerar mil tokens exigiria recalcular a atenção do zero mil vezes.

KVCache

O KV Cache troca recomputação por memória. Ele elimina cálculo redundante guardando o passado da sequência, mas esse passado precisa ficar guardado em algum lugar e esse lugar costuma ser a memória da GPU.

Por Que o KV Cache Vira Um Gargalo?

A grande limitação é que a pegada de memória do KV Cache cresce de forma linear com o comprimento do contexto e com o tamanho do batch. Conforme as janelas de contexto saltam de milhares para milhões de tokens, esse crescimento exaure rapidamente até GPUs de alta capacidade como H100 e H200. Em muitos casos, o KV Cache passa a consumir mais memória do que os próprios pesos do modelo.

Para dar uma ideia concreta da escala: um modelo de 70 bilhões de parâmetros com contexto de 8 mil tokens pode exigir cerca de 20 GB de cache por requisição, o que chega a aproximadamente 640 GB para um batch de 32 requisições simultâneas.

Há ainda um segundo efeito, menos óbvio mas igualmente crítico: a memória não é apenas um limite de capacidade, é também um limite de velocidade. A cada passo de decodificação, o cache precisa ser carregado da memória de alta largura de banda (HBM) para as unidades de cálculo. Esse movimento de dados é, na prática, o principal contribuinte para a latência de cada passo autorregressivo. Reduzir o tamanho do cache acelera a geração, não apenas economiza memória.

O Custo do Desperdício e Técnicas de Otimização

Sistemas de inferência tradicionais chegam a desperdiçar de 60% a 80% da memória alocada para o KV Cache por fragmentação e superalocação. Esse desperdício se traduz diretamente em menor throughput, custo mais alto e limites artificiais no tamanho do contexto.

Não existe uma técnica única de otimização que domine todos os cenários. A estratégia ideal depende do comprimento do contexto, das restrições de hardware e do tipo de carga de trabalho. As abordagens modernas costumam se organizar em algumas grandes famílias, que muitas vezes são combinadas entre si.

1. Modificações Arquiteturais (GQA, MQA e MLA)

Em vez de comprimir um cache que já existe, essas técnicas reduzem o cache por design. Na Multi-Query Attention (MQA), todas as cabeças de consulta compartilham um único par de chave e valor, o que produz a redução mais agressiva, porém com maior risco de perda de qualidade. A Grouped-Query Attention (GQA) agrupa as cabeças de consulta para compartilhar um conjunto menor de pares chave-valor, oferecendo um meio-termo equilibrado entre eficiência e qualidade.

A GQA tornou-se o padrão de fato nos LLMs abertos modernos. No Llama 2, apenas a variante de 70B usava GQA; o Llama 3 estendeu a técnica para os tamanhos de 8B e 70B, e o Mistral adotou GQA desde seu lançamento inicial de 7B. Para quem escolhe ou implanta novas famílias de modelos hoje, GQA já é uma expectativa básica e não uma otimização opcional. Uma evolução mais recente, a Multi-Head Latent Attention (MLA), substitui o agrupamento explícito por projeções de baixo posto, alcançando uso de memória ainda menor.

2. Quantização do Cache

A quantização reduz a memória diminuindo a precisão com que chaves e valores são armazenados, sem alterar as dimensões dos tensores. A dificuldade está em fazer isso preservando a fidelidade, já que valores extremos (outliers) podem se concentrar em determinados canais.

Métodos de referência tratam chaves e valores de forma diferente justamente por causa dessas distribuições. O KIVI, por exemplo, combina quantização por canal para as chaves e por token para os valores, atingindo desempenho praticamente sem perdas em 2 bits. O KVQuant usa níveis de quantização não uniformes aprendidos a partir de dados de calibração. Técnicas mais recentes como o TurboQuant chegam a comprimir o cache para 3 bits com perda de acurácia próxima de zero, alcançando cerca de 6x de redução de memória.

3. Gerenciamento Inteligente de Memória (PagedAttention)

Introduzida pelo framework vLLM, a PagedAttention revolucionou o gerenciamento de memória ao tratar o KV Cache como a memória virtual de um sistema operacional. Em vez de pré-alocar memória contígua para o comprimento máximo da sequência, ela divide o cache em blocos de tamanho fixo (tipicamente 16 tokens por bloco) alocados sob demanda e que podem ser armazenados de forma não contígua.

O resultado é expressivo: o desperdício de memória cai de 60% a 80% para menos de 4%, viabilizando ganhos de throughput de 2 a 4 vezes. Hoje a técnica é suportada por vLLM, TGI, TensorRT-LLM e outros frameworks de inferência de grande porte.

4. Eviction e Pruning de Tokens

Nem todo token contribui igualmente para a geração. Estratégias de eviction descartam do cache os tokens considerados menos importantes, liberando espaço. Métodos como H2O, Scissorhands e FastGen analisam o comportamento dos módulos de atenção e aplicam compressão de forma seletiva. O FastGen, por exemplo, reduz a demanda de memória em até 50% mantendo o desempenho por meio de compressão adaptativa. O cuidado aqui é não descartar contexto que voltará a ser relevante mais adiante.

5. Offloading e Memória Hierárquica

Quando o cache não cabe na GPU, a saída é movê-lo para níveis de memória mais baratos. Sistemas de offloading deslocam o cache inativo ou compartilhado para a DRAM da CPU ou para o disco local, liberando a GPU para novas requisições. Extensões como o LMCache vão além e permitem reutilizar caches de conteúdos repetidos e não apenas de prefixos, entre diferentes instâncias, o que é especialmente útil em cargas de trabalho como QA multi-turno, RAG e raciocínio sobre documentos longos.

Comparativo das Abordagens

A tabela a seguir resume as cinco famílias e seus principais compromissos. Na prática, pipelines de produção combinam várias delas, por exemplo GQA mais quantização mais PagedAttention, somando os ganhos de cada eixo.

Como Escolher na Prática

A lição das pesquisas recentes é que nenhuma técnica vence sozinha em todos os contextos. Em vez de procurar uma bala de prata, a recomendação é pensar em pipelines adaptativos e em múltiplos estágios, ajustados ao seu cenário específico.

• Contexto muito longo e requisição única: priorize quantização e técnicas de redução de footprint para caber na GPU.
• Serving de alto throughput em datacenter: PagedAttention e reuso de cache entre requisições tendem a dar o maior retorno.
• Conversas multi-turno e RAG: offloading e reuso de cache para conteúdo repetido reduzem recomputação.
• Dispositivos de borda e ambientes com pouca memória: quantização agressiva combinada com arquiteturas como GQA ou MLA.
• Tarefas críticas em acurácia: seja conservador com eviction e prefira quantização de alta fidelidade.

Um Exemplo Mental de Monitoramento

Em produção, otimizar o que não se mede é um tiro no escuro. Frameworks modernos de serving expõem métricas que permitem acompanhar a saúde do cache e disparar alertas. Um conjunto típico de indicadores observados via endpoint de métricas seria algo como:

# Métricas expostas em /metrics
kv_cache_usage_percent # % de uso do cache
kv_cache_total_blocks # blocos totais alocados
kv_cache_used_blocks # blocos em uso
prefix_cache_hit_rate # taxa de acerto de prefixo

# Regra de alerta sugerida:
# uso de cache > 90% -> escalar ou aplicar compressao

Acompanhar a utilização do cache, a taxa de acerto de prefixo e o número de blocos em uso ajuda a decidir, em tempo real, quando escalar a infraestrutura ou quando ativar uma estratégia de compressão mais agressiva.

Conclusão

O gerenciamento eficiente do KV Cache deixou de ser um detalhe de baixo nível para se tornar um desafio prioritário na implantação de LLMs em escala. Ele está no centro do trade-off entre custo, latência e qualidade que define a viabilidade econômica da IA Generativa em produção.

A boa notícia é que o ecossistema amadureceu rápido. Arquiteturas como GQA já vêm de fábrica nos modelos abertos, a quantização atinge compressões impressionantes com perda mínima e o gerenciamento por blocos da PagedAttention praticamente eliminou o desperdício de memória. Dominar essas técnicas, entender seus compromissos e combiná-las de acordo com a carga de trabalho é o que separa um protótipo de um sistema de IA pronto para o mundo real.

Equipe DSA

Referências:

Formação Engenheiro de IA 4.0

Formação AI Data Engineer 4.0