Енергоефективність LLM не є сталою властивістю моделі. Та сама модель може споживати дуже різну кількість енергії на корисний запит, якщо змінити довжину prefill, довжину виводу, форму batch, precision, час надходження запитів, частоти GPU або runtime обслуговування. Вимірюйте ці фактори разом із latency та якістю, перш ніж називати певну конфігурацію ефективною.
Цей посібник призначений для досвідчених читачів, які експлуатують або оцінюють LLM inference. Його практичний висновок простий: збирайте дані про енергію на рівні пристрою або вузла, пояснюйте їх за допомогою serving telemetry і нормалізуйте щодо корисної роботи на рівні запиту. Одне показання потужності не може виконати всі три завдання.
Ця відмінність стає важливішою зі зростанням reasoning budgets. Додаткові згенеровані токени збільшують обчислення, але система навколо цих токенів визначає, наскільки ефективно апаратне забезпечення виконує цю роботу. Мій попередній аналіз reasoning tokens та їхньої обчислювальної вартості охоплює сторону навантаження. Ця стаття зосереджена на аудиті енергії та стороні обслуговування.
Енергоефективність LLM є результатом serving stack
Енергія — це потужність, інтегрована за часом. Якщо GPU споживає в середньому 400 ват протягом десяти секунд, він використовує 4 000 джоулів. Ця частина проста. Складність полягає у виборі часового вікна, межі апаратного забезпечення та одиниці звітності.
«Енергія на токен» може означати щонайменше три різні речі:
| Метрика | Корисна для | Що може приховувати |
|---|---|---|
| --- | --- | --- |
| Джоулі на вихідний токен | Чат і генерація з переважанням decode | Обробку prompt, невдалі запити, відмінності в якості |
| Джоулі на ефективний вхідний токен | Prefill і роботу з довгим контекстом | Роботу над виводом і цінність запиту end-to-end |
| Джоулі на успішний запит | Порівняння продуктів і навантажень | Великі відмінності в довжині prompt і відповіді |
| Запити на кіловат-годину | Планування capacity та операцій | Складність запитів, якість і latency |
Жодна з них не є універсально правильною. Оберіть одиницю, яка відповідає контракту сервісу, а потім наведіть достатньо контексту, щоб інша команда могла повторити тест.
Межа апаратного забезпечення не менш важлива. Management API NVIDIA на підтримуваному обладнанні надає лічильники енергії пристрою. Це може дати чітку різницю для GPU, але за замовчуванням не включає роботу CPU, host memory, storage, networking, cooling або втрати перетворення потужності. CodeCarbon може розширити межу вимірюваними та оціненими компонентами, однак його документація описує fallback-оцінки для обладнання, показники якого він не може зчитати. «Виміряно інструментом» не означає, що кожну частину було виміряно окремо.
Чотири дослідження вимірювали різні частини stack
Нещодавні дослідження роблять вплив системи помітним. Наведені нижче відсотки не є рейтингом. Кожне дослідження використовує іншу платформу, навантаження, baseline і межу енергії.
| Дослідження | Обсяг і метод | Заявлений результат | Межа, яку слід враховувати |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Розділяє роботу attention і feed-forward, а потім керує provisioning, frequency, batch size та microbatching у системах на A800 | До 49% менше енергії на токен порівняно з протестованим disaggregated baseline за дотримання цільових TTFT і TPOT | Дві сім’ї моделей, обладнання A800 і production-style traces, що оцінювалися |
| Festina | Координує placement, partitioning GPU, operating point, consolidation і migration для спільного inference на H100 | До 56% нижче споживання енергії, а дотримання SLO залишалося в межах двох процентних пунктів у заявленій конфігурації | Контекст serverless зі спільним GPU; виграш зменшується, коли prefill уже є compute-intensive |
| EnerInfer | Прогнозує throughput і power для різних налаштувань NPU та memory, а потім керує control settings у межах thermal limits | Приріст енергоефективності 65% на телефонах, 12% на laptop і 24% на edge board | Економія на всьому пристрої була меншою — 4,2–11%, оскільки інші частини та фази все ще споживали енергію |
| Understanding Efficiency | Тестує quantization, batching, arrival patterns і serving choices на GPU H100 | Continuous batching зменшив енергію на запит у 12,5 раза порівняно з послідовним baseline дослідження; структуровані надходження дали більший приріст у фіксованому тесті | Короткі prompt, два розміри моделей Llama, одна сім’я accelerator і переважно GPU-орієнтовані дані про енергію |
Спільний результат сильніший за будь-який окремий відсоток: orchestration може настільки змінити споживання енергії, що оцінка лише за моделлю стане недійсною. Статті також показують, чому порада «використовуйте нижчу precision» є неповною. Дослідження H100 виявило, що нижча precision допомагала compute-bound prefill, тоді як overhead dequantization і kernel міг нівелювати або змінювати на протилежний бік перевагу під час memory-bound decode.
Сприймайте кожне число «до» як властивість експерименту авторів. AFlex не доводить економію 49% на вашому кластері B200. EnerInfer не доводить економію 65% на всьому пристрої для кожного телефона. Результати визначають control, які варто протестувати, а не заощадження, які можна безпосередньо перенести у прогноз.
Розділіть prefill і decode перед оптимізацією
Запит LLM має дві фази з різними bottleneck.
Prefill зазвичай є compute-heavy
Prefill обробляє prompt і створює key-value cache. Довгі prompt створюють сплески паралельної matrix work. Зміни precision і вищі частоти можуть допомогти, коли ця фаза є compute-bound, але менший time-to-first-token усе одно може супроводжуватися вищим піком потужності. Вимірюйте енергію, а не лише power.
Decode зазвичай є memory-heavy
Decode генерує токени по одному за крок. Він багаторазово зчитує ваги моделі та KV cache, що зростає, тому memory traffic і формування batch часто домінують. Вищі частоти можуть збільшити power без пропорційного throughput. Quantization також може додати overhead перетворення, якщо kernels або hardware path не узгоджені належним чином.
Цей поділ на фази пояснює, чому середнє значення за весь запит може вводити в оману. Конфігурація може покращити prefill для довгого prompt і погіршити decode для короткого. Разом із кожним результатом щодо енергії наводьте щонайменше довжину prompt, довжину виводу, batch або concurrency, precision і тривалість фаз.
KV cache має бути в тому самому записі. Мій посібник про збої eviction KV cache пояснює сторону надійності. Для роботи з енергією тиск на cache може змінювати memory traffic, recomputation, placement і частоту повторних спроб. Запуск із непомітними eviction не можна порівнювати із запуском без них.
Проведіть аудит енергії, який захищає latency SLO
Аудит потребує трьох пов’язаних рівнів: результатів запитів, контексту serving і енергії пристрою або вузла.
*Корисний результат щодо енергії потребує чіткої одиниці, контексту serving і явно визначеної межі апаратного забезпечення.*
1. Зафіксуйте репрезентативне навантаження
Створюйте зрізи навантаження, а не одне синтетичне середнє. Щонайменше розділіть короткі та довгі prompt, короткі та довгі виводи, стабільні та bursty arrivals, а також рівні якості, які використовує ваш застосунок. Під час порівняння зафіксуйте модель, tokenizer, sampling policy та stopping rules.
Використовуйте реальні форми запитів, якщо це дозволяють privacy та consent. Якщо ви застосовуєте synthetic prompt, збережіть розподіли довжини токенів і надходжень, які визначають поведінку системи. У фінальному звіті synthetic demand має бути позначений як synthetic.
2. Записуйте результати на рівні запиту
Для кожного запиту фіксуйте:
Не вилучайте невдалі запити із загального енергоспоживання. Конфігурація, яка витрачає менше енергії на завершені запити, перериваючи складні, не є ефективнішою.
3. Записуйте контекст serving
Логуйте control, які можуть пояснити зміну: тривалість prefill і decode, batch size, active sequences, queue depth, precision, parallelism, cache occupancy, placement, частоти або power limit GPU та навантаження co-tenant.
Ця telemetry також виявляє ефекти idle і burst. Runtime, який підтримує CPU активним, поки GPU очікує, може виглядати нормально у вимірюванні лише GPU і гірше — на межі вузла або fleet. Гілки issue у open-source проєктах корисні для пошуку таких failure mode, але це лише anecdote, доки ви не відтворите їх у своєму stack.
4. Вимірюйте явно визначену межу енергії
На підтримуваних GPU NVIDIA NVML надає загальний лічильник енергії в міліджоулях. Мінімальний Python probe може обмежити фіксоване навантаження:
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 щодо запитів до пристрою визначає лічильник і його одиниці. Перевірте підтримку на конкретних GPU та driver. Кумулятивне значення скидається під час перезавантаження driver, тому відхиляйте від’ємну або некоректну різницю. Для пристроїв без лічильника енергії вимірюйте power із частотою, яка фіксує короткі запити, і інтегруйте trace за те саме вікно.
Енергія GPU є коректною межею, якщо ви її називаєте. Для обліку capacity, cost або carbon додайте host і facility components відповідно до рішення, яке потрібно ухвалити. Документація CodeCarbon може розширити аудит, але перевірте, які значення інструмент вимірює, а які оцінює. Зовнішнє вимірювання на рівні rack або wall залишається надійнішою перевіркою для порівнянь усього вузла.
5. Нормалізуйте результат кількома способами
Звітуйте про невеликий набір метрик, а не про одне найкраще число:
Одна метрика допомагає налаштувати decode path. Інша пов’язує зміну з цінністю продукту. Поля latency та quality не дають енергетичній оптимізації непомітно послабити сервіс.
6. Змінюйте один control, а потім повторюйте навантаження
Починайте з ізольованих експериментів: precision, batch policy, request bucketing, cache setup, power або clock limit GPU та placement. Проводьте повторні випробування після warm-up. Змінюйте порядок між випробуваннями, якщо температура або час доби можуть вплинути на результат.
Потім повторіть найкращі варіанти на mixed arrivals. Festina і AFlex координують кілька control, оскільки локальні оптимуми взаємодіють. Перший етап має ізолювати причини; фінальний — перевірити комбіновану policy за реального SLO.
Оптимізуйте в порядку, який підтверджують дані
Найбезпечніший порядок оптимізації починається з усунення марної роботи, а потім переходить до точніших hardware controls.
Якщо система обслуговує різні рівні якості, поєднайте цей процес із benchmark на реальній роботі. Практичний workflow benchmarking моделей допомагає зберігати видимість quality, latency та cost під час зміни serving path.
Не плутайте energy, cost і carbon
Ці метрики відповідають на різні запитання.
Нижчий cloud bill не доводить нижче споживання енергії. Нижчий лічильник GPU не доводить нижче споживання енергії facility. Запуск із нижчим споживанням енергії не автоматично має нижчі emissions, якщо він відбувається в інший час або в іншій локації.
Проблема звітності вже достатньо актуальна, щоб потрапити до роботи над стандартами. Робочий пункт ITU-T щодо метрик енергоефективності AI inference охоплює межі токенів, показники energy-per-token, розрахунок carbon і правила звітності. Ця робота показує, що одиниці токенів і системні межі все ще не усталені. Це не завершений benchmark.
Правило production-рішення
Приймайте зміну енергоефективності LLM лише тоді, коли вона зменшує енергію для визначеної одиниці корисної роботи й утримує контракт запиту в межах бюджету.
Сформулюйте цей контракт до початку тесту:
Це правило запобігає трьом поширеним помилкам: оптимізації watts замість joules, оптимізації завершених токенів із приховуванням помилок і перенесенню результату «до» з наукової статті на інше апаратне забезпечення.
Дослідження вказують на практичний напрям, а не на універсальне налаштування. Профілюйте prefill і decode окремо. Зберігайте пов’язаними записи про запит, runtime та апаратне забезпечення. Вимірюйте ту межу, якою плануєте керувати. Саме так показник енергії перетворюється на engineering decision.