AI ready модуль: как мы проектировали модульный дата-центр для ИИ

В этой статье мы объясняли, почему для промышленного применения искусственного интеллекта одной модели недостаточно. Первым делом нужно создать инженерную инфраструктуру, готовую к вычислениям — и потом уже переходить к прикладным AI-сервисам.

В этой статье разбираем инженерный уровень AI ready инфраструктуры — AI Base. Это «железная» основа AI-системы: модуль, питание, охлаждение, ИБП, автоматика, безопасность и мониторинг.

Коротко: где расходятся стандартный МЦОД и AI Base

Как считали плотность: киловатты начали управлять площадью

Как сражались с компоновкой, чтобы всё поместилось и инженеру было где развернуться

Совместили две технологии охлаждения

Доказали, что 5 минут автономии — это много

Связали разрозненные показатели мониторинга

Пять практических выводов после пилота

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

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

Вопрос «сколько стоек поставить?» сменяется сразу несколькими новыми:

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

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

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

Поэтому стандартный МЦОД проектируется от ИТ-ёмкости к инженерным параметрам: сначала считается количество стоек, затем мощность, охлаждение и функции мониторинга. В AI Base порядок обратный: сначала тепловой и электрический баланс, затем сценарии отказа, а уже после этого компоновка, проходы, сервисные зоны и логика эксплуатации.

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

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

На этом этапе стало очевидно: формула «поставим GPU-стойки в готовый контейнер» не годится. Рост плотности приводит к цепной реакции. Увеличивается тепловыделение, растут токовые нагрузки, усиливаются требования к ИБП и распределительному оборудованию. Источники питания приходится разделять по критичности, а мониторинг должен видеть уже не только температуру в модуле, но и состояние систем вокруг каждой стойки.

Главный вывод этого этапа: охлаждение начинает управлять компоновкой.

В обычном МЦОДе сначала можно разместить стойки и затем подобрать инженерные системы. В AI Base так делать рискованно. Если не просчитать отвод тепла заранее, компактный модуль быстро превращается в красивый, но неудобный и перегретый объект.

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

Один из примеров — прокладка кабелей и трубопроводов. На раннем этапе казалось, что можно ограничиться боковыми и верхними лотками. Затем в проект вернулся фальшпол. По сути, его пришлось рассматривать не как декоративную часть машзала, а как инженерное подполье.

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

Для заказчика это ключевой фактор эксплуатации. Рендер может выглядеть убедительно, но в реальном проекте важнее другое: как быстро специалист доберётся до кабеля, датчика, трубы или АКБ, если возникнет перегрев, протечка или отказ. Модуль для ИИ должен быть не только компактным, но и обслуживаемым.

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

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

Следующие варианты — In-rack и direct-to-chip. In-rack переносит охлаждение внутрь самой стойки: воздух циркулирует в закрытом объёме, проходит через теплообменник и возвращается к оборудованию. Такая схема меньше зависит от классического разделения на холодный и горячий коридоры.

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

Для пилота выбрали D2C. При этом воздушное охлаждение не исчезает. В модуле остаются тепловые потери инженерных систем, поэтому воздушная схема сохраняется как дополнительная, а внутрирядные кондиционеры закладываются с резервом N+1.

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

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

В пилоте предусмотрено A/B-питание до каждой стойки. В схеме два независимых тракта и два распределительных блока PDU. Базовая логика — 2N. Но дальше появляется более сложный вопрос: как питать охлаждение, если именно оно удерживает вычислительный контур в рабочем режиме.

В текущей пилотной логике стойки, кондиционеры, CDU и драйкулеры заведены на защищённый контур вместе с ИТ-нагрузкой. Это решение проверено по отказным сценариям, а не по принципу «достаточно ли киловатт»: фиксировали, что произойдёт при потере одного элемента, как долго система сохранит режим и какие потребители критичны для безопасного завершения работы.

