Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разбирали стратегический вопрос: что проще и выгоднее — собирать самостоятельно или брать готовый ПАК (на примере ПАК Скала^р)? Поговорили и о том, что именно заказчик узнает о самосборе — не на этапе закупки, а через полгода эксплуатации.
Сегодня же переместимся на следующий уровень: поговорим про аппаратный стек.
Структура статьи такова: для каждого слоя железа — GPU, питание, охлаждение, хранение — я покажу, какую инженерную задачу мы решали при проектировании ПАК и почему приняли именно такие решения, а не другие. Там, где это уместно, приведем цифры, которые помогут понять пороги: когда одно решение заменяется другим и что это означает по деньгам и по производительности.
Бонус — чеклист из пяти вопросов, которые стоит задать любому вендору при обсуждении железа для ваших ИИ-нужд.
Почему ИИ-сервер — это не просто «сервер с GPU»
Давайте сразу на старте зафиксируем одно принципиальное отличие ИИ-нагрузки от всего, что серверный рынок видел раньше.
«Обычная» серверная нагрузка до «эпохи ИИ» — OLTP, web-сервисы, даже традиционный HPC — предсказуема и относительно равномерна. ИИ-нагрузка другая: обучение больших моделей создает резкие пики энергопотребления при старте эпох, потом длительное плато максимального потребления, потом мгновенные просадки. При этом между GPU идет непрерывный интенсивный обмен данными, который по объему сопоставим с пропускной способностью отдельных сетевых сегментов. И все это в жестком real-time: задержка синхронизации GPU в кластере — это не «чуть медленнее», а потеря итерации обучения (учитывая, что связанные с обучением задачи по профилю нагрузки существенно отличаются от стандартной).
Стандартный сервер не проектировался под подобный профиль нагрузок. Стандартный ЦОД — тоже. Разберем по слоям, что именно это означает на практике.
GPU: центр архитектуры, а не периферия
Итак, главная смена парадигмы при проектировании ПАК для ИИ: GPU — это не плата расширения, вокруг которой компонуется сервер. Это основной вычислительный ресурс, под который и проектируется все остальное: шины, память, питание, охлаждение, сеть. Если не учесть эту инверсию на этапе проектирования — получится просто дорогой сервер с GPU.
Выбор GPU: не «флагман», а «задача → граница рентабельности → выбор»
В нашем ПАК мы поддерживаем несколько разных типов GPU — не потому, что хотели максимально широкое портфолио, а потому что типовые задачи заказчиков реально распадаются на непересекающиеся классы.
NVIDIA H200* — когда нужен максимум для крупных LLM: предобучение, fine-tuning моделей от 30B параметров, сложные мультимодальные задачи. Transformer Engine с FP8 дает до 30x ускорения inference для больших языковых моделей, тензорные ядра четвертого поколения поддерживают весь спектр точностей — FP64, TF32, FP16, INT8, FP8. У H200 отдельно — память HBM3e до 141 ГБ (4,8 ТБ/с) и дают до 2x ускорения LLM inference по сравнению с H100.
Для задач инференса GPU-узлы в нашем ПАК с графическими картами H200 поддерживают установку до двух изолированных сегментов по 4 графических карты в каждом, что дает возможность развертывания на каждом сегменте моделей до 70 млрд параметров. Сетевая связность для инференса менее важна, поэтому все высокопроизводительные PCIe x16 отдаются под графические карты, на сеть же остаются сетевые карты 25 GbE и/или 100 GbE.
Для задач дообучения / обучения в сервер устанавливается только один сегмент с четырьмя графическими картами h200 — решающее значение начинает играть скорость межузлового обмена между узлами. Максимальную производительность для задач дообучения / обучения на серверах с поддержкой PCIe 5.0 дают сетевые карты 400 GbE, устанавливающиеся в таком же количестве, что и графические карты на GPU-узел, давая возможность каждой из карт полностью использовать пропускную способность сетевой карты 400 GbE, не конкурируя за сеть с другими.
Подробнее про сеть интерконнекта для ИИ-задач мы напишем в третьей статье из цикла про ПАК МИИ.
RTX 6000 Pro — универсальны и эффективны для «нетяжелых» задач инференса, что позволяет получить до +50% токенов на каждый рубль и дает существенно низкий CAPEX по сравнению с топовыми B300 с жидкостным охлаждением. Вот характеристики этой карты:
96 ГБ сверхбыстрой видеопамяти типа GDDR7 с поддержкой коррекции ошибок (ECC) и 512-битной шиной.
Поддержка: FP4 (NVFP4) — ультранизкая точность (впервые аппаратно поддерживается на архитектуре Blackwell); FP8; FP16 / BF16; TF32 (TensorFloat-32); FP32 (одинарная точность с производительностью около 126 TFLOPS для базовой рабочей версии); FP64 (двойная точность для научных расчетов); INT8 / INT4 / INT1 (целочисленные вычисления для инференса).
Moore Threads MTT S4000 — когда в приоритете миграция существующего CUDA-кода и вопросы реестровой принадлежности железа. Мы проводили подобные тесты — на ПАКе запустили две модели MWS AI: старшую Cotype Pro 3 размером 27 млрд параметров и облегченную Cotype Light 3 на 9 млрд параметров. Обе модели работают с текстом и изображениями и предназначены для создания ИИ-агентов, которые выполняют последовательность действий без постоянного участия человека, а ещё их можно развернуть в закрытом контуре компании.
В отдельных сценариях инференса ПАК на базе китайских GPU показал результаты, сопоставимые с системами на базе Nvidia H100. При входном контексте около 27 000 токенов, что приблизительно соответствует 50–60 страницам текста, модель начинала формировать ответ примерно через 8 секунд. При этом интервал между последующими токенами составлял от 111 мс, или до девяти токенов в секунду. Настройка драйверов и программного окружения повысила производительность платформы в отдельных задачах в 2–2,2 раза.
Архитектура MUSA с CUDA-совместимостью через инструмент MUSIFY, поддержка Megatron-LM, DeepSpeed, FSDP, Colossal-AI. Позиционируется для обучения LLM до 100B параметров.
MetaX C500 — для задач, требующих сопоставимой с Nvidia масштабируемости: inference средних моделей, embedding, RAG, экспериментальные стенды. 70–100 TFLOPS (FP16), 64 ГБ HBM2e, пропускная способность памяти 800–1200 ГБ/с, поддержка TensorFlow, PyTorch, PaddlePaddle.
Все типы GPU в ПАК доступны через единый слой управления ИИ-задачами через платформенное ПО «Спектр ИИ», то есть выбор железа не превращается в отдельный проект по пересборке ML-стека.
NVLink внутри узла: что это и почему не HGX/DGX
В GPU-узлах ПАК «Скала^р МИИ» мы используем NVLink для объединения нескольких GPU NVIDIA в составе одного сервера. NVLink — это специализированный протокол межсоединения от NVIDIA: в четвертом поколении (H100) каждый GPU имеет 18 NVLink-каналов, дающих 900 ГБ/с двунаправленной пропускной способности между картами внутри узла. Для сравнения: PCIe Gen5, к которому подключается «обычный» серверный GPU, дает 128 ГБ/с — примерно в 7 раз меньше.
Почему это важно? При распределенном обучении между GPU непрерывно идут операции синхронизации градиентов (all-reduce). При NVLink-соединении накладные расходы на коммуникацию составляют около 8% от времени итерации. А вот при PCIe-соединении — около 25%. Это означает, что NVLink-конфигурация при tensor parallelism на нескольких GPU дает примерно 1,2x прироста пропускной способности относительно PCIe — не из-за «лучшего железа», а просто из-за того, что меньше времени тратится на синхронизацию.
Почему мы не используем HGX и DGX? HGX — это базовая плата NVIDIA для 8-GPU SXM-конфигураций с полным NVLink-мешем. DGX — готовый «суперкомпьютер в коробке» от NVIDIA. Обе платформы технически великолепны, но есть одна проблемаа: ни HGX, ни DGX не входят в реестр российских серверных систем Минпромторга, что закрывает их для госсектора, КИИ-проектов и любых закупок с требованием к российскому происхождению оборудования.
Когда HGX-платформа была бы избыточна — даже без регуляторного ограничения? Это честный вопрос, на который есть ответ в цифрах.
Полноценная HGX H100 система на 8 GPU SXM5 стоит, по рыночным данным 2026 года, около $250 000–320 000 за узел — и это только сервер, без стойки, питания, сети и прочей обвязки. Максимально упакованное NVLink-меш-решение HGX (в котором каждый GPU напрямую связан с каждым) начинает давать значимое преимущество, по нашим оценкам, в сценариях, где:
модель целиком не помещается в VRAM одного GPU или VRAM 4 GPU, объединенных в NVlink, и требует tensor parallelism на >4 картах одновременно с интенсивным обменом данными;
размер или длина последовательности создают постоянную высокую нагрузку именно на inter-GPU коммуникацию внутри одного узла.
Практически это соответствует предобучению моделей от ~70B параметров в полной точности. Для fine-tuning и inference моделей до 30–40B параметров разница в топологии NVLink внутри узла не является определяющим фактором производительности — там узким местом обычно оказывается что-то другое: сеть между узлами, хранилище или пропускная способность памяти GPU. Переплачивать за полный HGX-меш в этом диапазоне — значит, платить за возможность, которую конкретная задача не использует.
MIG: когда делить GPU выгодно, а когда это ложная экономия
Multi-Instance GPU позволяет разделить один H100/H200 вплоть до семи изолированных экземпляров с гарантированными ресурсами. Это полезно в двух конкретных случаях:
Много небольших независимых задач — inference-эндпоинты, embedding-сервисы, небольшие fine-tuning задания. Один GPU вместо семи позволяет существенно сократить простой железа.
Мультитенантная среда — когда разным командам или проектам нужна изоляция, но полный GPU каждому не нужен.
MIG не подходит, когда задача требует всей памяти GPU (большие модели), когда важна максимальная производительность одной задачи, или когда нужен межмодульный обмен данными — MIG-инстансы не взаимодействуют через NVLink.
Сейчас мы в команде продукта Скала^р МИИ разрабатываем специальное ПО — Спектр ИИ, — в котором предусмотрено несколько модулей, Поток ИИ является одним из них. Поток ИИ эффективно и безопасно управляет аппаратными ресурсами, квотами на ресурсы, нативно запускаемых на ПАК МИИ согласно политикам безопасности и логике очередей и когорт из очередей, управляемых ролевой моделью в нашем ПО.
Пока продукт находится на этапе тестирования, придет время — и мы о нем обязательно расскажем в отдельной статье.
Питание: там, где «немного не хватит» стоит дорого
Профиль потребления ИИ-нагрузки: не то, для чего рассчитан стандартный PSU
Стандартный серверный блок питания рассчитан на относительно ровный профиль нагрузки с разумным запасом. H100 SXM в полной нагрузке обучения — это 700 Вт на карту. Восемь карт — 5,6 кВт только на GPU, а ведь еще есть CPU, RAM, диски, сеть. Итого типовой GPU-узел под полной ИИ-нагрузкой — 8–10 кВт.
При этом нагрузка не ровная: при старте эпохи обучения потребление резко прыгает от почти нуля к максимуму — быстро и синхронно по всем GPU узла. Стандартные серверные PSU при таких пиках дают нестабильность в самый неподходящий момент: когда уже запущено длительное задание обучения.
Источник: https://documentation.sigma2.no/code_development/guides/PyTorchProfilerMultiGpu.html
Схема резервирования в ПАК
В GPU-узлах «Скала^р МИИ» используются четыре блока питания в режиме резервирования с подключением по двум независимым линиям электропитания. Что это дает:
одного PSU система продолжает работу без прерывания;
одной линии питания система продолжает работу на второй линии с оставшимися PSU;
комбинация этих отказов — покрыта.
Единственный сценарий, который эта схема не покрывает — одновременный отказ обеих линий питания, но это уже вопрос к инфраструктуре ЦОДа, а не к узлу.
Что учитывать при планировании размещения
Правило расчета потребления: не берите номинальные характеристики GPU по TDP, берите пиковые значения под реальной нагрузкой и закладывайте 15–20% сверху для запаса мощности PSU. Типичная ошибка самосборщиков — занижение пикового потребления на 30–40%, что обнаруживается при первом полноценном запуске обучения.
Требования к ЦОД: 8–10 кВт на узел означает, что даже 4–5 GPU-серверов в одной стойке выводят ее на 40–50 кВт. Это за пределами стандартной стоечной PDU и нормативов большинства стоек «общего назначения». Планировать размещение нужно заранее, вместе с оператором ЦОДа — это не деталь, которую можно додумать после закупки железа.
Охлаждение: физика, которую не обойти выбором вентилятора помощнее
Текущий релиз ПАК ИИ использует воздушное охлаждение
В актуальном релизе «Скала^р МИИ» используются узлы с воздушным охлаждением. Это не компромисс — это осознанный выбор, который работает в определенном диапазоне плотности размещения. Разберем, где этот диапазон заканчивается.
Физическая граница воздушного охлаждения
Воздух — плохой теплоноситель: его теплоемкость в ~3-4 раза ниже, а теплопроводность в ~30 раз ниже, чем у воды. При плотности мощности в стойке до ~30–35 кВт воздушное охлаждение справляется при правильно организованном воздухопотоке (горячий/холодный коридор). А вот при превышении этого порога объем воздуха, необходимый для отвода тепла, реализовать физически уже гораздо сложнее.
Практическая граница воздушного охлаждения — около 35–40 кВт на стойку. Выше этого предпочтительны решения с жидкостным охлаждением.
Как это соотносится с конфигурацией наших узлов
Типовой GPU-узел «Скала^р МИИ» на 8x H100 при полной нагрузке потребляет 8–10 кВт.
Это означает:
Стойка | Количество узлов | Мощность | Охлаждение |
42U | 2–3 узла | ~20–30 кВт | Воздух, комфортно |
42U | 3–4 узла | ~30–40 кВт | Воздух, на границе |
42U | 5+ узлов | >40 кВт | Требуется жидкостное |
При типовом размещении 3–4 GPU-серверов в стойке воздушное охлаждение работает. При более плотном размещении — нет.
Экономика перехода на жидкостное охлаждение
Когда жидкостное охлаждение становится экономически оправданным? По отраслевым данным, TCO-паритет (когда 10-летняя стоимость жидкостного решения с учетом CAPEX на инфраструктуру начинает выигрывать у воздушного) наступает примерно при 30–40 кВт на стойку. Модернизация и установка жидкостного охлаждения в существующем ЦОДе — порядка $2–3 млн за МВт мощности. Зато операционная экономия на охлаждении при высокой плотности — 20–40% в год за счет PUE 1,02–1,15 против 1,4–1,6 для воздушного.
Жидкостное охлаждение в следующих релизах ПАК. Мы как производитель понимаем, что в новом поколении GPU воздух становится «менее эффективным», поэтому прорабатываем вопрос использования в ПАК жидкостного охлаждения. Рассмотрение того или иного решения происходит по процессу утвержденной валидации. Если при планировании конкретного проекта предполагается плотность выше 35–40 кВт на стойку или дальнейшее масштабирование в этом направлении — мы обсуждаем этот вопрос на этапе проектирования решения совместно с заказчиком.
Thermal throttling: тихий убийца производительности
Когда охлаждение «почти справляется», GPU при превышении температурных порогов начинают снижать тактовую частоту — и наступает тот самый thermal throttling. Это не аварийный останов, а «мягкая» деградация: задача выполняется, метрики GPU в Kubernetes выглядят нормально, но реальная производительность ниже на 15–25%. Узнают об этом обычно случайно — при сравнении с baseline-тестом или когда начинают смотреть непосредственно в GPU-телеметрию.
В ПАК мы включаем в мониторинг GPU-температурные метрики и настраиваем оповещения до того, как температура достигает порога throttling, а не после.
Хранение: три задачи с разными требованиями к I/O
Паттерны I/O в ИИ — почему нельзя взять одно универсальное решение
ИИ-инфраструктура создает три принципиально разных профиля нагрузки на хранилище:
Предобучение: непрерывное последовательное чтение датасетов (большие блоки, высокая пропускная способность), периодические большие последовательные записи при сохранении чекпоинтов.
Fine-tuning: загрузка весов базовой модели (последовательное чтение, размер от единиц до сотен ГБ), запись адаптеров и промежуточных состояний.
Inference и RAG: частое случайное чтение небольших блоков (embedding-поиск, KV-cache), низкие задержки здесь критичны.
Источник: https://hammerspace.com/ai-workloads-storage-architecture-performance-patterns-for-training-inference-and-llms/, https://www.solidigm.com/products/technology/understanding-i-o-demands-of-ai-workloads-video.html
Одна система хранения, оптимизированная лишь под один из этих паттернов, может быть неоптимальна для двух других. Поэтому правильно — проектировать хранилище по типу нагрузки.
Локальные диски GPU-узлов в ПАК
В GPU-узлах «Скала^р МИИ» используется следующие типовые локальные конфигурации:
от 4 × 1,92 ТБ SATA SSD — под ОС и локальные данные для инференса;
от 4 × 3,84 ТБ SATA SSD — под ОС и локальные данные обучения и дообучения.
SATA SSD дает последовательное чтение/запись около 500–550 МБ/с на диск; в массиве на четыре диска — около 1–1,5 ГБ/с на чтение. Для большинства fine-tuning и inference задач этого достаточно: модели до 30–40B параметров в квантизованном виде, локальные датасеты, чекпоинты при умеренной частоте сохранения.
Внешнее хранилище как основная модель для тяжелых задач
В типовых сценариях ПАК рассматривает внешнее хранилище как основной «уровень» для датасетов, данных обучения и долгосрочного хранения артефактов. Это позволяет:
масштабировать емкость независимо от вычислительных узлов;
использовать специализированные СХД с RDMA-доступом (NVMe-oF, RoCE) для требовательных нагрузок;
централизовать управление данными и реализовать «правильную» работу с данными в рамках Data Governanace (только в такой централизации создается единый «источник правды», реализуется контроль за утечками и уменьшается количество дублей и потерь данных);
настраивать централизованное управление политиками резервного копирования.
Интеграция с S3-совместимыми хранилищами через CSI-драйверы — стандартная механизм подключения внешних хранилищ к ПАК.
Когда SATA недостаточно: параметры, при которых мы рекомендуем NVMe
SATA становится узким местом в конкретных ситуациях, и их важно идентифицировать заранее.
Размер и частота чекпоинтов. Запись чекпоинта 10 ГБ на SATA занимает около 20 секунд; на NVMe PCIe Gen4 (~7 000 МБ/с) — около двух секунд. При больших моделях это становится критично: чекпоинт модели 70B в BF16 — это ~140 ГБ; на SATA-массиве запись такого объема займет несколько минут, что при высокой частоте чекпоинтинга создаст значимую задержку и паузы GPU-вычислений. При NVMe тот же чекпоинт укладывается в ~20 секунд — и задание не останавливается в ожидании записи.
Скорость загрузки датасетов. При предобучении на крупных датасетах GPU должны получать следующий батч данных до того, как завершат обработку текущего. Для H100 в полной нагрузке нужно поддерживать поток данных от 2–4 ГБ/с на один узел. SATA-массив на четыре диска приближается к этой границе, не оставляя запаса.
Inference с быстрой сменой моделей. Загрузка 40-гигабайтной модели с SATA — 70+ секунд, с NVMe Gen4 — около 15 секунд. Для продакшн inference-сервиса с SLA на время холодного старта — это принципиально разные числа.
Параметр | SATA (4 диска) | NVMe Gen4 (4 диска) |
Последовательное чтение, массив | ~1,5–2 ГБ/с | ~14–28 ГБ/с |
Запись чекпоинта 10 ГБ | ~20 с | ~2 с |
Запись чекпоинта 140 ГБ (70B модель) | ~4–5 мин | ~20–25 с |
Загрузка модели 40 ГБ | ~70+ с | ~15 с |
Оптимальный сценарий | Fine-tuning, умеренный инференс | Предобучение, быстрый инференс, высокая частота сохранения чекпоинтов |
При расчете конкретного решения для заказчика мы анализируем все эти параметры: размер модели, частоту чекпоинтов и требования к «холодному старту». Если нагрузка попадает в зону, где SATA создает узкое место, — включаем NVMe в конфигурацию GPU-узлов или рекомендуем соответствующую внешнюю СХД с NVMe-интерфейсом.
CPU и память: инфраструктура для GPU, а не конкурент
В GPU-сервере CPU реализует несколько критичных этапов: процессинг данных и подготовка батчей для GPU, оркестрацию и логирование, постобработку выходов модели в конвейер инференса. Если CPU не успевает готовить данные — GPU ждет, как следствие — утилизация падает.
Ориентир по памяти: использовать не менее 1024 ГБ RAM на 8-GPU-узел для комфортной работы без постоянного свопирования данных через PCIe. Может показаться, что это много — но при одновременной загрузке датасета, весов модели в CPU-памяти и буферов передачи данных это число набирается куда быстрее, чем ожидается.
Отдельный момент — NUMA-топология в двухсокетных конфигурациях. GPU, подключенный через PCIe к «чужому» NUMA-домену, работает с дополнительными задержками при обмене с CPU. Это редко является критическим узким местом, но при тонкой оптимизации инференс-конвейера — это фактор, который стоит учитывать при компоновке узла.
IPMI и мониторинг железа: не опция, а требование
Без правильно настроенного мониторинга на уровне железа типичный сценарий выглядит так: длительное задание обучения запущено, GPU-утилизация в Kubernetes выглядит нормально. Где-то ночью начинает деградировать система охлаждения одной из карт. Через несколько часов — thermal throttling, потом аварийный останов. Задание прерывается. Checkpoint был четыре часа назад. Инженеры узнают о случившемся только утром.
При нормальном IPMI-мониторинге алерт по температурному тренду пришел бы за 30–60 минут до инцидента — достаточно, чтобы сохранить checkpoint и корректно завершить задание.
Для GPU-узла стандартного серверного IPMI недостаточно. Нужно дополнительно следить за следующими показателями:
GPU die temperature и температура памяти по каждой карте;
GPU power draw — текущее значение и тренд;
NVLink error counters — аномалии, которые предшествуют деградации производительности меж-GPU коммуникации;
PCIe AER (Advanced Error Reporting) — сигнализирует о проблемах на шине.
В ПАК GPU-специфичную телеметрию через DCGM (Data Center GPU Manager) мы интегрируем в общий observability-стек кластера — инженер видит картину в одном месте, а не бегает между Kubernetes и IPMI-консолью.
Можно ли как-то автоматизировать «отлов» таких алертов? Да, можно :) По крайней мере, мы активно пробуем и создаем собственное решение — «Геном». В чем суть? На уровне железа в ПАКе собираются метрики IPMI, которые логическим образом складываются в «Геном» и визуализируются в «модель здоровья» всего ПАК. По данной модели легко понять текущее состояние устройств и выявить инцидент до того момента, пока ошибка или внешнее воздействие не успело повлиять на выполнение бизнес-задачи.
Пять вопросов, которые стоит задать при обсуждении железа с любым вендором
Как рассчитано энергопотребление? Спрашивайте не номинальный TDP, а пиковые параметры под реальной ИИ-нагрузкой и схему резервирования PSU.
Какой тепловой пакет на стойку и что предусмотрено в ЦОД? Если ответ «стандартная стойка» — уточните, сколько кВт она держит и сколько GPU-узлов предполагается.
Как устроена сетевая сегментация на уровне железа? ML-трафик и бэкап-трафик должны идти по разным физическим сегментам — иначе ночной бэкап убьет производительность обучения. Подробнее — в следующей статье.
Что происходит с заданием при отказе одного GPU-узла? Правильный ответ включает в себя аварийное выключение со стратегией сохранения чекпоинтов и автоматическую миграцию нагрузки.
Какой мониторинг на уровне железа, а не только в Kubernetes? GPU die temp, температура памяти, ошибки NVLink, power draw — все это должно быть в observability-стеке, а не только в IPMI-консоли.
Это самые важные нюансы, которые нужно учитывать при выборе железа на самом раннем этапе, и все их мы заранее учли в нашем ПАК, чтобы сэкономить время заказчиков.
В следующей статье цикла we need to go deeper, на уровень сети — RDMA, RoCEv2, сегментация трафика и почему правильная сетевая архитектура — это, пожалуй, самая недооцененная статья инфраструктурного бюджета в ИИ-проектах.
Если есть вопросы по аппаратному стеку или хотите разобрать конкретный сценарий — пишите в комментариях, с радостью ответим.
