Cache KV em camadas: como reduzir latência de LLMs em instâncias menores na AWS

O trade-off do cache KV em escala

Inferência de LLMs em escala costuma forçar uma escolha difícil: ou você paga por instâncias de GPU maiores para acomodar um cache KV crescente, ou aceita um time-to-first-token (TTFT) lento porque prompts idênticos são recomputados a cada requisição. O cache KV guarda as chaves e valores de atenção de cada token já processado, evitando recálculo; o prefix caching reaproveita esse cache entre requisições que compartilham tokens iniciais (como um system prompt comum). O problema: em instâncias econômicas como a ml.g6e.4xlarge (48 GB por GPU), a memória que sobra para prefix caching é limitada, e réplicas escaladas horizontalmente mantêm caches isolados — rotear para outra réplica é, na prática, um cold start.

A solução: cache KV em camadas

O artigo descreve uma arquitetura de cache KV em três camadas no Amazon SageMaker HyperPod, que estende a hierarquia para além da GPU e da CPU até um pool de NVMe distribuído e compartilhado:

• L0 (GPU HBM): o prefix cache nativo do vLLM, mantendo os blocos mais quentes na menor latência — mas limitado à memória que sobra após os pesos do modelo.
• L1 (memória CPU do host): o LMCache captura blocos expulsos da GPU na DRAM do host, como rede de segurança.
• L2 (NVMe compartilhado via Curvine): um filesystem de cache distribuído que agrupa os NVMe locais das instâncias G6e/P5 em um único namespace montado como ReadWriteMany, permitindo que um bloco KV escrito por uma réplica seja lido imediatamente por outra.

Sobre isso, o roteamento inteligente do HyperPod (prefix-aware ou kv-aware) direciona cada requisição para a réplica com maior probabilidade de acerto de cache, sem mudanças no lado do cliente.

Resultados medidos

Nos testes, a arquitetura alcançou até 100% de taxa de acerto entre Pods, melhoria de até 2,7x no TTFT e latência de leitura L2 entre nós de cerca de 56 ms para um prompt de ~1.900 tokens. Um prompt que em uma réplica fria levaria 774 ms foi concluído em 287 ms (2,7x). Em diálogo multi-turno, a latência total caiu de 4,21 s para 3,25 s (1,30x). A conclusão prática: cargas que antes exigiam instâncias P5 podem rodar em instâncias G6e mais baratas, reduzindo o custo por endpoint.

Quando compensa

Os números mostram que o L2 vale a pena acima de ~1.000 tokens de prompt (abaixo disso, o custo de ida e volta ao L2 é parecido com recomputar o prefill, e o ideal é acertar em L0/L1). O ganho cresce até ~2.500 tokens e depois desacelera. Para workloads com sobreposição moderada a alta de prompts (RAG que reutiliza contexto, diálogo multi-turno, tenants compartilhando template de system prompt), a economia de TTFT e de infraestrutura é substancial.