DRAM-PIM e poda de KV cache: dois papers apontam onde o decode perde energia

DRAM-PIM e poda de KV cache: dois papers apontam onde o decode perde energia

A janela das últimas 72 horas não trouxe lançamento de modelo que justifique manchete. O material mais concreto é de pesquisa aplicada, e rende mais que um anúncio: dois trabalhos do IBM Research atacam o mesmo gargalo por lados opostos. Um mede por que sistemas com processamento na memória (PIM) não entregam o ganho prometido na fase de decode. O outro mostra por que a poda de KV cache baseada em decaimento posicional tende a virar sliding window disfarçado.

Vale o contexto de uma linha: na geração token a token, o acelerador passa a maior parte do tempo esperando dados, não calculando. Cada token novo precisa ler o KV cache — chaves e valores de todos os tokens anteriores. Mais contexto significa mais memória para varrer e mais HBM energizada.

O que o paper de PIM mediu

Apresentado no SOCC 2026 (30 de setembro), "On Design Principles for Efficient Heterogeneous DRAM-PIM-GPU Systems" parte de uma promessa conhecida: colocar parte do cálculo dentro da DRAM encurta o caminho dos dados e alivia a pressão sobre a banda. A contribuição não é a ideia, é a avaliação sistemática, com arquiteturas e workloads variados — OPT-7B e OPT-70B, além de Mamba2-2.7B e Mamba2-70B.

O achado central: as práticas de projeto atuais ignoram fatores que decidem o desempenho no mundo real, e o primeiro deles é o consumo estático do DRAM . Consumo estático é o que o chip gasta só por estar energizado, com os bancos abertos, antes de qualquer leitura útil. Em sistemas PIM, esse custo cresce na mesma direção do recurso que se quer multiplicar: mais DRAM ativa, mais watt parado.

Duas consequências práticas. Primeiro, ganho de banda não é gratuito: se o limite do rack é energético, PIM pode trocar um gargalo por outro. Segundo, o recorte importa — o trabalho olha explicitamente para geração de saída longa, onde o decode domina o tempo total e qualquer watt extra na memória pesa mais do que pesaria no prefill, que é limitado por compute.

A poda de KV cache tem um teto de expressividade

O segundo trabalho é "A Self-Pruning Transformer: Extreme KV-Cache Compression with Universal Attention" (COLM 2026, 6 de outubro). A linha de pesquisa é substituir as embeddings posicionais RoPE por mecanismos baseados em decaimento, que permitem descartar entradas antigas do KV cache durante a inferência — um cache que encolhe sozinho, sem índice auxiliar.

A crítica é direta: funções de decaimento têm expressividade limitada e, na prática, degeneram em padrões de evicção parecidos com sliding window. Ou seja, o modelo "esquece" o começo do contexto de forma aproximadamente uniforme — exatamente o comportamento de uma janela deslizante. Os autores propõem um framework unificador, batizado de self-pruning, para compor mecanismos complementares em vez de um único decaimento.

Por que isso importa para quem paga a conta: se o mecanismo de poda se comporta como janela deslizante, a memória por requisição cai, mas a capacidade de recuperar informação distante — a razão de pagar por contexto de 1 milhão de tokens — cai junto. E isso aparece justamente em cargas agênticas, onde o objetivo declarado no início da sessão precisa sobreviver a dezenas de chamadas de ferramenta.

Cabe a distinção: ontem este blog tratou do custo do KV cache em produtos de serving, incluindo o caso de um fornecedor que fixa o cache em cerca de 72 MiB a 256 mil tokens. O recorte aqui é outro, e mais incômodo — o que acontece quando o mecanismo de compressão muda o comportamento do modelo, não apenas o consumo de memória.

O terceiro vetor: parar de raciocinar mais cedo

Fechando o mesmo COLM 2026, o TRACES (6 de outubro) ataca o outro lado da fatura. Modelos de raciocínio supergeram passos de verificação e reflexão, e boa parte deles não muda a resposta final. O trabalho etiqueta os passos por tipo para descobrir quais contribuem para o acerto e propõe early stopping adaptativo.

O incentivo econômico é óbvio: token de saída é o item caro de qualquer tabela. No GPT-6.1 Terra, US 1 na entrada — 5x. Cortar 20% dos passos de raciocínio vale mais que negociar desconto na entrada.

O que ainda não se sabe

Os resumos publicados dos três trabalhos não trazem números de tokens por segundo, joules por token ou taxa de acerto em tarefas de contexto longo; esses dados dependem dos anais de SOCC e COLM e de eventual liberação de artefatos. Também não há, até aqui, uma comparação fechada de PIM contra HBM na mesma carga e mesma quantização — o que impede tratar PIM como substituto direto. E resta a pergunta que interessa a quem roda agente em produção: se a poda por decaimento sobrevive a dependências longas reais ou só a benchmarks de recuperação sintética.

Leitura prática

Contexto longo é capex, não só preço de tabela. Ao dimensionar o custo por requisição, inclua memória e energia do KV cache — não apenas o preço por milhão de tokens da API.

Desconfie de benchmark de "extreme compression" sem tarefa de longo alcance. Peça a métrica em needle-in-a-haystack com distância real e em tarefa agêntica de múltiplos turnos.

PIM merece teste, não migração. Antes de considerar aceleradores com memória processante, meça o perfil energético da carga: se for saída longa e batch alto, o cálculo muda.

Orçamento de raciocínio é alavanca de custo mais rápida que troca de modelo. Limite de passos, verificação condicional e early stopping dão ganho imediato, sem migração.

Próximos passos

Acompanhar a publicação dos anais de SOCC e COLM 2026 e qualquer liberação de código do self-pruning transformer — é ali que se saberá se a poda de KV cache por decaimento é arquitetura ou apenas economia de memória.

Fontes