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 o`redis`. `tieredstorage` Si lo desea`redis`, actualice `l2CacheLocalUrl` con la URL del clúster de Redis.
```
kvCacheSpec:
enableL1Cache: true
enableL2Cache: true
l2CacheSpec:
l2CacheBackend:
l2CacheLocalUrl:
```
**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.
1. Habilite el enrutamiento inteligente `enabled` configurándolo `true` en abajo`intelligentRoutingSpec`. Puede especificar la estrategia de enrutamiento que desea utilizar`routingStrategy`. Si no se especifica ninguna estrategia de enrutamiento, el valor predeterminado es. `prefixaware`
```
intelligentRoutingSpec:
enabled: true
routingStrategy:
```
1. 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 inferior`modelInvocationPort`.
```
metrics:
enabled: true
modelMetrics:
port:
...
modelInvocationPort:
containerPort:
```
## 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:**
+ [Imagen vLLM: hub.docker. com/r/vllm/vllm-openai](https://hub.docker.com/r/vllm/vllm-openai)
+ [Imagen de LMCache: hub.docker. com/r/lmcache/vllm-openai](https://hub.docker.com/r/lmcache/vllm-openai/tags)
+ AWS [Contenedor de aprendizaje profundo: gallery.ecr. aws/deep-aprendizaje](https://gallery.ecr.aws/deep-learning-containers/vllm) - containers/vllm
| 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 | grep -i "register"
```
Un registro en buen estado muestra:
```
INFO: Worker registered: lmcacheengineconfig_
```
#### 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 | grep -i "kvaware\|Matched instance\|Lookup"
```
Cuando el KV-aware enrutamiento funciona correctamente:
```
INFO: Routing request to lmcacheengineconfig_ 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 | 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) |