Phase 17 - Lesson 18

Stack de Produção vLLM com Descarregamento de KV LMCache

A stack de produção do vLLM (production-stack) é a implantação de referência no Kubernetes — conectando roteador, engines e observabilidade. O LMCache é a camada de descarregamento (offloading) de KV que extrai o cache KV da memória da GPU e o reutiliza em diferentes consultas e engines (CPU DRAM e, em seguida, disco/Ceph). O Conector de Descarregamento de KV do vLLM 0.11.0 (janeiro de 2026) torna esse processo assíncrono e plugável por meio da API de Conectores (v0.9.0+). A latência do descarregamento não é voltada para o usuário. O LMCache é valioso mesmo sem prefixos compartilhados — quando uma GPU fica sem slots de KV, as requisições preemptadas podem ser restauradas a partir da CPU em vez de recalcular o prefill. Benchmarks publicados em 16x H100 (80GB HBM) distribuídos em 4 instâncias a3-highgpu-4g mostram que: quando o cache KV excede a HBM, tanto o descarregamento nativo para CPU quanto o LMCache melhoram substancialmente o throughput; com um consumo baixo de KV, todas as configurações se equiparam ao baseline com um pequeno overhead.

Type: Learn Languages: Python (stdlib, simulador simples de descarte de KV/KV-spill) Prerequisites: Phase 17 · 04 (vLLM Serving Internals), Phase 17 · 06 (SGLang/RadixAttention) Time: ~60 minutos

Objetivos de Aprendizado

• Diagramar as camadas da stack de produção do vLLM: roteador, engines, descarregamento de KV, observabilidade.
• Explicar a API de Conectores para Descarregamento de KV (v0.9.0+) e como o caminho assíncrono da versão 0.11.0 oculta a latência de descarregamento.
• Quantificar quando o LMCache CPU-DRAM ajuda (KV > HBM) vs quando adiciona overhead (KV pequeno o suficiente para caber na HBM).
• Escolher entre o descarregamento de CPU nativo do vLLM e o conector LMCache dadas as restrições de implantação.

O Problema

Seu serviço vLLM mostra GPUs com 100% de uso de HBM com eventos de preempção sempre que a concorrência aumenta. As requisições são despejadas, colocadas novamente na fila e você recalcula (re-prefill) o mesmo prompt de 2K tokens quatro vezes em um minuto. A computação da GPU é gasta em prefills redundantes; o throughput útil (goodput) fica bem abaixo do throughput bruto.

Adicionar mais GPUs custa linearmente. Adicionar mais HBM não é possível. No entanto, a CPU DRAM é barata — um socket possui mais de 512 GB com latência ordens de grandeza pior do que a HBM, mas aceitável para cache KV "temporariamente quente".

O LMCache extrai o cache KV para a CPU DRAM de modo que requisições preemptadas se recuperem rapidamente, e prefixos repetidos entre engines compartilhem o cache sem que cada engine recalcule o prefill.

O Conceito

Stack de produção vLLM

github.com/vllm-project/production-stack é a implantação de referência no Kubernetes:

• Roteador — ciente do cache (Fase 17 · 11). Consome eventos de KV.
• Engines — workers do vLLM. Um por GPU ou por grupo TP/PP.
• Descarregamento de cache KV — implantação do LMCache ou conector nativo.
• Observabilidade — coleta do Prometheus, painéis do Grafana, rastros do OTel.
• Plano de controle — descoberta de serviços, configurações, atualizações contínuas (rolling updates).

Distribuído como Helm chart + operador.

A API de Conectores para Descarregamento de KV (v0.9.0+)

O vLLM 0.9.0 introduziu uma API de Conectores para backends de cache KV plugáveis. Seu engine descarrega blocos para o conector; o conector os armazena (RAM, disco, armazenamento de objetos, LMCache). Quando uma requisição precisa de um bloco, o conector o carrega de volta.

O vLLM 0.11.0 (janeiro de 2026) adiciona um caminho de descarregamento assíncrono — o descarregamento pode ocorrer em segundo plano para que o engine não seja bloqueado no caso comum. A latência de ponta a ponta e o throughput ainda dependem do formato da carga de trabalho, da taxa de acerto do cache KV e da pressão do sistema; as notas do próprio vLLM alertam que o descarregamento com kernel customizado pode degradar o throughput em taxas de acerto baixas e que o agendamento assíncrono possui problemas conhecidos de interação com decodificação especulativa.

Descarregamento nativo para CPU vs LMCache

