KV cache em agentes de 1 milhão de tokens: a matemática do custo de inferência

Por que agentes de contexto longo ficam caros: a leitura que não dá para pular

Agentes de IA que carregam históricos de repositórios, logs de ferramentas e conversas inteiras chegam rotineiramente a um milhão de tokens de contexto. O que muita gente não percebe é que o gargalo desse tipo de sistema não é a “inteligência” do modelo — é a largura de banda de memória. E a matemática por trás disso, conhecida como KV cache, explica por que cada token gerado custa uma leitura completa de todo o histórico.

O que é o KV cache e por que ele cresce

Durante a geração, o transformer produz um token por vez. Para decidir o próximo, ele compara a query do token atual com a key de cada token anterior e combina os value vectors correspondentes. Essas keys e values de todos os tokens já vistos ficam armazenadas no KV cache, para não precisarem ser recalculadas a cada passo.

O tamanho por token segue uma fórmula simples:

bytes por token = 2 × camadas × KV heads × head dim × bytes por elemento

O “2” conta K e V. Aplicada a um modelo de classe 70B com atenção GQA (como o Llama 3.1 70B — 80 camadas, 8 KV heads, dimensão 128), o resultado é:

2 × 80 × 8 × 128 × 2 = 327.680 bytes ≈ 320 KB por token

O detalhe importante é o que o GQA fez aí: um modelo 70B roda 64 query heads, mas só 8 key-value heads, compartilhando KV entre grupos de queries. Sem esse compartilhamento, seriam cerca de 2,6 MB por token. O GQA já cortou essa conta em 8 vezes no design — e não existe outro fator “de graça” igual por aí.

A leitura que custa caro

A aritmética é trivial; as leituras, não. A cada token, todas as keys e values de todos os tokens anteriores viajam da memória HBM para as unidades de computação — mesmo aquelas que o softmax vai ponderar em uma parte em um milhão. A atenção não consegue pular uma leitura porque o peso que justificaria o pulo é calculado a partir da própria leitura. É por isso que a decodificação fica lenta com contexto longo mesmo quando a massa de atenção está concentrada numa fatia pequena do histórico.

Um dispositivo classe H100 entrega cerca de 300 FLOPs de computação fp16 para cada byte de largura de banda que move. A operação roda centenas de vezes abaixo do ponto de equilíbrio da máquina: os núcleos tensores ficam ociosos enquanto a memória flui. Isso se chama decodificação limitada por memória.

O “livro-caixa” de um milhão de tokens

Estendendo a conta: um milhão de tokens de contexto — conjunto de trabalho rotineiro para um agente de codificação — ocupa na ordem de 320 GB de KV cache. Somados os ~140 GB dos pesos em fp16, uma H100 de 80 GB não comporta nem um nem outro. São necessárias de 6 a 8 GPUs só para caber, antes de pensar em requisições concorrentes.

Na linha de banda: uma H100 move ~3,35 TB/s da HBM. Transmitir 320 GB leva ~95 ms por token decodificado — cerca de 10 tokens por segundo no melhor caso teórico, e uma resposta de 1.000 tokens carrega ~95 segundos de streaming puro de KV no caminho crítico. Fragmentar o cache em 8 GPUs derruba o piso para ~12 ms por token, mas os bytes não desaparecem: a frota continua movendo 320 GB por token, e o custo por token só cresce conforme a conversa avança.

O que dá para fazer hoje

Enquanto a pesquisa de atenção esparsa treinada (DuoAttention, NSA da DeepSeek, MoBA, SeerAttention) amadurece, os sistemas em produção aproximam o “pulo” descartando ou comprimindo cache:

Entre as evicções, o padrão mais seguro costuma ser começar pela quantização para fp8: reduz os bytes por token pela metade (de 320 KB para 160 KB no exemplo 70B), corta pela metade o custo de banda e a quantidade de GPUs necessária, com pouco impacto de qualidade — e é uma mudança de uma linha em engines como vLLM e TensorRT-LLM. O int4 (um quarto) fica para casos desesperados por capacidade, depois de medir recall no seu próprio tráfego.

Evicções como H2O e SnapKV são uma aposta de que o passado prevê a consulta — e conversas de agentes vivem de detalhes raros citados uma única vez. Se o seu tráfego responde perguntas sobre dados antigos (logs de auditoria, IDs, números exatos), o dinheiro seguro está em quantização + janelas conservadoras, reservando a compressão para regiões obsoletas do histórico.

A direção: um modelo que pula as próprias leituras

O jogo final é arquitetural: um modelo que decide, ele mesmo, o que não precisa ler. Enquanto os pesos não chegam treinados assim, a recomendação prática é medir — reexecutar uma amostra das conversas de produção offline e registrar, por camada, quanto da massa de atenção fica no topo de 1% dos blocos KV. Massa concentrada significa espaço para evicção; massa plana significa que seu tráfego realmente lê tudo, e aí a economia honesta está nos bytes (quantização), não na cirurgia.