A expulsão do KV Cache pode ocultar falhas de LLM em produção

Sim. A expulsão do KV cache pode ocultar falhas de LLM porque uma política de serving pode descartar estados de atenção importantes e, depois, não ter informações suficientes para estimar o dano usando apenas o cache retido.

Um artigo submetido em 23 de julho de 2026 estabelece um limite preciso para esse problema: a expulsão determinística top-k sem considerar valores não consegue estimar de forma consistente o erro induzido na saída da atenção usando apenas o estado retido. A alternativa proposta mantém uma amostra probabilística da cauda descartada e constrói um certificado estatístico em torno do erro estimado. O método melhorou a atribuição de falhas nos experimentos relatados, mas o protótipo é mais lento, os experimentos chegam apenas a contextos de 16K e 8B parâmetros, e o artigo não prova a correção das respostas de ponta a ponta.

Antes do rollout, compare cada tratamento de cache candidato com um controle de cache completo usando as mesmas requisições congeladas. Conte os casos em que o cache completo passa e o candidato falha. Teste expulsão, quantização, offload e reutilização separadamente para que cada comparação isole uma fonte de erro.

Nível do leitor: Avançado. Este guia pressupõe que você entende inferência de transformers, atenção e avaliação básica de modelos.

Conteúdo

Por que a expulsão do KV cache pode ocultar falhas

A saída da atenção depende das entradas retidas e das entradas removidas pela política. Depois que uma política determinística descarta a cauda, um monitor que vê apenas o conjunto selecionado não consegue inspecionar os valores ausentes.

ArXiv:2607.21475 estuda esse problema de observabilidade. Seu resultado negativo se aplica à expulsão determinística top-k sem considerar valores: apenas o estado retido não consegue sustentar uma estimativa consistente do erro na saída da atenção causado pela expulsão. O resultado não afirma que toda política determinística produz saídas ruins. Ele afirma que essa classe de políticas não consegue certificar de forma confiável o erro induzido usando apenas o que reteve.

O método proposto preserva evidências sobre a cauda descartada. Ele faz amostragem de Poisson das entradas que desapareceriam, aplica uma correção de Hájek e combina essa estimativa com um certificado de variância do conjunto retido.

Medido: O certificado de erro registrou 0,97 de cobertura em 12.096 células de replay de atenção. Um estudo separado com cargas de trabalho reais usou cerca de 74.000 gerações para testar a atribuição de falhas. Nesse estudo, o certificado alcançou AUC de 0,73–0,75 para distinguir falhas causadas pelo cache de falhas inerentes ao modelo. A confiança na saída alcançou 0,47–0,54 na mesma tarefa de atribuição.

Medido: A confiança na saída previu melhor a falha geral. Os dois sinais respondem a perguntas diferentes:

Inferido: A baixa confiança na saída não pode servir como único alarme de regressão do cache. Ela pode sinalizar uma resposta fraca sem identificar sua causa, enquanto uma resposta confiante ainda pode mudar depois que a política de cache remove estado útil.

O artigo também relata resultados negativos e operacionais. Três das sete afirmações pré-registradas falharam. O protótipo levou 0,043 segundo por token, em comparação com 0,023 para a expulsão determinística e 0,015 para o cache completo. Os experimentos cobriram contextos de até 16K, modelos de até 8B e um proxy de turno único. Os autores não fornecem nenhum teorema que conecte o certificado à correção da tarefa de ponta a ponta.

Interpretação prática: Trate o certificado como um sinal de atribuição nas condições estudadas. Ele não certifica a prontidão para produção.

Quatro tratamentos de cache, quatro perguntas de confiabilidade

As equipes frequentemente agrupam várias intervenções sob “otimização do KV cache”. Cada intervenção altera uma parte diferente da inferência.

O survey orientado ao sistema em arXiv:2607.08057 classifica o campo por agendamento temporal, posicionamento e migração espacial, e representação e retenção estrutural. Essa taxonomia também funciona como um limite de avaliação. Comparar um controle BF16 com cache completo a um candidato FP8 com expulsão altera duas variáveis estruturais ao mesmo tempo. Um candidato que falha não consegue identificar se a regressão foi causada pela expulsão, pela quantização ou pela interação entre ambas.

