Проект ИИ-инфраструктуры начинается с описания нагрузки и требований к результату. Формулировка «нужен GPU-кластер» оставляет открытыми ключевые вопросы: какие модели будут работать, сколько запросов поступит одновременно, где находятся данные и кто будет эксплуатировать систему. Без этих ответов сложно обоснованно выбрать серверы, оценить площадку и составить техническое задание.
Полезный результат первого этапа — согласованный профиль нагрузки и несколько проверяемых вариантов архитектуры. Он связывает бизнес-задачу с вычислительными ресурсами, а затем с электропитанием, охлаждением, сетью и условиями размещения.
Обучение с нуля формирует параметры модели на подготовленных данных. Для инфраструктурного проекта здесь важны объём выборки, продолжительность эксперимента, число параллельных запусков и способ распределения вычислений между серверами. Допустимая длительность обучения должна исходить из рабочего цикла команды: например, успевает ли она проверить новую гипотезу к следующему этапу разработки.
Дообучение, или fine-tuning, адаптирует уже обученную модель к конкретным данным и задачам. Его ресурсные требования зависят от размера модели и метода адаптации: обновление всех параметров и обучение небольшого набора дополнительных параметров требуют разных конфигураций. Нельзя переносить требования крупного обучающего кластера на любой проект дообучения.
Инференс — выполнение готовой моделью пользовательских запросов. Здесь оценивают скорость ответа, пропускную способность и поведение сервиса в часы пик. Для языковой модели имеют значение длина входного контекста и ответа; для видеоаналитики — число потоков, разрешение и частота обработки кадров. Если организация совмещает несколько сценариев, нужно определить их расписание и приоритеты. Обучающий эксперимент не должен случайно вытеснять ресурсы рабочего сервиса.
Выбор GPU только по пиковой вычислительной производительности не показывает, как будет работать конкретное приложение. Отдельно проверяют объём памяти ускорителя, скорость обмена с ней и фактическую загрузку вычислительных блоков. Для языковых моделей память нужна не только под веса, но и под рабочие данные, включая кеш при генерации. Рост числа одновременных запросов и длины контекста может изменить требования даже при неизменной модели.
До закупки стоит провести тест на репрезентативных данных. В протоколе фиксируют модель и её версию, точность представления, программную среду, конфигурацию сервера, распределение размеров запросов и число одновременно работающих пользователей. Для инференса измеряют задержку ответа, производительность и долю ошибок; для обучения — длительность шага или полного контрольного запуска. При изменении настроек сжатия модели дополнительно проверяют качество результата.
Такой тест помогает установить узкое место и понять, нужен ли GPU вообще: часть моделей и вспомогательных задач может выполняться на CPU с приемлемыми показателями. Он также даёт основу для подбора активного оборудования, совместимого с выбранной программной платформой.
Архитектуру рассматривают как связанную систему. Быстрые ускорители могут простаивать, если данные поступают медленно, а увеличение числа серверов не всегда даёт пропорциональный прирост скорости. Для распределённого обучения проверяют обмен между вычислительными узлами; для независимых сервисов инференса требования к такому обмену могут быть существенно скромнее.
Хранилище рассчитывают по объёму данных, характеру чтения и записи, числу параллельных заданий. В обучении учитывают сохранение контрольных точек и восстановление после прерывания. В эксплуатации модели — загрузку весов, обновления и резервные копии. Локальный кеш может сократить повторное чтение по сети, но его содержимое и порядок восстановления должны быть определены заранее.
Устанавливать максимальную скорость всех интерфейсов «на будущее» необязательно. Полезнее подтвердить, что сеть и хранилище обеспечивают выбранную нагрузку, а расширение возможно без замены критических элементов. Отдельно предусматривают управление оборудованием, разграничение доступа и наблюдение за состоянием системы.
Сначала составляют перечень оборудования: GPU-серверы, CPU-узлы, системы хранения и коммутаторы. Для каждого элемента уточняют питание, габариты, массу и требования производителя к окружающей среде. Затем оборудование распределяют по стойкам с учётом электрических подключений, кабелей и доступа для обслуживания.
Условный пример: четыре стойки с расчётной нагрузкой по 30 кВт дают 120 кВт IT-мощности. Это иллюстрация расчёта, а не характеристика решения SA MODULE. Мощность всей площадки должна учитывать также охлаждение, потери преобразования и другие инженерные потребители. Резервирование и запас для расширения рассчитывают по принятой схеме; их нельзя автоматически свести к одному универсальному коэффициенту.
Способ охлаждения выбирают по спецификации серверов и условиям размещения. Для оборудования с воздушным охлаждением проверяют расход и температуру воздуха, разделение потоков и отвод тепла от стоек. Если серверная платформа требует жидкостного охлаждения, прорабатывают контуры, параметры теплоносителя, теплообмен и обслуживание. Наличие GPU само по себе не означает обязательного жидкостного охлаждения. Взаимосвязь этих систем разобрана в материале об инженерной инфраструктуре ЦОД.
Собственный модульный ЦОД позволяет планировать инженерную конфигурацию под оборудование и условия своей площадки. Вместе с этим заказчик определяет ответственность за подключения, эксплуатацию, обслуживание и развитие объекта. Такой вариант следует оценивать при понятной постоянной нагрузке и требованиях к контролю инфраструктуры.
Колокация предполагает размещение собственных серверов на внешней площадке. До выбора оператора проверяют доступную мощность на стойку, совместимость охлаждения, возможности связи, доступ для обслуживания и условия расширения. Свободное место в стойке ещё не подтверждает возможность установить нужную конфигурацию.
Аренда вычислительных ресурсов позволяет проверить гипотезу или обслуживать переменную нагрузку без собственной инженерной площадки. Сопоставляют доступность нужных ускорителей, ограничения передачи данных, условия резервирования ресурсов и переносимость программной среды. Возможен смешанный подход: постоянные задачи работают на собственной инфраструктуре, отдельные эксперименты — на арендной. Решение принимают по сопоставимым сценариям загрузки, затрат и ответственности, без предположения о гарантированной окупаемости.
Первый этап — описание задачи и ограничений; его результатом становится согласованный профиль нагрузки. Второй — пилот: отчёт с измерениями подтверждает или корректирует вычислительную конфигурацию. Третий — обследование площадки и эскизная архитектура с перечнем подключений, инженерных систем и ограничений расширения.
Затем готовят техническое задание, распределяют зоны ответственности и определяют порядок реализации. На приёмке проверяют заранее согласованные показатели: производительность на контрольном наборе, задержку при заданной одновременной нагрузке, температурный режим под нагрузкой и восстановление после предусмотренного отказа. Для каждого показателя задают методику, допустимое значение и ответственного за подтверждение. Параметры, влияющие на бюджет и график, рассматриваются отдельно в статье о стоимости и сроках МЦОД.
Да, с описания задач и диапазона требований. Выбор оборудования при этом остаётся предварительным до проверки моделей и нагрузки.
Необязательно. Можно определить первую очередь и условия расширения, заранее проверив запас подключений и возможности инженерных систем.
Владелец бизнес-задачи, специалисты по моделям и данным, IT-команда, эксплуатация и ответственный за площадку. У проекта также должен быть назначен участник, принимающий согласованные решения.
SA MODULE помогает проработать инженерную инфраструктуру ЦОД и подбор активного оборудования в согласованных границах проекта. Чтобы обсудить исходные данные и следующий этап, направьте запрос с описанием задачи и сведениями о площадке.
Практическое руководство по подготовке площадки под модульный ЦОД: как проверить основание, электрическую мощность, каналы связи и логистику, чтобы избежать задержек и дополнительных расходов при монтаже.
Читать статьюПриемка модульного ЦОД — это подтверждение работоспособности инженерных и ИТ-систем на проектной нагрузке. Разбираем, какие показатели включить в программу испытаний и как распределить ответственность.
Читать статью