Привет, Хабр! Меня зовут Алексей, я архитектор в команде Скала^р (входим в Группу Rubytech). Мы разрабатываем программно-аппаратные комплексы (ПАК) — для баз данных, динамической инфраструктуры, интеллектуального хранения данных, больших данных и отраслевых задач в госсекторе, финансах и промышленности. В этой статье — про один из самых молодых, но самых турбулентных классов ПАК в нашем портфеле: инфраструктуру под ИИ-задачи, на примере «Машины искусственного интеллекта Скала^р (Скала^р МИИ)».

Формат статьи немного нетипичный для обзора продукта. Я не буду перечислять фичи по порядку — вместо этого попробую показать путь типового заказчика: с какими проблемами он сталкивается не на этапе закупки, а через два-три месяца эксплуатации, когда стенд уже работает, деньги потрачены, а перформанс почему-то не тот, что ожидался. И сразу — что мы сделали в ПАК, чтобы заказчик в принципе не попадал в эту точку.

Почему это вообще стало темой разговора

Два года назад ПАК под ML / AI — это была экзотика уровня «бигтех решил выпендриться». Сейчас всё иначе: взрывной рост интереса к ИИ, лавина конкурирующих моделей, госзапрос на цифровизацию — и в итоге свой ИИ-стенд стал не «было бы неплохо», а рабочей необходимостью и для крупного, и для среднего бизнеса.

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

И тут мы как вендор оказываемся в забавной позиции: мы не говорим «самосбор — это плохо». Мы говорим: «самосбор — это нормально, если вы заранее знаете весь список граблей, на которые наступите». Дальше — собственно список, по разделам инфраструктуры.

Итак, переходим к граблям

Грабли №1. Каждый компонент работает, а вместе — не факт

Это, пожалуй, главная ловушка самосбора, и она почти никогда не видна на этапе пилота. GPU-драйвер совместим с CUDA, CUDA нормально работает в контейнерах — отдельно всё ОК. А потом под нагрузкой начинаются утечки памяти на стыке слоёв. Или сетевой стек прекрасно держит обычный трафик, но при распределённом обучении возникают специфические паттерны нагрузки, которые приводят к потере данных или повышенной нагрузке и деградации сетевых каналов.

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

Во время сборки Скала^р МИИ, мы прошли весь этот путь интеграционного тестирования сами, один раз, и зафиксировали результат как продукт. Заказчик получает уже протестированную связку «железо + ОС + Kubernetes + GPU-стек + сетевой стек», а не набор спецификаций, которые предстоит свести вместе самостоятельно.

Ориентировочная разница в цифрах, которую мы видим на практике:

Грабли №2. Выбор GPU — это не один правильный ответ

Заказчики часто приходят с готовым убеждением «нам нужен H100, и точка». Иногда это действительно так. А иногда — нет, и выясняется это уже после закупки, когда счёт за электричество и охлаждение оказывается куда выше, чем рентабельность задачи это оправдывает.

Мы сознательно не привязываем ПАК к одной аппаратной платформе, а даём выбор под класс задачи:

     Стек NVIDIA — когда речь про крупные LLM и нужен максимум производительности:

• Transformer Engine с FP8 — до 30x ускорения инференса для больших языковых моделей.

• Тензорные ядра 4-го поколения с поддержкой FP64, TF32, FP16, INT8, FP8.

• NVLink/NVSwitch — высокоскоростное соединение до 900 ГБ/с.

• Multi-Instance GPU (MIG) — разбиение одной карты на несколько изолированных инстансов (до семи).

• у H200 отдельно — память HBM3e до 141 ГБ (4,8 ТБ/с) и объединение до четырёх карт через NVLink.

Стек графических карт китайского производства — когда в приоритете миграция на оборудование альтернативного поставщика и вопросы доступности оборудования:

• архитектура MUSA, CUDA-совместимость;

• поддержка распределенного обучения;

• заявленная возможность обучения LLM до 100 млрд параметров;

• 70–100 TFLOPS (FP16), 140–200 TOPS (INT8);

• поддержка объёма vRAM до 64 ГБ, пропускная способность 800–1200 ГБ/с;

• поддержка TensorFlow, PyTorch, PaddlePaddle;

• OpenCL, CUDA-совместимый уровень, MetaX Compute SDK.

Все платформы доступны заказчику через одинаковые оптимизированные контейнеры с PyTorch, TensorFlow, JAX, PaddlePaddle, MATLAB и библиотеками — то есть выбор железа не превращается в отдельный проект по пересборке софтверного стека.

