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

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

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

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

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

Оговорка: наш пилотный AI-ready модуль сейчас находится на этапе разработки. Финальная конфигурация еще не утверждена, но базовые инженерные решения уже приняты — о них я и расскажу в этой статье.

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

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

Инжиниринг традиционного МЦОДа и AI-ready модуля решает разные задачи:

• В МЦОДе главная цель — быстро и компактно разместить вычислительное оборудование.

• В проекте AI ready задача намного шире: отталкиваться приходится от теплового баланса, сценариев отказов и эргономики обслуживания.

Логика проектирования здесь разворачивается на 180 градусов: если в МЦОДе мы идём от ИТ-ёмкости к инженерным параметрам, то в AI ready — от управления теплом и аварийных сценариев к эргономике и компоновке.

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

Диалог с рынком

На ярославском форуме #МЫОтрасль один из коллег по рынку ЦОД усомнился в новизне продукта, назвав AI Base обычным «модным контейнером». В ходе дискуссии удалось прийти к двум ключевым выводам:

1. Проектирование энергоемкой инфраструктуры и МЦОДов для ИИ действительно имеет много точек пересечения.

2. Ни один классический AI-интегратор не берет на себя ответственность за работоспособность и отказоустойчивость инженерной базы.

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

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

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

Дополнительно инженеры просчитали граничные сценарии:

• Нижний диапазон (A100 / L40S): менее плотные конфигурации для базовых ИИ-задач.

• Верхний диапазон (B200): перспективная высоконагруженная среда для проверки предельного запаса прочности архитектуры.

Именно на этапе этих расчетов концепция «просто разместить стойки внутри стандартного контейнера МЦОД» окончательно себя исчерпала.

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

• Возрастает удельное тепловыделение.

• Ужесточаются требования к источникам бесперебойного питания.

• Растут токовые нагрузки, что меняет номиналы распределительного оборудования.

• Питание инженерных систем жестко сегрегируется по уровню критичности.

• Диспетчеризация расширяется: помимо общей температуры в модуле требуется сквозной контроль параметров вокруг каждой отдельной стойки.

Главное изменение — система охлаждения начинает полностью диктовать пространственную компоновку. Параллельно возрастает приоритет сервисной доступности, что напрямую усложняет планировку машзала.

Борьба за миллиметры: 12-метровый модуль и инженерное подполье

В компоновку пилота заложили 12-метровый модуль, вмещающий несколько IT-шкафов и телекоммуникационную стойку. Глубина стоек составляет 1200 мм. При общей ширине модуля порядка 3–3,2 метра такая посадка получается предельно плотной и заставляет отказываться от стандартных решений.

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

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

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

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

Однако при компоновке 12-метрового модуля проявился габаритный конфликт, где монтаж RDHx увеличивал глубину стойки примерно на 400 мм. Если для классического машзала это незначительный прирост, то в условиях компактного контейнера эти сантиметры критически урезали сервисные проходы. В итоге от технологии RDHx пришлось отказаться.

В качестве рабочих альтернатив инженеры перешли к анализу двух схем: In-Rack и Direct-to-Chip (D2C).

In-Rack (внутристоечное охлаждение). Стойка превращается в замкнутый тепловой контур, где воздух циркулирует внутри шкафа, проходит через встроенный теплообменник и возвращается к оборудованию. Схема минимально зависит от организации стандартных горячих и холодных коридоров, что крайне удобно для выигрыша пространства в проходах.

Direct-to-Chip / D2C (прямое жидкостное охлаждение кристаллов). Хладагент подводится непосредственно к самым горячим точкам GPU/CPU ускорителей. Это наиболее эффективный метод съема сверхвысоких тепловых нагрузок, но он требует отдельного контура для отвода остаточного тепла от прочих компонентов сервера и инженерных систем.

Выбор схемы и расчет теплового баланса

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

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

При расчете детализировали следующие параметры:

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

• Общее энергопотребление;

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

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

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

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

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

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

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

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

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

Ключевые вопросы к проектированию АКБ:

