Cache KV em Camadas para Grandes LLMs no Amazon SageMaker HyperPod com Curvine

Executar inferência de modelo de linguagem grande (LLM) em escala normalmente força uma troca no cache KV: ou pagar por instâncias de GPU superdimensionadas para acomodar um cache KV crescente, ou aceitar um tempo lento até o primeiro token (TTFT) à medida que prompts idênticos são recomputados em cada requisição. Para equipes que implantam um amplo catálogo de modelos de fundação (FMs) publicamente disponíveis, como Qwen, Llama, DeepSeek e outros, em endpoints por linha de negócios, pipelines de Geração Aumentada por Recuperação (RAG) ou aplicações de diálogo multi-turno, essa troca se traduz diretamente em maior custo de infraestrutura e experiência de usuário degradada. A causa raiz é que, durante a geração, o vLLM armazena chaves e valores de atenção para cada token em um cache KV, e o cache de prefixo reutiliza esse cache entre requisições com tokens iniciais compartilhados. Em instâncias econômicas como ml.g6e.4xlarge (48 GB por GPU), a memória disponível para cache de prefixo é limitada, e as taxas de acerto de cache caem em prompts longos; prompts de sistema idênticos são pré-preenchidos em cada requisição, e réplicas vLLM escaladas horizontalmente mantêm caches isolados. A solução constrói uma hierarquia de cache de três níveis: L0 (cache de prefixo na GPU), L1 (offload de memória da CPU) e L2 (pool compartilhado distribuído de NVMe via Curvine). L0 é a camada nativa de paged-attention do vLLM, L1 usa LMCache para transferir blocos de GPU despejados para a DRAM do host, e L2 agrupa drives NVMe locais em um namespace compartilhado via Curvine, montado como um PVC ReadWriteMany em cada Pod de inferência. O Roteamento Inteligente do HyperPod direciona requisições para réplicas com maior probabilidade de ter blocos KV relevantes, com estratégias como prefixo-aware, kv-aware e round-robin. O efeito líquido: apenas em uma falha completa o sistema recomeça o pré-preenchimento do zero, reduzindo substancialmente o TTFT para cargas de trabalho com sobreposição de prompts moderada a alta. Em uma implantação de teste, isso alcançou até 100% de taxa de acerto de cache 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. Com essa arquitetura, cargas de trabalho que anteriormente exigiam instâncias P5 podem ser executadas em instâncias G6e de menor custo, reduzindo o custo por endpoint. A implementação requer SageMaker HyperPod com Armazenamento em Camadas habilitado, um cluster EKS e a instalação do Inference Operator e do Curvine. O post percorre cinco etapas: habilitar o Armazenamento em Camadas, instalar o Inference Operator e dependências, instalar o Curvine, ajustar o Inference Operator para L2 com backend de sistema de arquivos e realizar benchmarking.