PrefixSim: simulador de cache KV de código aberto compara mais de 40 políticas de remoção

Se você executa LLMs em produção, provavelmente já ouviu falar em cache de prefixos. A ideia é simples: muitas requisições compartilham o mesmo início, como um prompt de sistema, a descrição das ferramentas ou o histórico da conversa. Não é preciso recalcular o cache KV desse prefixo a cada vez: ele pode ser armazenado e reutilizado. Mas a memória da GPU é finita e, mais cedo ou mais tarde, o cache precisa remover alguma coisa. A escolha do que descartar determina quanto tempo de GPU será desperdiçado.

É esse problema que o PrefixSim tenta resolver. Publicado como código aberto por Juncheng Yang (@1a1a11a), o projeto é um simulador rápido de cache de blocos KV para servir LLMs. Os autores também disponibilizaram dois conjuntos de dados com traces de cargas de trabalho. Uma ressalva: a publicação original no X termina no meio de uma frase, por isso o texto abaixo se limita ao que ela afirma explicitamente. Detalhes como o formato dos traces e a licença devem ser consultados no repositório.

Qual problema ele resolve

Políticas tradicionais de cache, como LRU, foram criadas para páginas da web e blocos de disco. Os blocos KV têm características diferentes. Eles se organizam como uma árvore de prefixos: um bloco no início de uma cadeia é necessário para todos os que vêm depois. Remover um bloco raiz “antigo” significa inutilizar um ramo inteiro. Além disso, o custo computacional varia entre blocos: recalcular um prefixo longo é muito mais caro do que recalcular um curto.

Por isso, a conhecida taxa de acertos pode ser enganosa nesse contexto. Os autores do PrefixSim apontam explicitamente a economia de processamento como o principal critério: quanto trabalho de prefill deixou de ser necessário. Duas políticas com a mesma taxa de acertos podem gerar economias de GPU muito diferentes.

Como funciona na prática

Imagine um assistente de chat com um prompt de sistema longo e dezenas de milhares de sessões por dia. Você pega um trace real de requisições e o reproduz no simulador com diferentes políticas de remoção. Segundo o autor, são mais de 40. Os resultados mostram qual delas economiza mais processamento com a quantidade de memória que você reservou para o cache.

A palavra-chave é “reais”. Cargas sintéticas muitas vezes produzem números bonitos que não se repetem em produção. Por isso, a publicação de dois conjuntos de dados abertos com traces de inferência já é útil por si só: a comunidade passa a ter uma base comum de comparação, em vez de uma coleção de benchmarks internos que não são comparáveis entre si.

Outro motivo para o valor do simulador é o custo dos experimentos. Testar uma política de remoção em um cluster em operação é demorado e arriscado: exige modificar o motor, implantar as mudanças e esperar por tráfego representativo. Simular um trace gravado leva minutos e não quebra nada.

O que fazer com ele

Se você está construindo sua própria stack de inferência ou ajustando vLLM, SGLang e motores semelhantes, o PrefixSim oferece uma forma de verificar se está deixando dinheiro na mesa. Grave um trace da sua carga de trabalho, execute-o no simulador e compare sua política atual com as alternativas. Se a diferença na economia de prefill for significativa, isso justifica aprimorar o cache. Caso contrário, você ao menos saberá que a opção padrão atende às suas necessidades.

Para gestores de produto e fundadores, há outro ponto relevante: a eficiência do cache afeta diretamente o tempo até o primeiro token e o custo por requisição. Em serviços com prefixos compartilhados longos, como agentes, assistentes RAG e assistentes de programação, isso pode representar uma parcela importante dos gastos.

Limitações

Um simulador continua sendo um modelo. Ele não contempla tudo o que acontece em um motor real: fragmentação de memória, escalonamento ou sobrecarga das filas. Os resultados obtidos com traces de empresas específicas não se aplicam necessariamente à sua carga de trabalho. Também ainda não vimos validações independentes: no momento da publicação, tratava-se de um anúncio no X com cerca de 7.500 visualizações. Ainda assim, tanto como ferramenta quanto como fonte de dados abertos para uma área controversa e subestimada da inferência com LLMs, o projeto parece valer uma noite de exploração.