Спрос на HPC-серверы вырос на 32%. Нужно ли менять план закупки

Директор приносит новость: спрос на высокопроизводительные серверы вырос на 32% — значит, пора закладывать «сервер под ИИ». Но это статистика клиентов HyperPC, а не всего российского рынка. И она не отвечает на вопрос, какое железо загрузит именно твоя компания.

Начинать закупку нужно с нагрузки. Инженерный расчёт, локальная модель и корпоративная система по-разному нагружают процессоры, память и диски. Если перенести конфигурацию HPC на 1С, получишь дорогой сервер, который простаивает или уступает машине попроще.

Основной спрос создают инженерные расчёты, а не ИИ

В первом полугодии 2026 года корпоративные клиенты HyperPC стали на 32% чаще интересоваться высокопроизводительными серверами и графическими станциями, чем годом ранее. Аналитики считали только клиентов компании. Значит, цифра описывает динамику одного поставщика, а не всего рынка. HyperPC передала результаты исследования CNews.

Распределение интереса говорит о спросе больше, чем заголовок новости:

Нагрузка	Доля интереса
CAE, CFD и другие инженерные расчёты	57%
ИИ, машинное обучение и LLM	19,2%
Корпоративное ПО и задачи ЦОД	11,8%
Видеомонтаж и CGI	7,5%
BIM и архитектура	2,4%

Инженерный сегмент почти втрое больше ИИ: 57 ÷ 19,2 = 2,97. Поэтому рост спроса на HPC не означает, что компании массово переносят нейросети в собственные серверные.

HyperPC связывает интерес оборонной промышленности, авиастроения и тяжёлого машиностроения с заменой ANSYS и Siemens NX на FlowVision и LOGOS. Этим программам нужно быстро считать большие модели в несколько потоков. Для бухгалтерской базы или файлового хранилища такая архитектура сама по себе ничего не даёт.

192 ядра нужны решателю, который умеет их занять

Рост инженерного сегмента HyperPC связывает с платформами AMD EPYC Turin — до 192 ядер и 12 каналов ECC DDR5 на процессор. Покупка имеет смысл при двух условиях: расчёт загружает десятки потоков, а лицензия не делает дополнительные ядра дороже самого сервера.

Смотри не на название процессора, а на длительность контрольного расчёта. Допустим, модель считается 18 часов на 64 ядрах, а результат нужен за одну рабочую смену. Запусти её на 96, 128 и 192 ядрах. Если последние 64 ядра экономят несколько минут, вложи деньги в память или второй независимый узел.

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

Для 1С, терминального доступа и офисной виртуализации эти 192 ядра ничего не обосновывают. Там процессор, память и дисковый массив выбирают через расчёт конфигурации по рабочей нагрузке.

Локальный ИИ требует считать GPU-память и часы загрузки

По наблюдениям HyperPC, часть корпоративных заказчиков переходит от опытов с публичными API к локальным генеративным моделям, RAG и компьютерному зрению. RAG ищет сведения во внутренних документах и передаёт найденный контекст модели. Данные и вычисления при этом остаются в инфраструктуре компании.

Среди флагманских решений HyperPC сервер AMPERE X ULTRA 4U получил долю 26,8%, модули NVIDIA H200 со 141 ГБ HBM3e — 12,8%, семейство AMPERE X ULTRA и PLUS — 18,6%. Это структура покупок клиентов HyperPC. По ней нельзя определить, сколько ускорителей нужно твоей модели.

Отправная точка — объём модели и число параллельных запросов. Если одна задача занимает до 120 ГБ памяти ускорителя, H200 со 141 ГБ вмещает её и оставляет 21 ГБ запаса. Для двух независимых задач понадобятся два модуля: 2 × 141 = 282 ГБ HBM3e. При этом каждая задача всё равно ограничена памятью своего ускорителя, если программа не распределяет модель между GPU.

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

Один корпус на четыре GPU повышает цену отказа

HyperPC отмечает спрос на «гибридные монолиты»: один корпус объединяет 256 процессорных ядер, четыре GPU и локальное хранилище на 120–144 ТБ. Данные лежат рядом с вычислителями, поэтому отдельный узел хранения не нужен.

Но плотная компоновка концентрирует риск. Поломка корпуса, питания или системной платы задевает сразу процессоры, ускорители и рабочие данные. Резервные блоки питания и RAID не превращают один сервер в отказоустойчивую систему.

