View a markdown version of this page

Almacenamiento en caché KV y enrutamiento inteligente - Amazon SageMaker AI
Configure el almacenamiento en caché KV y el enrutamiento inteligenteKV-aware compatibilidad de enrutamiento

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Almacenamiento en caché KV y enrutamiento inteligente

Amazon SageMaker HyperPod Inference proporciona almacenamiento en caché de valores clave (KV) por niveles gestionado y enrutamiento inteligente para optimizar el rendimiento de la inferencia para cargas de trabajo de modelos de lenguaje (LLM) de gran tamaño. El almacenamiento en caché KV guarda los vectores clave-valor precalculados después de procesar los tokens anteriores, lo que elimina los recálculos redundantes. Mediante una arquitectura de almacenamiento en caché de dos niveles, puede configurar una caché de nivel 1 que utilice la memoria de la CPU para una reutilización local de baja latencia y una caché de nivel 2 que utilice Redis o el almacenamiento en niveles gestionado para permitir el uso compartido de la caché a nivel de nodo de forma escalable.

El enrutamiento inteligente analiza las solicitudes entrantes y las dirige a la instancia de inferencia que tiene más probabilidades de tener los pares clave-valor relevantes almacenados en caché. El sistema examina la solicitud y la enruta en función de una de las siguientes estrategias de enrutamiento:

  • prefixaware— Las solicitudes posteriores con el mismo prefijo de solicitud se envían a la misma instancia.

  • kvaware— Las solicitudes entrantes se envían a la instancia con la tasa de aciertos de caché de KV más alta.

  • session— Las solicitudes de la misma sesión de usuario se envían a la misma instancia.

  • roundrobin— Distribuye las solicitudes de manera uniforme sin tener en cuenta el estado de la memoria caché KV.

El enrutamiento inteligente funciona con todos los métodos de despliegue de Amazon SageMaker HyperPod Inference, incluidos los SageMaker JumpStart despliegues de Amazon (tanto de consola como de kubectl), los despliegues de almacenamiento local de NVMe y los despliegues de Amazon S3, Amazon FSx o Hugging Face Hub. Puede habilitar el almacenamiento en caché y el enrutamiento independientemente del método de implementación que utilice para gestionar su modelo.

nota

El almacenamiento en caché de KV y el enrutamiento inteligente actualmente solo admiten contenedores de inferencia vLLM-based .

Configure el almacenamiento en caché KV y el enrutamiento inteligente

  1. Habilite el almacenamiento en caché de KV configurando y para. enableL1Cache enableL2Cache true A continuación, l2CacheSpec configúrelo configurando l2CacheBackend entre oredis. tieredstorage Si lo desearedis, actualice l2CacheLocalUrl con la URL del clúster de Redis.

      kvCacheSpec:
    enableL1Cache: true
    enableL2Cache: true
    l2CacheSpec:
      l2CacheBackend: <redis | tieredstorage>
      l2CacheLocalUrl: <Redis cluster URL if l2CacheBackend is redis >
    nota

    Si el clúster de Redis no está dentro de la misma Amazon VPC que HyperPod el clúster, no se garantiza el cifrado de los datos en tránsito.

    nota

    No es necesario l2CacheLocalUrl si tieredstorage está seleccionado.

  2. Habilite el enrutamiento inteligente enabled configurándolo true en abajointelligentRoutingSpec. Puede especificar la estrategia de enrutamiento que desea utilizarroutingStrategy. Si no se especifica ninguna estrategia de enrutamiento, el valor predeterminado es. prefixaware

    intelligentRoutingSpec:
    enabled: true
    routingStrategy: <routing strategy to use>

  3. Habilite las métricas del router y las métricas de almacenamiento en caché enabled configurándolas en debajo. true metrics El port valor debe ser el mismo que el containerPort valor inferiormodelInvocationPort.

    metrics:
    enabled: true
    modelMetrics:
      port: <port value>
    ...
    modelInvocationPort:
      containerPort: <port value>

