Context Caching e RadixAttention: Otimização de KV-Cache em LLMs

A inferência de modelos de linguagem encontrou seu limite físico na largura de banda de memória da GPU. O processamento inicial satura os núcleos de cálculo. Em seguida, a geração consome tempo transferindo tensores pela memória HBM.

Dominar a retenção de cache de chaves e valores (KV-Cache) tornou-se essencial. Técnicas como Automatic Prefix Caching no vLLM e RadixAttention no SGLang cortam custos e eliminam latência em produção.

O que é KV-Cache e por que ele governa o consumo de memória

O KV-Cache armazena os tensores de Chave (Key) e Valor (Value) das camadas de atenção passadas. Esse buffer na VRAM evita recalcular todo o histórico a cada novo token gerado. Sem ele, o custo computacional cresceria de forma quadrática.

Em modelos autorregressivos baseados em Transformer Decoder, a atenção clássica projeta matrizes entre tokens:

Attention(Q, K, V) = softmax((Q × K^T) ÷ (√d_k)) × V

Durante a fase de Decode, o modelo gera um token por vez. Ele projeta apenas o vetor Query do token atual. Para calcular a atenção, ele consulta as Chaves e Valores salvos na memória.

O consumo de memória cresce linearmente com a janela de contexto e o número de requisições simultâneas. A fórmula exata de dimensionamento em bytes é:

Memoria_KV = 2 × n_layers × n_kv_heads × d_head × bytes_por_elemento × seq_len × batch_size

Os termos da fórmula representam camadas (n_layers), cabeças de atenção (n_kv_heads), dimensão interna (d_head) e precisão numérica (bytes_por_elemento). Em precisão BF16, cada elemento ocupa 2 bytes.

O Grouped-Query Attention (GQA), documentado no relatório técnico do LLaMA 3, reduziu as cabeças de KV em 8x frente ao Multi-Head Attention. Mesmo assim, 128k tokens no LLaMA-3-70B exigem 40 GB de VRAM dedicados ao cache.

Em 64 requisições concorrentes de 8k tokens, a demanda atinge 163,8 GB de VRAM. O cache de ativação supera o peso dos próprios parâmetros do modelo quantizado em FP8 (~70 GB).

O Gargalo Operacional: Prefill Compute-Bound vs. Decode Memory-Bound

A inferência de LLMs opera em dois regimes computacionais distintos na GPU. O Prefill é limitado por poder de computação, enquanto o Decode é limitado por largura de banda de memória.

No Prefill (Time-to-First-Token - TTFT), todos os tokens do prompt são processados em paralelo. As matrizes densas operam com alta intensidade aritmética. Os Tensor Cores trabalham próximos de sua capacidade máxima.

No Decode (Time-per-Output-Token - TPOT), cada novo token surge de forma sequencial. A GPU precisa ler gigabytes de tensores da HBM para a SRAM apenas para produzir uma única unidade lexical.

O whitepaper da NVIDIA H100 lista 3.350 TFLOPS em FP8, mas sua memória HBM3 entrega 3,35 TB/s de vazão.

Na decodificação unitária, a intensidade aritmética cai para menos de 1 FLOP por byte transferido. A GPU aguarda os dados cruzarem o barramento.

Reaproveitar prefixos prontos elimina o prefill redundante. Essa economia preserva a largura de banda da memória para acelerar as respostas ativas de outros usuários.

PagedAttention e Automatic Prefix Caching no vLLM

O vLLM resolveu a fragmentação de VRAM criando paginação de memória virtual para tensores de atenção. O PagedAttention divide o KV-Cache em blocos físicos alocados sob demanda.

Sistemas antigos reservavam blocos contíguos de memória prevendo o tamanho máximo da conversa. Esse formato desperdiçava entre 60% e 80% da VRAM por fragmentação e sobrealocação.

O estudo de Kwon et al., publicado no ACM SOSP 2023, provou a eficiência de particionar tensores em blocos de 16 ou 32 tokens. A engine mapeia blocos lógicos para endereços físicos dispersos.

+-------------------------------------------------------------------+
|               TABELA DE PÁGINAS DO PAGEDATTENTION                 |
+-------------------------------------------------------------------+
| Bloco Lógico 0 (Tokens 0..15)   ---> Bloco Físico VRAM #42        |
| Bloco Lógico 1 (Tokens 16..31)  ---> Bloco Físico VRAM #108       |
| Bloco Lógico 2 (Tokens 32..47)  ---> Bloco Físico VRAM #15        |
+-------------------------------------------------------------------+

