Cache hiérarchique KV pour LLM sur Amazon SageMaker HyperPod avec Curvine
Amazon Web Services a publié une architecture technique combinant Amazon SageMaker HyperPod et un système de fichiers distribué nommé Curvine pour résoudre un problème récurrent de l'inférence de grands modèles de langage : le cache KV (clés-valeurs) devient soit trop coûteux à faire tenir sur des GPU surdimensionnés, soit source de lenteurs quand les invites identiques sont recalculées à chaque requête. La solution repose sur une hiérarchie à trois niveaux : L0 correspond au cache natif de vLLM logé dans la mémoire GPU (HBM), L1 déporte les blocs évincés vers la mémoire CPU locale via LMCache, et L2, la nouveauté, utilise Curvine comme couche partagée entre nœuds sur du stockage NVMe. Sur un déploiement de test utilisant des instances ml.g6e.4xlarge (48 Go de mémoire par GPU), cette architecture a permis d'atteindre un taux de réussite du cache inter-pods allant jusqu'à 100 %, une amélioration du délai avant premier token (TTFT) jusqu'à 2,7 fois, et une latence de lecture inter-nœuds d'environ 56 millisecondes pour une invite d'environ 1 900 tokens. Le dispositif s'appuie sur deux fonctionnalités de HyperPod, le Managed Tiered KV Cache et l'Intelligent Routing, complétées par un correctif de l'opérateur d'inférence pour prendre en charge un cache L2 basé sur système de fichiers.
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est directement financier et opérationnel pour les entreprises qui déploient de nombreux modèles de fondation publics, comme Qwen, Llama ou DeepSeek, sur des points de terminaison dédiés à différentes lignes de métier, des pipelines de génération augmentée par récupération (RAG) ou des applications de dialogue multi-tours. Sans cette architecture, chaque réplique de vLLM maintient un cache isolé : router une requête vers une autre instance équivaut à repartir de zéro, ce qui dégrade l'expérience utilisateur et gonfle les coûts d'infrastructure. Avec le cache partagé, des charges de travail qui nécessitaient auparavant des instances P5 haut de gamme peuvent désormais tourner sur des instances G6e moins chères, réduisant le coût par point de terminaison, même si les économies réelles dépendent de la taille du modèle et du profil de trafic.
Le problème vient de la mécanique même de l'inférence par attention paginée : vLLM conserve en mémoire les clés et valeurs déjà calculées pour éviter de les recalculer, et le préchargement de préfixe permet de réutiliser ce cache entre requêtes partageant un même début, comme une instruction système commune. Mais sur des GPU économiques, une fois les poids du modèle chargés, la mémoire restante pour le cache se réduit vite, en particulier avec des modèles plus volumineux ou une forte concurrence : un modèle de 32 milliards de paramètres occupe à lui seul environ 64 Go de poids, ne laissant presque plus de marge. Cette architecture s'inscrit dans l'effort plus large d'AWS pour optimiser l'infrastructure d'inférence face à la multiplication des déploiements de modèles ouverts, et pourrait inspirer des approches similaires chez d'autres fournisseurs cloud confrontés aux mêmes contraintes de coût et de latence.
Les entreprises europeennes deployant des modeles ouverts sur AWS pourraient reduire leurs couts d'infrastructure d'inference grace a cette architecture, sans qu'aucune entite francaise ou europeenne ne soit citee.