Pourquoi le décodage d’un LLM est-il limité par la mémoire et le prefill par le calcul ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Le décodage d’un LLM est souvent limité par la mémoire, car un petit lot ne réutilise chaque poids du modèle que quelques fois avant de charger les poids suivants. Le prefill de longues séquences ou de lots suffisamment grands réutilise les poids pour de nombreux tokens du prompt ; le calcul matriciel peut alors devenir la ressource limitante. Ces conditions dépendent de la charge de travail et ne sont pas des propriétés permanentes de chaque phase.
L’intensité arithmétique aide à décider s’il faut réduire les déplacements de données ou améliorer l’exécution des opérations matricielles.
Comparer les calculs aux octets transférés
L’intensité arithmétique est le nombre d’opérations en virgule flottante effectuées par octet transféré depuis la mémoire. Le modèle roofline la compare au rapport entre la puissance de calcul maximale et la bande passante mémoire.
Les spécifications de la H100 SXM de NVIDIA indiquent environ 989 TFLOPS pour les calculs denses FP16/BF16 sur Tensor Cores et une bande passante mémoire de 3.35 TB/s. Le chiffre annoncé de 1,979 TFLOPS suppose une parcimonie structurée. Leur rapport est d’environ 295 FLOPs par octet. Il s’agit d’une limite théorique fondée sur des spécifications matérielles comparables.
Une multiplication simplifiée d’une matrice dense par un vecteur effectue environ deux opérations par poids de deux octets : soit environ un FLOP par octet. Dans ce régime, un décodeur avec un lot de taille un ne peut pas exploiter le débit maximal de calcul matriciel du GPU. Des lots plus grands permettent à un poids chargé de contribuer au calcul de plusieurs tokens. Le prefill réutilise également les poids pour les tokens du prompt. Splitwise décrit ces caractéristiques différentes des phases.
Choisir une modification selon la limite mesurée
| Observation | Modification à étudier | Ce qui peut empêcher un gain |
|---|---|---|
| Le décodage de petits lots passe du temps à transférer les poids | Quantification des poids prise en charge ; lots de décodage plus grands | Kernels de quantification, perte de qualité, limites de latence |
| Le décodage avec un long contexte passe du temps à lire l’historique d’attention | Moins de têtes KV ; quantification KV prise en charge ; attention efficace | Architecture du modèle et prise en charge de la précision du cache |
| Un prefill important sollicite fortement les unités matricielles | Kernels matriciels efficaces ; calcul en précision réduite pris en charge | Prompts courts, petits lots, autres opérations |
| De nombreux kernels courts laissent des périodes sans exécution sur le GPU | Fusion ou réduction du surcoût de lancement | Utilisation accrue des registres et de la mémoire partagée |
Après chaque modification, mesurez à la fois la latence jusqu’au premier token et les intervalles entre les tokens suivants. Un lot plus grand peut augmenter le nombre total de tokens par seconde tout en ralentissant chaque requête. Le rapport matériel identifie une limite possible ; une trace établit quelle ressource votre charge de travail attend réellement.
Guide d’ingénierie : inférence limitée par la mémoire ou par le calcul présente le diagramme roofline et les optimisations propres à chaque phase.