KV Cache — Gerenciamento de Memória em Inferência

O Que É o KV Cache

A atenção computa: Attention(Q, K, V). Para cada token gerado, os K e V de todos os tokens anteriores precisam estar em memória. Esse cache cresce linearmente com o comprimento da sequência.

Fórmula: KV Cache Size = 2 × layers × heads × head_dim × seq_len × bytes_per_element

Exemplo: Llama 3 70B, seq 8K, BF16 → ~2 × 80 × 8 × 128 × 8192 × 2 bytes ≈ 42 GB

Problema: Para servidores com múltiplos usuários simultâneos, o KV cache compete diretamente com os pesos do modelo pela memória da GPU.

PagedAttention — Gerenciamento Paginado

  • arXiv: 2309.06180 | SOSP 2023 (vLLM)
  • Autores: Kwon et al. (Berkeley)
  • Ideia: Inspirado em paginação de memória virtual do SO
  • Mecanismo: KV cache armazenado em blocos não-contíguos (páginas); tabela de mapeamento virtual → físico
  • Benefícios:
    • Zero fragmentação interna: bloco é alocado só quando necessário
    • Compartilhamento de prefixo: prefixos comuns (system prompt) mapeados para as mesmas páginas físicas
    • Copy-on-write para beam search
  • Impacto: Fundação do vLLM; 24× mais throughput que HuggingFace transformers naive

RadixAttention (SGLang)

  • arXiv: 2312.07104
  • Mecanismo: Árvore radix de blocos de KV cache; reutilização automática de prefixos comuns entre requests
  • Caso de uso: Same system prompt para múltiplos usuários → cache compartilhado
  • Resultado: 5.6× throughput de PagedAttention para workloads com prefixos repetidos
  • Adoção: SGLang; inspirou prefix caching no vLLM

Chunked Prefill (vLLM, SGLang)

  • Mecanismo: Divide o prefill (processamento do prompt) em chunks menores para intercalar com decoding de outras requests
  • Benefício: Reduz latência de TTFT (time to first token) sob alta carga; melhor utilização de GPU
  • Implementação: --enable-chunked-prefill no vLLM

Sparse KV Cache — Compressão por Atenção Seletiva

H2O — Heavy Hitter Oracle

  • arXiv: 2306.14048
  • Mecanismo: Mantém apenas os K tokens mais "pesados" (maior atenção acumulada) + tokens recentes
  • Budget: Define orçamento de tokens por camada (ex: 20% do contexto)
  • Resultado: 90% de redução de memória com <5% queda em qualidade

SnapKV

  • arXiv: 2404.14469
  • Mecanismo: Identifica posições importantes via padrão de atenção do último bloco do prompt → retém essas posições no KV cache
  • Resultado: Melhor que H2O; menos perda em tarefas de recall

ScissorHands

  • arXiv: 2305.17118
  • Mecanismo: Pivots de atenção persistem ao longo da sequência; descarta tokens não-pivot
  • Resultado: Similar ao H2O com seleção mais estável

PyramidKV / PyramidInfer

  • arXiv: 2406.02069
  • Mecanismo: Camadas mais baixas mantêm mais tokens; camadas mais altas mantêm menos (pirâmide)
  • Resultado: Melhor preservação de informação global

RazorAttention

  • arXiv: 2407.15891
  • Mecanismo: Mantém KV apenas para "retrieval heads" (cabeças de atenção que fazem recuperação de informação); descarta das demais
  • Resultado: 70% menos KV cache com perda mínima

Streaming LLM — Janela Deslizante com Âncoras

  • arXiv: 2309.17453
  • Autores: Xiao et al. (MIT)
  • Problema: Atenção com janela deslizante perde tokens iniciais → perda de qualidade catastrófica
  • Solução: Mantém "attention sinks" (primeiros 4 tokens) + janela deslizante recente
  • Resultado: Geração contínua em sequências de qualquer comprimento sem re-computação
  • Adoção: transformers, llama.cpp

KV Cache Quantization

TurboQuant (Google, 2026)

  • arXiv: 2504.19874
  • ~3.5 bits efetivos para KV cache; 6× menos memória que FP16; zero perda de qualidade
  • Ver 05-inferencia/quantizacao.md para detalhes

FP8 KV Cache

  • Suporte nativo em vLLM, SGLang, TensorRT-LLM
  • ~2× menos memória que FP16

Multi-Head Latent Attention (MLA) — DeepSeek

  • arXiv: 2405.04434 (DeepSeek-V2)
  • Mecanismo: Projeta K,V para espaço latente de dimensão muito menor antes do KV cache
  • Resultado: KV cache 93% menor que Multi-Head Attention equivalente
  • DeepSeek-V3: MLA com 576 dims latentes vs 7168 em MHA → drástica redução
  • Limitação: Requer mudança na arquitetura do modelo (não é otimização post-hoc)
  • DeepSeek-V4 abandonou MLA em favor da hybrid CSA+HCA (próxima seção).