Com o PagedAttention ativo, o Automatic Prefix Caching (APC) do vLLM calcula hashes encadeados para cada bloco:

Hash_Bloco_N = SHA256(Hash_Bloco_{N-1} || Tokens_Bloco_N)

Quando um novo prompt chega com instruções ou documentos já processados, o vLLM consulta a tabela de hashes.

Havendo casamento exato, o escalonador reutiliza os blocos físicos existentes na VRAM.

A fase de prefill é descartada para o trecho repetido. A engine inicia a geração quase instantaneamente.

Ao atingir a capacidade total de VRAM, o vLLM aplica uma política LRU plana, liberando os blocos menos utilizados.

RadixAttention no SGLang: Estrutura em Árvore e Matching Dinâmico

O SGLang gerencia o KV-Cache por meio de uma árvore de prefixos compactada (Radix Tree) mantida na GPU. O algoritmo RadixAttention permite reutilizar tensores com granularidade exata de tokens.

Em fluxos com agentes autônomos, Few-shot e gramáticas JSON, os compartilhamentos raramente ocorrem em múltiplos exatos de 16 tokens.

O estudo do SGLang (Zheng et al., 2024) provou buscas em tempo $O(L)$, com $L$ sendo a extensão do prefixo.

A arquitetura do RadixAttention fundamenta-se em quatro capacidades principais:

• Matching e Forking Nativo: Quando múltiplas respostas partem de um mesmo prompt, a árvore cria novos ramos sem duplicar tensores existentes.

• Evicção Hierárquica: A liberação de memória ocorre das folhas em direção à raiz. Prefixos centrais de alta frequência permanecem protegidos na GPU.

• Agendamento Cache-Aware: O agendador direciona requisições com prefixos comuns para a mesma GPU, elevando a taxa de acerto do cache.

• Retenção Entre Sessões: Os tensores permanecem na árvore após o término da requisição HTTP, atendendo chamadas futuras com latência mínima.

No LMSYS Chatbot Arena e no GSM8K, o SGLang elevou a vazão entre 2,4x e 5,2x frente a motores tradicionais.

# Inicialização do servidor SGLang com RadixAttention ativo
python3 -m sglang.launch_server \
    --model-path meta-llama/Meta-Llama-3-70B-Instruct \
    --tp 4 \
    --mem-fraction-static 0.85 \
    --context-length 32768 \
    --port 30000

Comparativo Técnico: vLLM (APC) vs. SGLang (RadixAttention)

A escolha entre vLLM e SGLang depende do padrão de tráfego e do nível de ramificação de contexto da aplicação.

Estratégias Comerciais: Anthropic, Google Gemini e OpenAI

Os provedores de APIs proprietárias transformaram a retenção de KV-Cache em recursos comerciais com regras específicas de tarifação.

Anthropic Claude: Breakpoints Explícitos e 90% de Desconto

A Anthropic utiliza pontos de controle declarados no payload via parâmetro cache_control. O desenvolvedor marca blocos estáveis de texto.

• Estrutura: O desenvolvedor insere {"type": "ephemeral"} em prompts de sistema, bases documentais ou histórico de conversas.

• Regras: Suporta até 4 pontos de cache por requisição. O bloco mínimo é de 1.024 tokens no Sonnet/Opus e 2.048 tokens no Haiku.

• Valores: A escrita em cache custa 25% a mais que o input comum (1,25x). As leituras seguintes recebem 90% de desconto (0,10x do preço padrão).

• Validade: O TTL é de 5 minutos, sendo renovado a cada nova leitura bem-sucedida.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Você é o especialista técnico da Produtora MaxVision.",
        },
        {
            "type": "text",
            "text": open("base_conhecimento.txt").read(),
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[{"role": "user", "content": "Explique a gestão de VRAM no vLLM."}],
)

# Métricas de consumo do cache
usage = response.usage
print(f"Tokens Gravados: {usage.cache_creation_input_tokens}")
print(f"Tokens Lidos do Cache: {usage.cache_read_input_tokens}")

Google Gemini: Caching Persistente de Longa Duração

