AI ready: почему дата-центр для ИИ сложнее обычного модульного ЦОДа

В первой статье я рассказал, как мы пришли к идее AI ready — локального контура, который собирает инженерную базу, вычисления и прикладной ИИ в одну систему. Теперь подробнее про первый «железный» уровень ИИ-контура — AI Base.

Идеи есть у многих, до пилота добираются единицы. Мы думали: возьмём концепцию модульного ЦОДа, немного подобьём её под стойки с GPU, и наш пилот полетит. В МЦОДе уже решены базовые задачи по компоновке, комплектации и автоматике — так зачем изобретать велосипед? Но первая гипотеза провалилась, как только мы начали считать нагрузку.

AI-нагрузка меняет подход к проектированию МЦОДа. Как именно? Полгода назад рабочей группе инженеров только предстояло это понять.

Скажу сразу: пилот AI ready сейчас находится на этапе разработки. Итоговую конфигурацию мы пока не утвердили, но базовые инженерные решения уже приняты. Про них рассказываю в статье.

• Миссия 1. Киловатты и квадратные метры

• Миссия 2. Налить воды на вентилятор

• Миссия 3. Втык за отказы, или тревожная пятиминутка

• Миссия 4. Наблюдай, проверяй, предупреждай

• Пилот AI ready

• 5 выводов по ходу проекта

• Открытые вопросы 

Выберите игрока: МЦОД vs AI-ready модуль

Снаружи AI ready модуль выглядит как обычный модульный ЦОД: блок-контейнер, стойки, ИБП, распредка, охлаждение и так далее. Сходство заканчивается, когда вместо стандартных юнитов в стойки ставят GPU-серверы. Нагрузка на стойку с GPU в 2–3 раза больше, чем в стандартном МЦОДе.

Инжиниринг МЦОДа и AI ready решают разные задачи. В МЦОДе достаточно быстро и компактно разместить оборудование. Для проекта AI-модуля задача шире.

МЦОД проектируем от ИТ-ёмкости к инженерным параметрам, AI ready — от теплового баланса и отказов — к эргономике.

Расшифруем эти не сразу понятные слова. Пробежимся по отличиям детально.

Короче: в МЦОДе достаточно посчитать / разместить стойки под требуемое количестве серверов и хорошенько их запитать, в AI ready — сначала надо понять, как отводить тепло и обслуживать модуль, а потом согласовывать это с нагрузкой.

В начале июня в Ярославле на площадке #МЫОтрасль собирались топы и техдиректора рынка ЦОД. Ко мне подошёл один коллега и высказал скепсис относительно нашего нового продукта. Мол, AI Base — это просто модный контейнер. Мы недолго поспорили. В итоге сошлись на двух вещах. 

Первое — проектирование энергетической инфраструктуры и МЦОДов для ИИ во многом пересекаются. Второе — ни один AI-интегратор не возьмёт ответственность за работу инженерки. Поэтому ставка на наш AI ready пилот вполне может сыграть, но важно не зависнуть на теории, а как можно быстрее перейти к практике.

Миссия 1. Киловатты и квадратные метры

Для пилотного AI ready модуля приняли расчётную плотность 32–45 кВт на стойку. Базовая точка проектирования — 40–42 кВт. Это соответствует сценарию с GPU-серверами класса H100 / H200 — высокоплотным ускорителям (high-density) для обучения и инференса крупных моделей. 

Дополнительно проверили нижний и верхний сценарии:

• A100 / L40S — менее плотные конфигурации для лёгких AI-нагрузок;

• B200 — более тяжёлую перспективную нагрузку, чтобы понять запас инженерной архитектуры.

На этом этапе логика «поставим стойки в контейнер МЦОД» и перестала работать. 

Модульный ЦОД — локальная альтернатива классическому дата-центру. Внутри у МЦОДа знакомый набор систем, которые в целом совпадают с набором в AI ready.

Что меняет рост плотности в модульном ЦОДе для ИИ:

• Увеличивается тепловыделение;

• Усиливаются требования к ИБП;

• Растут токовые нагрузки;

• Меняются номиналы распредоборудования;

• Источники питания систем разделяются по критичности;

• В мониторинг к температуре в модуле добавляется состояние систем вокруг каждой стойки.

Но главное — охлаждение начинает диктовать компоновку. Кроме того, в AI ready растёт значимость сервисной доступности, поэтому проектирование компоновки осложняется расположением зон обслуживания.

В пилотную компоновку AI ready заложили 12-метровый модуль. В модуле несколько ИТ-шкафов и телеком-стойка. Глубина стоек — 1200 мм. Для модуля шириной около 3–3,2 метра это уже плотная посадка, которая заставляет инженера спотыкаться и мыслить творчески.

