Жидкостное охлаждение для GPU: когда выгодно в HPC

С чего начинается вопрос про жидкость в GPU кластере

Вопрос про жидкостное охлаждение для GPU обычно появляется не из любопытства, а из боли: новые поколения ускорителей выделяют больше тепла, и привычная схема с холодными коридорами и мощными CRAC/чиллерами начинает работать на пределе. Сначала растет температура на входе серверов, потом ускоряются вентиляторы, шум становится заметным даже за дверью, а стабильность под нагрузкой падает.

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

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

Перед закупками полезно ответить на несколько практичных вопросов:

• Какая целевая мощность на стойку через 12-24 месяца, а не только в текущем пилоте?
• Где узкое место сейчас: подача холода, отвод тепла, электропитание, место, шум?
• Какой уровень непрерывности нужен (например, 24/7 для обучения моделей) и как вы переживете остановку охлаждения?
• Кто будет обслуживать контур, и какие процедуры приемки и регламентов вы готовы вести?
• Как вы будете управлять рисками протечек: датчики, зоны, отсечные клапаны, доступ к обслуживанию?

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

Какие варианты жидкостного охлаждения встречаются в HPC

В HPC нет одного «правильного» способа охлаждать GPU. Выбор упирается в плотность мощности, ограничения помещения и то, как ваша команда привыкла обслуживать железо. При этом даже при переходе на жидкостное охлаждение часть тепла почти всегда остается на воздухе (память, VRM, сетевые карты, диски).

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

Основные варианты

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

Immersion (погружение) меняет сам подход: серверы работают в диэлектрической жидкости. Тепло снимается очень эффективно, но доступ к железу становится другим. Нужно уметь «работать с ванной», соблюдать чистоту, учитывать расходники и заранее обучать персонал.

Rear-door теплообменники (двери-теплообменники) ставятся на стойку и снимают тепло с выходящего горячего воздуха. Это часто выбирают для действующих залов, где сложно переделывать весь ИТ-контур, но можно подвести воду к рядам. По эффективности это компромисс: воздух остается внутри стойки, зато температура в помещении заметно падает.

Чтобы выбрать тип, проверьте пять вещей:

• можно ли подвести воду (и куда именно) без большого ремонта
• какой максимум кВт на стойку вы планируете через 1-2 года
• кто и как будет обслуживать узлы ночью и в выходные
• насколько критичны простои при протечке или ошибке персонала
• есть ли место под распределение, фильтрацию и мониторинг контура

Простой ориентир: если у вас уже стоит ряд с «плотными» GPU и нет возможности остановить зал на переделку, rear-door может дать выигрыш быстро. Если же вы строите новый кластер и заранее закладываете инженерку, direct-to-chip чаще дает лучший баланс эффективности и привычного сервиса.

Когда жидкость становится выгодной по плотности мощности

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

Есть практичные ориентиры. Пока стойка держится в районе 10-20 кВт, воздух чаще всего справляется при нормальной организации холодных и горячих коридоров. В диапазоне 20-30 кВт начинается зона, где любое отклонение (грязные фильтры, частичная рециркуляция, жаркое лето, неплотные фальшпанели) уже заметно повышает температуру на входе. А когда проект стремится к 30-60 кВт на стойку и выше (что типично для плотных GPU-узлов), жидкость часто становится самым прямым способом сохранить частоты и стабильность.

Проблема воздуха в том, что GPU чувствительны к температуре на входе: несколько градусов вверх приводят к росту оборотов вентиляторов, затем к троттлингу и падению производительности под нагрузкой. В реальных задачах HPC это выглядит так: кластер формально «работает», но время расчета растет, а результаты бенчмарков перестают повторяться.

Еще несколько признаков, что пора считать жидкость:

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

Например, если в действующей серверной уже заняты ряды и каждый новый GPU-узел поднимает температуру в горячем коридоре, жидкость может дать рост мощности без переезда. В таких проектах системный интегратор вроде GSE.kz обычно начинает с расчета: сколько кВт нужно увести из стойки сегодня и какой коридор расширения закладывается на 2-3 года, чтобы решение не пришлось переделывать после первой же очереди.

