Как выбрать сервер для ИИ: GPU, PCIe, питание, охлаждение

С чего начинаются проблемы при выборе ИИ сервера

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

Закупка под ИИ отличается от обычного обновления серверов тем, что нагрузка намного менее ровная. Обучение моделей дает длинные пики по энергии и теплу, активно гоняет данные между CPU, памятью, GPU и хранилищем и резко чувствительно к задержкам. Даже для аналитики и инференса важно не только сколько ядер и сколько ОЗУ, а как быстро система может кормить ускорители.

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

Перед разговором с поставщиком полезно заранее ответить на несколько вопросов. Что именно вы делаете (обучение, инференс, аналитика) и как долго идут типичные задания? Откуда берутся данные и сколько их в день нужно читать и записывать? Сколько GPU планируется сейчас и через 6-12 месяцев? Какие ограничения есть по стойке: питание, теплоотвод, уровень шума, место? Какие метрики важнее: время до результата, стоимость владения, отказоустойчивость?

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

Определяем сценарий: обучение, инференс или аналитика

Начните не с железа, а с вопроса: что будет делать сервер каждый день. Один и тот же набор GPU может отлично показать себя в обучении и при этом быть неудобным для инференса, или наоборот. Сценарий сразу отсекает лишние траты.

Обучение (training) почти всегда упирается в память GPU (VRAM) и скорость обмена данными между GPU и остальными компонентами. Если модель не помещается в VRAM, вы режете батч или переходите на более сложные схемы, и время обучения резко растет. Важны и стабильные долгие нагрузки: сервер должен держать частоты и температуры часами.

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

Аналитика и ETL нередко выигрывают не от дорогих GPU, а от сильных CPU, большого объема RAM и быстрых дисков. Если команда гоняет ежедневные витрины данных и тяжелые джойны, узкое место будет в памяти и I/O, а GPU может простаивать.

Чтобы перевести сценарий в требования к конфигурации, зафиксируйте несколько вводных: размер данных и частоту обновления, тип нагрузки (пакетная или потоковая), размер моделей и точность (FP16/FP32), сколько моделей нужно держать одновременно, а также что занимает больше времени - чтение данных, препроцессинг или расчет на GPU. Если есть SLA, заранее определите максимальную задержку и требования к доступности.

Фреймворк и «модная» библиотека обычно вторичны. Важнее тип модели (LLM, CV, табличные), ее реальный размер и то, как вы будете подавать данные.

GPU: ключевые параметры, которые влияют на результат

Когда речь заходит про ИИ сервер, чаще всего начинают с видеокарт. Это логично: именно GPU обычно дают прирост скорости. Но они же чаще всего создают неожиданные ограничения.

Первый вопрос - сколько GPU вам реально нужно. Для пилота, проверки гипотез и небольших моделей часто хватает 1-2 GPU: проще отладить код, дешевле питание и охлаждение, меньше рисков с совместимостью. Если нагрузка постоянная (обучение по расписанию, несколько команд, очередь задач), обычно смотрят в сторону 4-8 GPU, чтобы не терять время на ожидание.

Второй параметр - объем видеопамяти. Если модель или батч не помещаются, пиковые TFLOPS уже не спасают: начинаются компромиссы, падает качество или растет время обучения. Для многих задач объем памяти важнее «скорости на бумаге».

Связность между GPU

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

Форм-фактор и размещение

GPU бывают двухслотовыми или трехслотовыми, а серверы - 2U или 4U. Это напрямую влияет на то, сколько карт физически поместится и не задушит ли их охлаждение.

Перед закупкой проверьте несколько вещей: сколько GPU поддерживает корпус без ухудшения охлаждения, хватает ли VRAM под ваши модели и размеры батча, нужна ли быстрая связность GPU для обучения, а также не упирается ли установка в высоту 2U/4U и ширину карт.

PCIe и линии: как не потерять скорость на шине

Даже с мощными GPU сервер может работать медленно, если данные не успевают доехать до видеокарт. Часто причина не в дисках или сети, а в том, как внутри распределены PCIe-линии и на какой скорости реально работает каждый слот.

