Kv cache

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.

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

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

*roblema:*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

  • *rXiv:*2309.06180 | SOSP 2023 (vLLM)
  • *utores:*Kwon et al. (Berkeley)
  • *deia:*Inspirado em paginação de memória virtual do SO
  • *ecanismo:*KV cache armazenado em blocos não-contíguos (páginas); tabela de mapeamento virtual → físico
  • *enefí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
    • Copyonwrite para beam search
  • *mpacto:*Fundação do vLLM; 24× mais throughput que HuggingFace transformers naive

RadixAttention (SGLang)

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

Chunked Prefill (vLLM, SGLang)

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

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

H2O — Heavy Hitter Oracle

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

SnapKV

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

ScissorHands

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

PyramidKV / PyramidInfer

  • *rXiv:*2406.02069
  • *ecanismo:*Camadas mais baixas mantêm mais tokens; camadas mais altas mantêm menos (pirâmide)
  • *esultado:*Melhor preservação de informação global

RazorAttention

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

Streaming LLM — Janela Deslizante com Âncoras

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

KV Cache Quantization

TurboQuant (Google, 2026)

  • *rXiv:*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

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

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

  • *aper:*DeepSeek-V4 §3.6 (24042026)
  • *ódigo:*huggingface.codeepseek-aiDeepSeekV4Protreemain/inference (MIT)
  • *roblema:*A hybrid attention do V4 (CSA com fator m + HCA com fator m' ≫ m + SWA com n_win recentes) gera KV entries com *amanhos e políticas distintos por camada* violando os pressupostos do PagedAttention.
  • *olução — duas estruturas separadas:*
    1. *lassical 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. *tate cache*perrequest, fixo — armazena SWA KV (n_win recentes) + tail tokens uncompressed ainda não prontos para compressão. Tratado como statespace model: KV depende só da posição corrente.
  • *ixed-precision storage:*RoPE dims em BF16, demais em FP8 → ~50% de economia vs BF16 puro.
  • *ndisk KV cache:*entries comprimidas (CSA/HCA) e SWA têm estratégias separadas de persistência em disco para sharedprefix reuse — elimina re-prefill em prompts longos compartilhados.
  • *esultado 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.
  • *mportante:*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 *eterogê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

  • *roblema:*GPU memória esgotada para contextos muito longos
  • *olução:*Offload blocos frios para CPU DRAM ou NVMe via PCIe
  • *erramentas:*Inferflow, FlexGen
  • *rade-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 *stende*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

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

IMPRESS — ImportanceInformed MultiTier Prefix KV Storage

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

Kareto — Adaptive Multi-Objective Tiered Storage

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

MTDS — Multi-Tier Dynamic Storage

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

LMCache (produto)

  • *isponível em:*AWS SageMaker HyperPod, Google GKE
  • *iers:**BM (Tier 1) → CPU RAM (Tier 2) → Local SSD (Tier 3)*
  • *aso de uso:*prefix cache compartilhado entre múltiplos workers de inferência; reuso crossrequest e crosspod.

*adrã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).

*istinto do "heterogeneous KV cache" do DeepSeek-V4*(seção anterior): tiered KV é hierarquia de *torage*(mesma estrutura, locais distintos); heterogeneous KV é variedade de *struturas*(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. *agedAttention*via vLLM ou SGLang (base)
  2. *refix caching*para system prompts compartilhados (contexto do repositório)
  3. *P8 KV cache*(quando hardware suportar)
  4. *urboQuant*para máxima compressão em contextos de repositório longo
  5. *hunked prefill*para latência consistente em servidor compartilhado

Source: ../home/koder/dev/koder/meta/docs/ia/compendium/05-inferencia/kv-cache.md