Например, мы долго боролись с прокладкой кабелей. На этапе ТЗ планировали задействовать только боковые и верхние лотки. А потом присмотрелись к фальшполу. В одной из итераций поняли, что фальшпол корректнее считать инженерным подпольем. В пилоте под ним идут часть силовых трасс, трубопроводы охлаждения, дренаж и система контроля протечек. Доступ — через съёмные панели. Состояние подполья при этом планируем обязательно отражать в мониторинге, в том числе для визуального контроля. 

Да, красивый рендер может нарисовать кто угодно, в том числе ИИ. В реальном проекте важно, как инженер доберётся до труб, кабелей, датчиков и оборудования, если что-то потечёт, перегреется или выйдет из строя. Модуль должен быть не только компактным, но и обслуживаемым.

Миссия 2. Налить воды на вентилятор

На старте для пилота рассматривали охлаждения с RDHx — дверями-теплообменниками на стойках. Серверы охлаждаются воздухом, горячий поток проходит через теплообменник на задней двери, а тепло уходит во внешний водяной контур.

При компоновке в 12-метровом модуле возник конфликт: RDHx увеличивает глубину стойки примерно на 400 мм. Для обычного машзала это не проблема, а в компактном ИИ-модуле — это критично для ширины проходов и сервисных площадок. В итоге от RDHx отказались.

Следующие рабочие альтернативы: In-Rack и Direct-to-Chip.

In-Rack — охлаждение внутри самой стойки. В этом варианте стойка становится почти самостоятельным тепловым контуром: воздух циркулирует внутри, проходит через теплообменник и возвращается обратно к оборудованию. Такая схема менее зависима от классической планировки с холодным и горячим коридорами. В компактном модуле это полезно для ширины проходов и управления воздушными потоками вокруг стоек. 

Direct-to-Chip (D2C) — жидкостное охлаждение. Теплоноситель подводится напрямую к самым горячим компонентам GPU/CPU-серверов. Тепло отводится через жидкость, уходит в CDU — распределительный узел охлаждения, затем во внешний контур с драйкулером. 

При D2C в модуле остаются тепловые потери инженерных систем: ИБП, распредки, НКУ, автоматики и других вспомогательных систем. Поэтому воздушное охлаждение сохраняется как вспомогательное.

Для пилота выбрали D2C. Для воздушной схемы заложили внутрирядные кондиционеры на каждую стойку плюс один на резерв. Но прежде чем утвердить решение, нужно было доказать, что компоновка выдержит температурный режим. Для этого рассчитали тепловой баланс (heat budget).

Для расчёта разложили логику охлаждения по деталям:

• Холодопроизводительность;

• Энергопотребление;

• Зоны охлаждения;

• Движение потоков воздуха;

• Риски смешивания горячих и холодных потоков;

• Сценарии отказа одного из блоков. 

Итог «холодной миссии»: посчитали, сколько тепла D2C будет снимать через CDU, сколько останется от инженерных систем для отвода воздухом. Поймали тепловой баланс и перешли к электричеству. 

Миссия 3. Втык за отказы, или тревожная пятиминутка

Тепловой баланс ведёт за собой баланс электрический (power budget). Он показывает, сколько электрической мощности нужно всем потребителям AI ready, откуда они запитаны и как работают при отказе.  

В пилоте AI ready предусмотрели A/B питание до каждой стойки. В схеме два независимых тракта и два распределительных блока (PDU). В начале — простая логика 2N. Дальше вопрос со звёздочкой: как питать охлаждение? Мы завели его на ИБП вместе с ИТ-нагрузкой: стойки, кондиционеры, CDU и драйкулеры питаются от защищённого контура. 

Требования по ИБП и АКБ по техзаданию — не менее пяти минут при полной ИТ-нагрузке на конец жизненного цикла батарей. Вы скажете: «Пф-ф, 5 минут — что тут сложного?» Отвечу: для конфигурации high-density и пять минут дорогого стоят.  

Вот базовые вопросы к инженеру:

• Сколько батарей нужно?

• Как их разместить в ограниченном пространстве?

• Какая у АКБ масса?

• Выдержит ли основание модуля весовую нагрузку?

• Остаётся ли доступ для замены АКБ?

• Как поддерживать температурный режим?

• Как организовать вентиляцию?

• Как контролировать напряжение, ток, температуру и аварийные сигналы?

• Как старение батарей будет влиять на фактическую автономию?

Не ответите хотя бы на один — втык за отказ гарантирован. 

Базово выбрали АКБ AGM, но в решении есть риск. Температура 20–25 °C у стеллажей с АКБ обеспечивается воздухообменом с горячим коридором. Достаточно ли только воздуха? Этот вопрос пока открыт, но без ответа его оставлять нельзя, потому что перегрев ускоряет старение AGM и может сократить реальную автономию AI ready. Поэтому проверяем альтернативный вариант с литием (LFP).

Миссия 4. Наблюдай, проверяй, предупреждай