• Какое общее количество батарей потребуется?

• Как скомпоновать их в жестко ограниченном объеме модуля?

• Какова суммарная масса аккумуляторов?

• Пройдет ли весовая нагрузка по несущей способности основания?

• Сохранится ли сервисный доступ для оперативной замены аккумуляторов?

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

• Как правильно спроектировать схему вентиляции?

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

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

Игнорирование хотя бы одного из этих пунктов гарантирует сбой при первой же аварии.

Выбор аккумуляторов: AGM vs LFP

В качестве базового решения выбрали AGM-батареи, но здесь остается открытый риск: климат стеллажей (20–25 °C) поддерживается воздухообменом с горячим коридором. Достаточно ли только воздушного потока — вопрос пока открытый. Перегрев ускоряет старение AGM и режет реальное время автономии модуля, поэтому параллельно просчитывается альтернативный вариант на литиевых батареях (LFP).

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

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

Именно поэтому инженерные системы и диспетчеризацию (SCADA / BMS) нельзя разрывать на этапе проектирования. Мониторинг закладывается в архитектуру модуля с первого дня как базовый компонент платформы. В противном случае возникает ловушка «изолированной исправности», когда все узлы работают штатно сами по себе, но прозрачность общих режимов и понимание комплексных отказов отсутствуют.

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

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

Промежуточный срез: что зафиксировано в пилоте AI ready от ПСМ

Ключевые инженерные решения, принятые рабочей группой на текущем этапе разработки:

• Конструктив и оболочка: цельносварной транспортируемый модуль уличного типа, адаптированный к эксплуатации в температурном диапазоне от -40 °C до +40 °C.

• Профиль энергопотребления: плотность уровня high-density под задачи массового инференса с целевым ориентиром 40–42 кВт и рабочей вилкой 32–45 кВт на шкаф.

• Габариты и эргономика: 12-метровый контур, вмещающий специализированные стойки под GPU-серверы и телеком-оборудование с выверенной шириной проходов и регламентированными зонами обслуживания.

• Пространство под фальшполом: использование инженерного подполья для скрытой прокладки части коммуникаций, включая трассы гидравлики.

• Архитектура охлаждения: основной отвод тепла по технологии Direct-to-Chip (D2C) через распределительный блок CDU и вспомогательный воздушный контур для общесистемной автоматики.

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

• Двухлучевое электроснабжение: разводка независимых линий A/B с отдельными блоками распределения (PDU) до каждой стойки.

• Автономия и бесперебойность: массив AGM-аккумуляторов, гарантирующий от 5 минут автономной работы при максимальной загрузке ИТ-оборудования с учетом износа батарей.

• Единый контур SCADA / BMS: комплексная диспетчеризация электропитания, ИБП, батарей, PDU, микроклимата, гидравлических трактов, датчиков протечки, климатических блоков, систем пожаротушения и СКУД.

• Шлюз интеграции: вывод данных на верхнеуровневые платформы клиента через выделенную телеком-стойку.

• Чек-лист валидации: перечень обязательных инженерных проверок перед стартом следующей фазы проекта.

5 ключевых уроков проектирования

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

2. Именно технологическая схема охлаждения диктует размещение оборудования. Для сверхплотных стоек оптимален Direct-to-Chip (D2C), но окончательный выбор возможен только после сведения полного теплового баланса (heat budget).

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

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

5. Система SCADA / BMS должна закладываться параллельно с базовой инженеркой. Только так мониторинг становится инструментом предиктивной аналитики и управления, а не просто фиксатором случающихся аварий.

Что требует доработки: технологический беклог

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

Векторы работы для команды инженеров на ближайшие итерации:

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

• Смоделировать и посчитать контур охлаждения с применением чиллерных установок.

• Исследовать потенциал и границы охлаждения с применением внутристоечных систем In-Rack.

• Детально просчитать альтернативную концепцию гарантированного питания на литий-железо-фосфатных аккумуляторах (LFP).

• Провести углубленную экспертизу сценариев пожаротушения и противопожарной автоматики.

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

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