Descarregamento nativo para CPU do vLLM: local ao engine. Armazena blocos KV na memória RAM do host. Rápido de implementar, sem saltos de rede (network hops). Não cruza entre diferentes engines.

Conector LMCache: em escala de cluster. Armazena blocos em um servidor LMCache compartilhado (CPU DRAM + camada Ceph/S3). Os blocos são acessíveis por qualquer engine. Benchmarks em 16x H100 publicados.

Escolha o nativo quando um único engine tiver pressão de HBM. Escolha o LMCache quando múltiplos engines compartilharem prefixos (RAG com prompts de sistema comuns, multi-tenant com templates compartilhados).

Comportamento em benchmarks

O teste com 16x H100 (80 GB HBM) distribuídos em 4 instâncias a3-highgpu-4g:

• Baixo consumo de KV (prompts curtos, baixa concorrência): todas as configurações se equiparam ao baseline, com LMCache adicionando ~3-5% de overhead.
• Consumo moderado: o LMCache começa a ajudar no reuso de prefixos entre engines.
• KV excede a HBM: o descarregamento nativo para CPU e o LMCache melhoram substancialmente o throughput; o LMCache apresenta maior ganho devido ao compartilhamento entre engines.

Quando o LMCache é decisivo

• Serviços multi-tenant nos quais os prompts do sistema são compartilhados entre os tenants.
• RAG nos quais blocos de documentos (document chunks) se repetem nas consultas.
• Variantes ajustadas (LoRA) na mesma base, nas quais o reuso de KV do modelo base reduz o trabalho redundante.
• Cargas de trabalho com muita preempção: restaurar da CPU é mais barato do que recalcular o prefill.

Quando NÃO ativar

• Pouca pressão de HBM — você paga o overhead sem obter benefícios.
• Contextos curtos (<1K tokens) — tempo de transferência > recalcular o prefill.
• Cargas de trabalho de tenant único com prompt único — não há reuso para capturar.

Integração com o serviço desagregado

O serviço desagregado da Fase 17 · 17 se complementa com o LMCache: as transferências de KV do pool de prefill para o pool de decode são enviadas para o LMCache se não forem utilizadas; as consultas subsequentes as recuperam do LMCache. O roteador ciente de cache da Fase 17 · 11 pode rotear para o engine cuja correspondência de cache seja local OU compartilhada via LMCache.

Números que você deve lembrar

Os números dos benchmarks variam — a NVIDIA e a stack de inferência postam resultados atualizados a cada trimestre. Verifique novamente antes de citar.

• vLLM 0.9.0: API de Conectores lançada.
• vLLM 0.11.0 (Jan 2026): caminho de descarregamento assíncrono; o impacto na latência de ponta a ponta depende da carga de trabalho, da taxa de acerto do KV e da pressão do sistema (não é uma garantia absoluta).
• Benchmark de 16x H100: o LMCache ajuda quando o consumo de KV excede a HBM.
• Pouca pressão de HBM: 3-5% de overhead sem benefícios.

Use

code/main.py simula uma carga de trabalho com muita preempção com e sem LMCache. Relata os prefills evitados, o ganho de throughput e a utilização mínima de HBM para compensar o uso.

Coloque em Produção

Esta lição produz outputs/skill-vllm-stack-decider.md. Dado o formato da carga de trabalho e a implantação do vLLM, decide entre nativo, LMCache ou nenhum.

Exercícios

1. Execute code/main.py. Em qual nível de utilização de HBM o LMCache começa a compensar?
2. Um tenant compartilha um prompt de sistema de 6K tokens em 200 consultas/hora. Calcule a economia esperada com o LMCache por tenant.
3. O servidor LMCache é um ponto único de falha. Projete a estratégia de alta disponibilidade (réplicas, fallback para nativo).
4. O LMCache armazena no Ceph em discos rígidos tradicionais. Para um KV de 4K tokens no 70B FP8 (~500 MB), qual é o tempo de leitura versus o recalculo de prefill?
5. Discuta se o caminho assíncrono do vLLM 0.11.0 é "gratuito" — onde se esconde o overhead?

Termos-Chave

Leituras Adicionais

• vLLM Blog — KV Offloading Connector (Jan 2026)
• vLLM Production Stack GitHub — Helm chart + operador.
• LMCache for Enterprise-Scale LLM Inference (arXiv:2510.09665)
• LMCache GitHub — Conector de implementação.
• vLLM 0.11.0 release notes — detalhes do caminho assíncrono.