View a markdown version of this page

Mise en cache KV et routage intelligent - Amazon SageMaker AI
Configuration de la mise en cache KV et du routage intelligentKV-aware compatibilité de routage

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mise en cache KV et routage intelligent

Amazon SageMaker HyperPod Inference fournit une mise en cache de valeurs-clés (KV) hiérarchisée gérée et un routage intelligent afin d'optimiser les performances d'inférence pour les charges de travail de grands modèles linguistiques (LLM). La mise en cache KV enregistre les vecteurs clé-valeur précalculés après le traitement des jetons précédents, éliminant ainsi les recalculs redondants. Grâce à une architecture de mise en cache à deux niveaux, vous pouvez configurer un cache L1 qui utilise la mémoire du processeur pour une réutilisation locale à faible latence, et un cache L2 qui utilise Redis ou un stockage hiérarchisé géré pour permettre un partage de cache évolutif au niveau des nœuds.

Le routage intelligent analyse les demandes entrantes et les dirige vers l'instance d'inférence la plus susceptible de contenir les paires clé-valeur mises en cache pertinentes. Le système examine la demande et l'achemine selon l'une des stratégies de routage suivantes :

  • prefixaware— Les demandes suivantes avec le même préfixe d'invite sont acheminées vers la même instance.

  • kvaware— Les demandes entrantes sont acheminées vers l'instance ayant le taux de réussite du cache KV le plus élevé.

  • session— Les demandes provenant de la même session utilisateur sont acheminées vers la même instance.

  • roundrobin— Répartit les demandes de manière uniforme sans tenir compte de l'état du cache KV.

Le routage intelligent fonctionne avec toutes les méthodes de déploiement Amazon SageMaker HyperPod Inference, y compris les SageMaker JumpStart déploiements Amazon (console et kubectl), les déploiements de stockage local NVMe et les déploiements depuis Amazon S3, Amazon FSx ou Hugging Face Hub. Vous pouvez activer la mise en cache et le routage quelle que soit la méthode de déploiement que vous utilisez pour servir votre modèle.

Note

La mise en cache KV et le routage intelligent ne prennent actuellement en charge que les conteneurs d'inférence LLM-based v.

Configuration de la mise en cache KV et du routage intelligent

  1. Activez la mise en cache KV en configurant enableL1Cache et en. enableL2Cache true Ensuite, configurez l2CacheSpec en l2CacheBackend réglant sur redis outieredstorage. Si vous le souhaitezredis, effectuez la mise à jour l2CacheLocalUrl avec l'URL du cluster Redis.

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

    Si le cluster Redis ne fait pas partie du même Amazon VPC que HyperPod le cluster, le chiffrement des données en transit n'est pas garanti.

    Note

    Vous n'avez pas besoin tieredstorage qu'l2CacheLocalUrlil soit sélectionné.

  2. Activez le routage intelligent en enabled réglant sur true moinsintelligentRoutingSpec. Vous pouvez spécifier la stratégie de routage à utiliser dans le cadre de cette sectionroutingStrategy. Si aucune stratégie de routage n'est spécifiée, la valeur par défaut est. prefixaware

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

  3. Activez les métriques du routeur et les métriques de mise en cache en réglant enabled sur true moinsmetrics. La port valeur doit être identique à la containerPort valeur inférieuremodelInvocationPort.

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

KV-aware compatibilité de routage

La matrice de compatibilité et les contraintes de version de cette section s'appliquent uniquement à la stratégie kvaware de routage. La kvaware stratégie dirige les demandes entrantes vers l'instance d'inférence ayant le taux de réussite du cache KV le plus élevé et ne prend actuellement en charge que les LLM-based images v avec l'/completionsAPI comme point de terminaison d'appel.

Note

Si vous utilisez kvaware le routage, vous devez le invocationEndpoint définir /completions dans votre manifeste de déploiement. Le /v1/chat/completions point de terminaison n'est pas compatible avec kvaware le routage. Les autres stratégies de routage (prefixaware,session,roundrobin) fonctionnent avec n'importe quel point de terminaison d'invocation.

Images prises en charge :

Version de l'opérateur d'inférence Add-on Version d'Amazon EKS Version de l'image LMCache Version de l'image 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 post 2 v0.11.1
Note

Nous recommandons d'utiliser la version 3.1.3 ou supérieure de l'opérateur d'inférence avec les versions LMCache et vLLM correspondantes indiquées dans la matrice de support. Les nouvelles versions de LMCache prennent en charge le parallélisme des tenseurs, une meilleure gestion des défaillances et l'enregistrement des agents de cache, ce qui améliore la robustesse du routage. KV-aware

Validation du routage compatible avec le cache KV

Après avoir déployé un modèle avec le KV-aware routage activé, suivez les étapes ci-dessous pour vérifier que le routage fonctionne correctement.

Vérifiez l'enregistrement des travailleurs

Vérifiez que les employés se sont enregistrés auprès du routeur en consultant les journaux du routeur :

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

Un enregistrement sain montre que :

INFO: Worker registered: lmcacheengineconfig_<hash>

Vérifiez les accès au cache dans les journaux du routeur

Vérifiez que le routeur utilise le KV-aware routage pour diriger les demandes :

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

Lorsque KV-aware le routage fonctionne correctement :

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

Lorsque KV-aware le routage ne fonctionne pas (revient au round-robin) :

DEBUG: Matched instance url None

Vérifiez l'initialisation de LMCache dans les journaux de travail

Vérifiez que LMCache s'est correctement initialisé sur les modules de travail :

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

Une initialisation saine indique :

LMCache INFO: LMCacheManager initialized successfully

Si LMCache n'a pas réussi à s'initialiser, vous verrez :

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

Vérifiez avec les métriques de Grafana

Lorsque les métriques sont activées (metrics.enabled: true), les métriques suivantes provenant du point de /metrics terminaison de travail vLLM confirment les accès au cache. Ces métriques doivent afficher des valeurs élevées lorsque KV-aware le routage fonctionne correctement :

Métrique Description
vllm:prefix_cache_hits_total / vllm:prefix_cache_queries_total Taux de réussite du cache du préfixe du GPU (calculé sous forme de ratio)
lmcache:num_vllm_hit_tokens_total Nombre de jetons servis depuis LMCache
lmcache:num_lookup_hits_total / lmcache:num_lookup_tokens_total Taux de réussite des recherches LMCache (calculé sous forme de ratio)
lmcache:request_cache_hit_rate Per-request taux de réussite du cache (histogramme)