WAKMan: um gerenciador de cache para servidores de LLM que escolhe sua própria estratégia e ganha até 5 p.p. mais acertos

Por que uma única regra não serve para tudo

Servidores de modelos de linguagem grandes gastam uma parcela significativa de seu poder computacional reprocessando o mesmo contexto repetidamente. Quando duas requisições começam com um trecho de texto idêntico — uma instrução de sistema, por exemplo, ou um histórico de conversa compartilhado — o servidor pode calcular uma única vez as "chaves" e "valores" internos do modelo para esse trecho e, depois, simplesmente pegar o resultado já pronto da memória da placa de vídeo, em vez de recalculá-lo. Isso é chamado de reutilização de prefixo, e de fato acelera as respostas e reduz os custos de operação.

O problema é que a memória da placa de vídeo é limitada, então é preciso liberar espaço constantemente para esse cache, descartando entradas antigas. A regra usada para decidir o que descartar determina diretamente quantas vezes o servidor conseguirá reutilizar dados já calculados. Pesquisadores da Universidade de Maryland e da Capital One mostraram que não existe uma regra universal — e propuseram um sistema chamado WAKMan, que escolhe a estratégia adequada por conta própria, observando o tráfego real.

O tráfego para servidores de LLM costuma ser misto: há perguntas únicas sem memória de mensagens anteriores, conversas de vários turnos com histórico, e cenários de agentes, nos quais um sistema de IA executa por conta própria uma sequência de passos em poucos segundos.

Esses três tipos de requisição têm padrões de reutilização de dados fundamentalmente diferentes:

• Os passos de agentes retornam ao contexto compartilhado quase instantaneamente, em segundos, o que favorece a regra "descartar o mais antigo" (LRU) — hoje o padrão no popular mecanismo vLLM.
• Requisições fixas populares (como instruções de sistema de serviços muito usados) e conversas longas voltam ao seu contexto depois de muitas outras requisições não relacionadas. Para essas, o que importa não é a atualidade, mas a frequência de uso — e aí vence a regra S3FIFO, que protege blocos frequentemente requisitados de serem removidos por "ruído" de requisições pontuais.

Os autores testaram ambas as regras em 20 fluxos de requisições misturados artificialmente, com proporções variadas de cenários pontuais, de vários turnos e de agentes. O LRU superou o S3FIFO nas misturas voltadas para agentes, entregando até 12% mais acertos de cache, mas perdeu para ele em até 22% nas misturas dominadas por conversas e requisições repetidas. Além disso, mesmo com uma composição fixa de tráfego, bastava mudar um único parâmetro — por exemplo, o número médio de turnos em uma conversa ou o tamanho do texto de entrada de uma requisição pontual — para que o vencedor mudasse.

Na mesma mistura de requisições, o LRU vencia com conversas curtas de 2 turnos, mas com conversas de 8 turnos o S3FIFO já vencia com uma diferença de 15,4 pontos percentuais.

Como funciona o WAKMan

A ideia do WAKMan é parar de adivinhar o tipo de tráfego de antemão e, em vez disso, testá-lo constantemente na prática. O sistema mantém, ao lado do servidor real, duas cópias "sombra" do cache — uma com a regra LRU, outra com a regra S3FIFO — e faz o registro das requisições recentes do último intervalo de tempo passar por elas. Vence a estratégia que, nesse mesmo conjunto de requisições, obteve mais correspondências com dados já em cache. O servidor muda para essa estratégia até a próxima verificação.

Para isso, o WAKMan não precisa saber nada sobre o conteúdo das requisições, seu tipo ou o número do turno em uma conversa — ele usa apenas os hashes dos blocos de dados que o vLLM já calcula normalmente. Isso é importante porque, na prática, o servidor muitas vezes não tem como determinar o tipo de requisição: o histórico de conversa é montado do lado do cliente, e exigências de privacidade e separação de dados impedem que o servidor "leia" o conteúdo das requisições para adivinhar sua natureza.

Resultados e limitações

Em experimentos com um modelo Gemma implantado via vLLM em quatro placas de vídeo NVIDIA RTX PRO 6000, o WAKMan entregou, em média, 5 pontos percentuais mais acertos de cache em comparação com a regra LRU padrão do vLLM. Entre as três estratégias testadas — LRU puro, S3FIFO puro e WAKMan dinâmico —, foi o WAKMan que apresentou a menor diferença média e a menor diferença máxima em relação a um cache ideal de tamanho infinito, capaz, em teoria, de armazenar absolutamente tudo.

A principal fraqueza da abordagem é o atraso na reação: a decisão de trocar de estratégia não é tomada instantaneamente, mas ao final do intervalo decorrido, e se o perfil do tráfego muda bruscamente logo após uma troca, parte das requisições desse intervalo acaba sendo atendida por uma estratégia abaixo do ideal. Os autores também observam que outras estratégias de remoção de cache podem ser incorporadas ao sistema, desde que exista uma forma de simular seu funcionamento sem hardware real — então o conjunto de "candidatos" não se limita apenas a LRU e S3FIFO.

Para equipes que operam produtos de LLM com tráfego misto — em que parte dos usuários mantém conversas longas, parte usa cenários de agentes e parte apenas faz perguntas pontuais —, a conclusão prática é clara: uma estratégia de cache fixada rigidamente quase sempre perde desempenho em alguma parcela do tráfego, e vale a pena incorporar um mecanismo de troca adaptativa diretamente na infraestrutura, em vez de escolher "a única regra correta" de uma vez por todas.