Caché KV por niveles para LLMs grandes en Amazon SageMaker HyperPod con Curvine

Ejecutar inferencia de modelos de lenguaje grandes (LLM) a escala normalmente obliga a un compromiso con la caché KV: o se paga por instancias de GPU sobredimensionadas para acomodar una caché KV en crecimiento, o se acepta un tiempo lento hasta el primer token (TTFT) porque las indicaciones idénticas se recalculan en cada solicitud. Para equipos que despliegan un amplio catálogo de modelos fundacionales (FM) disponibles públicamente, como Qwen, Llama, DeepSeek y otros, en puntos de conexión por línea de negocio, canalizaciones de generación aumentada por recuperación (RAG) o aplicaciones de diálogo de múltiples turnos, este compromiso se traduce directamente en mayores costos de infraestructura y una experiencia de usuario degradada. La causa raíz es que durante la generación, vLLM almacena las claves y valores de atención de cada token en una caché KV, y el almacenamiento en caché de prefijos reutiliza esa caché entre solicitudes que comparten tokens iniciales. En instancias rentables como ml.g6e.4xlarge (48 GB por GPU), la memoria disponible para el almacenamiento en caché de prefijos es limitada, y las tasas de acierto de caché caen en indicaciones largas; las indicaciones de sistema idénticas se vuelven a preprocesar en cada solicitud, y las réplicas de vLLM escaladas horizontalmente mantienen cachés aisladas. La solución construye una jerarquía de caché de tres niveles: L0 (caché de prefijos en GPU), L1 (descarga a memoria de CPU) y L2 (grupo distribuido de NVMe compartido mediante Curvine). L0 es la capa nativa de atención paginada de vLLM, L1 utiliza LMCache para descargar bloques de GPU expulsados a la DRAM del host, y L2 agrupa unidades NVMe locales en un espacio de nombres compartido mediante Curvine, montado como un PVC ReadWriteMany en cada Pod de inferencia. El enrutamiento inteligente de HyperPod dirige las solicitudes a las réplicas con mayor probabilidad de tener los bloques KV relevantes, con estrategias que incluyen consciente de prefijo, consciente de KV y round-robin. El efecto neto: solo en un fallo total el sistema vuelve a preprocesar desde cero, lo que reduce sustancialmente el TTFT para cargas de trabajo con solapamiento de indicaciones de moderado a alto. En un despliegue de prueba, esto logró hasta un 100% de tasa de acierto de caché entre Pods, una mejora del TTFT de hasta 2,7 veces, y una latencia de lectura L2 entre nodos de aproximadamente 56 ms para una indicación de ~1.900 tokens. Con esta arquitectura, las cargas de trabajo que anteriormente requerían instancias P5 pueden ejecutarse en instancias G6e de menor costo, reduciendo el costo por punto de conexión. La implementación requiere SageMaker HyperPod con almacenamiento en niveles habilitado, un clúster EKS e instalación del Operador de Inferencia y Curvine. La publicación explica cinco etapas: habilitar el almacenamiento en niveles, instalar el Operador de Inferencia y las dependencias, instalar Curvine, parchear el Operador de Inferencia para el respaldo L2 basado en sistema de archivos y realizar pruebas comparativas.