LLM enerji verimliliği sabit bir model özelliği değildir. Prefill uzunluğunu, output uzunluğunu, batch şeklini, precision’ı, request zamanlamasını, GPU saat hızlarını veya serving runtime’ını değiştirdiğinizde aynı model, yararlı bir request başına çok farklı miktarda enerji tüketebilir. Bir kurulumu verimli olarak nitelendirmeden önce bu faktörleri latency ve kaliteyle birlikte ölçün.
Bu rehber, LLM inference işleten veya değerlendiren ileri düzey okuyucular içindir. Pratik sonuç basittir: enerjiyi device veya node seviyesinde toplayın, serving telemetry ile açıklayın ve request katmanındaki yararlı işe göre normalize edin. Tek bir watts ölçümü bu üç görevi birden yerine getiremez.
Reasoning bütçeleri büyüdükçe bu ayrım daha önemli hale gelir. Üretilen ek token’lar compute miktarını artırır, ancak bu token’ların çevresindeki sistem, donanımın bu işi ne kadar verimli yaptığına karar verir. reasoning token’ları ve compute maliyetleri üzerine önceki analizim workload tarafını ele alıyor. Bu makale energy audit ve serving tarafına odaklanıyor.
LLM enerji verimliliği serving stack’in sonucudur
Enerji, zaman boyunca entegre edilmiş power’dır. Bir GPU on saniye boyunca ortalama 400 watt çalışırsa 4.000 joule enerji kullanır. Bu kısım kolaydır. Zor olan, zaman aralığını, donanım sınırını ve raporlama birimini seçmektir.
“Token başına enerji” en az üç farklı anlama gelebilir:
| Metric | Useful for | What it can hide |
|---|---|---|
| --- | --- | --- |
| Output token başına joule | Decode ağırlıklı chat ve generation | Prompt processing, başarısız request’ler, kalite farklılıkları |
| Effective input token başına joule | Prefill ve long-context çalışmaları | Output işi ve uçtan uca request değeri |
| Başarılı request başına joule | Product ve workload karşılaştırması | Prompt ve response uzunluğundaki büyük farklılıklar |
| Kilowatt-hour başına request | Capacity ve operasyonel planlama | Request zorluğu, kalite ve latency |
Hiçbiri evrensel olarak doğru değildir. Service contract ile eşleşen birimi seçin, ardından başka bir ekibin testi tekrarlayabilmesi için yeterli bağlamı raporlayın.
Donanım sınırı da aynı derecede önemlidir. NVIDIA’nın management API’si desteklenen donanımlarda device energy counter’ları sunar. Bu, temiz bir GPU delta’sı üretebilir, ancak varsayılan olarak CPU işini, host memory’yi, storage’ı, networking’i, cooling’i veya power-conversion kayıplarını içermez. CodeCarbon, ölçülen ve tahmin edilen parçalarla sınırı genişletebilir; ancak dokümanları okuyamadığı donanımlar için fallback tahminleri açıklar. “Bir tool tarafından ölçüldü” ifadesi her parçanın metered olduğu anlamına gelmez.
Dört çalışma stack’in farklı bölümlerini ölçtü
Yakın tarihli araştırmalar sistem etkisini görünür kılıyor. Aşağıdaki headline yüzdeleri bir leaderboard değildir. Her çalışma farklı bir platform, workload, baseline ve energy boundary kullanır.
| Study | Scope and method | Reported result | Boundary to keep in view |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Attention ve feed-forward işini ayırır; ardından A800 sistemlerinde provisioning, frequency, batch size ve microbatching’i kontrol eder | Test edilen disaggregated baseline’a kıyasla token başına %49’a kadar daha az enerji; TTFT ve TPOT hedefleri karşılanırken | İki model ailesi, A800 donanımı ve değerlendirilen production-style trace’ler |
| Festina | Paylaşımlı H100 inference için placement, GPU partitioning, operating point, consolidation ve migration’ı koordine eder | Raporlanan kurulumda SLO attainment iki yüzde puanı içinde korunurken %56’ya kadar daha düşük enerji | Paylaşımlı GPU serverless bağlamı; prefill zaten compute-intensive olduğunda kazanımlar azalır |
| EnerInfer | NPU ve memory ayarları genelinde throughput ve power’ı tahmin eder, ardından thermal limit’ler altında control ayarlarını yönetir | Energy-efficiency kazanımları telefonlarda %65, laptop’ta %12 ve edge board’da %24 | Uçtan uca device tasarrufu daha küçüktü: %4,2–11; çünkü diğer parçalar ve fazlar hâlâ enerji tüketiyordu |
| Understanding Efficiency | H100 GPU’larda quantization, batching, arrival pattern’leri ve serving tercihlerini test eder | Continuous batching, çalışmanın sequential baseline’ına kıyasla request başına enerjiyi 12,5 kat azalttı; sabit bir testte structured arrival’lar daha büyük kazanımlara ulaştı | Kısa prompt’lar, iki Llama model boyutu, tek accelerator ailesi ve çoğunlukla GPU odaklı energy data |
Ortak sonuç, herhangi bir tekil yüzdeden daha güçlüdür: orchestration enerji kullanımını model-only tahminini geçersiz kılacak kadar değiştirebilir. Makaleler ayrıca “daha düşük precision kullanın” tavsiyesinin neden eksik olduğunu gösteriyor. H100 çalışması, daha düşük precision’ın compute-bound prefill’e yardımcı olduğunu; ancak memory-bound decode sırasında dequantization ve kernel overhead’inin faydayı ortadan kaldırabileceğini veya tersine çevirebileceğini buldu.
Her “up to” sayısını yazarların deneyinin bir özelliği olarak değerlendirin. AFlex, B200 cluster’ınızda %49 tasarrufu kanıtlamaz. EnerInfer, her telefon için %65 whole-device tasarrufu kanıtlamaz. Sonuçlar, forecast’e doğrudan kopyalayabileceğiniz tasarrufları değil, test etmeye değer kontrolleri belirler.
Optimize etmeden önce prefill’i decode’dan ayırın
Bir LLM request’i, farklı bottleneck’lere sahip iki fazdan oluşur.
Prefill genellikle compute-heavy’dir
Prefill prompt’u işler ve key-value cache’i oluşturur. Uzun prompt’lar, paralel matrix işi patlamaları yaratır. Bu faz compute-bound olduğunda precision değişiklikleri ve daha yüksek clock’lar yardımcı olabilir; ancak daha düşük time-to-first-token yine de daha yüksek bir power peak ile birlikte gelebilir. Yalnızca power’ı değil, enerjiyi de ölçün.
Decode genellikle memory-heavy’dir
Decode token’ları her seferinde bir adım üreterek oluşturur. Model weight’lerini ve büyüyen KV cache’i tekrar tekrar okuduğu için memory traffic ve batch formation çoğu zaman baskın hale gelir. Daha yüksek clock’lar, throughput ile orantılı bir artış olmadan power’ı yükseltebilir. Kernel’ler veya hardware path iyi eşleşmediğinde quantization conversion overhead’i de ekleyebilir.
Bu faz ayrımı, tüm request üzerinden alınan bir ortalamanın neden yanıltıcı olabileceğini açıklar. Bir kurulum long-prompt prefill’i iyileştirirken short-prompt decode’u kötüleştirebilir. Her energy sonucuyla birlikte en azından prompt length, output length, batch veya concurrency, precision ve phase timing’lerini raporlayın.
KV cache de aynı kaydın parçası olmalıdır. KV cache eviction failures rehberim reliability tarafını açıklıyor. Energy çalışmaları açısından cache pressure; memory traffic’i, recomputation’ı, placement’ı ve retry rate’lerini değiştirebilir. Sessiz eviction’ların yaşandığı bir run, bunların yaşanmadığı bir run ile karşılaştırılamaz.
Latency SLO’larını koruyan bir energy audit yürütün
Audit’in birbiriyle bağlantılı üç katmana ihtiyacı vardır: request outcomes, serving context ve device veya node energy.
*Yararlı bir energy sonucu net bir birime, serving context’e ve açıkça belirtilmiş bir hardware boundary’ye ihtiyaç duyar.*
1. Temsili bir workload’u sabitleyin
Tek bir synthetic average yerine workload slice’ları oluşturun. En azından short ve long prompt’ları, short ve long output’ları, steady ve bursty arrival’ları ve uygulamanızın kullandığı quality tier’larını ayırın. Bir karşılaştırma sırasında model’i, tokenizer’ı, sampling policy’yi ve stopping rule’ları sabit tutun.
Privacy ve consent izin verdiğinde gerçek request shape’lerini kullanın. Synthetic prompt’lar kullanıyorsanız sistemi yönlendiren token-length ve arrival distribution’larını koruyun. Final report, synthetic demand’i synthetic olarak etiketlemelidir.
2. Request-level outcome’ları kaydedin
Her request için şunları yakalayın:
Failure’ları energy total’ından silmeyin. Zor request’leri timeout’a uğratarak tamamlanan request’lerde daha az enerji harcayan bir setup daha verimli değildir.
3. Serving context’i kaydedin
Bir değişikliği açıklayabilecek kontrolleri log’layın: prefill ve decode duration, batch size, active sequence’lar, queue depth, precision, parallelism, cache occupancy, placement, GPU clock’ları veya power limit’i ve co-tenant load.
Bu telemetry idle ve burst etkilerini de yakalar. GPU beklerken CPU’ları meşgul tutan bir runtime, GPU-only reading’de iyi görünüp node veya fleet boundary’sinde daha kötü görünebilir. Open-source issue thread’leri bu failure mode’larını bulmak için yararlıdır, ancak kendi stack’inizde yeniden üretmediğiniz sürece anecdote olarak kalırlar.
4. Açık bir energy boundary ölçün
Desteklenen NVIDIA GPU’larda NVML, millijoule cinsinden total-energy counter sunar. Minimal bir Python probe, sabit bir workload’un sınırlarını belirleyebilir:
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 docs counter’ı ve birimlerini tanımlar. Tam GPU ve driver üzerinde desteği kontrol edin. Cumulative value, driver reload edildiğinde sıfırlanır; bu nedenle negatif veya bozuk bir delta’yı reddedin. Energy counter’ı olmayan device’larda kısa request’leri yakalayacak bir rate’te power sample’layın ve trace’i aynı zaman aralığı boyunca entegre edin.
GPU energy, adını açıkça koyduğunuz sürece geçerli bir boundary’dir. Capacity, cost veya carbon accounting için kararın gerektirdiği şekilde host ve facility parçalarını ekleyin. CodeCarbon docs audit’i genişletebilir, ancak tool’un hangi değerleri ölçtüğünü ve hangilerini tahmin ettiğini okuyun. Whole-node karşılaştırmaları için external rack veya wall metering daha güçlü bir kontroldür.
5. Sonucu birden fazla şekilde normalize edin
Tek bir kazanan sayı yerine küçük bir metric set raporlayın:
Bir metric decode path’i ayarlamaya yardımcı olur. Diğeri değişikliği product value ile ilişkilendirir. Latency ve quality alanları, bir energy optimization’ın service’i sessizce zayıflatmasını engeller.
6. Tek bir kontrolü değiştirin, ardından demand’i yeniden oynatın
İzole deneylerle başlayın: precision, batch policy, request bucketing, cache setup, GPU power veya clock limit’i ve placement. Warm-up sonrasında tekrarlı trial’lar çalıştırın. Heat veya time of day sonucu etkileyebilecekse trial’ların sırasını değiştirin.
Ardından en iyi adayları mixed arrival’lar altında yeniden oynatın. Festina ve AFlex, local optimum’lar etkileşime girdiği için birden fazla kontrolü koordine eder. İlk geçişiniz nedenleri izole etmeli; final geçişiniz ise combined policy’yi gerçek SLO altında test etmelidir.
Kanıtların desteklediği sırayla optimize edin
En güvenli optimization order, wasted work ile başlar ve ardından daha sıkı hardware control’lerine ilerler.
Sistem farklı quality tier’ları sunuyorsa bu süreci gerçek-work benchmark ile birleştirin. Practical model benchmarking workflow, serving path’i değiştirirken kaliteyi, latency’yi ve cost’u görünür tutar.
Energy, cost ve carbon’u karıştırmayın
Bu metric’ler farklı soruları yanıtlar.
Daha düşük bir cloud bill, daha düşük energy’yi kanıtlamaz. Daha düşük bir GPU counter’ı daha düşük facility energy’yi kanıtlamaz. Daha düşük energy kullanan bir run, farklı bir time veya location’da çalışıyorsa otomatik olarak daha düşük emissions anlamına gelmez.
Reporting problemi standards work seviyesine ulaşacak kadar aktiftir. AI inference energy-efficiency metrics üzerine ITU-T work item’ı, kapsamına token boundary’lerini, energy-per-token indicator’larını, carbon math’i ve reporting rule’larını dahil eder. Bu çalışma, token unit’lerinin ve system boundary’lerinin hâlâ kesinleşmediğini gösteriyor. Bu, tamamlanmış bir benchmark değildir.
Production karar kuralı
Bir LLM energy efficiency değişikliğini yalnızca hedeflenen yararlı iş birimi için energy’yi düşürdüğünde ve request contract’ı bütçe içinde tuttuğunda kabul edin.
Testten önce bu contract’ı yazın:
Bu kural üç yaygın hatayı önler: joule yerine watts’ı optimize etmek, failure’ları gizlerken completed token’ları optimize etmek ve bir makalenin “up to” sonucunu farklı donanıma aktarmak.
Araştırma evrensel bir ayara değil, pratik bir yöne işaret ediyor. Prefill ve decode’u ayrı ayrı profile edin. Request, runtime ve hardware kayıtlarını birleştirilmiş halde tutun. Yönetmeyi planladığınız boundary’yi ölçün. Bir energy sayısının engineering decision’a dönüşmesi böyle mümkün olur.