# Энергия GPU, CPU и сервера: где проходит граница измерения

Мощность GPU, CPU package и сервера на входе AC относятся к разным границам измерения.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-board-server-power-boundary/
Language: ru

Мощность GPU, CPU package и сервера на входе AC относятся к разным границам измерения. Складывать их без карты покрытия нельзя: некоторые зоны вложены, а часть потребителей вообще не представлена компонентными датчиками. Сначала определите физический объект каждого показания и единицы. Затем выбирайте либо системный итог, либо согласованный непересекающийся набор компонентов. Иначе отчет способен дважды учесть одну энергию и одновременно потерять вентиляторы, накопители или потери преобразования.

## Подпишите sensor boundary

[NVML device queries](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) описывает мощность GPU и связанной circuitry для соответствующего API, но такое показание не равно AC потреблению всего сервера. Сохраните название функции или поля, единицы и поддерживаемую область устройства. Не обозначайте его просто «server watts» в dashboard. Если источник измеряет энергию, а не мощность, укажите интервал и способ вычисления среднего. Одинаковая числовая единица ватт не делает два датчика взаимозаменяемыми: они могут охватывать разные компоненты и разные временные окна наблюдения.

## Найдите вложенные зоны CPU

[Linux powercap framework](https://docs.kernel.org/power/powercap/powercap.html) описывает иерархию зон и подзон. Родительская зона может включать дочерние части, поэтому их сумма способна повторно учитывать ту же энергию. Перед агрегацией сохраните дерево и смысл каждого name. Не приравнивайте RAPL package ко всему узлу и не предполагайте одинаковую карту покрытия на всех процессорах. Для сравнения узлов нужны согласованные boundaries, иначе разница показаний может объясняться только тем, какие области вообще представлены доступными счетчиками.

## Пример двойного учета

Предположим, родительская зона за тестовое окно показала 100 J, а вложенная часть — 40 J. Это условные числа для арифметики. Сумма 140 J не является корректным итогом родителя плюс нового независимого потребителя, если 40 J уже входят в 100 J. Аналогично нельзя прибавить AC счетчик сервера к GPU board energy и назвать результат энергией системы. Таблица измерения должна отмечать parent relation и исключать пересечение до любых сравнений эффективности модели или режима запуска.

## Выберите цель измерения

Для счета за электричество полезна соответствующая AC граница, а для анализа вычислительного компонента — его sensor domain. Эти задачи могут требовать разных отчетов. Сохраните простой расчет `Pavg = deltaE / deltaT` с согласованными единицами и одинаковыми окнами, если среднее получено из энергии. Разницу AC и суммы выбранных компонентов нельзя целиком объявлять PSU loss: в нее могут входить неучтенные consumers и погрешности. Не подставляйте недостающие части из рекламного TDP без прямого обоснования и ясно обозначенной модели оценки.

## Сохраните карту покрытия

Артефакт содержит датчик, объект, parent, единицы, окно и метод получения. Отдельно укажите unknown coverage и недоступные поля, не превращая их в ноль. Для сравнения режимов фиксируйте тот же boundary и workload. При переносе на другой сервер повторите inventory измерителей. Полезный итог позволяет читать каждую цифру как наблюдение конкретной области, а не как универсальное энергопотребление inference. Он сохраняет различие между board power, package energy и AC input, предотвращая красивые, но физически неверные суммы и выводы об экономии, которые на деле отражают смену датчика, удвоенный учет вложенной зоны или пропавший из наблюдения компонент оборудования.

## Связанные материалы

[Энергия на запрос LLM: как измерять без ложной точности](/ru/journal/measuring-energy-per-inference/); [Сколько стоит сдать сервер в аренду: пример счёта за электричество](/ru/journal/own-server-electricity-invoice/).