Atelier A — Estimation de la mémoire des poids et écart avec la réalité
Durée : 20 minutes · Format : en binôme, un tableur par binôme · Données sensibles : aucune
Remplissez le tableau pour un modèle de 7 milliards de paramètres à trois précisions, avec paramètres × bits par poids ÷ 8. Chargez ensuite le modèle que votre machine peut réellement exécuter, lisez la mémoire résidente rapportée par le runtime, et inscrivez l’écart dans la troisième colonne. Rapportez toujours les deux chiffres, jamais l’estimation seule.
| Précision | Estimation mémoire des poids | Mémoire résidente mesurée |
|---|---|---|
| 16 bits (FP16/BF16) | ||
| 8 bits (INT8) | ||
| 4 bits | ||
| 4 bits, contexte 8k, 1 séquence | ||
| 4 bits, contexte 8k, 8 séquences |
Corrigé détaillé
Pour 7 milliards de paramètres, les estimations valent environ 14 Go en 16 bits, environ 7 Go en 8 bits et environ 3,5 Go en 4 bits, puisque la formule est paramètres × bits par poids ÷ 8. La mémoire résidente mesurée est toujours supérieure à l’estimation : comptez grossièrement 10 à 30 pour cent de plus à contexte court pour les poids, les tampons d’exécution et la surcharge de l’allocateur, et nettement davantage dès que le cache KV se remplit. Les deux dernières lignes sont le cœur de l’atelier : à poids maintenus en 4 bits, passer d’une séquence à huit avec un contexte de 8k ajoute une mémoire de cache KV qui peut approcher ou dépasser les 3,5 Go de poids, selon le nombre de couches, les têtes KV, la dimension de tête et la précision du cache. Un binôme qui ne rapporte que le chiffre de 3,5 Go a dimensionné un service qui tombera en concurrence.
Atelier B — Mesurer deux précisions à charge constante
Durée : 25 minutes · Format : en binôme au terminal, résultats publiés sur le bloc partagé · Données sensibles : aucune
Comparez une version de plus haute précision et une version quantifiée du même modèle sur la même machine. Tout doit rester constant sauf la précision. Publiez vos cinq chiffres sur le bloc partagé pour que le groupe compare les écarts entre matériels.
- Écrire, avant tout chargement : la version de référence, le jeu de prompts figé, la longueur de sortie figée, le niveau de concurrence, et le seuil de retour arrière qualité que vous acceptez.
- Exécuter la version de référence et relever le temps jusqu’au premier token, la latence inter-tokens, le débit de sortie et la mémoire crête, en écartant la première exécution comme phase de chauffe.
- Exécuter la version quantifiée avec le même jeu de prompts, la même longueur de sortie, la même concurrence et la même version de runtime, puis relever les quatre mêmes chiffres.
- Noter les deux versions sur le même petit ensemble de sorties de tâches représentatives avec la même grille, et signaler toute réponse où la version quantifiée s’est dégradée.
- Consigner le matériel, la version du runtime et le hash de l’artefact de chaque version à côté des chiffres, puis dire si le candidat passe votre seuil.
Corrigé détaillé
La forme attendue du résultat est que la version quantifiée consomme nettement moins de mémoire pour les poids, environ la moitié en 8 bits et environ le quart en 4 bits par rapport à 16 bits, tandis que le résultat de latence n’est pas prévisible à l’avance. Sur un matériel dont les noyaux gèrent bien le format, le débit de décodage s’améliore souvent parce que moins de données de poids sont lues par token. Sur un matériel dépourvu de ces noyaux, ou lorsque le runtime déquantifie à la volée, la version plus petite peut être plus lente que la référence, et dans une salle au matériel hétérogène au moins un binôme observe exactement cela. La qualité se dégrade en général légèrement et de façon non uniforme : les réponses factuelles courtes paraissent souvent identiques alors que les raisonnements longs ou les sorties de code montrent l’écart en premier. Un binôme incapable d’énoncer sa référence, ses variables figées et son seuil a produit une anecdote, pas une mesure.
Atelier C — Rédiger la porte de sortie
Durée : 10 minutes · Format : individuel, sur papier, puis deux volontaires lisent la leur à voix haute · Données sensibles : aucune
On vous demande de mettre en production une version 4 bits d’un modèle actuellement servi en 16 bits, pour un assistant interne traitant environ 20 utilisateurs simultanés avec des contextes jusqu’à 8k tokens. Rédigez la porte de sortie qui doit être franchie avant la bascule.
- Nommer explicitement la référence : quelle version, quelle révision, quelle version de runtime servira de point de comparaison.
- Énumérer les tâches représentatives et la grille de qualité, et fixer le seuil de retour arrière sous forme de nombre avant toute mesure.
- Énumérer les mesures de performance exigées à la concurrence et à la distribution de contexte réelles : TTFT, latence inter-tokens, débit, mémoire crête.
- Énoncer le relevé d’environnement : matériel, version de runtime, hash d’artefact pour les deux versions.
- Énoncer la procédure de retour arrière et qui décide, y compris ce qui se passe si la qualité passe mais pas la mémoire crête.
Corrigé détaillé
Une porte valable désigne la version 16 bits à une révision figée comme référence, fixe un jeu de tâches tiré du trafic réel plutôt qu’un jeu de test générique, et fixe un seuil de qualité à l’avance, par exemple une baisse maximale annoncée sur la grille, sans aucune régression sur le sous-ensemble lié à la sûreté. Elle exige TTFT, latence inter-tokens, débit et mémoire crête mesurés à 20 séquences simultanées avec des contextes de 8k, et non à concurrence 1, car c’est le cache KV à cette charge qui décide si la machine tient. Elle consigne le matériel, la version du runtime et le hash d’artefact des deux versions pour que l’exécution soit reproductible. Enfin elle nomme un responsable et un chemin de retour arrière, et traite un échec sur la mémoire crête comme bloquant même si la qualité passe, car un dépassement mémoire en charge est un résultat pire qu’une réponse légèrement plus faible.
Ouvrir l’outil interactif — CPU et GPU Ouvrir l’outil interactif — quantification