Обычная AI-инфраструктура уже умеет дергать энергосеть скачками на десятки мегаватт. Теперь исследователи показали, что вредоносная GPU-нагрузка может делать это не случайно, а по сценарию атаки: около 1000 GPU, по их расчетам, достаточно, чтобы раскачать локальную энергосистему мощностью 1 МВт, вызвать сильные гармонические искажения и запустить каскадные сбои. Для облачных провайдеров, дата-центров и крупных команд, арендующих ускорители, это неприятная новость: риск лежит уже не только в сети и гипервизоре, но и в самом профиле вычислений.
Об этом сообщает The Register со ссылкой на препринт Bit2Watt: A Cyber-Physical Vulnerability Exploiting GPU Workloads Across Power and Computing Infrastructures, который подготовили Zhouhao Ji, Kaikai Pan и Wenyuan Xu из Чжэцзянского университета в Ханчжоу. Идея атаки проста и от этого еще менее симпатична: злоумышленник маскируется под обычного арендатора облака, получает доступ к GPU и запускает задачи, спроектированные не ради обучения модели, а ради дестабилизации электропитания дата-центра и связанной с ним инфраструктуры.
Исследователи называют этот сценарий Bit2Watt. Ключевой тезис в том, что современные GPU-нагрузки могут модулировать энергопотребление с частотами выше 6000 Гц. Для сравнения: бытовые потребители вроде кондиционеров обычно работают на уровне нескольких герц. Разница не академическая. Чем выше и точнее управляемы колебания нагрузки, тем проще попасть в чувствительные режимы работы силовой электроники и распределительной сети, вызвать скачки напряжения, ухудшить демпфирование и накачать систему «паразитной» энергией, которая уходит не в полезную работу, а в потери и нагрев.
В статье приводится конкретная модель: атака на локальную энергосеть 1 МВт, где большую роль играют распределенные источники энергии, например солнечная генерация. При использовании примерно 1000 GPU авторы получили суммарное гармоническое искажение тока на уровне 46,8 процента. Грубо говоря, почти половина тока начинает тратиться на непроизводительную работу. Параллельно система выделяет примерно на 20 процентов больше тепла, чем в штатном режиме. Для оборудования дата-центра это плохая комбинация: растут потери, ухудшается стабильность питания, а дальше начинают срабатывать защитные механизмы. И вот тут проблема перестает быть «только про серверную».
Авторы утверждают, что в такой конфигурации появляется отрицательный коэффициент демпфирования на уровне -0,27, то есть в системе возникает неустойчивый режим. Если автоматика начинает сбрасывать вычислительную нагрузку, чтобы защитить железо, это может запустить каскадные отказы. В большой энергосистеме, по их оценке, масштаб отключений теоретически способен превысить 80 процентов. Звучит как сценарий из презентации для CISO, который все надеялись никогда не увидеть. Но важнее другое: речь не о взломе подстанции через экзотический эксплойт, а об использовании вполне разрешенного пути исполнения задач внутри облака.
Почему это вообще правдоподобно
У отрасли уже был контекст, на который опирается эта работа. В 2025 году Microsoft, Nvidia и OpenAI в отдельной исследовательской публикации разбирали, почему во время обучения ИИ требуются механизмы стабилизации электропитания. Проблема возникает в моменты перехода от вычислений на GPU к синхронизации данных между ускорителями: нагрузка резко меняется, и это создает мощные колебания потребления. Если спектр таких колебаний совпадает с критическими частотами энергосистемы, последствия выходят далеко за пределы просадки по эффективности кластера.
Похожий мотив встречался и в материалах Meta о тренировке Llama 3. Компания прямо описывала, что десятки тысяч GPU могут почти одновременно увеличить или уменьшить энергопотребление, например когда ускорители ждут завершения checkpointing или коллективных операций, либо когда стартует или останавливается крупная training job. В таких случаях мгновенные колебания мощности по всему дата-центру измеряются уже не киловаттами, а десятками мегаватт. Это не баг отчета по энергоучету, а физика современной AI-инфраструктуры.
Bit2Watt отличается тем, что берет этот известный операционный риск и превращает его в осмысленный вектор атаки. Не «обучение модели случайно создало резкий профиль потребления», а «нагрузка специально сконструирована так, чтобы бить по слабым местам связки между вычислительным кластером и энергосистемой». Для русскоязычной IT-аудитории здесь важен сдвиг в модели угроз. Команды, которые привыкли делить ответственность на «безопасность облака» и «эксплуатацию инженерки», получают третий слой: безопасность поведения workload на стыке софта, планировщика ресурсов и силовой инфраструктуры.
Есть и еще одна неприятная деталь. По версии авторов, такая вредоносная GPU-нагрузка может быть довольно скрытной. Она запускается по легитимному каналу, выглядит как разрешенная вычислительная задача и не обязана ломать API, VM или контейнерный runtime. Если мониторинг провайдера заточен на сетевую аномалию, побег из среды исполнения или очевидный abuse, он может просто не увидеть, что злоумышленник играет не против соседних арендаторов, а против электропитания как такового. То есть классическая облачная телеметрия в одиночку тут уже не спасает.
Что это меняет для облаков и бизнеса
Первый вывод для провайдеров: планировщик GPU-ресурсов становится частью системы безопасности, а не только инструментом утилизации кластера. Если задача может управлять профилем потребления настолько тонко, значит одной проверки образа, лимитов по времени и обычного rate limiting мало. Придется анализировать паттерны вычислений, синхронизации и энергопотребления в связке. Вероятно, появится спрос на политику допуска для «тяжелых» AI-job, особенно в мультиарендных средах, где у клиента есть доступ к большому числу ускорителей сразу.
Второй вывод касается инженерной инфраструктуры. Авторы отдельно говорят о необходимости локальных буферов энергии, способных сглаживать всплески спроса. Для бизнеса это означает дополнительные затраты не на модные AI-фичи, а на скучные, но жизненно важные вещи: накопители, управление качеством электроэнергии, защитную автоматику, новые схемы распределения нагрузок. Парадокс эпохи генеративного ИИ в том, что чем более «облачным» кажется продукт, тем больше он упирается в бетон, кабели, трансформаторы и теплотехнику.
Третий момент важен для разработчиков и ML-команд. Пока индустрия учится считать стоимость токенов и часов на H100, ей, похоже, придется думать и о профиле энергопотребления кода. В ряде сценариев вредоносной может оказаться не только явно атакующая задача, но и просто плохо спроектированный workload, который создает экстремальные колебания из-за синхронных пауз, checkpointing или неудачного orchestration. Иными словами, наблюдаемость training job скоро может включать не только throughput, utilization и latency, но и «электрическое поведение» кластера.
Наконец, исследователи указывают на еще один побочный риск: канал Watt2Bit. Идея в том, что электрическая и тепловая нагрузка на оборудование позволяет не только устраивать отказ в обслуживании, но и использовать модуляцию потребления для скрытой передачи данных. В proof of concept авторы смогли восстановить тестовую последовательность длиной 50 бит с помощью частотной манипуляции. До шпионского триллера тут пока далеко, но сама постановка вопроса неприятная: энергопотребление превращается не только в поверхность атаки, но и в канал утечки.
Открытый вопрос теперь не в том, возможны ли у облаков проблемы из-за прожорливости AI-кластеров. Это уже давно не вопрос. Вопрос в том, успеют ли провайдеры встроить защиту от вредоносной GPU-нагрузки раньше, чем рынок окончательно привыкнет считать GPU обычным арендным ресурсом, который можно выдать любому платежеспособному клиенту почти без оглядки на физические последствия. Детали исследования можно посмотреть в материале .