Грабли №3. Сеть — там, где «незаметно» теряется производительность

Это, по нашему опыту, самая недооценённая статья граблей при самосборе. Картина обычно такая: команда месяцами отлаживает «странные тормоза» при распределенном обучении, и в итоге оказывается, что RDMA-трафик между GPU и трафик резервного копирования СХД идет через один и тот же коммутатор. Кто-то из команды заказчика посчитал, что по утверждённому регламенту резервного копирования ночью можно трафик бэкапа пустить через ИИ-интерконнект-коммутатор. Ночной бэкап — и производительность ML-задач проваливается в разы. Дёшево сэкономили на коммутаторах — дорого потеряли на простое GPU.

В ПАК мы изначально закладываем физическое разделение трафика по назначению:

• 400GbE/100GbE — ИИ-интерконнект между вычислительными узлами;

• 25GbE — клиентский доступ и подключение к внешним системам хранения;

• 1GbE — управление (IPMI, PXE, мониторинг).

Типичные ошибки самосборки на этом уровне, которые мы закрываем архитектурно:

• Одна сеть «для экономии на коммутаторах» → непредсказуемые задержки;

• неправильная настройка RDMA → не используются все возможности InfiniBand/RoCE;

• отсутствие QoS → управляющий трафик блокирует data plane;

• некорректный MTU → jumbo frames не работают.

Агрегация каналов и отказоустойчивость сети

Для служебного взаимодействия между узлами мы используем агрегацию двух и более портов 25/100/400 Гбит/с — на уровне ОС это один логический bond-интерфейс. При самосборе здесь регулярно встречаются:

• active-backup вместо нормальной балансировки нагрузки;

• некорректный хэширующий алгоритм → трафик распределяется неравномерно;

• отсутствие мониторинга bond-состояния → деградация канала остаётся незамеченной;

• разный MTU на физических интерфейсах внутри одного bond.

Для самой сети ИИ-интерконнекта мы используем два сетевых узла (коммутатора) с портами 100/400 Гбит/с, объединённые в один виртуальный порт по технологии MLAG. Это даёт автоматическое переключение при отказе одного из коммутаторов, балансировку нагрузки и отсутствие единой точки отказа — то есть всё, что в самосборе требует отдельной экспертизы по MLAG, spanning tree и failover-тестированию (и регулярно работает «в теории, но не в реальности», особенно с multicast, который критичен для некоторых ML-фреймворков).

Сегментация трафика

Для клиентского доступа — два коммутатора 25 Гбит/с, для управления и мониторинга — один-два узла на 1 Гбит/с. Сегментация строится по трём контурам: продуктивная сеть (ИИ-трафик между узлами), сеть хранения данных и внешнего доступа и сеть управления (IPMI, PXE, служебный трафик). При самосборе смешение этих контуров — едва ли не самая частая причина «необъяснимой» нестабильности производительности.

Грабли №4. Отказоустойчивость, о которой вспоминают после первого инцидента

Самостоятельное развёртывание Kubernetes-кластера на масштабе предприятия упирается в довольно длинный список вещей, которые «работают, пока не сломаются»:

• etcd split-brain при сетевых проблемах — команды систематически недооценивают важность правильной настройки кворума;

• планировщик не понимает GPU-топологию — GPU-интенсивные поды размещаются неоптимально;

• отсутствие мониторинга GPU-метрик — проблема обнаруживается постфактум, а не в момент возникновения;

• некорректные лимиты ресурсов — один под способен «съесть» весь узел.

В ПАК слой управления GPU реализован отказоустойчиво по схеме с резервным мастером (Standby Master): реплицированный экземпляр автоматически перехватывает управление при отказе основного. Рабочие узлы поддерживают миграцию при сбоях — но здесь у самосбора регулярно «забывают» три вещи: правильный node drain timeout для GPU-задач (они могут долго завершаться), graceful shutdown для stateful ML-приложений и резервирование ресурсов под системные поды.

И отдельно — про так называемый «разрыв» по ресурсам. Планировщик в ПАК — наша собственная разработка — умеет самостоятельно запускать нагрузку на резервных узлах. Это не просто «запас на будущее»: если внезапно отказывает сервер с 8 GPU, планировщик позволяет оперативно закрыть проблему без остановки бизнес-процессов, переключив очереди задач. В самосборе такая логика — это отдельный, обычно недооценённый по трудоёмкости архитектурный проект.

Грабли №5. Питание и охлаждение — там, где ИИ-нагрузка не похожа на обычную