Interpretação prática: Teste cada intervenção de cache como um experimento próprio. Combine-as apenas depois que os tratamentos individuais forem aprovados.

Políticas que preservam mais estado útil

Dois outros artigos mostram que o desenho da política pode preservar mais qualidade com o mesmo orçamento de memória. Nenhum deles fornece um limite universal para produção.

VaSE, arXiv:2606.03928 protege estados de valor de alta magnitude enquanto mantém diversidade estocástica. No Qwen3-4B e no Qwen3-14B, em seis tarefas de raciocínio, alcançou aproximadamente 4× de compressão do cache e melhorou os resultados em 4,4 e 4,9 pontos em relação ao baseline de expulsão mais forte. Uma configuração de 16K em uma única A100 alcançou 3,1× tokens por segundo.

Essas medições cobrem apenas decode, modelos Qwen3 e nenhum batching de produção. Elas não estabelecem o mesmo ganho para outra família de modelos, engine de serving, nível de concorrência ou carga de trabalho.

K-VEC, arXiv:2606.29563 coordena a cobertura de retenção entre cabeças e camadas de atenção. No Llama 3.1 8B, em 16 subconjuntos do LongBench, melhorou as pontuações em até 10,35 pontos e em 1,61 ponto em média com um orçamento de `B=128`. A avaliação usa uma família de modelos e uma suíte de benchmarks, e o método adiciona trabalho de prefill.

Interpretação prática: Políticas orientadas por valor, estocásticas e orientadas por cobertura merecem vagas como candidatas em uma avaliação. Sua execução com cache completo continua sendo a fonte local de verdade.

Por que a quantização precisa de um controle separado

A quantização FP8 do KV cache reduz a precisão em vez de remover tokens. Seus erros ainda podem chegar à aplicação sem um erro do engine.

Uma investigação oficial do FP8 no vLLM, publicada em 22 de abril de 2026, relatou que a precisão em um teste de needle de contexto longo caiu de 91% com cache BF16 para 13% com FP8 antes de uma correção de acumulação em dois níveis. A correção restaurou a precisão para 89%. Na melhor configuração FP8 relatada, a inclinação do decode foi de 54% da do BF16.

Medido: Um caminho numérico produziu uma regressão severa, e uma correção no nível do kernel recuperou a maior parte da precisão perdida.

Não estabelecido: O cache FP8 não causa universalmente essa regressão nem entrega esse ganho de velocidade. O resultado depende da implementação, do modelo, do hardware, do caminho de atenção e do benchmark.

A issue #37554 do vLLM acrescenta um alerta específico: um relator encontrou corrupção silenciosa do scaling de KV FP8 em um modelo híbrido. Esse relatório de bug não pode sustentar uma afirmação geral sobre FP8 ou arquiteturas híbridas.

Uma discussão no LocalLLaMA de 7 de abril contém relatos conflitantes de praticantes sobre formatos de cache e qualidade. Esses relatos podem sugerir casos de teste, mas uma avaliação controlada deve decidir o rollout.

O lançamento do vLLM v0.26.0, datado de 25 de julho, contém 411 commits de 212 contribuidores e amplia a visibilidade sobre tiering do KV, métricas de offload e reutilização de cache. A atividade de lançamento e os novos recursos de observabilidade não provam adoção ampla em produção nem correção.

Um fluxo de validação pareada com cache completo

Defina “cache completo” como o comportamento nativo de atenção do modelo, sem expulsão adicional nem quantização do cache. Mantenha pesos do modelo, tokenizer, versão do runtime, backend de atenção, configurações de amostragem, tokens do prompt e validador de saída fixos dentro de cada par.

1. Execute uma matriz de ablação

Use pelo menos quatro tratamentos:

Comparar apenas A com D pode revelar uma regressão combinada, mas não consegue atribuir uma causa. As execuções B e C fornecem os controles ausentes.