Что мониторят в стандартном МЦОДе? Обычно достаточно видеть температуру, питание, аварии и доступы. В AI ready класса high-density этого мало. Кроме сигнала о том, что «стало жарко», нужно видеть, где именно нарушается температурный режим: в стойке, в жидкостном контуре, в АКБ, в PDU, в CDU, во внешнем контуре охлаждения или на вводе питания.

Поэтому SCADA / BMS отдельно от остальной инфраструктуры проектировать нельзя. Мониторинг должен быть частью продукта и прорабатываться одновременно со всеми остальными системами с нуля. Иначе выйдет набор выверенных исправных систем, которые не видят друг друга: стойки работают, охлаждение работает, ИБП работает, но общей картины по режимам и отказам нет.  

В пилоте AI ready заложен интерфейс обмена с верхним уровнем заказчика. Градус ответственности здесь примерно такой же, как у стойки с B200, которая считает цифрового двойника буровой посреди июля. Собрать инженерные данные — не проблема, а вот интеграция наверх зависит от архитектуры заказчика и пока не зафиксирована в типовом виде. 

Для AI ready это принципиальный момент — эксплуатация не должна превращаться в примитивную реакцию на аварии.

Пилот AI ready

Подытожу, что уже готово/определено в пилоте AI ready разработки ПСМ:

• Базовая архитектура модуля: цельносварной инженерный модуль уличного исполнения от -40 ^оС до +40 ^оС, рассчитанный на транспортировку;

• Расчётный класс нагрузки: high-density под массовый инференс (32–45 кВт на стойку с базовой точкой 40–42 кВт);

• Рабочая компоновка: 12-метровый модуль с ИТ-стойками под GPU-серверы и телеком-стойкой, с утверждённой шириной проходов и площадью сервисных зон;

• Инженерное подполье: фальшпол, под которым проходит часть инженерных коммуникаций, в том числе контур охлаждения;

• Развилка по охлаждению: Direct-to-Chip (D2C) c жидкостным контуром CDU и дополнительное воздушное охлаждение для инженерных систем;

• Резерв воздушного охлаждения: внутрирядные кондиционеры по схеме N+1;

• A/B-питание до каждой стойки: два независимых тракта питания и два PDU;

• Логика ИБП и АКБ: AGM АКБ для минимум пяти минут автономии при полной ИТ-нагрузке на конец срока службы батарей;

• Логика SCADA / BMS: мониторинг питания, ИБП, АКБ, PDU, микроклимата, жидкостного контура, протечек, кондиционеров, пожарной системы и доступов в единой системе;

• Точка передачи данных заказчику: через телеком-стойку в верхний уровень;

• Список проверок перед следующей итерацией.

5 выводов по ходу проекта

1. AI ready в отличие от стандартного МЦОДа проектируется от теплового баланса и отказов — к эргономике. МЦОД проектируется от ИТ-ёмкости к инженерным параметрам. Ключевое различие продуктов — ИТ-нагрузка. В AI ready она выше в 2–3 раза, и это полностью меняет логику проектирования. 

2. Охлаждение управляет компоновкой. Для высокой плотности лучше подходит D2C, но утверждать решение можно только после расчёта теплового баланса.

3. Необходим расчёт энергетического баланса. Он показывает, сколько электрической мощности нужно всем потребителям AI ready, откуда они запитаны и как работают при отказе.  

4. Сервисная доступность — неизбежная головная боль инженера AI ready. Если стойку, панель или АКБ невозможно быстро обслужить без разборки соседнего оборудования, ИИ-модуль свою функцию не выполнит.

5. Мониторинг SCADA / BMS нужно проектировать с самого начала вместе со всей инженеркой, чтобы он обеспечивал управляемую эксплуатацию с аналитикой, а не только реакции на отказы.

Открытые вопросы

На момент написания этой статьи пилот AI ready (если быть точным, его инженерный слой AI Base) находится на этапе проверки инженерной гипотезы. Базовые решения уже приняты, но многие детали требуют дополнительных расчётов и проверок. По-другому никак, учитывая, что подобного рабочего продукта на рынке пока нет.

Следующие миссии для нашей инженерной группы:

• Проверить конфигурации, в которых может быть достаточно охлаждения RDHx вместо D2C;

• Рассчитать схему охлаждения с чиллерами;

• Оценить перспективу охлаждения внутри стоек In-Rack;

• Проработать альтернативное резервирование с литием — АКБ LFP;

• Дополнительно проанализировать пожарную логику;

• Разделить зоны ответственности за интеграцию в верхний уровень SCADA / BMS заказчика.

Глобально нам ещё предстоит понять, насколько реально сделать решение типовым с учётом разных ИИ-нагрузок. Вполне возможно, что проектное исполнение перейдёт границу серийных моделей. Но выяснить это мы сможем только на практике.