Atelier A — Dimensionner un cache KV à partir de la fiche d’architecture
Durée : 25 minutes · Format : en binôme · Données sensibles : aucune
Appliquez 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, puis étendez-la à plusieurs contextes et niveaux de concurrence. Travaillez en octets, convertissez à la fin, et inscrivez l’architecture supposée à côté de chaque chiffre. Pour cet atelier, supposez un décodeur de 80 couches, 8 têtes KV, dimension de tête 128, et un cache stocké en éléments de 16 bits (2 octets).
| # | Ce qu’il faut calculer | Votre résultat |
|---|---|---|
| 1 | Octets mis en cache par token pour l’architecture indiquée | |
| 2 | Cache pour une séquence conservant 4096 tokens | |
| 3 | Cache pour une séquence conservant 8192 tokens | |
| 4 | Cache pour 8 séquences concurrentes de 8192 tokens chacune | |
| 5 | Même calcul que la ligne 4 avec un cache 8 bits au lieu de 16 bits | |
| 6 | Même calcul que la ligne 4 si le modèle avait 64 têtes KV au lieu de 8 |
Corrigé détaillé
Par token, l’estimation donne 2 x 80 x 8 x 128 x 2 octets = 327 680 octets, soit environ 320 Kio par token ; à 4096 tokens cela représente environ 1,3 Go (1,25 Gio) pour une seule séquence, et environ 2,7 Go (2,5 Gio) à 8192 tokens. Huit séquences concurrentes de 8192 tokens chacune approchent 21 Go (20 Gio), ce qui constitue déjà une large part d’un accélérateur unique avant même de compter les poids et les activations. Réduire de moitié la taille d’élément à 8 bits ramène le chiffre à environ 10 Go, et passer de 8 à 64 têtes KV le multiplie par huit, vers environ 170 Go — cet écart d’un facteur huit résume à lui seul l’argument en faveur de l’attention à requêtes groupées. Présentez ces résultats comme des ordres de grandeur : la formule ignore les poids, les activations, la fragmentation de l’allocateur et la surcharge du moteur, si bien que l’empreinte mesurée sera plus élevée, et chaque binôme doit terminer l’atelier avec une fourchette et une architecture énoncée plutôt qu’un chiffre unique.
Atelier B — Choisir les leviers pour un déploiement qui ne tient plus
Durée : 15 minutes · Format : groupes de trois · Données sensibles : aucune
Un service sert un modèle de classe 70B avec GQA sur un accélérateur de 80 Go. Les poids en 16 bits occupent environ 140 Go, donc le déploiement s’étale déjà sur deux appareils ; l’équipe veut 16 séquences concurrentes de 8192 tokens, ce que l’atelier A chiffre à environ 43 Go de cache KV. Décidez quoi changer, dans quel ordre, et ce que coûte chaque geste.
- Écrivez explicitement le budget KV actuel et le budget visé, en reprenant les chiffres de l’atelier A et en énonçant l’architecture supposée.
- Classez ces leviers par économie de mémoire attendue : borner le contexte conservé, plafonner la concurrence, quantifier le cache, adopter l’attention paginée, réutiliser un préfixe partagé vérifié.
- Pour chaque levier, écrivez le coût que vous acceptez : contexte perdu, débit réduit, risque de qualité, effort d’ingénierie, ou contrainte de frontière de confiance.
- Choisissez les deux leviers que vous livreriez en premier et justifiez en une phrase chacun pourquoi les autres attendent.
- Rédigez le plan de mesure qui confirmerait que le changement a fonctionné : quelles mesures, sur quelle distribution de longueurs de contexte, à quels deux niveaux de concurrence.
Corrigé détaillé
Les deux gestes livrés en premier sont presque toujours borner le contexte conservé et adopter l’attention paginée, car tous deux réduisent la mémoire sans toucher à la qualité du modèle : borner le contexte attaque directement le terme linéaire en tokens, et l’allocation par blocs récupère la mémoire gaspillée par la réservation du pire cas par séquence. Plafonner la concurrence fonctionne arithmétiquement mais se paie en débit : c’est un garde-fou de délestage plutôt qu’un choix de conception. La quantification du cache est le plus gros levier restant — elle divise approximativement par deux l’empreinte en passant de 16 à 8 bits — mais elle doit attendre sa propre évaluation sur les contextes longs et les échanges multi-tours, car son mode de défaillance n’est pas celui de la quantification des poids. La réutilisation vérifiée de préfixe n’aide que lorsqu’un préfixe substantiel est réellement identique octet par octet et partagé à l’intérieur d’une même frontière de confiance, ce qui l’exclut pour des instructions système propres à chaque client. Un plan de mesure acceptable nomme le temps jusqu’au premier token, la latence inter-tokens, le débit de sortie, l’occupation du cache et le taux d’éviction/recalcul, rapportés en p50 et p95, sur une distribution réaliste de longueurs de contexte et à deux niveaux de concurrence plutôt qu’avec un prompt unique et fixe.
Atelier C — Lire un tableau de bord de service sous pression de cache
Durée : 15 minutes · Format : individuel · Données sensibles : aucune
À partir des captures du tableau de bord (ou d’une exécution en direct si elle est disponible), diagnostiquez un déploiement dont la latence se dégrade quand la concurrence augmente. Remplissez une ligne par observation et engagez-vous sur un diagnostic avant de lire le corrigé.
| # | Signal à lire | Votre lecture |
|---|---|---|
| 1 | Temps jusqu’au premier token à faible concurrence puis à forte concurrence | |
| 2 | Latence inter-tokens aux deux mêmes points | |
| 3 | Occupation du cache en proportion du budget | |
| 4 | Taux d’éviction et de recalcul sur la durée de l’exécution | |
| 5 | Écart entre les latences p50 et p95 | |
| 6 | Votre diagnostic en une phrase et le premier levier que vous actionneriez |
Corrigé détaillé
Le motif caractéristique est le suivant : la latence inter-tokens reste à peu près stable tandis que le temps jusqu’au premier token grimpe fortement avec la concurrence, l’occupation frôle le plafond du budget, et le taux d’éviction/recalcul devient non nul exactement là où le premier token décroche. Cette combinaison identifie une pression sur le cache et non une boucle de décodage lente : les séquences évincées doivent être repréremplies, et c’est précisément le préremplissage que mesure le temps jusqu’au premier token. L’écart entre p95 et p50 s’élargit bien plus que les médianes ne bougent, ce qui explique habituellement qu’un service paraisse acceptable en moyenne et manque son objectif de latence en pratique. Le bon premier levier est de réduire les tokens en cache — borner le contexte conservé et admettre moins de séquences que le budget ne le permet plutôt que de les évincer ensuite — puisque le recalcul après éviction est du travail purement perdu.