AI И НЕЙРОСЕТИ

Софт может снизить энергозатраты ИИ-ЦОД без замены GPU

945 ТВт·ч электроэнергии могут потребоваться ИИ к 2030 году — почти как всё нынешнее потребление Японии. Часть нагрузки помогут снять софт и алгоритмы.

✍️ Редакция iTech News | 09.10.2026 | ⏱ 4 мин | Источник: Tom's Hardware
💡

К 2030 году ИИ может потреблять до 945 ТВт·ч электроэнергии в год — примерно столько же, сколько сейчас использует Япония. На фоне дефицита мощности для дата-центров энергоэффективность ИИ всё меньше сводится к покупке очередных GPU: заметную часть нагрузки можно убрать настройкой моделей, планировщиков и прикладного кода.

Об этом сообщает Tom's Hardware со ссылкой на исследователей и представителей индустрии дата-центров. Их тезис довольно приземлённый: железо менять дорого и долго, а три верхних слоя вычислительного стека — системное ПО, алгоритмы и приложения — можно оптимизировать быстрее. Причём эффект складывается: более компактный запрос снижает число токенов, удачный батчинг повышает загрузку ускорителей, а планировщик переносит некритичную задачу на часы, когда сеть менее перегружена.

Не только охлаждать, но и перестать считать лишнее

Обычно эффективность ЦОД измеряют показателем PUE — отношением общего энергопотребления площадки к энергии, которую получают IT-нагрузки. Он показывает потери на охлаждение и электроснабжение, но не отвечает на неудобный вопрос: полезную ли работу выполняют сами серверы. По данным опроса Uptime Institute за 2025 год, средний PUE почти не менялся шесть лет подряд. Дальше выжимать проценты из инженерной инфраструктуры становится всё сложнее, тогда как программные потери зачастую лежат на поверхности.

Серверы дают около 60% энергопотребления современного дата-центра. На охлаждение приходится примерно 7% в эффективных гиперскейл-площадках и более 30% в менее эффективных корпоративных ЦОД. Поэтому экономия на вычислениях способна оказаться заметнее очередной настройки холодного коридора. Jae-Won Chung, аспирант Мичиганского университета и исследователь инициативы ML.Energy, предлагает смотреть на инфраструктуру как на стек: внизу оборудование, выше — системное ПО, алгоритмы и приложения. Нижний слой инертен: чипы нельзя заменить патчем во вторник вечером. Остальные — вполне можно.

В тестах ML.Energy инференс модели Alibaba Qwen 3 235B A22B Thinking в формате FP8 потреблял примерно на треть меньше энергии, чем вариант с bfloat16, при решении задач на рассуждение. FP8 снижает точность представления чисел, но для части инференс-нагрузок этот компромисс оказывается приемлемым. Разработанный Chung оптимизатор обучения Perseus, в свою очередь, находит менее загруженные части процесса обучения большой модели и замедляет их так, чтобы они завершались одновременно с более тяжёлыми участками. В опубликованных тестах это уменьшало энергозатраты на обучение до 30% без падения пропускной способности и без замены оборудования.

Похожую логику применяет Nvidia в профилях энергопотребления для Blackwell. Они подстраивают частоты вычислительных блоков и памяти, лимиты мощности, состояния NVLink и параметры кеша под конкретную задачу. По оценке Nvidia, такой подход способен сократить расход энергии до 15%, сохранив не менее 97% производительности. Для площадки, упёршейся в доступную мощность, это означает возможность разместить больше GPU и увеличить суммарную производительность до 13% — не за счёт новой подстанции, а за счёт более аккуратного режима работы уже установленного кластера.

Самый громкий сервер часто обслуживает старый код

Быстрые меры не всегда требуют исследования форматов чисел. Chetan Visrolia из поставщика IT-инфраструктуры SHI называет типичной точкой потерь устаревшее оборудование, которое продолжает поддерживать старый код. Такой шкаф легко обнаружить в машинном зале буквально на слух: он громче остальных, но его нагрузка нередко не соответствует потребляемой мощности. Для бизнеса это аргумент пересмотреть не только парк серверов, но и список сервисов, их владельцев, SLA и реальную востребованность.

У облачных и AI-команд набор практик ещё шире. Инстансы можно подбирать по фактической нагрузке, повторяющиеся промпты — кешировать, а типовые запросы отправлять маленьким моделям, оставляя крупные для сложных случаев. Компиляторы и батчинг помогают не держать ускорители в ожидании, сокращение контекста и ограничение длины ответа уменьшают число обработанных токенов. Здесь энергоэффективность ИИ перестаёт быть задачей эксплуатации ЦОД: она становится частью API-дизайна, продуктовых метрик и инженерной дисциплины. Если продукт без нужды генерирует длинный ответ, счёт за электричество начинается ещё до стойки с GPU.

Есть и географический уровень оптимизации. Sophie Hall из Лаборатории автоматического управления ETH Zurich, изучавшая перенос нагрузок между дата-центрами Google, предлагает учитывать не только объём потребления, но и время, место и влияние на электросеть. Некритичные пакетные задания можно отложить до снижения локального спроса или направить в регион со свободной мощностью и менее углеродной генерацией. Для этого нужны планирование на сутки вперёд и диспетчеризация в реальном времени с соблюдением обещанных сроков выполнения.

Подход не универсален: требования к суверенитету данных могут запретить перенос задачи за границу, а перемещение больших наборов данных само по себе дорого, медленно и рискованно. Наконец, действует парадокс Джевонса: сэкономленный ватт не уменьшит итоговое потребление, если на нём тут же сгенерируют ещё больше токенов. Но при дефиците подключаемой мощности цель иная — получить максимум полезного вычисления на каждый ватт. Для российских команд, строящих или арендущих GPU-кластеры, энергоэффективность ИИ стоит включать в оценку моделей и сервисов наравне с качеством ответов, задержкой и стоимостью запроса.

Поделиться: Telegram X LinkedIn