O imposto do KV cache: por que servidores de inferência ficam sem memória antes de computação

O modelo cabe na memória — os pedidos, não

A VRAM sempre foi uma preocupação de treinamento: você dimensionava o cluster para os pesos, os estados do otimizador e os gradientes. Servir o modelo parecia barato em comparação — carrega os pesos, roda a inferência, pronto. Até que o modelo vai para produção, recebe tráfego real e cai sob uma carga que não faz sentido.

Foi exatamente o que aconteceu com o engenheiro Mostafa Ibrahim ao dimensionar uma implantação de inferência para um modelo de porte médio em um pool compartilhado de GPUs. Os pesos cabiam com folga, e o servidor rodava bem em teste. Sob tráfego concorrente, retornava erros de CUDA out-of-memory enquanto a utilização de computação da GPU ficava muito abaixo da saturação. O culpado: o cache de chave-valor (KV cache), que cresce a cada pedido simultâneo.

A equação do orçamento de VRAM

Três coisas dividem a memória da GPU durante a inferência: os pesos do modelo, as ativações transitórias e o KV cache. Os pesos são fixos; o KV cache é a variável que se move. O tamanho por token vem de quatro fatores multiplicados: dois bytes para a chave e o valor de cada token, o número de camadas, o número de cabeças de chave/valor vezes a dimensão da cabeça, e a precisão usada para armazenar o cache.

Colocando o Llama 3.1 70B nessa conta em BF16 — 80 camadas, 8 cabeças de chave/valor e dimensão de cabeça 128 — cada token custa cerca de 320 KB de cache. Multiplique pelo tráfego: a 128 pedidos concorrentes segurando 4 mil tokens de contexto cada, só o KV cache precisa de 160 GB — mais do que os 140 GB dos próprios pesos. O cache cresceu além do modelo.

A lição central: seu orçamento de KV é função dos pedidos concorrentes, não do tamanho do prompt isoladamente. E o estouro de memória chega no pico de tráfego, não na média.

O desperdício de 60% a 80% que ninguém usa

Pilhas de serving antigas reservavam a memória de KV em um bloco contíguo por pedido, dimensionado para a sequência máxima possível. Um pedido que gerava 200 tokens contra uma reserva de 4.096 deixava o resto parado e inutilizável. Uma análise da vLLM mediu o estrago: 60% a 80% da memória de KV alocada desperdiçada por fragmentação e super-reserva.

A solução — PagedAttention — pega emprestada a ideia de memória virtual dos sistemas operacionais: o KV cache é armazenado em blocos de tamanho fixo que não precisam ser contíguos. O resultado é direto: desperdício caindo para menos de 4% e throughput até 24 vezes maior sobre um pipeline ingênuo, porque a memória recuperada permite agrupar mais pedidos por GPU.

As três estratégias, na ordem certa

Ibrahim mapeia três otimizações e a ordem em que devem ser aplicadas:

• PagedAttention (comece aqui): obrigatório em qualquer implantação de produção. Elimina o desperdício de alocação sem esforço proporcional.
• Prefix caching (adicione quando houver sobreposição): muitos workloads enviam os mesmos tokens repetidamente — um system prompt fixo, um preâmbulo de few-shot. O RadixAttention da SGLang organiza prefixos em cache numa árvore radix e reporta até 5 vezes mais throughput com reuso pesado. Mas só compensa quando os pedidos realmente compartilham prefixos: monitore a taxa de acerto antes de ativar.
• Quantização de KV (só quando ainda estiver limitado por memória): armazenar o cache em menos bits. FP8 dobra a capacidade; o trabalho KIVI quantiza para 2 bits, ganhando cerca de 4 vezes em tamanho de lote. O custo é qualidade — e ela não é uniforme: a vLLM documentou um score de “needle-in-a-haystack” despencando de 91% em BF16 para 13% com FP8 ingênuo. Valide no seu próprio workload de contexto longo antes de confiar em benchmarks agregados.

O que isso significa para quem serve modelos

O conselho prático de Ibrahim é direto: ligue PagedAttention e prefix caching no primeiro dia; recorra à quantização só se continuar limitado por capacidade — e só depois de validar a qualidade. E dimensione o deployment pelo pico de concorrência, não pela carga média, porque o OOM chega no spike. “O modelo caber na memória nunca foi a pergunta que importava”, resume.