PCIe можно представить как дороги с полосами. Чем больше «полос» (линий) и выше поколение (PCIe 4.0/5.0), тем больше пропускная способность. Но полосы не бесконечные: их дает процессор, а часть устройств подключается через чипсет, где появляется общий «мост» и лишняя задержка.

Типичная ситуация: вы ставите 2-4 GPU и быстрые NVMe. Если GPU получают не x16, а x8 или x4, а NVMe сидят за чипсетом, загрузка датасета и обмен данными становятся узким местом. В мониторинге это выглядит так: GPU загружены на 40-60% вместо ожидаемых значений.

Проверяйте не «сколько слотов», а как они разведены по линиям:

• сколько PCIe-линий дает выбранный CPU и хватает ли их на все GPU и NVMe одновременно;
• какие слоты работают x16, а какие делят линии (например, x16 превращается в x8/x8);
• есть ли поддержка бифуркации и как она включается в BIOS;
• что подключено через чипсет, а что идет напрямую в CPU;
• как райзеры влияют на число линий и режим работы.

Попросите у поставщика схему PCIe (block diagram) и сверяйте ее с вашим набором GPU, NVMe и сетевых карт еще до закупки.

CPU и память: что должно совпасть с вашей нагрузкой

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

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

Признаки того, что упираетесь в CPU, а не в GPU:

• загрузка GPU низкая или идет «пилой», хотя обучение должно быть стабильным;
• ядра CPU постоянно близко к 100% во время обучения;
• DataLoader/ETL занимает больше времени, чем сама модель;
• ускорение от более мощного GPU почти не заметно.

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

Как прикинуть ОЗУ: возьмите пик потребления RAM в пилоте и умножьте на 1.5-2, добавьте запас под кеш файлов и буферы (особенно при активном чтении датасета), а также учтите параллельность (больше воркеров загрузки данных требует больше памяти).

Отдельная тема - NUMA. На двухпроцессорных платформах важна не только сумма RAM, но и где лежат данные. Если процесс, который кормит GPU, получает память «с другого сокета», задержки растут. CPU, RAM и PCIe-устройства должны быть согласованы по размещению, особенно в конфигурациях с несколькими GPU.

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

Данные: хранение и сеть, которые кормят GPU

GPU легко простаивает, если данные приходят рывками. Поэтому выбор часто упирается не в видеокарту, а в то, как быстро вы читаете датасет, готовите батчи и отдаете их в память GPU.

Хранилище: скорость и IOPS

Для обучения важны и пропускная способность, и мелкие операции чтения. Типичный датасет - тысячи и миллионы небольших файлов, где узким местом становятся IOPS и задержки (особенно при случайном перемешивании и аугментациях). Для аналитики и ETL чаще важнее ровный поток (MB/s) при чтении больших таблиц, плюс место под временные результаты.

Выбор между локальным NVMe и сетевым хранилищем обычно сводится к задачам:

• локальный NVMe берут, когда нужно максимально быстро кормить 1-2 GPU и вы готовы держать «горячий» датасет рядом с вычислением;
• сетевое хранилище удобнее, когда датасеты общие для команды, важны контроль доступа и единая точка бэкапа;
• компромисс - хранить исходные данные в сети, а на сервере держать NVMe-кэш под активные выборки.

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

Сеть и путь данных: где рождаются задержки

Сеть имеет смысл масштабировать вместе с данными. 10G достаточно для многих аналитических задач и умеренных датасетов. 25G часто становится разумным минимумом для серверов с несколькими GPU. 100G оправдано, когда несколько узлов одновременно читают большие объемы из сети или вы строите общий пул данных для кластера.

Задержки чаще всего появляются там, где много мелких файлов и медленные метаданные на файловой системе, не хватает NVMe под кэш и временные файлы, сеть 10G делится между несколькими активными потребителями, или подготовка данных упирается в CPU (распаковка, преобразования), и GPU ждет.

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

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

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