Teste cada modelo, runtime, kernel e caminho de hardware compatível separadamente. O resultado de FP8 do vLLM mostra por que um rótulo como “FP8 habilitado” não contém detalhes suficientes para uma decisão de confiabilidade.

*Legenda: A validação pareada com cache completo isola falhas exclusivas do candidato antes que a expulsão ou a quantização chegue à produção.*

2. Congele uma matriz de cargas de trabalho

Construa a matriz a partir dos formatos reais de requisição e inclua casos de limite:

Cargas de trabalho de contexto longo precisam de mais do que um teste sintético de needle. Se o produto executa agentes de código ou fluxos de trabalho extensos, inclua traces representativos. O volume de tokens e o formato do fluxo afetam a economia descrita em More Tokens, Better AI — and the Compute Bill e Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6.

3. Faça o pareamento das requisições e isole o estado do cache

Use esta lógica de avaliação:

text for each frozen_case: full = run(frozen_case, treatment=A, isolated_cache=true) candidate = run(frozen_case, treatment=candidate, isolated_cache=true)

full_pass = validate(full, frozen_case.expected_behavior) candidate_pass = validate(candidate, frozen_case.expected_behavior)

record(full_pass, candidate_pass, context_length, task_type, model, runtime, hardware, treatment)

Este bloco é pseudocódigo, não uma API específica de engine. Use um validador de tarefa em vez de igualdade textual quando várias respostas puderem estar corretas. Validadores adequados incluem testes unitários para código gerado, verificações de schema para saída estruturada, verificações exatas de ferramenta e argumentos, asserções de recuperação ou um rubric pré-registrado.

Mantenha os namespaces do cache isolados. O estado de prefixo reutilizado entre tratamentos pode contaminar a comparação.

4. Meça falhas exclusivas do candidato

Use esta métrica principal:

text cache_induced_failure_rate = count(full passes and candidate fails) / count(full passes)

O denominador condiciona a taxa ao sucesso do cache completo. Um par em que ambas as execuções falham não mostra que a compressão do cache causou a falha.

Relate o numerador e o denominador brutos para cada recorte crítico. Um único agregado pode ocultar uma regressão no contexto máximo, em um modelo ou sob um backend de atenção específico. Acompanhe a taxa de falha total ao lado da métrica pareada, pois os sinais de confiança na saída e de atribuição ao cache cobrem modos de falha diferentes.

5. Declare previamente a regra de decisão

Escolha a taxa máxima aceitável, `τ`, antes de visualizar os resultados do candidato. Defina regras mais rigorosas para tarefas críticas. Uma falha exclusiva do candidato, reproduzível, pode justificar a rejeição em um caminho de ferramenta, segurança ou transação mesmo quando o agregado permanece abaixo de `τ`.

A configuração do cache pertence à política de execução. Registre-a e aplique-a com a disciplina usada para permissões determinísticas de agentes de AI: configuração explícita, decisões observáveis e um caminho de reparo quando a aplicação falhar.

Decisões de rollout

Atividade em release notes, relatos anedóticos e ganhos médios em benchmarks não podem substituir um gate de rollout pareado.

Limites das evidências atuais

O resultado mais forte do certificado cobre o erro na saída da atenção sob um proxy de turno único, não a correção da aplicação de ponta a ponta. Seus experimentos param em 16K e 8B, enquanto sistemas de produção podem executar modelos maiores, contextos mais longos, múltiplos turnos, ferramentas e batches. O protótipo medido também custa mais tempo por token do que a expulsão determinística e o cache completo na configuração relatada.

VaSE e K-VEC continuam vinculados a modelos, tarefas, orçamentos e configurações de serving específicos. As evidências do vLLM mostram que detalhes de implementação podem dominar um resultado de formato de cache. Nenhuma dessas fontes fornece uma taxa universalmente segura de compressão.

Interpretação prática: Use a pesquisa para escolher políticas candidatas e sinais de monitoramento. Use a validação pareada com cache completo para decidir se sua implementação atende aos limites de confiabilidade da sua carga de trabalho.

Verificações das afirmações

Fontes