HyperPC не приводит цены таких конфигураций, замеры энергопотребления и производительности, а также время восстановления. По этим данным нельзя рассчитать окупаемость или проверить, укладывается ли простой в требования бизнеса. Для сметы понадобятся паспортные мощности компонентов и профиль загрузки. Здесь пригодится расчёт, как серверная нагрузка превращается в расходы на питание.

Спецификация под задачу

Это не три универсальные сборки. Ниже — стартовые заявки с явными допущениями, чтобы вместо «посчитайте сервер под ИИ» поставщик получил описание нагрузки.

Инженерные расчёты

Берём компанию, которая одновременно запускает два задания по 64 потока. Они занимают 128 ядер. Добавляем 25% для системы и нерегулярных пиков: 128 × 1,25 = 160 ядер. Ближайший класс из исследования HyperPC — платформа AMD EPYC Turin с числом ядер до 192.

• Процессор: 192 ядра. Минимальную базовую частоту определяем по контрольной модели в целевом решателе.
• Память: 12-канальная ECC DDR5. Объём должен покрывать пик двух заданий и ещё 25%. Если каждое задание занимает 320 ГБ, получаем (320 × 2) × 1,25 = 800 ГБ и ставим в заявку 1 ТБ.
• Диски: два накопителя под систему в зеркале, отдельный NVMe-массив — под расчётные данные. Он должен вместить три одновременных рабочих набора и временные файлы.
• Сеть: пропускную способность определяем по обмену с хранилищем во время контрольного задания. На одиночном узле локальные NVMe полезнее дорогого межузлового соединения.
• Питание: два блока с раздельным подключением. Их мощность считаем после выбора процессора, дисков и карт расширения.
• Корпус: стоечный, со свободными отсеками под второй NVMe-массив и слотами под сетевые адаптеры.

Цена такой конфигурации — лицензирование. Если решатель оплачивается по ядрам, система на 192 ядра может поднять стоимость ПО, почти не сократив расчёт.

Локальный ИИ

Считаем узел для двух параллельных задач. Каждой нужно до 120 ГБ GPU-памяти, поэтому берём два H200 по 141 ГБ: один ускоритель на задачу.

• Ускорители: 2 × NVIDIA H200 141 ГБ HBM3e, вместе 282 ГБ.
• Процессор: 32 ядра. Исходное допущение — по 16 ядер на GPU для подготовки данных. Частоту и число ядер проверяем на своей цепочке обработки.
• Память: 512 ГБ ECC, по 256 ГБ на задачу. Если рабочий набор растёт, оперативную память увеличиваем вместе с ним.
• Диски: зеркало под систему и отдельный NVMe-массив под модели, индексы RAG и временные данные.
• Сеть: пропускную способность рассчитываем по входящему потоку и обмену с основным хранилищем.
• Питание: резервируемые блоки, которым хватает мощности при одновременной работе обоих GPU и процессора.
• Корпус: 4U с местом ещё под два ускорителя — при условии, что охлаждение и питание выдержат расширение.

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

1С и офисная виртуализация

Берём 12 виртуальных машин по 4 vCPU. При переподписке 3:1 нагрузке нужны 12 × 4 ÷ 3 = 16 физических ядер. Ещё восемь оставляем гипервизору и пиковым нагрузкам. Итого — 24.

• Процессор: 24 ядра. Базовую частоту выбираем по замеру самой чувствительной системы — например, 1С.
• Память: 12 машин по 12 ГБ занимают 144 ГБ. С запасом 25% получаем 144 × 1,25 = 180 ГБ, поэтому ставим 256 ГБ ECC RDIMM.
• Диски: два системных накопителя в зеркале и отдельный массив под виртуальные машины. Уровень RAID зависит от допустимого простоя и профиля записи.
• Сеть: два независимых подключения, если отказ одного порта не должен останавливать работу.
• Питание: два блока, когда сервер обязан продолжать работу после отказа одного из них.
• Корпус: 2U, со свободными слотами памяти и хотя бы двумя незанятыми дисковыми отсеками.

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

Рост спроса на 32% — не аргумент для закупки. В заявке нужны три строки: какая нагрузка работает на сервере, почему её держат внутри компании и какой ресурс она занимает постоянно. Без них конфигурация на 192–256 ядер и четыре GPU просто повторяет чужую покупку.