LLMのエネルギー効率は、モデルに固定された特性ではありません。同じモデルでも、Prefillの長さ、出力の長さ、Batchの形状、Precision、リクエストのタイミング、GPUのクロック、Serving Runtimeを変えると、有用なリクエスト1件あたりの消費エネルギーは大きく変わります。ある構成を効率的だと判断する前に、LatencyとQualityとともに、これらの要因を測定してください。
このガイドは、LLM Inferenceを運用または評価する上級者向けです。実務上の結論はシンプルです。エネルギーをデバイスまたはノードで収集し、Serving Telemetryで説明し、リクエスト層の有用な仕事量に対して正規化します。単一のワット数の読み取り値だけでは、この3つの役割をすべて果たせません。
Reasoning Budgetが増えるほど、この区別は重要になります。生成される追加Tokenは計算量を増やしますが、ハードウェアがその処理をどれだけ効率的に実行できるかは、そのTokenを取り巻くシステムによって決まります。以前のReasoning Tokenとその計算コストに関する分析では、Workload側を扱いました。この記事では、Energy AuditとServing側に焦点を当てます。
LLMのエネルギー効率はServing Stackの結果である
エネルギーは、時間にわたって積分された電力です。GPUが10秒間平均400ワットで動作した場合、4,000ジュールを消費します。ここまでは簡単です。難しいのは、時間の範囲、ハードウェアの境界、報告単位を選ぶことです。
「Tokenあたりのエネルギー」は、少なくとも次の3つの異なる意味を持ちます。
| Metric | Useful for | What it can hide |
|---|---|---|
| --- | --- | --- |
| 出力Tokenあたりのジュール | Decode中心のChatとGeneration | Prompt処理、失敗したリクエスト、Qualityの違い |
| 実効入力Tokenあたりのジュール | PrefillとLong Contextの処理 | 出力処理とEnd-to-Endのリクエスト価値 |
| 成功したリクエストあたりのジュール | ProductとWorkloadの比較 | PromptとResponseの長さの大きな違い |
| キロワット時あたりのリクエスト数 | Capacityと運用計画 | リクエストの難易度、Quality、Latency |
普遍的に正しい指標はありません。Service Contractに合う単位を選び、別のチームがテストを再現できるよう、十分なコンテキストを併せて報告してください。
ハードウェアの境界も同じくらい重要です。NVIDIAのManagement APIは、対応ハードウェア上でデバイスのエネルギーカウンターを公開します。これによりGPUの差分を明確に取得できますが、デフォルトではCPU処理、ホストメモリ、Storage、Network、Cooling、電力変換損失は含まれません。CodeCarbonは、測定値と推定値を組み合わせて境界を広げられますが、読み取れないハードウェアについてはFallback推定値を使うとドキュメントに記載されています。「ツールで測定した」ことは、すべての部分がMeteringされたことを意味しません。
4つの研究がStackの異なる部分を測定した
近年の研究は、システムの影響を明らかにしています。以下の見出しとなる割合はLeaderboardではありません。各研究は、異なるPlatform、Workload、Baseline、Energy Boundaryを使用しています。
| Study | Scope and method | Reported result | Boundary to keep in view |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | AttentionとFeed-Forward処理を分離し、A800システム上でProvisioning、Frequency、Batch Size、Microbatchingを制御 | TTFTとTPOTの目標を満たしながら、テストした分離構成のBaselineと比べてTokenあたり最大49%のエネルギー削減 | 2つのModel Family、A800 Hardware、評価対象となったProduction形式のTrace |
| Festina | 共有H100 Inference向けに、配置、GPU Partitioning、Operating Point、Consolidation、Migrationを調整 | 報告された構成でSLO達成率を2ポイント以内に維持しながら、エネルギーを最大56%削減 | 共有GPUのServerless Context。PrefillがすでにCompute Intensiveな場合、効果は小さくなる |
| EnerInfer | NPUとMemoryの設定全体でThroughputとPowerを予測し、Thermal Limit下でControl Settingを管理 | Phoneで65%、Laptopで12%、Edge Boardで24%のEnergy Efficiency向上 | End-to-Endのデバイス削減は4.2〜11%と小さかった。その他の部分とPhaseが依然としてエネルギーを消費したため |
| Understanding Efficiency | H100 GPU上でQuantization、Batching、Arrival Pattern、Servingの選択をテスト | Continuous Batchingにより、研究のSequential Baselineと比べてリクエストあたりのエネルギーを12.5倍削減。固定テストではStructured Arrivalでさらに大きな効果 | Short Prompt、2種類のLlama Model Size、1種類のAccelerator Family、主にGPU中心のEnergy Data |
共通する結果は、個々の割合よりも重要です。Orchestrationは、Modelだけから見積もった値を無効にするほどエネルギー使用量を変えられます。また、論文は「Lower Precisionを使う」という助言が不完全である理由も示しています。H100の研究では、Lower PrecisionはCompute-BoundなPrefillには有効でしたが、Memory-BoundなDecodeではDequantizationとKernel Overheadが効果を打ち消したり、逆効果にしたりする可能性がありました。
「最大」という数値はすべて、著者の実験における特性として扱ってください。AFlexは、あなたのB200 Clusterで49%の削減が実現することを証明していません。EnerInferは、すべてのPhoneでデバイス全体のエネルギーを65%削減できることを証明していません。これらの結果は、テストする価値のあるControlを示すものであり、Forecastにそのままコピーできる削減量ではありません。
最適化する前にPrefillとDecodeを分ける
LLMのリクエストには、ボトルネックが異なる2つのPhaseがあります。
Prefillは通常Compute Heavyである
PrefillはPromptを処理し、Key-Value Cacheを構築します。長いPromptは、並列性の高いMatrix処理のBurstを生みます。このPhaseがCompute-Boundであれば、Precisionの変更や高いClockが有効な場合がありますが、Time to First Tokenが短くなってもPower Peakが高くなる可能性があります。Powerだけでなく、エネルギーを測定してください。
Decodeは通常Memory Heavyである
Decodeは、一度に1つずつTokenを生成します。Model Weightと増加するKV Cacheを繰り返し読み込むため、Memory TrafficとBatch形成が支配的になることがよくあります。高いClockは、Throughputに比例した効果をもたらさずにPowerだけを増加させる可能性があります。KernelやHardware Pathとの適合が不十分な場合、QuantizationによってConversion Overheadが追加されることもあります。
このPhase分割は、リクエスト全体の平均が誤解を招く理由を説明します。ある構成がLong PromptのPrefillを改善する一方で、Short PromptのDecodeを悪化させる可能性があります。すべてのEnergy Resultに、少なくともPrompt Length、Output Length、BatchまたはConcurrency、Precision、Phase Timingを記録してください。
KV Cacheも同じ記録に含めるべきです。KV Cache Evictionの失敗に関するガイドでは、Reliability側を説明しています。Energy Workでは、Cache PressureがMemory Traffic、Recomputation、Placement、Retry Rateを変える可能性があります。静かなEvictionが発生しているRunは、発生していないRunと比較できません。
Latency SLOを守るEnergy Auditを実行する
Auditには、Request Outcome、Serving Context、DeviceまたはNode Energyという、相互に接続された3つのLayerが必要です。
*有用なEnergy Resultには、明確な単位、Serving Context、明示的なHardware Boundaryが必要です。*
1. 代表的なWorkloadを固定する
1つのSynthetic Averageではなく、Workload Sliceを作成してください。最低限、Short PromptとLong Prompt、Short OutputとLong Output、Steady ArrivalとBursty Arrival、アプリケーションが使用するQuality Tierを分けます。比較中は、Model、Tokenizer、Sampling Policy、Stopping Ruleを固定してください。
PrivacyとConsentが許す場合は、実際のリクエスト形状を使用してください。Synthetic Promptを使う場合は、システムを動かすToken LengthとArrival Distributionを維持します。最終レポートでは、Synthetic DemandをSyntheticとして明示してください。
2. Request LevelのOutcomeを記録する
各リクエストについて、次を取得します。
Energy Totalから失敗を削除しないでください。難しいリクエストをTimeoutさせることで完了したリクエストのエネルギーを少なく見せる構成は、より効率的ではありません。
3. Serving Contextを記録する
変化を説明できるControlをLogに記録します。PrefillとDecodeのDuration、Batch Size、Active Sequence数、Queue Depth、Precision、Parallelism、Cache Occupancy、Placement、GPU ClockまたはPower Limit、Co-Tenant Loadなどです。
このTelemetryは、IdleとBurstの影響も捉えます。GPUが待機している間もCPUを稼働させ続けるRuntimeは、GPUのみの読み取りでは問題なく見えても、NodeまたはFleetの境界では悪化して見える可能性があります。Open SourceのIssue Threadは、こうしたFailure Modeを見つけるのに役立ちますが、自分のStackで再現するまでは逸話にすぎません。
4. 明示的なEnergy Boundaryを測定する
対応するNVIDIA GPUでは、NVMLがミリジュール単位のTotal Energy Counterを公開します。最小限のPython Probeで、固定Workloadの前後を測定できます。
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 Device Queryのドキュメントでは、Counterとその単位を定義しています。正確なGPUとDriverでサポート状況を確認してください。累積値はDriverがReloadされるとResetされるため、負の差分や壊れた差分は除外します。Energy Counterのないデバイスでは、短いリクエストを捉えられるRateでPowerをSamplingし、同じWindowでTraceを積分してください。
GPU Energyは、名前を明示すれば有効なBoundaryです。Capacity、Cost、Carbon Accountingでは、意思決定に応じてHostとFacilityの要素を追加してください。CodeCarbonのドキュメントはAuditの範囲を広げられますが、Toolがどの値を測定し、どの値を推定しているかを確認してください。Whole Nodeの比較では、外部のRackまたはWall Meteringがより強力な検証になります。
5. 結果を複数の方法で正規化する
1つの勝ち数値ではなく、小さなMetric Setを報告してください。
1つのMetricはDecode PathのTuningに役立ちます。別のMetricは、変更をProduct Valueに結び付けます。LatencyとQualityの項目により、Energy Optimizationがサービスを密かに弱体化させることを防げます。
6. 1つのControlを変更してからDemandを再生する
まず、Precision、Batch Policy、Request Bucketing、Cache Setup、GPU PowerまたはClock Limit、Placementについて、分離した実験を行います。Warm-up後にTrialを繰り返してください。熱や時刻が結果に偏りを与える可能性がある場合は、Trial間で順序を入れ替えます。
次に、最良の候補をMixed Arrivalの下で再生します。FestinaとAFlexはいずれも複数のControlを調整しています。これは、局所最適が相互作用するためです。最初のPassでは原因を分離し、最終Passでは実際のSLOの下でCombined Policyをテストしてください。
Evidenceが支持する順序で最適化する
最も安全なOptimization Orderは、無駄な処理から始め、より細かなHardware Controlへ進むことです。
システムが異なるQuality Tierを提供する場合は、このプロセスを実際のWork Benchmarkと組み合わせてください。実務的なModel Benchmarking Workflowでは、Serving Pathを変更する間もQuality、Latency、Costを可視化できます。
Energy、Cost、Carbonを混同しない
これらのMetricは、それぞれ異なる問いに答えます。
Cloud Billが低くなったからといって、Energyが低くなったとは限りません。GPU Counterが低くなったからといって、Facility Energyが低くなったとは限りません。Energyの少ないRunでも、異なる時間や場所で実行されれば、Emissionが自動的に低くなるわけではありません。
Reportingの問題は、Standards Workにまで発展するほど活発です。AI InferenceのEnergy Efficiency Metricに関するITU-T Work Itemでは、Token Boundary、Energy-per-Token Indicator、Carbon Math、Reporting RuleがScopeに含まれています。この取り組みは、Token UnitとSystem Boundaryが依然として確定していないことを示しています。これは完成済みのBenchmarkではありません。
Productionにおける意思決定ルール
LLMのEnergy Efficiencyの変更は、意図した有用な仕事量の単位あたりのEnergyを削減し、Request Contractを予算内に維持できる場合にのみ採用してください。
テストの前に、そのContractを記述します。
このルールは、よくある3つの誤りを防ぎます。JouleではなくWattを最適化すること、Failureを隠しながらCompleted Tokenを最適化すること、論文の「最大」という結果を異なるHardwareに移植することです。
研究が示しているのは、普遍的な設定ではなく、実務的な方向性です。PrefillとDecodeを分けてProfileしてください。Request、Runtime、Hardwareの記録を結合した状態に保ってください。管理する予定のBoundaryを測定してください。そうすることで、Energyの数値がEngineering Decisionになります。