Session systèmes 3/4 · Guide formateur

Dimensionnement et optimisation du cache KV

Objectifs pédagogiques

  1. Expliquer ce que stocke le cache clé-valeur, pourquoi il supprime du travail d’attention redondant pendant le décodage, et pourquoi il croît à la fois avec la longueur de contexte et avec la concurrence.
  2. Appliquer l’estimation 2 x couches x têtes KV x dimension de tête x tokens en cache x octets par élément à une architecture donnée, puis la multiplier par le nombre de séquences actives.
  3. Prédire la conséquence mémoire d’un doublement du contexte actif ou d’un doublement de la concurrence sous cette estimation linéaire, et nommer les endroits où l’estimation cesse d’être linéaire.
  4. Comparer le contexte borné, le regroupement délibéré des requêtes, l’attention GQA/MQA, la pagination des blocs de cache, la réutilisation vérifiée de préfixes et la précision réduite du cache comme des leviers distincts aux coûts distincts.
  5. Distinguer le cache de prompt d’un fournisseur du cache KV d’exécution d’une requête unique, et énoncer les règles d’éligibilité et de persistance qui régissent chacun.
  6. Choisir les mesures de service qui révèlent la pression sur le cache : temps jusqu’au premier token, latence inter-tokens, débit de sortie, occupation du cache, taux d’éviction et de recalcul, latences p50/p95.
  7. Concevoir un test de charge dont la distribution des longueurs de contexte et le niveau de concurrence correspondent au trafic de production qu’il prétend prédire.

Matériel nécessaire

Déroulé minute par minute

HeureDuréeSéquence
0:0010 minCadrage : pourquoi le deuxième token coûte moins cher que le premier, et ce que cela coûte en mémoire.
0:1020 minConcept 1 : ce que contient le cache KV. Schéma au tableau par token, par séquence, par déploiement.
0:3025 minAtelier A : appliquer la formule de dimensionnement à trois architectures et construire le tableau contexte x concurrence.
0:555 minPause.
1:0010 minDébriefing de l’atelier A : où l’estimation linéaire tient, et où elle se rompt discrètement.
1:1020 minConcept 2 : les leviers — contexte borné, regroupement des requêtes, GQA/MQA, attention paginée, réutilisation de préfixes, précision du cache.
1:3015 minAtelier B : choisir et ordonner les leviers pour un déploiement qui ne tient plus en mémoire.
1:4510 minConcept 3 : mesurer le service. Premier token, latence inter-tokens, occupation, éviction et recalcul, p50/p95.
1:555 minClôture : le cache de prompt d’un fournisseur n’est pas le cache KV d’exécution. Questions ouvertes.

Messages clés à faire passer

  1. Le cache KV achète de la vitesse de décodage avec de la mémoire. Chaque token conservé dans le contexte est un état à maintenir aussi longtemps que la séquence vit.
  2. Sous l’estimation linéaire simplifiée, doubler le contexte actif double approximativement la mémoire KV, et doubler le nombre de séquences concurrentes également.
  3. La formule 2 x couches x têtes KV x dimension de tête x tokens en cache x octets par élément est une estimation pour un décodeur simple. Les architectures et les moteurs s’en écartent : traitez le résultat comme un ordre de grandeur et vérifiez-le auprès du moteur.
  4. Ce sont les têtes KV, et non les têtes d’attention, qui déterminent la taille du cache. C’est pourquoi GQA et MQA réduisent la mémoire de cache en laissant le nombre de paramètres presque inchangé.
  5. La précision du cache et celle des poids sont deux décisions séparées, aux effets de qualité séparés. Évaluez un cache de précision réduite pour lui-même, avec son propre jeu d’évaluation.
  6. Le cache de prompt d’un fournisseur n’est pas le cache KV d’exécution de votre requête. La réutilisation de préfixe côté fournisseur a ses propres conditions d’éligibilité, sa propre fenêtre de persistance et sa propre facturation.

Pièges fréquents

Les participants utilisent le nombre total de têtes d’attention au lieu du nombre de têtes KV et surestiment la mémoire du facteur de groupement GQA.

Faites figurer les deux nombres côte à côte sur chaque fiche de configuration imprimée et exigez que le nombre de têtes KV soit entouré avant tout calcul.

La formule est prise pour une comptabilité exacte de la mémoire du GPU, et les apprenants s’étonnent que le moteur en annonce davantage.

Annoncez tôt que les poids, les activations, la fragmentation et la surcharge du moteur restent hors formule. Demandez une fourchette, jamais un nombre exact unique.

Quelqu’un conclut que quantifier le cache est gratuit parce que la quantification des poids a bien fonctionné sur son modèle.

Séparez explicitement les deux au tableau et exigez une évaluation distincte. C’est sur les contextes longs et les échanges multi-tours que la précision du cache se dégrade en premier.

La réutilisation de préfixe est proposée pour des prompts qui ne sont identiques qu’en apparence : même gabarit, mais client ou instruction système différents.

Imposez une comparaison octet par octet de deux prompts réels pendant l’atelier B. La réutilisation à travers une frontière de confiance est une question de correction et de confidentialité, pas un détail d’optimisation.

Le cache de prompt du fournisseur est confondu avec le cache KV d’exécution, et les affirmations de coût dérivent vers la fiction.

Lisez la page du fournisseur à voix haute pendant la clôture, et listez les règles d’éligibilité qu’elle énonce réellement, pas celles que l’on suppose.

Le banc d’essai utilise une seule longueur de prompt et un seul niveau de concurrence, puis le déploiement se comporte autrement en production.

Exigez une distribution de longueurs de contexte et au moins deux niveaux de concurrence dans le plan de mesure de l’atelier B avant de l’accepter comme terminé.