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édigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
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 européennes déployant des modèles ouverts sur AWS pourraient réduire leurs couts d'infrastructure d'inférence grâce a cette architecture, sans qu'aucune entité française ou européenne ne soit citée.
Le vrai enjeu ici c'est pas la perf brute, c'est le routing. Avant, dès qu'une requête tombait sur une autre instance vLLM que la précédente, tout le préfixe calculé partait à la poubelle : t'étais coincé à sur-dimensionner tes GPU juste pour éviter ça. Avec un cache partagé façon Curvine, tu peux enfin router sans perdre le boulot déjà fait, et faire tourner du 32B sur du G6e au lieu du P5. Reste à voir si ça tient avec du vrai trafic de prod et pas juste un benchmark maison chez AWS.