С блоками питания важны три вещи: резервирование (N+1, если простой дорог), высокий КПД и корректное распределение нагрузки по линиям питания. Иногда формально «ватт хватает», но часть коннекторов или линий не рассчитана на нужный ток для нескольких GPU, и это ограничивает конфигурацию.

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

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

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

Пошаговый подход: как подобрать конфигурацию до закупки

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

1) Зафиксируйте нагрузку, а не «хотелки»

Соберите 2-3 типовых сценария и их пики: сколько задач идет параллельно, как часто, сколько длится прогон, что важнее - скорость ответа или максимальная точность. Так вы поймете, куда делать упор: обучение, инференс или аналитику.

Дальше пройдите по короткому плану. Определите, сколько видеопамяти нужно одной задаче и сколько GPU требуется одновременно (часто хватает меньшего числа, но с большей памятью). Прикиньте поток данных: откуда читаются датасеты, куда пишутся результаты, каков размер типичного батча и сколько таких потоков будет одновременно. Сверьте CPU и RAM с GPU, особенно если много предобработки на CPU. Проверьте, выдержит ли шасси конфигурацию: PCIe-линии, питание не только по суммарным ваттам, но и по разъемам, а также охлаждение при полной нагрузке. И сразу заложите рост: вверх (больше GPU в одном сервере) или вширь (несколько узлов), продумав сеть и хранение.

2) Прогоните «узкие места» на бумаге

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

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

Быстрые проверки перед подписанием спецификации

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

Чеклист на 5 минут

Спросите у поставщика (и проверьте сами):

• не режутся ли GPU или NVMe по шине: хватит ли PCIe-линий и нужной версии PCIe для всех устройств одновременно;
• есть ли запас по питанию: учтены ли пиковые нагрузки GPU/CPU, количество блоков питания, схема резервирования (например, N+1) и реальная доступная мощность в стойке;
• потянет ли охлаждение: соответствует ли корпус суммарному TDP, не будет ли троттлинга при длительной нагрузке;
• успевают ли данные кормить GPU: достаточно ли IOPS/скорости NVMe, подходит ли сеть по пропускной способности и задержкам;
• как будет обслуживаться сервер: быстрый доступ к дискам, вентиляторам, GPU и БП, понятные сроки и схема замены, поддержка на месте.

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

Частые ошибки и ловушки при выборе ИИ сервера

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

Один из типичных промахов - выбирать ускорители только по TFLOPS и «новизне». Если у модели мало видеопамяти или неудобный профиль потребления, обучение может упираться не в вычисления, а в обмен данными и частые выгрузки в RAM.

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

Что чаще всего роняет производительность и сроки:

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

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

Пример: сервер под аналитический отдел и пилот ИИ

Представим отдел аналитики на 8-10 человек. Раз в неделю они обучают модель (например, прогноз спроса), а каждый день гоняют инференс для отчетов и дашбордов. Задача - взять сервер так, чтобы пилот ИИ не уперся в железо через 2-3 месяца.

Вариант A (пилот и ежедневный инференс): упор на 1-2 GPU и быстрый локальный NVMe под датасеты и кэш фич. Такой подход обычно дает лучший баланс цены и скорости, потому что команда чаще считает, чем обучает. Важно, чтобы CPU не был слишком слабым: он готовит данные, распаковывает, делает препроцессинг, и если он не успевает, GPU простаивает.

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

Чтобы заранее понять, где будет узкое место, прогоните короткий тестовый цикл на своих данных (хотя бы на части) и ответьте на вопросы: сколько времени уходит на чтение датасета и препроцессинг по сравнению с расчетом на GPU, растет ли загрузка CPU до 90-100% и начинается ли своп, хватает ли PCIe-линий и слотов, не падает ли частота GPU через 10-20 минут нагрузки из-за перегрева, и если датасет лежит не локально - успевает ли сеть кормить обучение без пауз.

Следующие шаги: как перейти от оценки к закупке

Оформите оценку в короткий пакет требований. Он должен быть понятен и вашей команде, и закупке, и поставщику.

1) Зафиксируйте профиль нагрузки в 1-2 страницах

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

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

2) Подготовьте вопросы, которые защитят вас после закупки

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

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