WAKMan escolhe a política de remoção do KV-cache e supera o LRU em 5 p.p.

O prefix caching em servidores de LLM economiza dinheiro e tempo, mas só enquanto o prefixo necessário continua na memória. A memória é limitada, e o resultado depende da política de remoção do KV-cache. Os pesquisadores Suhas Kumar Morisetty e mais três autores, que trabalharam durante um estágio na Capital One, testaram as estratégias mais populares em 20 misturas de carga. A conclusão é simples: não existe uma política única que seja a melhor. Eles propuseram o WAKMan, um gerenciador que escolhe a política de remoção com base no tráfego real. Em média, ele melhora o hit rate em 5 pontos percentuais em comparação com o LRU.

Por que agentes e chatbots querem coisas diferentes do cache

O prefix caching permite que o servidor reaproveite os estados Key-Value de requisições cujo prefixo é igual ao de prompts anteriores. Isso acelera a etapa de prefill e reduz a latência e o custo de atendimento. Mas o tráfego real em produção é variado: requisições isoladas, diálogos de vários turnos, cadeias agênticas ou qualquer mistura desses tipos.

Cada tipo de requisição tem um "tempo de retorno" diferente ao prefixo. Os passos de um agente voltam em poucos segundos e precisam de um cache que lembre o que é recente. Prompts populares e diálogos longos voltam depois de muitas outras requisições, e para eles a frequência de acesso pesa mais. O primeiro cenário combina bem com o LRU; o segundo, com políticas baseadas em frequência.

Onde o LRU ganha e onde perde

O vLLM usa o LRU por padrão. Os autores o compararam com o S3FIFO, orientado a frequência, e chegaram a um quadro que derruba o hábito de escolher uma política e mantê-la para sempre:

• em misturas com predominância de requisições agênticas, o LRU tem 12% mais acertos de cache que o S3FIFO;
• nas demais misturas, o LRU fica atrás do S3FIFO em até 22%;
• mesmo um único parâmetro da carga pode trocar o vencedor dentro de uma mesma mistura.

O último ponto é o mais incômodo para os engenheiros. Não dá para medir o tráfego uma vez, escolher a política e esquecer o assunto. Basta um parâmetro se deslocar para que o líder de ontem vá parar no fim da fila.

O que o WAKMan faz

O WAKMan escolhe a política de remoção com base no tráfego real. Ele não precisa saber quais requisições estão chegando nem ler os prompts. Em produção, essa é uma condição importante: o conteúdo das requisições costuma ser sensível, sobretudo em uma organização como a empresa financeira onde foi feito o estágio. O gerenciador só precisa observar o comportamento do tráfego.

Resultados finais do WAKMan:

• ganho médio de 5 pontos percentuais de hit rate sobre o LRU;
• a menor distância média em relação à política ótima entre todas as comparadas;
• a menor distância no pior caso em relação ao ótimo entre todas as comparadas;
• validação em 20 misturas de cargas single-turn, multi-turn e agentic.

O segundo e o terceiro pontos pesam mais que o ganho médio. Eles indicam previsibilidade: o WAKMan não necessariamente vence em cada mistura individual, mas erra a melhor opção com menos frequência e por margens menores. Para quem opera inferência, isso vale mais que uma vitória bonita em um benchmark específico.

O que fazer se a parcela de agentes no seu tráfego está crescendo

Os cenários agênticos ocupam rapidamente uma fatia cada vez maior do tráfego. Com eles, muda o perfil do cache: aumentam os retornos curtos a dados "quentes", e os prompts populares e os diálogos longos ficam de fundo. Se a política de remoção está embutida no servidor e nunca é revista, parte do ganho do prefix caching se perde. A perda aparece na forma de prefill repetido, ou seja, segundos de GPU desperdiçados e latência extra.

Conclusões práticas para quem mantém a própria inferência em vLLM:

• meça o hit rate separadamente por tipo de carga, e não apenas a média do servidor;
• não trate o LRU como uma escolha segura em qualquer situação: em parte das misturas, ele perde para o S3FIFO em até 22%;
• reavalie a política sempre que mudar a parcela de tráfego agêntico;
• avalie as soluções pelo pior caso, e não apenas pelo ganho médio.

O WAKMan mostra que é possível automatizar a escolha da política sem acesso ao conteúdo das requisições. Em grandes implantações, um acréscimo de 5 pontos percentuais de hit rate significa menos recomputação em cada prefixo e uma latência mais estável com tráfego misto.