L’efficacité énergétique des LLM n’est pas une caractéristique fixe du modèle. Le même modèle peut consommer une quantité d’énergie très différente par requête utile lorsque vous modifiez la longueur du prefill, la longueur de sortie, la forme des batchs, la précision, le moment des requêtes, la fréquence des GPU ou le runtime de serving. Mesurez ces facteurs avec la latence et la qualité avant de qualifier une configuration d’efficace.
Ce guide s’adresse aux lecteurs avancés qui exploitent ou évaluent l’inférence des LLM. Sa conclusion pratique est simple : collectez l’énergie au niveau de l’appareil ou du nœud, expliquez-la avec la télémétrie du serving, puis normalisez-la par rapport au travail utile au niveau de la requête. Une seule mesure en watts ne peut pas remplir ces trois fonctions.
Cette distinction devient plus importante à mesure que les budgets de raisonnement augmentent. Les tokens générés supplémentaires accroissent le calcul, mais le système qui les entoure détermine l’efficacité avec laquelle le matériel réalise ce travail. Mon analyse précédente des tokens de raisonnement et de leur coût de calcul couvre l’aspect charge de travail. Cet article se concentre sur l’audit énergétique et l’aspect serving.
L’efficacité énergétique des LLM est un résultat de la stack de serving
L’énergie est la puissance intégrée dans le temps. Si un GPU consomme en moyenne 400 watts pendant dix secondes, il utilise 4 000 joules. Cette partie est simple. La difficulté consiste à choisir la fenêtre temporelle, la limite matérielle et l’unité de reporting.
« Énergie par token » peut désigner au moins trois choses différentes :
| Métrique | Utile pour | Ce qu’elle peut masquer |
|---|---|---|
| --- | --- | --- |
| Joules par token de sortie | Chat et génération dominés par le decode | Traitement du prompt, requêtes échouées, différences de qualité |
| Joules par token d’entrée effectif | Prefill et travail sur de longs contextes | Travail de sortie et valeur de la requête de bout en bout |
| Joules par requête réussie | Comparaison de produits et de charges de travail | Grandes différences de longueur des prompts et des réponses |
| Requêtes par kilowatt-heure | Planification de capacité et opérations | Difficulté des requêtes, qualité et latence |
Aucune n’est universellement correcte. Choisissez l’unité qui correspond au contrat de service, puis fournissez suffisamment de contexte pour qu’une autre équipe puisse reproduire le test.
La limite matérielle est tout aussi importante. L’API de gestion de NVIDIA expose des compteurs d’énergie des appareils sur le matériel pris en charge. Cela peut produire un delta GPU propre, mais n’inclut pas par défaut le travail du CPU, la mémoire hôte, le stockage, le réseau, le refroidissement ni les pertes de conversion électrique. CodeCarbon peut élargir la limite avec des éléments mesurés et estimés, mais sa documentation décrit des estimations de secours pour le matériel qu’il ne peut pas lire. « Mesuré par un outil » ne signifie pas que chaque composant a été instrumenté.
Quatre études ont mesuré différentes parties de la stack
Des recherches récentes rendent visible l’effet du système. Les pourcentages principaux ci-dessous ne constituent pas un classement. Chaque étude utilise une plateforme, une charge de travail, une référence et une limite énergétique différentes.
| Étude | Portée et méthode | Résultat rapporté | Limite à garder à l’esprit |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Désagrège le travail d’attention et feed-forward, puis contrôle le provisionnement, la fréquence, la taille des batchs et le microbatching sur des systèmes A800 | Jusqu’à 49 % d’énergie en moins par token que la référence désagrégée testée, tout en respectant les objectifs de TTFT et de TPOT | Deux familles de modèles, matériel A800 et traces de style production évaluées |
| Festina | Coordonne le placement, le partitionnement des GPU, le point de fonctionnement, la consolidation et la migration pour l’inférence partagée sur H100 | Jusqu’à 56 % d’énergie en moins, avec le respect des SLO maintenu dans une marge de deux points de pourcentage dans la configuration rapportée | Contexte serverless avec GPU partagé ; les gains diminuent lorsque le prefill est déjà intensif en calcul |
| EnerInfer | Prévoit le débit et la puissance selon les réglages du NPU et de la mémoire, puis gère les paramètres de contrôle sous contraintes thermiques | Gains d’efficacité énergétique de 65 % sur les téléphones, 12 % sur un ordinateur portable et 24 % sur une carte edge | Les économies sur l’ensemble de l’appareil étaient plus faibles, de 4,2 à 11 %, car d’autres composants et phases consommaient encore de l’énergie |
| Understanding Efficiency | Teste la quantification, le batching, les profils d’arrivée et les choix de serving sur des GPU H100 | Le continuous batching a réduit de 12,5× l’énergie par requête par rapport à la référence séquentielle de l’étude ; les arrivées structurées ont atteint des gains supérieurs lors d’un test fixe | Prompts courts, deux tailles de modèles Llama, une seule famille d’accélérateurs et données énergétiques principalement centrées sur le GPU |
Le résultat commun est plus important que n’importe quel pourcentage individuel : l’orchestration peut modifier suffisamment la consommation d’énergie pour invalider une estimation fondée uniquement sur le modèle. Les articles montrent également pourquoi « utilisez une précision plus faible » est un conseil incomplet. L’étude sur H100 a constaté qu’une précision plus faible aidait le prefill limité par le calcul, tandis que le surcoût de déquantification et des kernels pouvait annuler ou inverser le bénéfice pendant le decode limité par la mémoire.
Considérez chaque valeur « jusqu’à » comme une propriété de l’expérience des auteurs. AFlex ne prouve pas une économie de 49 % sur votre cluster B200. EnerInfer ne prouve pas une économie de 65 % sur l’ensemble de l’appareil pour tous les téléphones. Ces résultats identifient des contrôles à tester, et non des économies que vous pouvez recopier dans une prévision.
Séparez le prefill du decode avant d’optimiser
Une requête LLM comporte deux phases dont les goulots d’étranglement diffèrent.
Le prefill est généralement intensif en calcul
Le prefill traite le prompt et construit le cache clé-valeur. Les prompts longs créent des pics de travail matriciel parallèle. Les changements de précision et des fréquences plus élevées peuvent aider lorsque cette phase est limitée par le calcul, mais une réduction du time-to-first-token peut tout de même s’accompagner d’un pic de puissance plus élevé. Mesurez l’énergie, pas uniquement la puissance.
Le decode est généralement limité par la mémoire
Le decode produit les tokens un par un. Il relit à plusieurs reprises les poids du modèle et le KV cache qui s’agrandit ; le trafic mémoire et la formation des batchs dominent donc souvent. Des fréquences plus élevées peuvent augmenter la puissance sans accroître proportionnellement le débit. La quantification peut également ajouter un surcoût de conversion lorsque les kernels ou le chemin matériel sont mal adaptés.
Cette séparation des phases explique pourquoi une moyenne sur l’ensemble de la requête peut être trompeuse. Une configuration peut améliorer le prefill de prompts longs et dégrader le decode de prompts courts. Indiquez au minimum la longueur du prompt, la longueur de sortie, le batch ou la concurrence, la précision et les temps de chaque phase avec chaque résultat énergétique.
Le KV cache doit figurer dans le même enregistrement. Mon guide sur les échecs d’éviction du KV cache explique l’aspect fiabilité. Pour le travail énergétique, la pression sur le cache peut modifier le trafic mémoire, le recalcul, le placement et les taux de nouvelle tentative. Une exécution avec des évictions silencieuses n’est pas comparable à une exécution qui n’en comporte pas.
Réalisez un audit énergétique qui protège les SLO de latence
L’audit nécessite trois couches connectées : les résultats des requêtes, le contexte du serving et l’énergie de l’appareil ou du nœud.
*Un résultat énergétique utile nécessite une unité claire, un contexte de serving et une limite matérielle explicite.*
1. Figez une charge de travail représentative
Construisez des segments de charge de travail plutôt qu’une seule moyenne synthétique. Séparez au minimum les prompts courts et longs, les sorties courtes et longues, les arrivées régulières et en rafales, ainsi que les niveaux de qualité utilisés par votre application. Gardez le modèle, le tokenizer, la politique d’échantillonnage et les règles d’arrêt fixes pendant une comparaison.
Utilisez des formes de requêtes réelles lorsque la confidentialité et le consentement le permettent. Si vous utilisez des prompts synthétiques, préservez les distributions de longueur des tokens et d’arrivée qui pilotent le système. Le rapport final doit identifier la demande synthétique comme telle.
2. Enregistrez les résultats au niveau de la requête
Pour chaque requête, capturez :
Ne supprimez pas les échecs du total énergétique. Une configuration qui consomme moins d’énergie sur les requêtes terminées en faisant expirer les requêtes difficiles n’est pas plus efficace.
3. Enregistrez le contexte du serving
Journalisez les contrôles susceptibles d’expliquer une variation : durée du prefill et du decode, taille des batchs, séquences actives, profondeur de la file, précision, parallélisme, occupation du cache, placement, fréquences ou limite de puissance du GPU et charge des co-tenant.
Cette télémétrie détecte également les effets d’inactivité et de rafale. Un runtime qui maintient les CPU actifs pendant que le GPU attend peut sembler correct dans une mesure limitée au GPU et pire à la limite du nœud ou de la flotte. Les fils de discussion sur les problèmes open source sont utiles pour repérer ces modes d’échec, mais ils restent anecdotiques tant que vous ne les avez pas reproduits sur votre stack.
4. Mesurez une limite énergétique explicite
Sur les GPU NVIDIA pris en charge, NVML expose un compteur d’énergie totale en millijoules. Une sonde Python minimale peut encadrer une charge de travail fixe :
python from pynvml import ( nvmlDeviceGetHandleByIndex, nvmlDeviceGetTotalEnergyConsumption, nvmlInit, nvmlShutdown, )
nvmlInit() gpu = nvmlDeviceGetHandleByIndex(0) start_mj = nvmlDeviceGetTotalEnergyConsumption(gpu)
run_fixed_workload() # same requests, model, and stopping rules
end_mj = nvmlDeviceGetTotalEnergyConsumption(gpu) nvmlShutdown()
gpu_joules = (end_mj - start_mj) / 1_000 joules_per_output_token = gpu_joules / completed_output_tokens
La documentation des requêtes d’appareil NVML définit le compteur et ses unités. Vérifiez la prise en charge sur le GPU et le driver exacts. La valeur cumulative est réinitialisée lors du rechargement du driver ; rejetez donc tout delta négatif ou incohérent. Pour les appareils dépourvus de compteur d’énergie, échantillonnez la puissance à une fréquence qui capture les requêtes courtes et intégrez la trace sur la même fenêtre.
L’énergie GPU constitue une limite valide si vous la nommez. Pour la capacité, les coûts ou la comptabilité carbone, ajoutez les composants hôte et infrastructure selon la décision à prendre. La documentation de CodeCarbon peut élargir l’audit, mais vérifiez quelles valeurs l’outil mesure et lesquelles il estime. Un comptage externe au niveau du rack ou du mur reste le contrôle le plus solide pour les comparaisons sur l’ensemble d’un nœud.
5. Normalisez le résultat de plusieurs façons
Rapportez un petit ensemble de métriques plutôt qu’un seul chiffre gagnant :
Une métrique aide à régler le chemin de decode. Une autre relie la modification à la valeur produit. Les champs de latence et de qualité empêchent une optimisation énergétique d’affaiblir discrètement le service.
6. Modifiez un seul contrôle, puis rejouez la demande
Commencez par des expériences isolées : précision, politique de batch, regroupement des requêtes, configuration du cache, limite de puissance ou de fréquence du GPU et placement. Effectuez plusieurs essais après la phase de chauffe. Modifiez l’ordre entre les essais lorsque la chaleur ou l’heure de la journée peut biaiser le résultat.
Rejouez ensuite les meilleurs candidats avec des arrivées mixtes. Festina et AFlex coordonnent tous deux plusieurs contrôles, car les optima locaux interagissent. Votre première passe doit isoler les causes ; votre passe finale doit tester la politique combinée sous le SLO réel.
Optimisez dans l’ordre soutenu par les données
L’ordre d’optimisation le plus sûr commence par le travail gaspillé, puis se dirige vers des contrôles matériels plus précis.
Si le système sert différents niveaux de qualité, combinez ce processus avec un benchmark du travail réel. Le workflow pratique de benchmarking des modèles maintient la qualité, la latence et le coût visibles pendant que vous modifiez le chemin de serving.
Ne confondez pas énergie, coût et carbone
Ces métriques répondent à des questions différentes.
Une facture cloud plus faible ne prouve pas une énergie plus faible. Un compteur GPU plus bas ne prouve pas une consommation plus faible de l’infrastructure. Une exécution moins énergivore n’a pas automatiquement des émissions plus faibles si elle s’effectue à une autre heure ou dans un autre lieu.
Le problème du reporting est suffisamment actif pour atteindre les travaux de normalisation. Un élément de travail de l’ITU-T sur les métriques d’efficacité énergétique de l’inférence AI inclut dans son périmètre les limites liées aux tokens, les indicateurs d’énergie par token, les calculs carbone et les règles de reporting. Ces travaux montrent que les unités de tokens et les limites système restent indéterminées. Il ne s’agit pas d’un benchmark finalisé.
La règle de décision pour la production
N’acceptez une modification de l’efficacité énergétique des LLM que lorsqu’elle réduit l’énergie pour l’unité de travail utile visée et maintient le contrat de requête dans les limites prévues.
Rédigez ce contrat avant le test :
Cette règle évite trois erreurs courantes : optimiser les watts au lieu des joules, optimiser les tokens terminés en masquant les échecs et transposer le résultat « jusqu’à » d’un article à un matériel différent.
La recherche indique une direction pratique, et non une configuration universelle. Profilez séparément le prefill et le decode. Gardez les enregistrements de la requête, du runtime et du matériel associés. Mesurez la limite que vous prévoyez de gérer. C’est ainsi qu’un chiffre énergétique devient une décision d’ingénierie.