Экономика и окупаемость: как сравнивать воздух и жидкость

Сравнение воздуха и жидкости почти всегда упирается в то, что расходы распределены по-разному. У воздуха обычно ниже старт, но быстрее растут ограничения по плотности и шуму. У жидкости выше затраты на входе, зато проще держать высокую нагрузку без перегрева. Если вы рассматриваете жидкостное охлаждение для GPU, полезно считать не только «железо», но и то, как оно будет жить 3-5 лет.

В CAPEX закладывают не только стоимость серверов, но и инженерную часть, монтаж и пусконаладку: коллекторы, трубопроводы, запорную арматуру, датчики протечек, ввод теплообменника, работы на площадке. Часто именно монтаж и переделки помещения делают проект «дорогим».

В OPEX обычно недооценивают две вещи: стоимость простоев и трудозатраты команды. Экономия по электроэнергии бывает, но она не всегда главная. На практике важнее, что при стабильных температурах GPU реже уходят в троттлинг и дольше держат частоты. В расчете это выглядит как прирост полезных вычислений на тот же парк ускорителей, то есть вы покупаете меньше GPU для той же задачи.

Отдельной строкой добавьте расходники и мелкие замены:

• фильтры и обслуживание контуров
• теплоноситель и анализ его состояния
• быстросъемы, уплотнения, соединители
• датчики и тестовые комплекты для контроля протечек
• резервные элементы для «быстрого ремонта»

Сравнивайте сценарии раздельно: новая площадка и модернизация действующей. В новом зале проще заложить нужные магистрали и резервирование заранее. В существующей серверной обычно дороже обходятся остановки, ограничения по месту и необходимость работать «без выключения». Здесь помогает предварительный аудит инженерии и аккуратный план миграции, который часто делают системные интеграторы уровня GSE.kz.

Как прикинуть проект: пошаговый подход без лишней теории

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

Дальше выберите целевую схему охлаждения, но привязывайте ее к вашим условиям. Direct-to-chip обычно проще по внедрению и обслуживанию. «Задние двери» (rear door) хорошо заходят там, где нельзя трогать серверы. Immersion чаще оправдан, когда плотность очень высокая и вы готовы менять операционные привычки.

Чтобы оценка была предметной, соберите на старте:

• потребление (кВт) на узел и планируемое количество узлов через 12-24 месяца
• целевую плотность стойки и допустимую температуру в «холодном» коридоре
• ограничения помещения (высота фальшпола, доступ к коммуникациям, проходы)
• требования по отказоустойчивости (что считается простоем и сколько его можно)
• команду эксплуатации: кто реально будет обслуживать контуры и по каким регламентам

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

Затем прикиньте состав «середины» системы: CDU, насосы, резервирование, датчики протечки, учет давления и расхода, интеграцию мониторинга. И только потом проверьте на плане помещения, где это все встанет и как к нему подойти для сервиса.

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

Что проверить в инженерной части помещения

Жидкостное охлаждение для GPU дает выигрыш по плотности, но только если помещение готово принять «воду» как часть инженерной системы. Ошибка здесь обычно дороже, чем лишние вентиляторы в стойке.

Планировка и места под оборудование

Сразу прикиньте, куда встанут CDU (узлы распределения охлаждения), коллекторы и трассы трубопроводов. Важно не только «влезает ли», но и есть ли нормальный доступ для обслуживания: замена фильтров, работа с арматурой, слив и заполнение контура, подъем оборудования.

Если серверная уже работает, полезно пройти маршрут глазами техника: можно ли подойти к CDU с инструментом, не перекрывая проход, и есть ли место для безопасного демонтажа шлангов без риска задеть соседние стойки.

Безопасность, проливы и аварийные сценарии

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

Ключевое - сценарий «насосы остановились». При потере питания часть контуров может быстро перегреться, а часть - уйти в ошибку по давлению. Нужны понятные действия автоматики и людей.

Проверьте минимум:

