Por Que o KV Cache é o Gargalo do Serving
Rodar um modelo dense de 70B com comprimento de sequência de 128K em 256 sessões paralelas exige sozinho cerca de 1 TB de HBM apenas para o KV cache. Em modelos MoE (como Mixtral-8x22B ou a série DeepSeek-V3), o processamento é esparso graças à seleção de experts, tornando a computação leve — mas o KV cache é mantido integralmente, então a pressão de memória é equivalente ou superior à de modelos dense. O maior desafio que os times de serving enfrentam em 2026 é "como compactar o KV para manter as GPUs ocupadas", e é evidente que apenas a HBM não é suficiente. Este artigo apresenta uma visão unificada de design sobre quantização FP8, paging, offload para CPU/NVMe, RadixAttention e isolamento multi-tenant.
Trade-offs de Qualidade do KV Cache FP8
O KV FP8 (tipicamente E5M2 ou E4M3) reduz o uso de HBM pela metade em comparação ao FP16. Em 2025 ainda havia preocupações com degradação na qualidade da saída, mas em 2026 o consenso consolidado por inúmeros artigos e benchmarks internos é que "com o método de quantização adequado, a perda de qualidade fica abaixo de 0,5%". As recomendações são as seguintes.
- E5M2 (5 exp, 2 mantissa): Dynamic range mais amplo. Adequado para contextos longos e workloads multilíngues. A perda de precisão é ligeiramente maior que E4M3, mas com menos falhas do tipo alucinação.
- E4M3 (4 exp, 3 mantissa): Mais mantissa, mais preciso. Adequado para geração de código e raciocínio matemático. Activations com outliers são clipadas.
- per-channel scale + per-token shift: Quantização ciente de activations que absorve outliers. Implementada tanto no SGLang 0.4.x quanto no vLLM 0.7.x.
Nos benchmarks de qualidade da KGA (MT-Bench, HumanEval, JMMLU e 4 benchmarks internos de RAG em japonês), ao descer o KV do Llama-3.3-70B de FP16 para FP8 E5M2, a degradação no aggregate score ficou em -0,3%; no Qwen3-72B, em -0,6%. Por outro lado, o uso de HBM cai pela metade, e é possível ampliar o número de sessões simultâneas na mesma GPU em 1,8x. Para implantação em produção, a configuração inicial ideal é E5M2, com E4M3 sendo avaliado em endpoints especializados em código/matemática.
Perfil de Memória dos Modelos MoE
Os modelos MoE são frequentemente mal compreendidos pela esparsidade do roteamento, mas o KV cache é completamente materializado para todos os tokens. Na série DeepSeek-V3 (671B total, 37B ativados), os parâmetros dos experts ocupam a maior parte da HBM, mas em operações com contexto longo o KV ultrapassa e passa a dominar.
Há três pontos de design de KV específicos para MoE. Primeiro, modelos da família MLA (Multi-head Latent Attention) possuem uma representação comprimida do KV aprendida durante o treinamento, e a capacidade de KV é mais de 70% menor que a de modelos dense com parâmetros equivalentes. Isso reduz dramaticamente o custo de serving no DeepSeek-V3 e na série Qwen3-MoE. Segundo, misturar o posicionamento de experts por GPU (expert parallelism) com o posicionamento do KV cache (tensor parallelism) gera desequilíbrio de carga, fazendo o KV de algumas GPUs transbordar primeiro. É obrigatório separar corretamente EP e TP, distribuindo o KV uniformemente entre todas as GPUs. Terceiro, há tendência nos padrões hot/cold de roteamento, com experts específicos sendo ativados com mais frequência — o prefetch deve ser projetado levando em conta que o KV desses experts é acessado frequentemente.
Paging e Offload para CPU/NVMe
O PagedAttention gerencia o KV em unidades de páginas de 16 tokens, eliminando a necessidade de alocação contínua de HBM. Em 2026, a configuração de distribuir essas "páginas" pelas três camadas de HBM, memória CPU e NVMe entrou na fase de uso prático.
Offload para CPU. O KV de sessões ociosas (usuário esperando, step de agente em longa reflexão) é movido para a memória CPU. O custo de transferência PCIe na retomada é da ordem de 40 GB/s, e o KV de 128K de sequência de um modelo 70B retorna à GPU em algumas centenas de milissegundos. Use swap do vLLM, offload backend do SGLang ou LMCache.
Offload para NVMe. Sessões com idle ainda mais baixo (de minutos a horas) são descarregadas para NVMe. Com Gen5 NVMe a 12 GB/s efetivos, o custo de restauração de um KV de 128K é de 2 a 3 segundos. Para restauração após longo idle, use pipeline assíncrono em dois estágios: NVMe para CPU, depois CPU para GPU.
Política de camadas. Em casos de clientes da KGA, a heurística de cair o KV ativo nos últimos 30 segundos na HBM, de 30 segundos a 10 minutos na CPU e acima de 10 minutos na NVMe funciona bem de forma geral. Porém, em multi-tenant, é necessário definir TTLs específicos por tenant.
Benchmark: LMCache vs. SGLang RadixAttention
Benchmark realizado internamente na KGA no Q1 de 2026. Workload: RAG chat (system prompt de 1,5K, contexto recuperado de 8K, turno do usuário de média 200 tokens, média de 6 turnos multi-turn). Modelo: Qwen3-72B FP8. Hardware: 8x H200 SXM.
- vLLM prefix caching apenas: throughput agregado 2.100 tok/s, TTFT P50 210 ms, TTFT P99 720 ms, taxa de recomputação de prefill 38%.
- SGLang RadixAttention: throughput 2.650 tok/s, TTFT P50 140 ms, TTFT P99 510 ms, taxa de recomputação de prefill 17%.
- vLLM + LMCache (CPU+NVMe local): throughput 2.450 tok/s, TTFT P50 160 ms, TTFT P99 430 ms, taxa de recomputação de prefill 11%.
- vLLM + LMCache (distribuído, NVMe compartilhado): throughput 2.380 tok/s, TTFT P50 180 ms, TTFT P99 480 ms, taxa de recomputação de prefill 6%. No modo distribuído, não supera a reutilização de HBM local por nó, mas o efeito de compartilhar o cache por todo o cluster aparece no P99.
Conclusão: para nó único, SGLang RadixAttention; para cache compartilhado multi-nó, vLLM + LMCache são os dois líderes atuais. O TensorRT-LLM possui funcionalidade equivalente, mas os dois anteriores têm vantagem em flexibilidade de configuração.
Isolamento e Equidade em Multi-Tenant
Ao fazer serving multi-tenant em SaaS, a camada de KV tem quatro restrições de design.
Risco de vazamento. Quando se compartilha o mesmo system prompt não há problema, mas há a possibilidade de um "cache timing side channel" em que requisições de outro tenant acessam KV contendo dados exclusivos de um tenant. Em domínios de alta segurança como financeiro, médico e governamental, a solução prática é separar fisicamente o KV, isolando por tenant em nível de processo GPU ou grupo de GPUs.
Equidade. Com LRU simples, tenants que enviam muitas requisições monopolizam o KV, degradando o TTFT dos demais. A KGA propõe uma "política híbrida": definir quotas de KV por tenant; a parte que excede a quota segue LRU, mas em operação normal um tenant pode usar no máximo 50%.
Qualidade de serviço por SLA. É comum garantir uma reserva residente em HBM para tenants premium, enquanto tenants básicos têm prioridade de offload para CPU/NVMe. Tanto vLLM quanto SGLang possuem scheduler plugável que permite implementar políticas customizadas.
Visibilidade. Exportar via prometheus a taxa de hit de KV, taxa de eviction de KV e utilização de quota de KV por tenant e visualizá-las em dashboard conecta a cobrança ao planejamento de capacidade. No stack padrão da KGA, isso é visualizado no Grafana.
Exemplo de Configuração: vLLM + LMCache + FP8 KV
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
No lado do LMCache, aloca-se 256 GB para a camada CPU e 2 TB para a camada NVMe, com namespaces lógicos por tenant para gerenciar quotas.
Conclusão
O KV cache de 2026 não está mais na era de "simplesmente manter o máximo que cabe na HBM". É necessário que seis camadas funcionem simultaneamente: reduzir a capacidade pela metade com KV FP8, compactar estruturalmente com modelos da família MLA, eliminar fragmentação com PagedAttention, ativar o compartilhamento de prefixo com LMCache ou RadixAttention, armazenar KV de longo prazo em camadas de CPU/NVMe e proteger a qualidade de serviço com políticas de isolamento e equidade multi-tenant. Somente com tudo isso operando em conjunto é possível alcançar throughput efetivo de milhares de tok/s por nó e o SLO de TTFT P99 de 500 ms. Quem dominar o KV domina o serving de LLMs em 2026.