Como comprimir o KV cache do seu LLM em 33x sem treino

#python #machinelearning #portuguese

Como comprimir o KV cache do seu LLM em 33x sem treino

Se alguma vez tentaste correr um LLM com contextos longos, provavelmente te deparaste com o mesmo problema: a memória acaba.

O culpado é o KV cache — a tabela de chaves e valores que o modelo mantém para cada token. Num modelo moderno com 128K de contexto, esse cache pode facilmente ocupar 80 GB. Um A100 inteiro, apenas para guardar atenção intermédia.

NexusQuant elimina esse bottleneck. Sem treino. Sem calibração. Uma linha de código.

Instalação

pip install nexusquant-kv
pip install "nexusquant-kv[hf]"  # com HuggingFace transformers

Quickstart

from nexusquant import nexusquant_evict

with nexusquant_evict(model, quality="balanced"):
    output = model.generate(input_ids, max_new_tokens=512)

É literalmente isto. O modelo não é modificado — os hooks são instalados e removidos automaticamente pelo context manager.

Os números

Medidos no Mistral-7B, A100, FP16. Todos os rácios incluem overhead (escalas, índices, metadados).

Preset	Compressão	Degradação PPL	Contexto em 80 GB
`high`	10x	+0.4%	~1.3M tokens
`balanced`	17x	+1.3%	~2.2M tokens
`max`	33x	+2.6%	~4.2M tokens

Em concreto: 128K tokens de contexto → 4.2M tokens com max, na mesma GPU.

Como funciona (em 6 passos)

Pontuação de importância — rankear tokens pelo produto interno cross-head das atenções
Eviction de tokens — eliminar os tokens menos importantes; preservar sempre o BOS e uma janela deslizante recente
Remoção de RoPE — desfazer os embeddings rotatórios nas keys para que partilhem um subespaço comum, reduzindo o erro de quantização ~0.7 pp
Rotação de Hadamard — distribuir energia uniformemente entre dimensões para que nenhum outlier domine a escala de quantização
Quantização na rede E8 — quantizar grupos de 8 floats na rede raiz E8 (a embalagem de esferas mais densa em 8D), 2 bits/dim
Delta coding + zstd — tokens consecutivos produzem índices de rede semelhantes; armazenar deltas e comprimir com zstd dá mais 2-3x no stream de índices

Eviction reduz a contagem (~2.5x a 60% de eviction). E8 reduz a precisão (~7x após entropy coding). Combinados: 17x.

Comparação com a concorrência

Método	Compressão	Degradação PPL	Requer treino
NexusQuant	10-33x	+0.4-2.6%	Não
TurboQuant (Google)	~5-6x	~0%	Não
KVTC (NVIDIA)	até 20x	<1%	Sim (calibração)
CommVQ (Apple)	~8x	~0%	Sim (treino completo)
Palu	11x	~25% rel	Sim (calibração)

NexusQuant é o método training-free com maior compressão. Os números dos concorrentes são dos seus papers publicados, não reproduzidos no nosso hardware.

Modelos suportados

Qualquer LM causal HuggingFace que use split-half RoPE (o padrão desde Llama-2):

Família Llama (Llama-2, Llama-3, Llama-3.1)
Mistral / Mixtral
Qwen
Phi
Gemma

Ainda não suportados: modelos com RoPE intercalado (GPT-NeoX, GPT-J).

Limitações (honestidade acima de tudo)

A qualidade depende do texto. Texto criativo/narrativo degrada mais do que texto estruturado/técnico ao mesmo rácio. Testa no teu workload real antes de fazer deploy.
Prefixes curtos penalizam. Prefixes com menos de 500 tokens veem mais degradação do que os números acima, que foram medidos entre 1600-3500 tokens.
E8 é CPU-bound. Um deploy em produção precisa de kernels Triton/CUDA para o passo de quantização.
Eviction é permanente. Tokens evictados desaparecem. Se a tua tarefa requer recall preciso de um token específico, mede a sensibilidade ao eviction primeiro.