• электропитание CDU и насосов: резервирование, ИБП, что будет при переключениях
• перекрывающую арматуру: где стоят клапаны, как быстро отсечь контур, кто имеет доступ
• качество воды или теплоносителя: фильтрация, контроль коррозии и совместимость материалов
• согласование с вентиляцией: что остается на воздухе (память, VRM, сетевые карты) и хватает ли потока
• логику аварий: сигнализация, останов кластера, уведомления, порядок восстановления

В проектах системной интеграции (например, когда кластер собирают и сопровождают такие команды, как GSE.kz) эти проверки обычно фиксируют в одном документе: схема контуров, точки контроля и четкий план действий при протечке и при остановке насосов.

Обслуживание и эксплуатация: что меняется для команды

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

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

Регламент осмотров и расходники

Плановые проверки становятся регулярными и короткими, но обязательными. Обычно смотрят не только на температуру, но и на «механику» контура:

• соединители и уплотнения на следы влаги и коррозии
• фильтры и качество теплоносителя по регламенту
• давление и его стабильность во времени
• крепления шлангов и отсутствие натяга
• чистоту теплообменников и отсутствие воздушных пробок

Параллельно появляется учет расходников: уплотнительные кольца, фильтры, теплоноситель, датчики. Важно обучить дежурных не просто «как открутить», а как не занести воздух в контур и не перепутать линии подачи и обратки.

Замена GPU и работа без долгого простоя

Желательно заранее продумать, как заменить GPU или плату так, чтобы не гасить всю стойку. В проектах с высокой плотностью мощности это часто решается сегментацией контура по шасси или по узлам, чтобы локально изолировать участок.

Отдельная тема - мониторинг. Помимо температуры подачи полезно контролировать:

• перепад давления (как ранний признак засора)
• расход по веткам или стойкам
• температуру обратки
• тревоги по утечке (датчики в поддонах, у соединителей)
• тренды, а не только текущие значения

Если вы работаете с интегратором и производителем (например, при сборке и поддержке GPU-серверов на площадке), попросите сразу включить эти процедуры в эксплуатационные инструкции и провести короткую тренировку на «учебном» выводе узла из контура.

Частые ошибки и ловушки в проектах с жидкостью

Жидкостное охлаждение для GPU иногда воспринимают как простой обмен «шумных вентиляторов» на трубы и теплообменники. На практике большинство проблем появляется не в стойке, а на стыке инженерии, эксплуатации и регламентов.

Одна из частых ошибок - забыть про тепло, которое все равно остается на воздухе. Даже если GPU и CPU на жидкости, в сервере остаются VRM, память, сетевые карты, накопители и блоки питания. Если в стойке ухудшится воздушный поток или поднимется температура приточного воздуха, эти узлы начнут перегреваться первыми, и вы увидите сбои там, где их не ожидали.

Вторая ловушка - слишком сложная схема контуров без ясной логики обслуживания. Лишние коллекторы, нестандартные ветки и разные типы соединителей делают любой ремонт долгим. Чем сложнее гидравлика, тем важнее заранее решить, какие элементы можно обслужить без остановки стойки, а какие потребуют полного вывода из работы.

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

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

Вот что стоит проверить до закупки и монтажа:

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

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

Быстрый чеклист перед закупкой и монтажом

Перед тем как подписывать спецификацию на жидкостное охлаждение для GPU, зафиксируйте несколько вещей на бумаге. Это снижает риск сюрпризов уже на этапе монтажа и первых недель эксплуатации.

Сначала проверьте расчеты тепла не «в среднем по больнице», а по конкретным конфигурациям серверов и профилям нагрузки. В HPC один и тот же узел может вести себя по-разному в обучении, инференсе и смешанных задачах. Если есть сомнения, заложите запас и подтвердите цифры по паспортам и реальным измерениям в пилоте.

Дальше убедитесь, что гидравлика спроектирована не «впритык»: температуры подачи и обратки определены, расчетный расход по каждому контуру понятен, а по насосам есть резерв (хотя бы N+1 на критичных линиях). Отдельно проверьте совместимость теплоносителя с материалами в контуре и требования к фильтрации.

Короткий контрольный список перед закупкой:

• Тепловая нагрузка подтверждена по конфигурациям узлов и целевой плотности стойки.
• Параметры контуров (температуры, расход, давление) согласованы, запас по насосам и теплообмену заложен.
• План размещения CDU, коллекторов и трасс обеспечивает доступ для обслуживания и безопасную прокладку.
• Защита от протечек включает датчики, автоматическое перекрытие и понятные сценарии оповещения.
• Риски простоя оценены, есть план восстановления: кто и что делает в первые 15, 60 и 240 минут.

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

Что стоит заранее согласовать с командой эксплуатации и подрядчиками:

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

Если проект делает системный интегратор, попросите, чтобы этот чеклист был частью приемки. В проектах GSE.kz обычно фиксируют точки контроля по трассам, датчикам и регламентам до ввода в эксплуатацию, чтобы запуск прошел без лишних остановок.

Пример сценария: рост GPU кластера в существующей серверной

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

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

Решение выбрали не самое сложное, но управляемое: direct-to-chip (D2C) для CPU и GPU плюс CDU (coolant distribution unit) на контуре. Логику сделали простой: отдельный контур для вычислительных узлов, отдельный - для остального оборудования, чтобы не тянуть изменения на всю серверную сразу. Параллельно договорились о мониторинге: температура подачи и обратки, давление, расход, а также тревоги по утечкам.

Перед монтажом пришлось проверить не только стойки, но и помещение:

• где физически разместить CDU так, чтобы был нормальный доступ для сервиса
• как проложить магистрали без пересечения с силовыми трассами
• куда выводить дренаж и как организовать безопасный слив при обслуживании
• где поставить датчики протечки и как завести их в общую систему оповещения
• как обеспечить проходы и доступ к быстросъемным соединениям

Успех оценивали не «по ощущениям», а по метрикам. После запуска сравнили стабильность частот GPU на длинных задачах, количество остановок по перегреву и предсказуемость обслуживания (плановые проверки вместо внеплановых выездов). В проектах такого типа полезно заранее закрепить регламент: кто и как делает долив, проверку фильтров, тест утечек и что считается аварией.

Если проект ведет системный интегратор, важно, чтобы он взял на себя не только подбор железа, но и стыковку инженерии и эксплуатации. В Казахстане это часто удобнее делать вместе с локальным производителем и интегратором, например GSE.kz, чтобы одна команда отвечала за поставку, ввод в работу и дальнейшую поддержку.

Следующие шаги: как перейти от идеи к рабочему проекту

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

Дальше сравните несколько вариантов охлаждения так, как вы будете жить с ними в эксплуатации. Часто побеждает не самая «эффективная» схема, а та, где понятнее обслуживание и быстрее восстановление после инцидента. Смотрите на доступность запчастей, сроки поставки узлов, совместимость с выбранными GPU-серверами и кто реально будет обслуживать систему на месте.

Полезно идти по простому плану:

• собрать тепловой профиль кластера и прогноз расширения по стойкам и кВт
• выбрать 2-3 архитектуры охлаждения и оценить сервис, риски протечек, требования к персоналу
• сформулировать требования к инженерии помещения (питание, резервирование, мониторинг, водоподготовка, дренаж, зоны обслуживания)
• подготовить регламенты до закупки: кто и как проводит ТО, что считается аварией, какие есть запасы расходников
• свести все в один документ для тендера или закупки: состав, сроки, этапы работ, критерии приемки

Требования к инженерии и регламентам лучше фиксировать заранее. Иначе легко получить «идеальную» стойку, которая не помещается по трубам, не проходит по нагрузке на ИБП или требует обслуживания, к которому команда не готова.

Если проект большой или сроки сжаты, имеет смысл рассмотреть системную интеграцию под ключ: обследование площадки, подбор GPU-серверов и инфраструктуры, внедрение и сопровождение 24/7. Для организаций в Казахстане это можно делать с опорой на опыт GSE.kz (gse.kz) как производителя и интегратора: у компании есть линейка серверов S200 и компетенции по инфраструктуре дата-центров, что помогает проще свести железо, инженерную часть и дальнейшую поддержку в один план.