ИИ-нагрузка с точки зрения электропитания ведёт себя не так, как привычные корпоративные сервисы: резкие пики потребления при старте обучения и затем длительные периоды максимального потребления. Стандартные серверные БП, рассчитанные на более ровный профиль нагрузки, в таком режиме часто дают нестабильность именно тогда, когда стабильность важнее всего — под полной нагрузкой обучения.

В узлах ПАК мы используем блоки питания в режиме резервирования с подключением по двум независимым линиям электропитания, SSD для ОС, оптимизированные под интенсивное логирование, и IPMI-мониторинг для раннего обнаружения проблем железа. Типичные ошибки самосборки здесь — недооценка энергопотребления GPU под полной нагрузкой, неправильное охлаждение (с thermal throttling, который незаметно снижает производительность месяцами) и отсутствие IPMI-мониторинга, из-за которого проблема с железом обнаруживается слишком поздно.

Грабли №6. Сертификация и аттестация — там, где время считается месяцами, а не днями

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

• отсутствие audit trail для ML-операций;

• сложности с разграничением доступа к GPU-ресурсам между проектами и командами;

• отсутствие multi-tenant-изоляции на уровне железа, а не только namespace’ов.

С готовым ПАК заказчик получает сертификаты ФСТЭК России на ключевые компоненты, RBAC с поддержкой GPU-квот и multi-tenancy с изоляцией на уровне namespace’ов и аппаратной части. По нашим оценкам, это существенно (до двух раз) сокращает цикл аттестации.

Где всё это конвертируется в конкретные цифры: три сценария

Обучение

Самосбор — стандартный Kubernetes и стандартные CSI. ПАК — разработанный планировщик с поддержкой GPU-топологий, оптимизированный NCCL для коллективных операций и постоянные тома с высоким IOPS под чекпоинты. На практике это даёт прирост производительности около 3x за счёт устранения сетевых «бутылочных горлышек» и оптимизации паттернов GPU-коммуникации.

Дообучение

Здесь команды чаще всего недооценивают именно время на интеграцию инструментов — Jupyter с GPU-поддержкой «из коробки» — это далеко не docker run jupyter/tensorflow-notebook. Мы регулярно видим у заказчиков на самосборе утилизацию GPU на уровне 30% при том, что сроки всё равно сдвигаются вправо — ресурсов формально достаточно, а задач выполняется мало. ПАК может поставляться с готовым container registry со встроенными образами популярных ML-фреймворков, JupyterHub с GPU-поддержкой из коробки и другими инструментами. По нашей практике, это сокращает время отладки среды с месяцев до недель — примерно в 15 раз.

Инференс

Самосборка — стандартное развёртывание Kubernetes. ПАК — готовый к внедрению «конвейер для инференса»: включает в себя автоматическое масштабирование сервиса развёртывания моделей по GPU-метрикам, «батчирование» с оптимизированной очередью задач, A/B-тестирование моделей и ML-специфичный мониторинг (выявление отклонений, деградация производительности). Результат — снижение задержек до 4x и повышение пропускной способности за счёт оптимизации конвейера и грамотного управления ресурсами.

Итоговая сводная таблица

Вместо заключения: что из этого стоит забрать с собой

• Самосбор — не ошибка, а решение с открытыми глазами. Если в команде есть экспертиза по каждому из перечисленных слоёв, достаточные финансовые ресурсы и время на то, чтобы пройти все грабли самостоятельно — это рабочий путь. Кстати, про экономику создания ПАКа и финансовую сторону самостоятельно собранных решений мы обязательно как-нибудь расскажем в следующих статьях. Вопрос не в том, «плохо» это или «хорошо», а в том, готовы ли вы заплатить эту цену именно временем и экспертизой, а не только деньгами на железо.

• Производительность — это не про железо само по себе. Одинаковые GPU в разных архитектурах дают кратно разный результат: всё решает интеграция компонентов.

• Сетевая архитектура — самое недооценённое место. Экономия на коммутаторах и QoS чаще всего убивает производительность ML-задач сильнее, чем выбор GPU.

• GPU-scheduling требует специализации. Стандартный Kubernetes не понимает GPU-топологию «из коробки», и это системно ограничивает утилизацию ресурсов.

• Аттестация и compliance — это не бумажная формальность, а реальный срок проекта. Готовые сертификаты на компоненты сокращают этот срок в разы.

Готовый ПАК в этом смысле — это не столько «коробка с железом», сколько чужой опыт прохождения всех перечисленных граблей, упакованный в продукт с гарантиями и поддержкой. Наша задача как вендора была именно в том, чтобы заказчик не узнал про каждый из этих пунктов на собственном опыте — через инцидент в проде.