Мы общаемся с экспертами отрасли о том, как спрос на ускорение ИИ стимулирует новые подходы к измерению выбросов парниковых газов. — computerweekly.com
По словам генерального директора Nvidia Дженсена Хуанга, объем вычислений, необходимых для работы искусственного интеллекта (ИИ), в 1000 раз превышает вычислительную мощность, требуемую для запуска не-ИИ программного обеспечения. В то время как традиционные стойки центров обработки данных генерируют от 20 до 40 киловатт на стойку, Райан Хотчкин, старший директор по управлению центрами обработки данных и бизнесом в SHI, заявляет, что Nvidia удваивает этот показатель каждый год. «С GB200 и NVL72 мы говорим о 120 киловаттах на стойку. Более мощные графические процессоры [GPU] влекут за собой больший спрос на блоки распределения питания [PDU], что, в свою очередь, сказывается на электрической инфраструктуре», — добавляет он. Это стимулирует спрос на большее количество энергии из сети, дополнительные резервные мощности и варианты с использованием ядерной энергии. «Например, мы видим малые модульные реакторы [SMR], которые можно производить, доставлять и развертывать поэтапно», — говорит Хотчкин. Помимо потребления электроэнергии, использование GPU вызывает рост спроса на охлаждение, добавляет он: «Воздушное охлаждение не справляется, мы видим, как доминирует жидкостное охлаждение. Теплообменники на задней двери [RDHx], прямое чиповое и иммерсионное охлаждение помогают решить проблему ввода мощности и вывода тепла. Но эти новые решения для охлаждения намного тяжелее». Таким образом, установка стоек с жидкостным охлаждением в зданиях с ограничениями по весу невозможна — или, в случае нового строительства, может вызвать дилеммы относительно места расположения объекта.
Непрерывное измерение
В то время как ИИ вызывает экспоненциальный рост вычислений, Бенджамин Бриал, основатель Cycloid, отмечает, что большинство организаций никогда не проектируют свое использование вычислительных ресурсов с учетом огромного роста, требуемого ИИ. «Устойчивое развитие по-прежнему рассматривается как галочка для соблюдения требований, нечто, что проверяется постфактум в квартальном отчете», — говорит он. «Рассмотрение устойчивого развития как отдельной строки отчетности только усугубляет проблему. «Когда GreenOps существует в панелях мониторинга, оторванных от рабочих процессов разработчиков, организации фактически жестко кодируют в своей инфраструктуре «силос отходов». Если компания не готова постоянно обеспечивать кадрами, финансировать и операционализировать этот «силос» — а большинство этого не делают — это становится театром, а не контролем». По словам Бриала, реальная устойчивость работает только тогда, когда сигналы о затратах и углеродном следе являются частью тех же платформ, которые разработчики используют для создания, развертывания и масштабирования программного обеспечения. В противном случае неэффективность — это не случайность, а архитектурный выбор. Итак, каков ответ? По мнению Бриала, реальная устойчивость не должна начинаться с замедления внедрения ИИ или ограничения экспериментов, а с предоставления командам платформ, которые делают потребление видимым и управляемым с самого начала. «Без этой основы ИИ просто усугубляет неэффективность. С ней команды могут уверенно внедрять инновации, зная о последствиях своего выбора до того, как они его примут», — говорит он. Как отмечает Бриал, затраты и углеродный след определяются теми же инфраструктурными решениями, которые команды разработчиков принимают каждый день. «В облаке финансовые и экологические последствия невозможно разделить. Размер экземпляров, выбор хранилища, перемещение данных и то, как долго работают сервисы — все это влияет как на расходы, так и на выбросы», — добавляет он. Это не стратегические решения, принимаемые раз в год; это небольшие, частые выборы, сделанные на этапе сборки и развертывания. «Когда команды не видят этих последствий в момент принятия решений, оптимизация становится медленной, разочаровывающей и часто игнорируется, поскольку становится препятствием из-за первоначальной плохой реализации», — говорит Бриал. Он утверждает, что разработчикам нужен больший надзор за их воздействием на окружающую среду — хотя бы по чисто фискальным причинам. Они уже оптимизируют производительность, надежность и скорость доставки, потому что эти сигналы видимы и немедленны. Но по опыту Бриала, затраты и углеродный след обычно более непрозрачны и проявляются только через недели, погребенные в отчетах, которые приходят задолго после того, как код оказался в продакшене. «Устойчивое развитие часто ошибочно понимают как «делать меньше». В действительности, это «потреблять лучше». Правильное определение размера, эластичность и автоматизация сокращают неиспользуемые ресурсы и ненужные рабочие нагрузки. Это улучшает скорость доставки и надежность в той же мере, что и сокращает отходы, и позволяет направить больше денег на инициативы, которые работают или приносят больше пользы. Так что на самом деле речь идет не о сдерживании инноваций, а о том, чтобы сделать их ориентированными на доставку», — добавляет Бриал. И когда платформы обеспечивают непрерывную оптимизацию, разработчики тратят меньше времени на устранение неполадок и больше времени на разработку. Бриал говорит, что самые эффективные организации рассматривают GreenOps и FinOps как результат хорошего продуктового дизайна, а не как отдельные инициативы. Когда затраты и углеродный след становятся сигналами внутри платформ разработчиков, устойчивое развитие перестает быть задачей по уборке и становится частью того, как программное обеспечение доставляется каждый день. По словам Бриала, команды, которые инвестируют в этот подход, будут двигаться быстрее, тратить меньше и масштабироваться ответственно, не потому, что им это сказали, а потому, что платформа делает это самым простым путем вперед.
Ненужные отходы
Одной из областей, которой часто пренебрегают при рассмотрении оптимизации, является хранение данных. Сохам Мазумдар, соучредитель и генеральный директор WisdomAI, говорит, что ИТ-руководители должны учитывать отходы, возникающие при ненужном дублировании данных. «У большинства организаций есть три или четыре копии каждого значимого набора данных: исходная система учета; производная копия, созданная в результате операций извлечения, преобразования и загрузки [ETL] для аналитики или отчетности; одна или несколько тестовых или экспериментальных версий; производственная копия, питающая панели мониторинга и модели или нижестоящие приложения», — говорит Мазумдар. «Каждая копия потребляет хранилище, вычислительные ресурсы и операционные усилия». Хотя набор данных может быть критически важным во время запуска продукта, цикла прогнозирования или эксперимента ИИ, его ценность падает после закрытия этого окна, но данные остаются. «Хранение кажется дешевым, а вычисления — эластичными, поэтому данные остаются редко используемыми, редко проверяемыми и почти никогда не удаляются. Это нехорошо для глобальных выбросов», — добавляет Мазумдар. По его опыту, инженеры сосредоточены на немедленной проблеме: перемещении данных, их преобразовании, подключении систем. Он говорит: «Никто не поощряет сбор мусора. В облаке создавать ресурсы легко. Стимулов для их очистки мало». По словам Мазумдара, у команд Google есть явные квоты на хранение и вычисления. Хотя эти квоты могут быть большими, они все же существуют, что заставляет расставлять приоритеты. «Если набор данных или конвейер больше не имели значения, им приходилось обосновывать свое дальнейшее существование. Это приводило к более здоровым системам с меньшим количеством забытых активов», — добавляет он. Он говорит, что ручная подотчетность больше не масштабируется. Хотя инстинктивный ответ — требовать большей подотчетности от инженеров, он считает, что это больше не работает. Это связано с тем, что в эпоху ИИ подотчетность движется в противоположном направлении. Команды экспериментируют, создают прототипы и как можно быстрее подключают данные к новым моделям. Временные конвейеры и наборы данных множатся. Все это означает, что ручные процессы не могут угнаться за темпом. Мазумдар рекомендует внедрять автоматизацию, отслеживающую «жизнеспособность» (liveness). Это включает системы, которые идентифицируют наборы данных, не использовавшиеся месяцами, конвейеры, которые больше не производят выходные данные, и вычислительные сервисы, которые не получают трафика. «Эти сигналы должны инициировать действие: архивирование, перемещение в холодное хранилище или удаление», — говорит Мазумдар. «Наша миссия сейчас — перейти от устремлений к операционной реальности. Путь вперед — это не аскетизм, а видимость, отслеживание жизнеспособности и автоматизированная дисциплина, встроенная в системы данных. Когда вы понимаете, какие данные «живые», какие спящие и какие действительно необходимы, вы сокращаете отходы, снижаете воздействие на окружающую среду и создаете более здоровую основу для аналитики и ИИ».
Метрики на основе компонентов
Видимость начинается с понимания воздействия на окружающую среду каждого компонента в стеке инфраструктуры ИИ: от оборудования центров обработки данных до использования программного обеспечения и последующей утилизации оборудования. В отчете Gartner «Как измерять и смягчать воздействие ИИ на экологическую устойчивость», опубликованном в июле 2025 года, рекомендуется, чтобы ИТ-руководители отдавали приоритет использованию измерений на основе компонентов, где это возможно, поскольку это наиболее точная методология для измерения воздействия ИИ на окружающую среду. Gartner позиционирует измерение на основе компонентов как один из наиболее гранулированных способов измерения углеродного следа ИИ. Оно основано на разбивке составных частей инфраструктуры ИИ и их индивидуальном измерении. Эти компоненты охватывают физическую ИТ-инфраструктуру, используемую для обучения и запуска моделей ИИ, а также операционные системы программного обеспечения, языки программирования и приложения с поддержкой ИИ, использующие модели и фреймворки. Gartner заявляет, что подход на основе компонентов измеряет вычислительные ресурсы, используемые моделями ИИ, в частности количественно оценивая базовое оборудование (в основном GPU и CPU), продолжительность процесса обучения, неактивное энергопотребление серверов и PUE центров обработки данных, где происходят эти вычисления. При подходе на основе компонентов для расчета углеродного следа ИИ выбросы углерода, связанные с обучением и развертыванием моделей ИИ, затем рассчитываются путем умножения общего потребляемого количества энергии на интенсивность углерода электросети в конкретном географическом регионе, где расположена инфраструктура ИИ. Необходимо учитывать электроэнергию, потребляемую оборудованием, и энергию, необходимую для охлаждения центров обработки данных, а также электроэнергию, необходимую для хранения данных, используемых для обучения и инференса ИИ. Для полного расчета Gartner рекомендует учитывать жизненный цикл оборудования центров обработки данных. Это включает производство, развертывание, эксплуатацию и последующую утилизацию всех компонентов.
Устойчивое развитие — это дорожная карта для ИИ
Хотя основное внимание технологического сектора в значительной степени было сосредоточено на предоставлении более мощных моделей ИИ, которые могут максимально использовать последние достижения в области оборудования, меньше внимания уделялось достижению этого наиболее устойчивым способом. Поскольку энергосети испытывают нагрузку из-за требований к питанию ИИ-фабрик и центров обработки данных с большим количеством GPU, планирование таких объектов все чаще оказывается в центре внимания. Если прогноз генерального директора Nvidia показывает направление движения технологического сектора, эффективность этих объектов должна будет расти экспоненциально. И для ИТ-руководителей будет уделяться гораздо больше внимания эффективности ИИ, а не его абсолютной производительности.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор –