Combien de mémoire réserver au cache KV ?

Décrire ce qui reste en mémoire

Pendant une génération autorégressive, les clés et valeurs des tokens déjà traités peuvent être conservées pour les étapes suivantes. Ce cache appartient aux couches d’attention. Son volume dépend donc du modèle et de l’historique conservé, pas seulement du nombre de paramètres. Le contexte d’une conversation comprend aussi les instructions, les messages précédents et les documents ajoutés par l’application.

Votre première décision est opérationnelle : combien de séquences devront rester actives, jusqu’à quelle longueur ? Une file de vingt demandes dont deux sont exécutées simultanément ne représente pas nécessairement vingt caches résidents. Relevez l’admission réelle des requêtes et les éventuelles séquences supplémentaires créées par la génération.

Préparez une fiche avec la révision du modèle, les couches d’attention, les têtes KV, la dimension des clés et valeurs, leur dtype et la stratégie de cache. Comptez les tokens après le tokenizer et le gabarit de conversation. Une limite en caractères ne décrit pas cette allocation.

Sources techniques : Hugging Face — fonctionnement et forme des caches par couche

Employer les têtes KV, notamment avec GQA

Le nombre de têtes de requête Q et celui des têtes KV peuvent différer. En attention multi-têtes classique, ils coïncident. Avec MQA, une seule tête KV est partagée ; GQA regroupe plusieurs têtes Q autour d’une tête KV. Lisez num_key_value_heads dans la configuration quand ce champ existe et vérifiez sa signification pour l’architecture.

Par exemple, quarante têtes Q et huit têtes KV forment cinq têtes Q par groupe KV. La formule du cache stocké utilise huit, pas quarante. Ce ratio ne décrit pas toute la mémoire de l’attention : des opérations ou conversions peuvent produire des temporaires.

Ne modifiez pas simplement ce nombre pour réduire le besoin mémoire d’un modèle déjà entraîné. Le schéma d’attention fait partie de son architecture. Deux modèles aux nombres de têtes différents ne deviennent pas des variantes équivalentes par un calcul de capacité ; leur qualité doit être évaluée séparément.

Sources techniques : Hugging Face — champs LlamaConfig et distinction MHA, MQA, GQA · PyTorch — dimensions Q/K/V et contraintes de l’attention GQA

Poser la formule et ses unités

Dans le cas uniforme, L est le nombre de couches, Hkv le nombre de têtes KV, D leur dimension, T le nombre de positions conservées par séquence, B le nombre de séquences et q le nombre d’octets par valeur. Le facteur deux compte K et V. Cette approximation suppose des clés et valeurs de même dimension et de même format, sans compression ni partage de préfixe.

Convertissez seulement le résultat final : un Gio vaut 1 073 741 824 octets ; un Go décimal vaut 1 000 000 000 octets. Gardez les octets dans votre fiche pour éviter qu’un arrondi ou un changement d’unité masque une différence.

Pour des longueurs différentes sans padding, remplacez B × T par la somme des positions réellement stockées. Pour des couches hétérogènes, faites une somme couche par couche. Un stockage dense avec padding, une allocation par blocs ou une réservation statique exige de compter les emplacements alloués, qui peuvent dépasser les tokens utiles.

Sources techniques : Hugging Face — dimensions des tenseurs du cache · NIST — unités décimales et préfixes binaires

Exemple travaillé : six séquences, sans mesure de GPU

Prenons une architecture fictive de quarante couches, huit têtes KV et une dimension de 128. Supposons un cache uniforme à deux octets par valeur. Chaque séquence reçoit au plus 3 072 tokens d’entrée et une réservation pour 1 024 tokens supplémentaires, soit une borne de 4 096 positions. Ce sont des hypothèses pédagogiques, pas la configuration attestée d’un modèle.

Le coût calculé par position et par séquence est 2 × 40 × 8 × 128 × 2 = 163 840 octets. Une séquence de 4 096 positions représente alors 671 088 640 octets, soit 0,625 Gio. Six séquences donnent 4 026 531 840 octets, soit 3,75 Gio pour le seul cache.

Doubler la longueur conservée double ce poste dans cette formule. Remplacer huit têtes KV par quarante le multiplie par cinq, toutes les autres hypothèses étant inchangées. Ces proportions n’annoncent aucune accélération, perte de qualité ou compatibilité d’un modèle réel.

Adapter le budget à la stratégie de cache

Un cache dynamique grandit avec les positions conservées. Un cache statique réserve une capacité maximale : dimensionnez cette réservation, pas seulement la requête courte observée au démarrage. Pour une attention à fenêtre glissante, certaines couches peuvent plafonner leur historique ; les couches à attention complète demandent un calcul distinct.

La quantification du cache et son déport vers le CPU sont d’autres stratégies, dépendantes du modèle et du logiciel. Elles modifient les contraintes de stockage, de transfert ou de calcul. Quantifier les poids ne prouve pas que le cache possède le même format.

Notez la classe de cache et ses paramètres explicites. Vérifiez aussi la libération des emplacements après la fin ou l’annulation d’une requête. Pour une charge mêlant séquences courtes et longues, une réservation maximale uniforme peut peser davantage que la seule somme des contenus utiles.

Sources techniques : Hugging Face — caches dynamiques, statiques, quantifiés et déportés

Vérifier une charge représentative par étapes

Construisez trois cas : entrée habituelle, entrée longue attendue et nombre maximal de requêtes simultanées autorisé. Fixez modèle, tokenizer, gabarit, limite de génération et règle de fin. Faites varier une dimension à la fois ; une réponse écourtée ou un document tronqué change le travail fourni.

Relevez séparément chargement, traitement initial de l’entrée et génération. Synchronisez le device autour des phases chronométrées, conservez les niveaux mémoire de départ et les pics. La méthode mémoire explique pourquoi allocated et reserved ne s’additionnent pas et pourquoi la différence de leurs maxima n’isole pas le cache.

Votre contrôle doit aboutir à une borne testée et à des sorties acceptables : IDs des requêtes terminées, erreurs, longueur produite et critère de qualité. Un lancement qui tient sur une entrée courte ne valide pas la concurrence maximale. Une erreur mémoire avant la fin ne constitue pas une mesure du besoin d’une exécution complète.

Sources techniques : PyTorch — synchronisation du travail sur le device choisi · PyTorch — périmètre des compteurs mémoire

Écarter les erreurs qui faussent le choix

Ne transformez pas le cache calculé en capacité GPU totale. Ajoutez une analyse des poids, des activations temporaires, des sorties conservées et du logiciel. Ne divisez pas non plus ce volume automatiquement par le nombre de cartes : le placement des couches ou des têtes doit être réellement configuré et vérifié sur chaque device.

Le notebook IteraGPU Lab est un exercice d’instrumentation sur un petit réseau dense sans attention. Il aide à lire des phases mémoire ; son paramètre context ne valide pas ce calcul KV. Utilisez la fiche de charge et le dossier inférence pour préparer l’essai de votre propre modèle.

Comparez les capacités des offres seulement après avoir distingué le volume arithmétique, le maximum réellement observé et les cas encore non testés. Le forfait de location organise votre fenêtre de travail ; il ne garantit aucune longueur de contexte ni cadence de génération.

• Confondre têtes Q et têtes KV : reprendre la configuration de l’architecture.
• Budgéter seulement le prompt : intégrer la génération et la réservation effective.
• Lire « poids 4 bits » comme « cache 4 bits » : relever les deux formats.
• Oublier la concurrence : compter les séquences réellement résidentes.
• Promettre une mémoire commune entre cartes : vérifier le placement réel.

Questions pratiques