Heterogeneous KV Cache (DeepSeek-V4) — Hybrid CSA + HCA + SWA

  • Paper: DeepSeek-V4 §3.6 (24042026)
  • Código: huggingface.codeepseek-aiDeepSeek-V4-Protreemain/inference (MIT)
  • Problema: A hybrid attention do V4 (CSA com fator m + HCA com fator m' ≫ m + SWA com n_win recentes) gera KV entries com tamanhos e políticas distintos por camada, violando os pressupostos do PagedAttention.
  • Solução — duas estruturas separadas:
    1. Classical block cache — armazena CSA Indexer KV + CSA Main KV + HCA KV; block size = lcm(m, m'), gerando k1 = lcm/m entries CSA e k2 = lcm/m' entries HCA por bloco. Atende ao SparseAttention kernel co-design (alignment com cache lines).
    2. State cache per-request, fixo — armazena SWA KV (n_win recentes) + tail tokens uncompressed ainda não prontos para compressão. Tratado como state-space model: KV depende só da posição corrente.
  • Mixed-precision storage: RoPE dims em BF16, demais em FP8 → ~50% de economia vs BF16 puro.
  • On-disk KV cache: entries comprimidas (CSA/HCA) e SWA têm estratégias separadas de persistência em disco para shared-prefix reuse — elimina re-prefill em prompts longos compartilhados.
  • Resultado combinado (com CSA+HCA+precisão mista): KV cache em 1M tokens cai para ~2% do baseline BF16 GQA8 equivalente; ~10× menor que DeepSeek-V3 em 1M.
  • Importante: O conceito não é "KV cache em 3 tiers por frequência de acesso" (descrição imprecisa que circula em vídeos de divulgação). É um cache heterogêneo de 2 componentes (block + state), com on-disk como camada de persistência separada.

Técnicas de Prefill Otimizado

Cross-Attention KV Sharing

  • Prefixos compartilhados (system prompts) ficam no cache uma vez, servem todos

Prefix Caching (vLLM v0.5+)

  • Hash de prefixo → reutiliza KV cache computado anteriormente
  • Implementação do RadixAttention no vLLM

Automatic Prefix Caching (APC)

  • vLLM detecta prefixos automaticamente sem configuração explícita

CPU Offloading de KV Cache

  • Problema: GPU memória esgotada para contextos muito longos
  • Solução: Offload blocos frios para CPU DRAM ou NVMe via PCIe
  • Ferramentas: Inferflow, FlexGen
  • Trade-off: Latência de PCIe vs VRAM (PCIe 5.0: ~64 GBs vs HBM3e: 3.4 TBs — 50× diferença)

Tiered KV Cache — Família de Sistemas Multi-Tier

Família de trabalhos que estende o conceito de offloading para uma hierarquia formal HBM → DRAM → SSD/Disk, com gestão adaptativa entre tiers. Não é uma técnica única, é um padrão arquitetural.

TTKV — Temporal-Tiered KV Cache

  • arXiv: 2604.19769 (2026)
  • Mecanismo: Organiza KV em tiers temporais com capacidade, precisão e latência heterogêneas, alinhados à hierarquia HBM–DRAM. Co-projeta tier layout, tier content e tier interaction.
  • Diferencial: integra redução de KV (sparsity) com awareness da hierarquia de memória — não trata os dois separadamente.

IMPRESS — Importance-Informed Multi-Tier Prefix KV Storage

  • Venue: USENIX FAST 2025
  • Mecanismo: 3 tiers explícitos — GPU memory + CPU memory + disk. Carrega seletivamente apenas KVs "importantes" para prefill/decoding; ataca o gargalo de disco diretamente.

Kareto — Adaptive Multi-Objective Tiered Storage

  • arXiv: 2603.08739
  • Foco: Configuração dinâmica de armazenamento heterogêneo balanceando custo, throughput e latência sob workloads variáveis. Multi-objective optimization explícito.

MTDS — Multi-Tier Dynamic Storage

  • Venue: Complex & Intelligent Systems (Springer, 2025)
  • Mecanismo: Offload de KV de GPU VRAM para hierarquia local; reduz tanto memória quanto computação na GPU.

LMCache (produto)

  • Disponível em: AWS SageMaker HyperPod, Google GKE
  • Tiers: HBM (Tier 1) → CPU RAM (Tier 2) → Local SSD (Tier 3)
  • Caso de uso: prefix cache compartilhado entre múltiplos workers de inferência; reuso cross-request e cross-pod.

Padrão comum dessa família: latência cresce ~10–100× a cada tier abaixo (HBM 3 TBs → DRAM 100 GBs → SSD 5 GBs), mas capacidade cresce 10–1000×. Política de promoçãoeviction é a chave — tipicamente baseada em (a) frequência (LRU/LFU clássico), (b) importância de atenção (IMPRESS), ou (c) idade temporal (TTKV).

Distinto do "heterogeneous KV cache" do DeepSeek-V4 (seção anterior): tiered KV é hierarquia de storage (mesma estrutura, locais distintos); heterogeneous KV é variedade de estruturas (CSAHCASWA com schemas distintos). Ortogonais — V4 poderia rodar sobre LMCache.

Tabela Resumo

Técnica Redução de Memória Perda de Qualidade Requer Mudança no Modelo?
PagedAttention Gerenciamento (não reduz) Zero Não
TurboQuant 6× Zero Não
FP8 KV 2× Mínima Não
H2O até 10× Leve Não
SnapKV até 10× Mínima Não
MLA 13× Zero Sim (arquitetura)
StreamingLLM Janela fixa Perda fora da janela Não

Stack Recomendado para Kode

  1. PagedAttention via vLLM ou SGLang (base)
  2. Prefix caching para system prompts compartilhados (contexto do repositório)
  3. FP8 KV cache (quando hardware suportar)
  4. TurboQuant para máxima compressão em contextos de repositório longo
  5. Chunked prefill para latência consistente em servidor compartilhado