- Энергоэффективность ИИ я предлагаю оценивать по энергии на принятый бизнесом результат, включая неудачные попытки.
- Сокращение токенов не доказывает экономию электроэнергии или сохранение качества.
- Для небольшого облачного пилота я бы начал с качества, расходов, повторов и времени исправлений. Измерение энергии требует отдельной методики.
Что случилось
25 сентября 2026 года EnterpriseDB призвала учитывать энергоэффективность ИИ при проектировании инфраструктуры. По предварительным результатам сентябрьского исследования EDB среди 300 респондентов, 69% при выборе платформ для данных и ИИ уделяют энергетике больше внимания, чем годом ранее. В пресс-релизе EDB нет подробной методики и состава выборки. Переносить результат на российский рынок я бы не стал.
EDB предлагает сокращать лишние вычисления и перемещение данных. С направлением согласен, но для выбора платформы нужны измерения. MLCommons, организация, развивающая тесты производительности ИИ, в материале о MLPerf Power объясняет: одной мощности недостаточно, нужно учитывать производительность, качество и потребление компонентов системы. Это методический ориентир, а не подтверждение результатов EDB.
Что это значит для бизнеса
Сначала я бы определил, какой результат готов принять бизнес: черновик ответа на обращение или проверенный ответ с подтверждёнными данными. Без этого сравнивать эффективность рано.
Токены – фрагменты текста, которые обрабатывает модель. Их количество полезно для учёта запросов, но я предлагаю считать шире:
Расход ресурсов на результат = ресурсы всех попыток / число принятых результатов.
Деньги, энергию и вычислительное время нужно считать отдельно, а время человека на проверку и исправления показывать рядом. Если принятых результатов нет, сначала надо добиться работающего решения.
Для энергии нужны границы измерения. В MLPerf Inference: Datacenter мощность измеряют на входе питания всей тестируемой системы во время теста. Результат относится к конкретному тесту; паспортная мощность оборудования его не заменяет.
Для бизнес-проекта я бы зафиксировал:
- Критерии приёмки и одинаковый набор задач для сравнения.
- Все обращения к модели, поиску и базе данных, включая повторы.
- Предел попыток и порядок передачи задачи человеку.
- Что измерено, что сообщил провайдер, что осталось оценкой.
Энергетический аудит небольшого облачного пилота я считаю избыточным, если мы проверяем полезность продукта. Достаточно качества, расходов на запросы и времени исправлений. При выборе собственного оборудования или ограничении доступной мощности моя рекомендация меняется: измерения энергии откладывать нельзя.
Как это выглядит на практике
В релизе от 22 апреля 2026 года EDB описала пилот с неназванным глобальным телеком-провайдером: сокращение потребления токенов до 57%, сохранение 90% качества и выигрыш в 72% сценариев. Число задач, определение качества и критерий выигрыша вендор не привёл.
Проверка упирается в тупик: воспроизвести сравнение по этому описанию нельзя. «Сохранено 90% качества» не означает «качество не пострадало». Сокращение токенов нельзя автоматически записать в экономию электроэнергии.
Я бы запросил примеры ухудшившихся ответов и правила оценки, затем сравнил варианты на собственных задачах с одинаковыми требованиями. Для внутреннего черновика и операции с заказом клиента допустимы разные ошибки.
В CRT один инженер с ИИ-инструментами ведёт задачу от бизнес-постановки до работающего решения. Я считаю учёт ресурсов частью этой ответственности. Если запросов стало меньше, а сотрудник дольше исправляет ответ, вопрос об эффективности остаётся открытым.
Вопросы и ответы
Можно ли оценить энергопотребление через облачный API?
По одному числу токенов достоверно определить энергопотребление нельзя. Нужны сведения об оборудовании, режиме работы и границах расчёта. Счёт за API показывает финансовые расходы, но не измеряет энергию.
Когда достаточно учитывать расходы на запросы?
Для небольшого облачного пилота расходы на запросы подходят как стартовая финансовая метрика. Их нужно сопоставлять с принятыми результатами, повторами и временем исправлений. Для выбора оборудования по энергоэффективности этого недостаточно.
Что делать
До масштабирования я бы определил критерии качества и наладил учёт всех попыток. В CRT такую работу можно выстроить в формате AI Software Engineer: инженер ведёт решение от требований до запуска, а бизнес определяет, какой результат готов принять.
Обсудить задачу
