Переход к GPU меняет инженерную картину ЦОДа быстрее, чем успевает меняться привычная терминология. Для нового объекта требования к высокой плотности мощности можно заложить в проект заранее. В brownfield-проектах все иначе: приходится иметь дело с реальными ИБП, шинопроводами, кабельными трассами, тепловыми режимами, насосами, свободным местом и ограничениями эксплуатации. Поэтому разговор о готовности лучше начинать не со слова «ИИ», а с конкретного профиля будущей нагрузки.
Важно и другое: делить инфраструктуру на «для обучения» и «для инференса» слишком грубо. Инженерный профиль задает не название вычислительной задачи, а конкретное оборудование и режим его работы. Крупный инференс-кластер способен предъявлять столь же высокие требования к мощности и охлаждению, как система для обучения. И наоборот, несколько GPU-серверов могут нормально работать в традиционной серверной. Поэтому сначала — подсчет ИT-нагрузки, потом — вывод о площадке.
Не спрашивать «готов ли ЦОД», а просчитывать конкретный сценарий
Практичная последовательность действий для работающей площадки выглядит так: сначала фиксируется целевая конфигурация, затем — фактическое состояние объекта, после этого — разрыв между ними и только в конце принимается решение о модернизации. Мы в FacilitySide называем эту цепочку «Target → Current → Gap → Decision».
Причем для целевой нагрузки недостаточно знать только «80 кВт на стойку». Нужны схема питания, число вводов, требования к резервированию, тип охлаждения, доля тепла, снимаемая жидкостью, остаточная воздушная нагрузка, требуемые температуры и расход теплоносителя, масса стойки, сервисные зоны и допустимые режимы при отказе.
Для примера: Nvidia для DGX GB200 NVL72 указывает потребление стойки около 120 кВт и штатную жидкостную систему охлаждения. Это не типовая ИИ-стойка и не универсальный нормативный порог. Но пример хорошо показывает, насколько далеко современная нагрузка на стойку ушла от привычных 5–15 кВт. А допустимый режим в каждом случае определяется требованиями конкретного ИT-оборудования, схемой объекта и результатами измерений.
Первое ограничение часто находится не там, где его ищут
При обследовании часто можно услышать: «На объекте есть свободные 500 кВт, значит, несколько GPU-стоек поставим без проблем». На практике свободная мощность на вводе — только начало цепочки. До конкретной стойки энергия доходит через ГРЩ, ИБП, распределительные панели, шинопроводы, PDU, кабели и коммутационные аппараты. Слабым местом может оказаться любой участок.
Поэтому оценивать нужно не общий резерв объекта, а мощность, которую можно безопасно довести до выбранной точки машинного зала в штатном и аварийном режимах. Если в штатной схеме ветвь загружена умеренно, это еще не означает, что после отключения соседнего ИБП или секции оставшаяся инфраструктура сохранит допустимую загрузку.
Есть и типичная brownfield-проблема: проектная документация говорит одно, а объект за годы эксплуатации начал жить по другой схеме. Добавлялись щиты, переносились нагрузки, менялись автоматы. Поэтому решения по высокой плотности нельзя принимать только по старой однолинейной схеме — документацию нужно сверять с фактическим состоянием и результатами измерений.
Высокая плотность требует не только жидкостного охлаждения
Универсальной границы, после которой «воздух больше не работает», нет. Она зависит от серверов, расхода воздуха, температуры подачи, качества изоляции горячих и холодных коридоров, рециркуляции и возможностей холодоснабжения. Но направление отрасли очевидно: с ростом плотности возрастает роль непосредственного жидкостного охлаждения (direct-to-chip) и других жидкостных схем.
ASHRAE в документе AI Data Center Energy Performance Framework рассматривает жидкостные и гибридные архитектуры как базовый путь для высокоплотных ИИ-нагрузок и отдельно выделяет диапазон 50–100+ кВт на стойку. Для модернизации действующих площадок логичен гибридный подход: основную тепловую нагрузку процессоров снимать жидкостью, а существующий воздушный контур использовать для остаточного тепла.
Установка холодной пластины (cold plate) на GPU не означает, что воздушное охлаждение больше не нужно. Часть тепла по-прежнему остается в воздухе, а жидкостный контур еще должен передать тепло на уровень объекта и вывести его наружу. Поэтому мнение «поставим CDU — и все заработает» почти всегда слишком оптимистично.
CDU нужно рассматривать как часть гидравлики объекта
Блок распределения охлаждающей жидкости (coolant distribution unit, CDU) связывает технологический контур серверов с системой охлаждения площадки. В действующем ЦОДе приходится выяснять, куда его физически установить, откуда взять теплоноситель нужной температуры, хватит ли расхода и перепада давления, что произойдет при отказе насоса, как организовать фильтрацию, подпитку, дренаж и обнаружение утечек.
Если готовой системы водяного охлаждения площадки нет, возможны промежуточные решения, например CDU с теплообменником «жидкость — воздух». Они позволяют подключить охлаждаемое жидкостью ИТ-оборудование без немедленного строительства полноценного водяного контура. Но тепло в этом случае возвращается в воздух машинного зала, и его все равно должен принять существующий воздушный контур. Такой вариант может быть хорош для пилотной инсталляции или ограниченной зоны, но необязательно, что он окажется пригоден для масштабирования на десятки стоек.
Главный результат обследования — не «балл готовности»
Для владельца действующего ЦОДа намного полезнее получить текущий безопасный эксплуатационный диапазон (current safe envelope), т.е. понять, какую новую нагрузку площадка способна принять сегодня без нарушения согласованных критериев надежности и температурного режима, а где начинаются ограничения.
Нужно подтвердить доступную мощность в точке подключения; запас по ИБП, PDU и шинопроводам; фактический запас по охлаждению; температуры, расход и давление в жидкостном контуре; массу и габариты стойки; нагрузку на пол; сервисные зоны; трассы труб и кабелей; сценарии отказа, переключения, ремонта и утечки.
Отдельно выделяются стоп-факторы. Например, мощности на объекте достаточно, но после отказа одной ветви оставшаяся цепочка перегружается. Или вода нужной температуры есть, но существующая гидравлика не обеспечивает требуемый расход. Или стойку невозможно безопасно установить и обслуживать в выбранной точке.
После обследования решение обычно попадает в одну из четырех категорий:
- Go — целевую нагрузку можно вводить.
- Conditional go — можно, но после конкретного перечня работ.
- No go — текущая архитектура требует слишком глубокой реконструкции или создает неприемлемый риск.
- Inconclusive — данных недостаточно и нужны дополнительные измерения.
Последний вариант не менее важен, чем остальные: лучше прямо зафиксировать, что данных недостаточно для обоснованного вывода, чем принимать решение, опираясь лишь на предположения.
Не всегда нужно модернизировать весь ЦОД
После определения ограничений становится понятно, какой масштаб работ действительно нужен. Иногда рационально начать с одной пилотной стойки и проверить питание, охлаждение и эксплуатационные процедуры под реальной нагрузкой. Иногда логичнее выделить отдельную GPU-зону со своей схемой распределения мощности и жидкостным контуром. А иногда ограничения объекта настолько фундаментальны, что глубокая модернизация проигрывает альтернативному размещению по срокам, риску и CAPEX.
Поэтому вендоронейтральное обследование должно предшествовать выбору конкретного CDU, чиллера или ИБП. Иначе появляется риск оптимизировать не ту часть системы. Сначала нужно найти реальное узкое место, затем сравнить сценарии его устранения.
Последняя проверка — под нагрузкой
Даже хороший проект еще не доказывает, что высокоплотная зона готова к эксплуатации. Для этого нужен commissioning: поэтапный ввод нагрузки, проверка переключений, отказов, автоматики, температурных режимов и реакции мониторинга.
Именно здесь проверяется главное: выдерживает ли связка «электрика + холод + гидравлика + автоматика + персонал» те режимы, ради которых проект и строился. Для действующего ЦОДа это особенно важно, потому что новая ИИ-зона должна не только работать сама, но и не ухудшить устойчивость уже работающей инфраструктуры.
Что в итоге должен получить владелец площадки
Хороший brownfield-аудит заканчивается не длинным перечнем замечаний, а инженерной картой решения: что именно хотим разместить; что реально есть на объекте; где находятся ограничения; какие из них критичны; какую нагрузку можно принять без реконструкции; что нужно изменить для следующего шага; какова последовательность работ и где после модернизации потребуется повторная проверка.
Тогда слово «AI-ready» перестает быть маркетинговым ярлыком и превращается в проверяемое утверждение для конкретной конфигурации оборудования и конкретного режима эксплуатации. На мой взгляд, это единственный полезный способ говорить о готовности действующего ЦОДа к AI/GPU-нагрузкам.
Технические ориентиры:
- ASHRAE. AI Data Center Energy Performance Framework;
- ASHRAE TC 9.9. Thermal Guidelines for Data Processing Environments;
- Материалы ASHRAE по жидкостному охлаждению;
- Nvidia. DGX GB Rack Scale Systems User Guide — разделы по электропитанию, жидкостному охлаждению и предотвращению утечек.
Матвей Жарков, руководитель проекта, FacilitySide