O Google Cloud Vertex AI e o Google AI Studio adotam objetos persistentes gerenciados por identificador único.

• Estrutura: O usuário cria um recurso cachedContents com grandes volumes de dados (arquivos de código, livros ou vídeos).

• Regras: O volume mínimo aceito é de 32.768 tokens (32k).

• Valores: Tokens cacheados recebem 75% de desconto no processamento. Há cobrança por hora de armazenamento ($4,50/1M tok/h no Pro e $1,00/1M tok/h no Flash).

• Validade: O TTL padrão é de 1 hora, expansível programaticamente.

OpenAI: Prompt Caching 100% Automático

A OpenAI implementou retenção automática e transparente no nível do balanceador de carga.

• Estrutura: Não exige configuração manual nem parâmetros específicos no payload.

• Regras: Aplica-se automaticamente a prompts com 1.024 tokens ou mais, avaliados em blocos de 128 tokens.

• Valores: Desconto direto de 50% no custo dos tokens de entrada cacheados, sem taxa de escrita ou storage.

• Validade: Os tensores permanecem ativos por períodos de 5 a 10 minutos após o último acesso.

Simulação de Impacto Financeiro e Latência em Produção

O uso de cache de contexto produz economias financeiras expressivas em sistemas corporativos com prompts extensos e tráfego contínuo.

Considere uma operação com 10.000 requisições diárias, prompt base compartilhado de 50.000 tokens e saída média de 500 tokens por chamada.

Cálculo do Gemini 1.5 Pro inclui custo de retenção de 50.000 tokens por 720 horas mensais ($162/mês de storage).

Em latência de resposta, o ganho no Time-to-First-Token é substancial. Em testes com 32.000 tokens de prompt, o TTFT caiu de 4.600 ms para 65 ms. O ganho representa 98,6% de redução no tempo de espera inicial.

Playbook de Implementação e Boas Práticas de Engenharia

Garantir alta taxa de acerto no cache exige desenhar prompts com ordenação determinística de conteúdo.

• Posicionamento Estratégico de Conteúdo: Posicione instruções de sistema, definições de ferramentas e documentos fixos no topo do prompt. Mantenha variáveis de sessão e perguntas dinâmicas sempre no final.

• Serialização Estrita de JSON: Utilize serializadores determinísticos com chaves ordenadas alfabeticamente em chamadas de ferramentas. Qualquer alteração em espaços ou ordem de campos invalida o cache.

• Dimensionamento em Múltiplos de Bloco: No vLLM, formate blocos de documentação em múltiplos de 16 ou 32 tokens para evitar fragmentação no último nó.

• Roteamento com Afinidade de Sessão: Em clusters distribuídos, configure o balanceador com hashing consistente. Direcionar o mesmo usuário ou documento para a mesma GPU maximiza o reuso de memória.

A otimização de KV-Cache redefine a economia da inferência de IA. A união entre paginação na GPU, árvores de prefixos e descontos comerciais viabiliza sistemas rápidos, econômicos e prontos para escala global.

Fontes Primárias

• Meta AI: The Llama 3 Herd of Models. Relatório Técnico Oficial, 2024. Disponível em: arXiv:2407.21783.

• Kwon, Woosuk et al.: Efficient Memory Management for Large Language Model Serving with PagedAttention. Proceedings of the 29th ACM Symposium on Operating Systems Principles (SOSP '23), 2023. DOI: 10.1145/3575693.3575782 | arXiv:2309.06180.

• Zheng, Lianmin et al.: SGLang: Efficient Execution of Structured Language Model Programs. UC Berkeley / LMSYS, 2024. Disponível em: arXiv:2312.07104.

• NVIDIA Corporation: NVIDIA H100 Tensor Core GPU Architecture Whitepaper. Especificações de Microarquitetura e Memória HBM3, 2024. Disponível em: NVIDIA Technical Docs.

• Anthropic: Prompt Caching in Claude — Developer Documentation & Architecture Overview. 2026. Disponível em: Anthropic Docs.

• Google Cloud: Context Caching Overview & Gemini API Reference Guide. Google Cloud Vertex AI Documentation, 2026. Disponível em: Google Cloud Documentation.

• OpenAI: Prompt Caching Guide — OpenAI Platform API Documentation. 2026. Disponível em: OpenAI Platform Docs.