Cache KV à plusieurs niveaux pour les grands modèles de langage sur Amazon SageMaker HyperPod avec Curvine

Exécuter l'inférence de grands modèles de langage (LLM) à grande échelle impose généralement un compromis sur la mémoire cache KV : soit payer pour des instances GPU surdimensionnées afin de s'adapter à une mémoire cache croissante, soit accepter un temps de première réponse (TTFT) lent, car des invitations identiques sont recalculées à chaque requête. Pour les équipes déployant un large catalogue de modèles de base (FM) disponibles publiquement, tels que Qwen, Llama, DeepSeek, et d'autres, à travers des points de terminaison spécifiques à chaque ligne métier, des pipelines de génération augmentée par récupération (RAG), ou des applications de dialogue multi-tours, ce compromis se traduit directement par des coûts d'infrastructure plus élevés et une expérience utilisateur dégradée. La cause fondamentale est que pendant la génération, vLLM stocke les clés et valeurs d'attention pour chaque jeton dans une mémoire cache KV, et la mise en cache des préfixes réutilise cette mémoire entre les requêtes ayant des jetons initiaux communs. Sur des instances économiques comme ml.g6e.4xlarge (48 Go par GPU), la mémoire laissée pour la mise en cache des préfixes est limitée, et les taux de réussite du cache diminuent pour les invitations longues, les invitations système identiques sont re-remplies à chaque requête, et les répliques de vLLM mises à l'échelle horizontalement maintiennent des mémoires cache isolées. La solution construit une hiérarchie de cache à trois niveaux : L0 (cache de préfixes GPU), L1 (déchargement sur mémoire CPU), et L2 (pool NVMe distribué partagé via Curvine). L0 est la couche native d'attention paginée de vLLM, L1 utilise LMCache pour décharger les blocs GPU évincés vers la DRAM de l'hôte, et L2 regroupe les disques NVMe locaux dans un espace de noms partagé via Curvine, monté comme un volume PVC ReadWriteMany dans chaque pod d'inférence. Le routage intelligent d'HyperPod dirige les requêtes vers les répliques les plus susceptibles de détenir les blocs KV pertinents, avec des stratégies incluant le préfixe, la KV et le round-robin. L'effet net : seulement en cas d'échec complet le système re-remplit à partir de zéro, réduisant considérablement le TTFT pour les charges de travail avec un chevauchement d'invitations modéré à élevé. Sur un déploiement test, cela a permis d'atteindre jusqu'à 100 % de taux de réussite du cache inter-pods, une amélioration du TTFT jusqu'à 2,7 fois, et une latence de lecture L2 inter-nœuds d'environ 56 ms pour une invitation d'environ 1 900 jetons. Avec cette architecture, les charges de travail qui nécessitaient auparavant des instances P5 peuvent s'exécuter sur des instances G6e à moindre coût, réduisant ainsi le coût par point de terminaison. La mise en œuvre nécessite SageMaker HyperPod avec stockage hiérarchique activé, un cluster EKS et l'installation de l'opérateur d'inférence et de Curvine. L'article détaille cinq étapes : activation du stockage hiérarchique, installation de l'opérateur d'inférence et des dépendances, installation de Curvine, adaptation de l'opérateur d'inférence pour la couche L2 basée sur le système de fichiers, et l'analyse comparative des performances.