LLM-energieffektivitet är inte en fast modeleegenskap. Samma modell kan förbruka mycket olika mängder energi per användbar förfrågan när du ändrar prefill-längd, output-längd, batchform, precision, tidpunkt för förfrågningar, GPU-klockfrekvenser eller serving-runtime. Mät dessa faktorer tillsammans med latens och kvalitet innan du kallar en konfiguration effektiv.
Den här guiden är för avancerade läsare som driver eller utvärderar LLM-inference. Den praktiska slutsatsen är enkel: samla in energi på enhets- eller nodnivå, förklara den med serving-telemetri och normalisera den mot nyttigt arbete på förfrågningsnivå. En enda wattmätning kan inte göra alla tre saker.
Skillnaden blir viktigare när reasoning-budgetar växer. Extra genererade tokens ökar beräkningsarbetet, men systemet runt dessa tokens avgör hur effektivt hårdvaran utför arbetet. Min tidigare analys av reasoning-tokens och deras beräkningskostnad täcker arbetsbelastningssidan. Den här artikeln fokuserar på energigranskning och serving-sidan.
LLM-energieffektivitet är ett resultat av serving-stacken
Energi är effekt integrerad över tid. Om en GPU i genomsnitt använder 400 watt i tio sekunder förbrukar den 4 000 joule. Den delen är enkel. Det svåra är att välja tidsfönster, hårdvarugräns och rapporteringsenhet.
”Energi per token” kan betyda minst tre olika saker:
| Mätvärde | Användbart för | Vad det kan dölja |
|---|---|---|
| --- | --- | --- |
| Joule per output-token | Decode-tung chatt och generering | Promptbearbetning, misslyckade förfrågningar, kvalitetsskillnader |
| Joule per effektiv input-token | Prefill och arbete med lång kontext | Output-arbete och värdet av förfrågan från början till slut |
| Joule per lyckad förfrågan | Produkt- och arbetsbelastningsjämförelser | Stora skillnader i prompt- och svarslängd |
| Förfrågningar per kilowattimme | Kapacitet och operativ planering | Förfrågningarnas svårighetsgrad, kvalitet och latens |
Ingen av dem är universellt korrekt. Välj den enhet som motsvarar tjänstekontraktet och rapportera sedan tillräckligt med kontext för att ett annat team ska kunna upprepa testet.
Hårdvarugränsen är lika viktig. NVIDIAs management-API exponerar energiräknare för enheter på hårdvara som stöds. Det kan ge en tydlig GPU-differens, men inkluderar som standard inte CPU-arbete, värdminne, lagring, nätverk, kylning eller effektomvandlingsförluster. CodeCarbon kan utöka gränsen med uppmätta och uppskattade delar, men dokumentationen beskriver reservuppskattningar för hårdvara som verktyget inte kan läsa av. ”Mätt av ett verktyg” betyder inte att varje del har mätts.
Fyra studier mätte olika delar av stacken
Ny forskning gör systemeffekten synlig. Procentsiffrorna nedan är ingen topplista. Varje studie använder en annan plattform, arbetsbelastning, baslinje och energigräns.
| Studie | Omfattning och metod | Rapporterat resultat | Gräns att hålla i åtanke |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Delar upp attention- och feed-forward-arbete och styr sedan provisionering, frekvens, batchstorlek och microbatching på A800-system | Upp till 49 % mindre energi per token än den testade disaggregated-baslinjen samtidigt som TTFT- och TPOT-målen uppfylldes | Två modellfamiljer, A800-hårdvara och utvärderade traces i produktionsstil |
| Festina | Samordnar placering, GPU-partitionering, driftspunkt, konsolidering och migrering för delad H100-inference | Upp till 56 % lägre energiförbrukning, medan SLO-uppfyllelsen i den rapporterade konfigurationen hölls inom två procentenheter | Serverless-kontext med delade GPU:er; vinsterna minskar när prefill redan är beräkningsintensiv |
| EnerInfer | Förutspår throughput och effekt över NPU- och minnesinställningar och hanterar sedan styrinställningar under termiska begränsningar | Energieffektivitetsvinster på 65 % i telefoner, 12 % på en laptop och 24 % på ett edge-kort | Besparingarna för hela enheten var mindre, 4,2–11 %, eftersom andra delar och faser fortfarande förbrukade energi |
| Understanding Efficiency | Testar kvantisering, batching, ankomstmönster och serving-val på H100-GPU:er | Continuous batching minskade energin per förfrågan med 12,5× jämfört med studiens sekventiella baslinje; strukturerade ankomster nådde större vinster i ett fast test | Korta promptar, två Llama-modellstorlekar, en acceleratorfamilj och huvudsakligen GPU-fokuserade energidata |
Det gemensamma resultatet är starkare än någon enskild procentsiffra: orkestrering kan förändra energianvändningen tillräckligt mycket för att ogiltigförklara en modellbaserad uppskattning. Artiklarna visar också varför ”använd lägre precision” är ett ofullständigt råd. H100-studien fann att lägre precision hjälpte beräkningsbunden prefill, medan dequantization- och kernel-overhead kunde radera eller vända fördelen under minnesbunden decode.
Behandla varje ”upp till”-siffra som en egenskap hos författarnas experiment. AFlex bevisar inte en besparing på 49 % i ditt B200-kluster. EnerInfer bevisar inte en besparing på 65 % för hela enheten i varje telefon. Resultaten identifierar kontroller som är värda att testa, inte besparingar du kan kopiera in i en prognos.
Separera prefill från decode innan du optimerar
En LLM-förfrågan har två faser med olika flaskhalsar.
Prefill är vanligtvis beräkningsintensiv
Prefill bearbetar prompten och bygger key-value-cachen. Långa promptar skapar intensiva utbrott av parallellt matrisarbete. Precisionsändringar och högre klockfrekvenser kan hjälpa när denna fas är beräkningsbunden, men kortare time-to-first-token kan fortfarande komma med en högre effekttopp. Mät energi, inte bara effekt.
Decode är vanligtvis minnesintensiv
Decode producerar tokens ett steg i taget. Den läser upprepade gånger modellvikter och den växande KV-cachen, så minnestrafik och batchbildning dominerar ofta. Högre klockfrekvenser kan öka effekten utan proportionell throughput. Kvantisering kan också lägga till konverteringskostnader när kernels eller hårdvarusökvägen inte passar väl ihop.
Denna fasuppdelning förklarar varför ett genomsnitt över hela förfrågan kan vara missvisande. En konfiguration kan förbättra prefill för långa promptar och försämra decode för korta promptar. Rapportera åtminstone promptlängd, output-längd, batch eller samtidighet, precision och fasernas tidsmätningar tillsammans med varje energiresultat.
KV-cachen hör hemma i samma post. Min guide till misslyckanden vid KV-cache eviction förklarar tillförlitlighetssidan. För energiarbete kan cachetryck förändra minnestrafik, omberäkning, placering och antal omförsök. En körning med tysta evictions är inte jämförbar med en utan dem.
Genomför en energigranskning som skyddar latens-SLO:er
Granskningen behöver tre sammankopplade lager: resultat för förfrågningar, serving-kontext och energi på enhets- eller nodnivå.
*Ett användbart energiresultat behöver en tydlig enhet, serving-kontext och en uttrycklig hårdvarugräns.*
1. Lås en representativ arbetsbelastning
Skapa arbetsbelastningssegment i stället för ett enda syntetiskt genomsnitt. Separera åtminstone korta och långa promptar, korta och långa output, jämna och burstiga ankomster samt de kvalitetsnivåer som applikationen använder. Håll modell, tokenizer, sampling-policy och stoppregler fasta under en jämförelse.
Använd verkliga förfrågningsformer när integritet och samtycke tillåter det. Om du använder syntetiska promptar ska du bevara de tokenlängds- och ankomstfördelningar som driver systemet. Slutrapporten ska märka syntetisk efterfrågan som syntetisk.
2. Registrera resultat på förfrågningsnivå
Fånga följande för varje förfrågan:
Ta inte bort misslyckanden från energitotalen. En konfiguration som förbrukar mindre energi på slutförda förfrågningar genom att låta de svåra löpa ut är inte effektivare.
3. Registrera serving-kontext
Logga de kontroller som kan förklara en förändring: prefill- och decode-varaktighet, batchstorlek, aktiva sekvenser, ködjup, precision, parallellism, cache-beläggning, placering, GPU-klockfrekvenser eller effektgräns samt belastning från samhyresgäster.
Denna telemetri fångar också idle- och bursteffekter. En runtime som håller CPU:er upptagna medan GPU:n väntar kan se bra ut i en GPU-mätning och sämre ut vid nod- eller fleet-gränsen. Trådar i open source-issue trackers är användbara för att hitta dessa fellägen, men de är anekdoter tills du återskapar dem i din stack.
4. Mät en uttrycklig energigräns
På NVIDIA-GPU:er som stöds exponerar NVML en total energiräknare i millijoule. En minimal Python-prob kan rama in en fast arbetsbelastning:
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
NVML-dokumentationen för enhetsfrågor definierar räknaren och dess enheter. Kontrollera stöd på den exakta GPU:n och drivrutinen. Det kumulativa värdet återställs när drivrutinen laddas om, så avvisa en negativ eller trasig differens. För enheter utan energiräknare ska du sampla effekt med en frekvens som fångar korta förfrågningar och integrera kurvan över samma tidsfönster.
GPU-energi är en giltig gräns om du namnger den. För kapacitets-, kostnads- eller koldioxidredovisning ska du lägga till värd- och anläggningsdelar enligt vad beslutet kräver. CodeCarbon-dokumentationen kan bredda granskningen, men läs vilka värden verktyget mäter och vilka det uppskattar. Extern mätning vid rack eller vägg är fortfarande den starkare kontrollen för jämförelser av hela noder.
5. Normalisera resultatet på mer än ett sätt
Rapportera en liten uppsättning mätvärden i stället för ett enda vinnande tal:
Ett mätvärde hjälper till att finjustera decode-sökvägen. Ett annat kopplar förändringen till produktvärde. Latens- och kvalitetsfälten hindrar en energioptimering från att i tysthet försvaga tjänsten.
6. Ändra en kontroll och spela sedan upp efterfrågan
Börja med isolerade experiment: precision, batch-policy, gruppering av förfrågningar, cache-konfiguration, GPU-effekt eller klockgräns samt placering. Kör upprepade försök efter uppvärmning. Ändra ordningen mellan försöken när värme eller tid på dagen kan snedvrida resultatet.
Spela sedan upp de bästa kandidaterna under blandade ankomster. Festina och AFlex samordnar båda flera kontroller eftersom lokala optimum samverkar. Ditt första steg bör isolera orsaker; det slutliga steget bör testa den kombinerade policyn under det verkliga SLO:t.
Optimera i den ordning som evidensen stöder
Den säkraste optimeringsordningen börjar med bortkastat arbete och går sedan mot stramare hårdvarukontroller.
Om systemet betjänar olika kvalitetsnivåer ska du kombinera denna process med ett benchmark för verkligt arbete. Det praktiska arbetsflödet för modellbenchmarking håller kvalitet, latens och kostnad synliga medan du ändrar serving-sökvägen.
Blanda inte ihop energi, kostnad och koldioxid
Dessa mätvärden besvarar olika frågor.
En lägre molnräkning bevisar inte lägre energiförbrukning. En lägre GPU-räknare bevisar inte lägre energiförbrukning i anläggningen. En körning med lägre energiförbrukning har inte automatiskt lägre utsläpp om den körs vid en annan tid eller på en annan plats.
Rapporteringsproblemet är tillräckligt aktuellt för att nå standardiseringsarbete. Ett ITU-T-arbetsobjekt om energieffektivitetsmått för AI-inference omfattar token-gränser, indikatorer för energi per token, koldioxidberäkningar och rapporteringsregler. Arbetet visar att token-enheter och systemgränser fortfarande är oklara. Det är inget färdigt benchmark.
Beslutsregeln för produktion
Godkänn en förändring av LLM-energieffektiviteten endast när den minskar energin för den avsedda enheten nyttigt arbete och håller förfrågningskontraktet inom budget.
Skriv kontraktet före testet:
Denna regel förhindrar tre vanliga fel: att optimera watt i stället för joule, att optimera slutförda tokens samtidigt som fel döljs och att överföra en artikels ”upp till”-resultat till annan hårdvara.
Forskningen pekar mot en praktisk riktning, inte en universell inställning. Profilera prefill och decode separat. Håll posterna för förfrågning, runtime och hårdvara sammanlänkade. Mät den gräns du planerar att styra. Det är så ett energital blir till ett tekniskt beslut.