KV-aware compatibilidad de enrutamiento

La matriz de compatibilidad y las restricciones de versión de esta sección se aplican únicamente a la estrategia de kvaware enrutamiento. La kvaware estrategia dirige las solicitudes entrantes a la instancia de inferencia con la tasa de aciertos de caché de KV más alta y, actualmente, solo admite LLM-based imágenes v con la /completions API como punto final de invocación.

nota

Si utilizas el kvaware enrutamiento, debes configurarlo /completions en tu invocationEndpoint manifiesto de implementación. El /v1/chat/completions punto final no es compatible con el kvaware enrutamiento. Otras estrategias de enrutamiento (prefixaware,session,roundrobin) funcionan con cualquier punto final de invocación.

Imágenes compatibles:

Versión de operador de inferencia Add-on Versión Amazon EKS Versión de imagen de LMCache Versión de imagen vLLM
>= v3.1.3 >= v1.2.1-eksbuild.1 >= v0.4.3 >= v0.19.1
< v3.1.3 < v1.2.1-eksbuild.1 v0.3.9 post2 v0.11.1
nota

Se recomienda utilizar la versión 3.1.3 o superior del operador de inferencia con las versiones LMCache y vLLM correspondientes que se muestran en la matriz de soporte. Las versiones más recientes de LMCache admiten el paralelismo tensorial, una mejor gestión de los errores y el registro de los trabajadores de la memoria caché, lo que proporciona una mayor solidez al enrutamiento. KV-aware

Validación del enrutamiento compatible con la memoria caché de KV

Después de implementar un modelo con el KV-aware enrutamiento habilitado, siga los siguientes pasos para verificar que el enrutamiento funcione correctamente.

Compruebe el registro de los trabajadores

Verifique que los trabajadores se hayan registrado en el router consultando los registros del router:

kubectl logs -n hyperpod-inference-system <router-pod> | grep -i "register"

Un registro en buen estado muestra:

INFO: Worker registered: lmcacheengineconfig_<hash>

Compruebe las visitas a la caché en los registros del router

Verifique que el router utilice el KV-aware enrutamiento para dirigir las solicitudes:

kubectl logs -n hyperpod-inference-system <router-pod> | grep -i "kvaware\|Matched instance\|Lookup"

Cuando el KV-aware enrutamiento funciona correctamente:

INFO: Routing request to lmcacheengineconfig_<hash> found by kvaware router

Cuando el KV-aware enrutamiento no funciona (se recurre al método de todos contra todos):

DEBUG: Matched instance url None

Compruebe la inicialización de LMCache en los registros de trabajo

Compruebe que LMCache se haya inicializado correctamente en los módulos de trabajo:

kubectl logs -n <namespace> <worker-pod> | grep -i "LMCache"

Una inicialización correcta muestra:

LMCache INFO: LMCacheManager initialized successfully

Si LMCache no se pudo inicializar, verá lo siguiente:

LMCache ERROR: Failed to initialize LMCacheManager components: . System will operate in degraded mode (recompute).

Verifica con las métricas de Grafana

Con las métricas habilitadas (metrics.enabled: true), las siguientes métricas del /metrics punto final de trabajo de vLLM confirman las visitas a la caché. Estas métricas deberían mostrar valores altos cuando el KV-aware enrutamiento funcione correctamente:

Métrica Description (Descripción)
vllm:prefix_cache_hits_total / vllm:prefix_cache_queries_total Tasa de aciertos de la caché de prefijos de la GPU (calculada como una proporción)
lmcache:num_vllm_hit_tokens_total Número de fichas servidas desde LMCache
lmcache:num_lookup_hits_total / lmcache:num_lookup_tokens_total Tasa de aciertos de búsqueda en LMCache (calculada como una proporción)
lmcache:request_cache_hit_rate Per-request tasa de aciertos de caché (histograma)