GPU-сервер отличается от обычной физической машины не только наличием одной или нескольких видеокарт. Для colocation такая конфигурация почти всегда означает повышенное энергопотребление, больше тепла, более строгие требования к корпусу и иногда совершенно другой подход к размещению в стойке. Сервер, который спокойно помещается в 2U или 4U, может оказаться слишком энергоёмким для стандартного тарифа даже при наличии свободного места.
Именно поэтому GPU-сервер лучше согласовывать с дата-центром до покупки или доставки оборудования. Для обычной машины достаточно сообщить форм-фактор, примерную мощность и количество сетевых подключений. Для конфигурации с несколькими ускорителями оператору важно понимать тепловую нагрузку, максимальное энергопотребление, тип силовых подключений и возможность размещения в зоне с высокой плотностью мощности.
Особенно это актуально для серверов машинного обучения, рендеринга, обработки видео, научных расчётов и других задач, где GPU загружены долго и почти постоянно. В таком режиме паспортная мощность ускорителей перестаёт быть абстрактной цифрой и напрямую влияет на стоимость colocation.
Почему GPU-сервер нельзя оценивать только по количеству юнитов
Обычный сервер 1U или 2U может потреблять несколько сотен ватт. GPU-система аналогичного размера способна требовать значительно больше. Один производительный ускоритель уже добавляет заметную нагрузку, а несколько GPU способны поднять потребление всей машины до нескольких киловатт.
Для дата-центра это принципиальная разница. Стойка имеет ограничение не только по физическому пространству, но и по доступной электрической мощности и способности системы охлаждения отводить тепло.
Поэтому свободные 4U в шкафу ещё не означают, что туда можно установить любой GPU-сервер. Если энергетический лимит стойки почти исчерпан, оператор либо предложит другую зону, либо не сможет принять такую конфигурацию на стандартных условиях.
Энергопотребление нужно измерять под реальной нагрузкой
Для GPU особенно опасно ориентироваться только на мощность блоков питания. Сервер с двумя PSU по 2000 Вт не обязательно постоянно потребляет 4 кВт, но и считать его обычной машиной на 500 Вт тоже нельзя.
Перед colocation желательно запустить типичную рабочую нагрузку и посмотреть реальное потребление через BMC или внешний ваттметр. Для сервера машинного обучения это может быть длительная загрузка всех GPU и процессоров одновременно.
Важно увидеть не только среднее значение, но и максимальные пики. Некоторые ускорители способны кратковременно выходить на высокое энергопотребление, особенно при одновременной загрузке CPU, памяти и дисков.
После измерения уже можно выбирать тариф с нормальным запасом. Заказывать мощность впритык к обычной нагрузке рискованно, а многократный запас без реальной необходимости просто увеличивает ежемесячные расходы.
Отдельно нужно проверить резервирование блоков питания. Если сервер рассчитан на работу с двумя PSU, каждый из них должен быть способен обслуживать систему после отказа второго либо конфигурация должна соответствовать схеме производителя.
Для критичного GPU-сервера имеет смысл подключение к независимым A/B-линиям. Тогда проблема одного PDU или отдельной ветви электропитания не обязательно останавливает машину.
Но здесь нужно уточнить у ЦОД, способна ли каждая линия выдержать полную согласованную нагрузку после отказа второй. Для мощного сервера это особенно важно.
Следующий вопрос — охлаждение. GPU превращают значительную часть потребляемой энергии в тепло. Если сервер получает несколько киловатт электрической мощности, примерно сопоставимую тепловую нагрузку дата-центру приходится постоянно отводить.
Именно поэтому высокоплотные GPU-зоны отличаются от обычных стоек. У них могут быть более мощные системы подачи холодного воздуха, специальные схемы горячих и холодных коридоров или другие инженерные решения.
Некоторые современные ускорители используют очень плотные конфигурации, где обычного воздушного охлаждения уже недостаточно. В таких случаях применяются жидкостные системы, и далеко не каждый ЦОД готов принять подобное оборудование.
Если сервер использует штатное воздушное охлаждение и создан производителем как законченная GPU-платформа, задача проще. Dell, HPE, Lenovo, Supermicro и другие производители проектируют корпус, вентиляторы и воздушные каналы именно под определённое количество ускорителей.
Самосборная машина требует больше внимания. Несколько мощных GPU могут прекрасно работать в тестовой комнате, но в стойке с ограниченным воздушным потоком температуры окажутся выше.
Перед перевозкой стоит провести длительный стресс-тест и убедиться, что GPU, CPU, память и накопители остаются в нормальном температурном диапазоне.
Важно и направление воздушного потока. В профессиональной стойке воздух обычно входит спереди и выходит сзади. Если сервер выбрасывает горячий воздух в необычном направлении, он может конфликтовать с общей системой охлаждения.
Для стандартного rackmount-оборудования такой проблемы обычно нет, но нестандартную платформу лучше согласовать заранее.
Что ещё проверить у ЦОД перед размещением GPU-сервера
Первый практический вопрос — максимальная доступная мощность на один сервер и на одну стойку. Некоторые площадки прекрасно подходят для обычного colocation, но не рассчитаны на очень высокую плотность вычислений.
Если сервер потребляет 2-3 кВт, оператор должен подтвердить, что такая нагрузка допустима именно в той зоне, где будет стоять оборудование.
Второй вопрос — тип подключения питания. Мощные GPU-системы могут использовать другие силовые разъёмы и схемы, чем стандартный 1U-сервер. Лучше заранее отправить ЦОД модель оборудования или техническую спецификацию, чтобы не выяснять совместимость в день установки.
Третий момент — вес. GPU-серверы 4U и более крупные платформы способны быть очень тяжёлыми. Это влияет на доставку, установку в стойку и требования к направляющим.
Такую машину редко удобно устанавливать одному человеку. Поэтому стоит заранее узнать, входит ли монтаж в услугу и кто физически будет размещать оборудование.
Для особенно тяжёлых платформ может потребоваться нижняя часть стойки, где нагрузка на конструкцию распределяется безопаснее.
Следом идёт сеть. GPU-сервер часто создаёт больший трафик, чем обычный веб-сервер, но это зависит от задачи.
Если машина только выполняет вычисления и получает сравнительно небольшие наборы данных, обычного гигабитного подключения может хватать. Если сервер постоянно обменивается большими моделями, датасетами или результатами вычислений с другими узлами, 10 или 25 Гбит/с становятся намного интереснее.
Особенно важна сеть при кластере из нескольких GPU-серверов. Если машины обмениваются данными между собой во время распределённого обучения, обычный публичный Ethernet может стать узким местом раньше самих GPU.
В таком случае нужно заранее обсуждать приватную сеть, низкую задержку и более быстрые интерфейсы.
Иногда используются специализированные сети вроде InfiniBand. Это уже отдельный класс инфраструктуры, и далеко не каждый colocation-провайдер готов предоставить соответствующие подключения.
Если такая технология действительно нужна проекту, выбирать ЦОД только по цене 4U бессмысленно. Сетевая инфраструктура становится одним из главных критериев.
Не стоит забывать и про DDoS-защиту, если GPU-сервер предоставляет публичный сервис. Сам факт наличия дорогих ускорителей никак не защищает сетевой канал.
Для публичного API или SaaS нужно уточнить, какая фильтрация входит в тариф и что произойдёт при крупной атаке.
Аппаратный удалённый доступ тоже желательно предусмотреть. GPU-сервер часто используется без физического присутствия администратора, поэтому IPMI, iDRAC, iLO или аналогичный BMC сильно упрощает восстановление после проблем с системой.
Если машина не загрузилась после обновления драйверов NVIDIA или изменения конфигурации, возможность увидеть консоль удалённо намного удобнее вызова инженера к стойке.
При этом GPU добавляют ещё один уровень мониторинга. Недостаточно следить только за CPU и RAM. Полезно контролировать температуру каждого ускорителя, загрузку, энергопотребление, ошибки памяти и состояние драйверов.
Для NVIDIA это можно делать через соответствующие инструменты и интегрировать данные в общую систему мониторинга.
Особенно важны аппаратные ошибки. Если один GPU начал нестабильно работать, лучше обнаружить проблему до полного отказа или падения длительной вычислительной задачи.
Remote Hands для такой инфраструктуры тоже имеет свои особенности. Заменить обычный hot-swap SSD сравнительно просто. Вытащить тяжёлую GPU-карту из 4U-сервера и установить новую уже намного сложнее.
Не каждый дежурный инженер ЦОД будет выполнять подобную работу без предварительного согласования.
Поэтому стоит узнать, какие операции оператор готов выполнять с GPU-оборудованием и сколько это стоит.
Если сервер находится далеко от офиса, полезно иметь на площадке хотя бы основные запасные компоненты. Но хранить дополнительный дорогой GPU просто ради возможного отказа не всегда экономически разумно.
Здесь нужно исходить из стоимости простоя и доступности конкретной модели ускорителя.
Для очень критичной системы иногда выгоднее иметь целый резервный GPU-сервер, чем пытаться максимально быстро ремонтировать единственную машину.
Но для многих вычислительных проектов допустим простой в несколько часов или даже дней, поэтому настолько дорогое резервирование не требуется.
При расчёте мощности для colocation GPU-сервера полезно сразу учитывать не только текущую конфигурацию, но и планы модернизации. Добавление ещё одного ускорителя способно заметно изменить требования к питанию и охлаждению.
Если сегодня машина использует два GPU, а корпус рассчитан на четыре, это ещё не означает, что дата-центр автоматически разрешит установить оставшиеся два позже на прежнем тарифе.
Энергетический лимит придётся пересчитать.
Стоимость colocation для GPU обычно сильнее зависит от мощности, чем от количества юнитов. Сервер может занимать всего 4U, но его энергетические требования окажутся главным компонентом ежемесячного счёта.
Поэтому сравнивать площадки только по цене 4U неправильно.
Нужно отправлять одинаковую техническую конфигурацию: форм-фактор, вес, максимальное потребление, количество PSU, сетевые интерфейсы и требования к охлаждению.
Тогда один оператор может предложить стандартную высокоплотную стойку, другой — специальную GPU-зону, а третий честно сообщит, что такая нагрузка для его инфраструктуры неудобна.
Последний вариант намного лучше ситуации, когда проблема выясняется после доставки тяжёлого сервера.
Особенно внимательно стоит относиться к очень дешёвому размещению GPU. Низкая цена может быть нормальной, но нужно понять, включена ли необходимая мощность и насколько площадка действительно рассчитана на подобное оборудование.
Если сервер постоянно троттлит из-за температуры или оператор просит ограничить его энергопотребление после установки, экономия теряет смысл.
При этом для одного умеренного GPU-сервера не обязательно искать самый дорогой специализированный ЦОД. Машина с одной или двумя видеокартами может прекрасно работать в обычной профессиональной стойке, если энергетическая и тепловая нагрузка укладывается в возможности площадки.
Главное — не делать вывод по слову GPU.
Нужно смотреть на конкретную конфигурацию.
Один ускоритель среднего класса и восемь мощных серверных GPU создают совершенно разные требования, хотя обе машины формально называются GPU-серверами.
Поэтому перед заказом colocation стоит подготовить технический паспорт машины и задать оператору несколько конкретных вопросов: сколько мощности можно выделить, как организованы A/B-линии, выдерживает ли зона такую тепловую нагрузку, какой сетевой порт доступен и есть ли опыт работы с подобным оборудованием.
Если ответы понятны, сам процесс размещения мало отличается от обычного сервера. Машина устанавливается в стойку, подключается к питанию и сети, после чего управляется удалённо.
Разница заключается только в том, что GPU значительно быстрее обнаруживают слабые места инженерной инфраструктуры. Там, где обычный веб-сервер потребляет несколько сотен ватт и почти не нагружает сеть, вычислительная система способна одновременно потребовать киловатты энергии, мощное охлаждение и высокоскоростный обмен данными.
Именно поэтому для GPU хороший colocation начинается не с свободных юнитов в стойке, а с подтверждения того, что дата-центр действительно способен стабильно обслуживать конкретную нагрузку.
