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é du 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 des 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 du modèle de langage (LLM) volumineux. 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 exploite 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 disposer de 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 requêtes 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 dont le taux de réussite du cache KV est le plus élevé.

  • session— Les demandes provenant d'une 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 LLM-based d'inférence v.

Configuration de la mise en cache KV et du routage intelligent

  1. Activez la mise en cache KV en réglant enableL1Cache et enableL2Cache sur. 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 se trouve pas dans le même Amazon VPC que le HyperPod 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 le enabled réglant sur true inférieurintelligentRoutingSpec. Vous pouvez spécifier la stratégie de routage à utiliserroutingStrategy. Si aucune stratégie de routage n'est spécifiée, sa 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 Undermetrics. La port valeur doit être la même que la containerPort valeur inférieuremodelInvocationPort.

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

KV-aware compatibilité du routage

La matrice de compatibilité et les contraintes de version de cette section s'appliquent uniquement à la stratégie de kvaware routage. La kvaware stratégie dirige les demandes entrantes vers l'instance d'inférence présentant 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'invocation.

Note

Si vous utilisez le kvaware routage, vous devez invocationEndpoint définir cette valeur /completions dans votre manifeste de déploiement. Le /v1/chat/completions point de terminaison n'est pas pris en charge pour 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 post2 v0.11.1
Note

Nous vous recommandons d'utiliser la version v3.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 opérateurs de cache, ce qui améliore la robustesse du routage. KV-aware

Validation du routage prenant en compte le cache KV

Après avoir déployé un modèle avec le KV-aware routage activé, procédez comme suit 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 en bonne santé 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 (retour 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 pods 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 à l'aide des métriques Grafana

Lorsque les métriques sont activées (metrics.enabled: true), les mesures suivantes provenant du /metrics terminal 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 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 de la recherche LMCache (calculé sous forme de ratio)
lmcache:request_cache_hit_rate Per-request taux de réussite du cache (histogramme)