Die Energieeffizienz von LLMs ist keine feste Modelleigenschaft. Dasselbe Modell kann pro nützlicher Anfrage sehr unterschiedlich viel Energie verbrauchen, wenn du Prefill-Länge, Ausgabelänge, Batch-Form, Präzision, Anfragezeitpunkt, GPU-Taktraten oder die Serving-Runtime änderst. Miss diese Faktoren gemeinsam mit Latenz und Qualität, bevor du ein Setup als effizient bezeichnest.
Dieser Leitfaden richtet sich an fortgeschrittene Leser, die LLM-Inferenz betreiben oder bewerten. Die praktische Schlussfolgerung ist einfach: Erfasse Energie auf Geräte- oder Node-Ebene, erkläre sie mit Serving-Telemetrie und normalisiere sie auf nützliche Arbeit auf Anfrageebene. Ein einzelner Watt-Messwert kann diese drei Aufgaben nicht erfüllen.
Die Unterscheidung wird umso wichtiger, je größer die Reasoning-Budgets werden. Zusätzliche generierte Tokens erhöhen den Rechenaufwand, aber das System rund um diese Tokens entscheidet, wie effektiv die Hardware diese Arbeit erledigt. Meine frühere Analyse zu Reasoning-Tokens und ihren Rechenkosten behandelt die Workload-Seite. Dieser Artikel konzentriert sich auf das Energie-Audit und die Serving-Seite.
Die Energieeffizienz von LLMs ist ein Ergebnis des Serving-Stacks
Energie ist über die Zeit integrierte Leistung. Wenn eine GPU zehn Sekunden lang durchschnittlich 400 Watt verbraucht, nutzt sie 4.000 Joule. Dieser Teil ist einfach. Schwieriger ist die Wahl des Zeitfensters, der Hardwaregrenze und der Berichtseinheit.
„Energie pro Token“ kann mindestens drei verschiedene Dinge bedeuten:
| Metrik | Nützlich für | Was sie verbergen kann |
|---|---|---|
| --- | --- | --- |
| Joule pro Output-Token | Decode-lastige Chats und Generierung | Prompt-Verarbeitung, fehlgeschlagene Anfragen, Qualitätsunterschiede |
| Joule pro effektivem Input-Token | Prefill und Arbeit mit langen Kontexten | Output-Arbeit und der Wert der Anfrage von Ende zu Ende |
| Joule pro erfolgreicher Anfrage | Produkt- und Workload-Vergleiche | Große Unterschiede bei Prompt- und Antwortlänge |
| Anfragen pro Kilowattstunde | Kapazitäts- und Betriebsplanung | Anfrageschwierigkeit, Qualität und Latenz |
Keine dieser Einheiten ist universell korrekt. Wähle die Einheit, die zum Servicevertrag passt, und berichte anschließend genügend Kontext, damit ein anderes Team den Test wiederholen kann.
Die Hardwaregrenze ist ebenso wichtig. Die Management-API von NVIDIA stellt auf unterstützter Hardware Energiezähler für Geräte bereit. Das kann einen sauberen GPU-Delta-Wert liefern, umfasst standardmäßig jedoch weder CPU-Arbeit, Host-Speicher, Storage, Netzwerk, Kühlung noch Verluste bei der Leistungsumwandlung. CodeCarbon kann die Grenze um gemessene und geschätzte Bestandteile erweitern, doch die Dokumentation beschreibt Fallback-Schätzungen für Hardware, die das Tool nicht auslesen kann. „Von einem Tool gemessen“ bedeutet nicht, dass jeder Bestandteil erfasst wurde.
Vier Studien haben unterschiedliche Teile des Stacks gemessen
Aktuelle Forschung macht den Systemeffekt sichtbar. Die unten genannten Spitzenwerte sind keine Rangliste. Jede Studie verwendet eine andere Plattform, Workload, Baseline und Energiegrenze.
| Studie | Umfang und Methode | Berichtetes Ergebnis | Zu beachtende Grenze |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Disaggregiert Attention- und Feed-Forward-Arbeit und steuert anschließend Provisioning, Frequenz, Batch-Größe und Microbatching auf A800-Systemen | Bis zu 49 % weniger Energie pro Token als die getestete disaggregierte Baseline bei Einhaltung der TTFT- und TPOT-Ziele | Zwei Modellfamilien, A800-Hardware und ausgewertete produktionsnahe Traces |
| Festina | Koordiniert Platzierung, GPU-Partitionierung, Betriebspunkt, Konsolidierung und Migration für gemeinsam genutzte H100-Inferenz | Bis zu 56 % weniger Energie bei einer SLO-Einhaltung, die im berichteten Setup innerhalb von zwei Prozentpunkten blieb | Serverless-Kontext mit gemeinsam genutzten GPUs; die Gewinne schrumpfen, wenn Prefill bereits rechenintensiv ist |
| EnerInfer | Prognostiziert Durchsatz und Leistung über NPU- und Speichereinstellungen hinweg und verwaltet anschließend Steuereinstellungen unter thermischen Grenzen | Verbesserungen der Energieeffizienz um 65 % auf Smartphones, 12 % auf einem Laptop und 24 % auf einem Edge-Board | Die Einsparungen auf Geräteebene waren mit 4,2–11 % geringer, da andere Komponenten und Phasen weiterhin Energie verbrauchten |
| Understanding Efficiency | Testet Quantisierung, Batching, Ankunftsmuster und Serving-Entscheidungen auf H100-GPUs | Continuous Batching senkte die Energie pro Anfrage gegenüber der sequenziellen Baseline der Studie um das 12,5-Fache; strukturierte Ankünfte erzielten in einem festen Test größere Gewinne | Kurze Prompts, zwei Llama-Modellgrößen, eine Accelerator-Familie und überwiegend GPU-fokussierte Energiedaten |
Das gemeinsame Ergebnis ist aussagekräftiger als jeder einzelne Prozentwert: Orchestrierung kann den Energieverbrauch so stark verändern, dass eine modellbasierte Schätzung ungültig wird. Die Studien zeigen außerdem, warum „Verwende niedrigere Präzision“ unvollständiger Rat ist. Die H100-Studie stellte fest, dass niedrigere Präzision bei compute-bound Prefill half, während Dequantisierung und Kernel-Overhead den Vorteil bei memory-bound Decode aufheben oder umkehren konnten.
Behandle jede „bis zu“-Zahl als Eigenschaft des Experiments der jeweiligen Autoren. AFlex beweist keine Einsparung von 49 % auf deinem B200-Cluster. EnerInfer beweist keine Einsparung von 65 % auf dem gesamten Gerät für jedes Smartphone. Die Ergebnisse zeigen Steuergrößen auf, die du testen solltest, nicht Einsparungen, die du direkt in eine Prognose übernehmen kannst.
Trenne Prefill und Decode, bevor du optimierst
Eine LLM-Anfrage besteht aus zwei Phasen mit unterschiedlichen Engpässen.
Prefill ist normalerweise rechenintensiv
Prefill verarbeitet den Prompt und erstellt den Key-Value-Cache. Lange Prompts erzeugen Bursts paralleler Matrixarbeit. Änderungen an der Präzision und höhere Taktraten können helfen, wenn diese Phase compute-bound ist, aber eine geringere Time-to-First-Token kann dennoch mit einer höheren Leistungsspitze einhergehen. Miss Energie, nicht nur Leistung.
Decode ist normalerweise speicherintensiv
Decode erzeugt Tokens Schritt für Schritt. Dabei werden Modellgewichte und der wachsende KV-Cache wiederholt gelesen, sodass Speicherverkehr und Batch-Bildung häufig dominieren. Höhere Taktraten können die Leistung erhöhen, ohne den Durchsatz proportional zu steigern. Quantisierung kann ebenfalls Konvertierungs-Overhead verursachen, wenn Kernel oder Hardwarepfad nicht gut aufeinander abgestimmt sind.
Diese Phasentrennung erklärt, warum ein Durchschnitt über die gesamte Anfrage irreführend sein kann. Ein Setup kann langes Prompt-Prefill verbessern und kurzes Decode verschlechtern. Berichte mit jedem Energieergebnis mindestens Prompt-Länge, Ausgabelänge, Batch oder Concurrency, Präzision und Phasen-Timings.
Der KV-Cache gehört in denselben Datensatz. Mein Leitfaden zu Fehlern bei der KV-Cache-Eviction erklärt die Zuverlässigkeitsseite. Für Energieanalysen kann Cache-Druck Speicherverkehr, Neuberechnung, Platzierung und Retry-Raten verändern. Ein Lauf mit stillen Evictions ist nicht mit einem Lauf ohne sie vergleichbar.
Führe ein Energie-Audit durch, das Latenz-SLOs schützt
Das Audit benötigt drei miteinander verbundene Ebenen: Anfrageergebnisse, Serving-Kontext und Energie auf Geräte- oder Node-Ebene.
*Ein aussagekräftiges Energieergebnis benötigt eine klare Einheit, Serving-Kontext und eine explizite Hardwaregrenze.*
1. Fixiere einen repräsentativen Workload
Erstelle Workload-Slices statt eines einzigen synthetischen Durchschnitts. Trenne mindestens kurze und lange Prompts, kurze und lange Ausgaben, gleichmäßige und burstartige Ankünfte sowie die von deiner Anwendung verwendeten Qualitätsstufen. Halte Modell, Tokenizer, Sampling-Policy und Stoppregeln während eines Vergleichs konstant.
Verwende reale Anfrageformen, sofern Datenschutz und Einwilligung dies erlauben. Wenn du synthetische Prompts verwendest, bewahre die Tokenlängen- und Ankunftsverteilungen, die das System antreiben. Der Abschlussbericht sollte synthetische Nachfrage als synthetisch kennzeichnen.
2. Erfasse Ergebnisse auf Anfrageebene
Erfasse für jede Anfrage:
Entferne Fehler nicht aus der Energiesumme. Ein Setup, das bei abgeschlossenen Anfragen weniger Energie verbraucht, indem es schwierige Anfragen mit einem Timeout beendet, ist nicht effizienter.
3. Erfasse den Serving-Kontext
Protokolliere die Steuergrößen, die eine Änderung erklären können: Dauer von Prefill und Decode, Batch-Größe, aktive Sequenzen, Queue-Tiefe, Präzision, Parallelität, Cache-Auslastung, Platzierung, GPU-Taktraten oder Power-Limit sowie die Last von Co-Tenants.
Diese Telemetrie erfasst auch Leerlauf- und Burst-Effekte. Eine Runtime, die CPUs beschäftigt hält, während die GPU wartet, kann in einer reinen GPU-Messung unauffällig wirken und an der Node- oder Fleet-Grenze schlechter aussehen. Open-Source-Issue-Threads sind nützlich, um solche Fehlerbilder zu finden, bleiben aber Anekdoten, bis du sie auf deinem Stack reproduzierst.
4. Miss eine explizite Energiegrenze
Auf unterstützten NVIDIA-GPUs stellt NVML einen Gesamtenergiezähler in Millijoule bereit. Eine minimale Python-Probe kann einen festen Workload eingrenzen:
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
Die NVML-Dokumentation zu Geräteabfragen definiert den Zähler und seine Einheiten. Prüfe die Unterstützung auf der exakten GPU und mit dem exakten Treiber. Der kumulative Wert wird zurückgesetzt, wenn der Treiber neu geladen wird; verwerfe daher ein negatives oder fehlerhaftes Delta. Für Geräte ohne Energiezähler solltest du die Leistung mit einer Rate abtasten, die kurze Anfragen erfasst, und die Kurve über dasselbe Zeitfenster integrieren.
GPU-Energie ist eine gültige Grenze, wenn du sie benennst. Für Kapazitäts-, Kosten- oder CO₂-Bilanzierung solltest du je nach Entscheidung Host- und Facility-Bestandteile hinzufügen. Die CodeCarbon-Dokumentation kann das Audit erweitern, aber lies nach, welche Werte das Tool misst und welche es schätzt. Eine externe Messung am Rack oder an der Wand bleibt die bessere Kontrolle für Vergleiche ganzer Nodes.
5. Normalisiere das Ergebnis auf mehr als eine Weise
Berichte eine kleine Gruppe von Metriken statt einer einzigen Gewinnerzahl:
Eine Metrik hilft bei der Optimierung des Decode-Pfads. Eine andere verbindet die Änderung mit dem Produktwert. Die Felder für Latenz und Qualität verhindern, dass eine Energieoptimierung den Service unbemerkt schwächt.
6. Ändere eine Steuergröße und spiele die Nachfrage erneut ab
Beginne mit isolierten Experimenten: Präzision, Batch-Policy, Request-Bucketing, Cache-Setup, GPU-Power- oder Clock-Limit und Platzierung. Führe nach dem Warm-up wiederholte Versuche durch. Ändere die Reihenfolge zwischen den Versuchen, wenn Wärme oder Tageszeit das Ergebnis verzerren könnten.
Spiele anschließend die besten Kandidaten unter gemischten Ankünften erneut ab. Festina und AFlex koordinieren mehrere Steuergrößen, weil lokale Optima miteinander interagieren. Dein erster Durchlauf sollte Ursachen isolieren; dein finaler Durchlauf sollte die kombinierte Policy unter dem realen SLO testen.
Optimiere in der Reihenfolge, die von der Evidenz gestützt wird
Die sicherste Optimierungsreihenfolge beginnt mit verschwendeter Arbeit und bewegt sich anschließend zu engeren Hardwarekontrollen.
Wenn das System verschiedene Qualitätsstufen bedient, kombiniere diesen Prozess mit einem Benchmark für reale Arbeit. Der praktische Workflow für Model-Benchmarking hält Qualität, Latenz und Kosten sichtbar, während du den Serving-Pfad änderst.
Verwechsle Energie, Kosten und CO₂ nicht
Diese Metriken beantworten unterschiedliche Fragen.
Eine niedrigere Cloud-Rechnung beweist keine geringere Energie. Ein niedrigerer GPU-Zähler beweist keine geringere Facility-Energie. Ein Lauf mit geringerem Energieverbrauch hat nicht automatisch niedrigere Emissionen, wenn er zu einer anderen Zeit oder an einem anderen Ort ausgeführt wird.
Das Berichtsproblem ist inzwischen so relevant, dass es in die Standardisierungsarbeit einfließt. Ein ITU-T-Arbeitspunkt zu Metriken für die Energieeffizienz von AI-Inferenz umfasst Token-Grenzen, Energie-pro-Token-Indikatoren, CO₂-Berechnungen und Berichtsregeln. Diese Arbeit zeigt, dass Token-Einheiten und Systemgrenzen weiterhin nicht abschließend geklärt sind. Sie ist kein fertiger Benchmark.
Die Entscheidungsregel für die Produktion
Akzeptiere eine Änderung der LLM-Energieeffizienz nur dann, wenn sie den Energieverbrauch für die vorgesehene Einheit nützlicher Arbeit senkt und den Anfragevertrag innerhalb des Budgets hält.
Formuliere diesen Vertrag vor dem Test:
Diese Regel verhindert drei häufige Fehler: Watt statt Joule zu optimieren, abgeschlossene Tokens zu optimieren und dabei Fehler zu verbergen, sowie das „bis zu“-Ergebnis einer Studie auf andere Hardware zu übertragen.
Die Forschung weist auf eine praktische Richtung hin, nicht auf eine universelle Einstellung. Profiliere Prefill und Decode getrennt. Halte Anfrage-, Runtime- und Hardwaredaten miteinander verknüpft. Miss die Grenze, die du verwalten willst. So wird aus einer Energiezahl eine technische Entscheidung.