Синхронизация измерителей энергии с окном GPU-теста

Энергию GPU теста сравнивают только после согласования окна workload и временных границ измерителей. Начало клиентского запроса, начало GPU работы и timestamp счетчика могут относиться к разным событиям и clocks. Сохраните их связь до вычисления joules per task. Иначе часть прогрева или idle попадет в одну серию и исчезнет из другой, создавая видимую экономию без реального изменения исследуемого вычисления и его полной стоимости выполнения.

Определите окно задачи

Выберите, что входит в эксперимент: загрузка модели, warmup, очередь, inference или завершение всех ответов. Разные задачи допускают разные границы, но они должны совпадать в сравниваемых сериях. Сохраните явные workload markers и идентичность набора запросов. Не называйте оба результата одинаковым «energy per inference», если один включает startup, а второй начинается после него. Также определите, считается ли полезной работой отправленный запрос или успешно завершенная задача с нужным результатом; этот выбор меняет знаменатель и смысл итоговой метрики.

Разведите clock domains

Linux clock_gettime manual описывает realtime, monotonic и их свойства. Локальную длительность следует измерять подходящими часами, отдельно сохраняя связь с wall time для внешнего meter. Timestamp разных устройств не становится синхронным только из-за одинакового формата даты. Запишите clock source, возможный offset и точность сопоставления. Если источник обновляет показание редко, момент чтения не обязательно совпадает с концом внутреннего measurement window. Такая неопределенность должна оставаться в отчете, а не скрываться добавлением лишних знаков после запятой.

Пример карточки границ

Создайте строки workload start, first energy read, workload complete и final energy read. В каждой укажите source clock, event meaning и допустимую неопределенность. Это схема регистрации, не готовые временные значения. Для внешнего AC meter дополните его interval coverage и способ alignment с host markers. Если чтение начинается раньше задачи и заканчивается позже, обозначьте включенный idle. Не обрезайте его произвольным средним baseline без описания: такое вычитание уже является моделью оценки, а не непосредственно измеренной энергией самой задачи.

Проверьте накопительный счетчик

Powercap documentation описывает energy counters и maximum range для соответствующих зон. До разности определите единицы, scope, возможность wrap и lifecycle. Рестарт или смена источника нельзя считать отрицательным потреблением. При wrap используйте корректную процедуру для выбранного интерфейса и сохраните достаточное покрытие чтениями. Не переносите правила CPU zone на любой GPU или внешнее устройство без документации. Даже правильно вычисленная delta остается энергией конкретного domain за его интервал, а не автоматически всего сервера или отдельного request.

Приемка сопоставимого результата

В пакет включите raw readings, workload markers, clock map, units и формулу integration либо delta. Отдельно укажите пропуски, начало и конец покрытия. Повторите серию и убедитесь, что выбранный способ alignment стабилен. Если точности недостаточно для короткого workload, увеличьте длительность согласованной серии или выберите подходящий измеритель, а не придумывайте missing samples. Полезный итог показывает, какая энергия действительно покрывает принятый интервал и где остается uncertainty. Он позволяет сравнивать operating points без случайной смены границ и не превращает разницу timestamps в доказательство экономии, когда на деле два отчета включили разные фазы загрузки, ожидания, генерации или возврата оборудования в idle после завершения полезной работы.

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

Энергия на запрос LLM: как измерять без ложной точности; Счёт площадки и телеметрия GPU: как объяснить расхождение расхода.