Требование к ИБП и АКБ — не менее пяти минут автономии при полной ИТ-нагрузке на конец срока службы батарей. На бумаге пять минут выглядят скромно. При высокоплотной нагрузке это сложная инженерная задача: нужно рассчитать количество батарей, массу, нагрузку на основание, вентиляцию, температурный режим, мониторинг тока, напряжения и аварийных сигналов.

Базово для пилота выбрали AGM АКБ. Но у решения есть риск: температурный режим 20–25 °C у стеллажей с АКБ предполагается обеспечивать воздухообменом с горячим коридором. Эту гипотезу нельзя оставлять без расчёта: перегрев ускоряет старение AGM и может снизить фактическую автономию. Поэтому параллельно мы рассматриваем и вариант с литием.

В стандартном МЦОДе мониторинг сводится к контролю температуры, питания, аварий и доступов. Для ИИ-нагрузки этого мало. Система должна показывать не только факт отклонения, но и место, где возникла проблема: стойка, жидкостный контур охлаждения, АКБ или ввод питания.

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

В пилоте предусмотрен интерфейс обмена с верхним уровнем заказчика. Собрать инженерные данные — технически решаемая задача. Сложнее определить границу интеграции: что остаётся на стороне AI Base, что передаётся в SCADA / BMS заказчика и как эти данные будут использоваться в эксплуатации.

Для AI-системы это принципиально. Эксплуатация не должна превращаться в реакцию на аварию постфактум. Мониторинг должен управлять режимами: показывать тренды, предупреждать об отклонениях по теплу, питанию, протечкам, АКБ и охлаждению до того, как возникнет критический отказ.

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

Определена базовая архитектура: цельносварной инженерный модуль уличного исполнения, рассчитанный на транспортировку и работу в климатическом диапазоне от -40 °C до +40 °C. Принят расчётный класс нагрузки high-density: 32–45 кВт на стойку, базовая точка 40–42 кВт.

Рабочая компоновка строится вокруг 12-метрового модуля с четырьмя ИИ-стойками и одной телеком-стойкой глубиной 1200 мм. Внутри учитываются ширина проходов, сервисные зоны, инженерное подполье, жидкостный контур охлаждения, силовые трассы, дренаж и контроль протечек.

По охлаждению выбрана развилка с direct-to-chip, жидкостным контуром CDU и дополнительным воздушным охлаждением инженерных систем. Для воздушной части заложены внутрирядные кондиционеры по схеме N+1.

По питанию предусмотрены два независимых тракта и два PDU, A/B-питание до каждой стойки, логика ИБП и АКБ для минимум пяти минут автономии на конец срока службы батарей. По мониторингу — единая SCADA / BMS для питания, ИБП, АКБ, PDU, микроклимата, жидкостного контура, протечек, кондиционеров, пожарной системы и доступов. Данные планируется передавать на верхний уровень через телеком-стойку.

1. AI Base (модульный ЦОД для ИИ) нельзя проектировать как стандартный МЦОД с повышенной мощностью. Ключевое отличие — плотность ИТ-нагрузки, которая полностью меняет порядок проектирования.

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

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

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

5. Систему SCADA / BMS нужно закладывать с самого начала. Для AI Base мониторинг — это не набор аварийных сигналов, а нервная система, которая связывает питание, холод, протечки, АКБ, PDU, пожарку и доступы в единую эксплуатационную картину.

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

Дальше инженерной группе ПСМ предстоит проверить конфигурации охлаждения, где может быть достаточно RDHx вместо D2C, рассчитать конфигурацию с чиллерами, оценить перспективу технологии In-rack. В планах проработать альтернативное резервирование на литий-ионных АКБ, уточнить пожарную логику и разделить зоны ответственности за интеграцию с верхним уровнем SCADA / BMS заказчика.

Главный открытый вопрос — насколько типовым может стать такое решение. AI-нагрузки сильно различаются, а значит, в какой-то момент серийная модель может перейти в проектное исполнение. Но ответить на это можно только после запуска в промышленную эксплуатацию.