Привет, Хабр! Меня зовут Алексей, я архитектор в команде Скала^р (входим в Группу Rubytech). Мы разрабатываем программно-аппаратные комплексы (ПАК) — для баз данных, динамической инфраструктуры, интеллектуального хранения данных, больших данных и отраслевых задач в госсекторе, финансах и промышленности. В этой статье — про один из самых молодых, но самых турбулентных классов ПАК в нашем портфеле: инфраструктуру под ИИ-задачи, на примере «Машины искусственного интеллекта Скала^р (Скала^р МИИ)».
Формат статьи немного нетипичный для обзора продукта. Я не буду перечислять фичи по порядку — вместо этого попробую показать путь типового заказчика: с какими проблемами он сталкивается не на этапе закупки, а через два-три месяца эксплуатации, когда стенд уже работает, деньги потрачены, а перформанс почему-то не тот, что ожидался. И сразу — что мы сделали в ПАК, чтобы заказчик в принципе не попадал в эту точку.
Почему это вообще стало темой разговора
Два года назад ПАК под ML / AI — это была экзотика уровня «бигтех решил выпендриться». Сейчас всё иначе: взрывной рост интереса к ИИ, лавина конкурирующих моделей, госзапрос на цифровизацию — и в итоге свой ИИ-стенд стал не «было бы неплохо», а рабочей необходимостью и для крупного, и для среднего бизнеса.
Триггер обычно один и тот же: компания заводит ИИ-агентов внутри периметра и почти сразу спотыкается о то, что внешнему провайдеру нельзя отдавать конфиденциальные данные, модель нужно дообучать на внутренних данных, а регулятор по-прежнему требует своего. Вывод один — нужна своя инфраструктура. А вот дальше начинается развилка: собрать самим или взять готовое.
И тут мы как вендор оказываемся в забавной позиции: мы не говорим «самосбор — это плохо». Мы говорим: «самосбор — это нормально, если вы заранее знаете весь список граблей, на которые наступите». Дальше — собственно список, по разделам инфраструктуры.
Итак, переходим к граблям
Грабли №1. Каждый компонент работает, а вместе — не факт
Это, пожалуй, главная ловушка самосбора, и она почти никогда не видна на этапе пилота. GPU-драйвер совместим с CUDA, CUDA нормально работает в контейнерах — отдельно всё ОК. А потом под нагрузкой начинаются утечки памяти на стыке слоёв. Или сетевой стек прекрасно держит обычный трафик, но при распределённом обучении возникают специфические паттерны нагрузки, которые приводят к потере данных или повышенной нагрузке и деградации сетевых каналов.
Проблема в том, что протестировать компонент легко, а протестировать систему из компонентов под реальной ИИ-нагрузкой — дорого, долго и требует экспертизы, которой в моменте закупки железа обычно ни у кого ещё нет: её нарабатывают по ходу эксплуатации, на тех самых граблях.
Во время сборки Скала^р МИИ, мы прошли весь этот путь интеграционного тестирования сами, один раз, и зафиксировали результат как продукт. Заказчик получает уже протестированную связку «железо + ОС + Kubernetes + GPU-стек + сетевой стек», а не набор спецификаций, которые предстоит свести вместе самостоятельно.
Ориентировочная разница в цифрах, которую мы видим на практике:
Критерий | Самостоятельная сборка | Готовый ПАК «Скала^р МИИ» |
Время развёртывания | 2–4 месяца интеграции + постоянная отладка в проде | 1–2 недели установки + предсказуемое поведение |
Производительность | «Типовая», с непредсказуемыми провалами | Стабильно +200–300% |
Поддержка и устранение проблем | Инженеры разбираются с интеграционными проблемами сами | Техподдержка «из одного окна» |
Грабли №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 и повышение пропускной способности за счёт оптимизации конвейера и грамотного управления ресурсами.
Итоговая сводная таблица
Аспект | Самостоятельная сборка | Готовый ПАК | Эффект |
Время развёртывания | 2–4 месяца | 1–2 недели | ~15x быстрее |
Производительность обучения | Базовые показатели (100%) | +200–300% | ~3x прирост |
Производительность инференса | Базовые показатели (100%) | +300–400% | ~4x прирост |
Отказоустойчивость | Зависит от экспертизы команды | Протестированная архитектура | Гарантированная надёжность |
Сетевая архитектура | Часто единая сеть, «бутылочное горлышко» | Физическое разделение трафика | Предсказуемая производительность |
GPU-планирование | Стандартный K8s планировщик | Разработанный планировщик с поддержкой GPU топологий | Оптимальное размещение нагрузок |
Мониторинг | Требует отдельной настройки | GPU-метрики из коробки | Проактивное обнаружение проблем |
Техподдержка | Множество вендоров | «Одно окно» | Быстрое решение проблем |
Аттестация / сертификация | Несколько лет | 6–12 месяцев | ~2x быстрее |
Интеграция ML-инструментов | Ручная настройка каждого | Преднастроенный стек | ~5x ускорение работы data-инженеров |
Масштабирование | Линейное, с деградацией | Оптимизированное модулями | Эффективное использование ресурсов |
RDMA / высокоскоростная сеть | Часто не используется | Оптимизированный NCCL + RDMA | Критично для распределенного обучения |
Безопасность | Требует отдельной экспертизы | RBAC + аудит + изоляция + ИБ-решения для ИИ | Безопасность энтерпрайз-уровня |
TCO (3 года) | Высокие скрытые затраты | Предсказуемые затраты | Снижение операционных расходов |
Вместо заключения: что из этого стоит забрать с собой
Самосбор — не ошибка, а решение с открытыми глазами. Если в команде есть экспертиза по каждому из перечисленных слоёв, достаточные финансовые ресурсы и время на то, чтобы пройти все грабли самостоятельно — это рабочий путь. Кстати, про экономику создания ПАКа и финансовую сторону самостоятельно собранных решений мы обязательно как-нибудь расскажем в следующих статьях. Вопрос не в том, «плохо» это или «хорошо», а в том, готовы ли вы заплатить эту цену именно временем и экспертизой, а не только деньгами на железо.
Производительность — это не про железо само по себе. Одинаковые GPU в разных архитектурах дают кратно разный результат: всё решает интеграция компонентов.
Сетевая архитектура — самое недооценённое место. Экономия на коммутаторах и QoS чаще всего убивает производительность ML-задач сильнее, чем выбор GPU.
GPU-scheduling требует специализации. Стандартный Kubernetes не понимает GPU-топологию «из коробки», и это системно ограничивает утилизацию ресурсов.
Аттестация и compliance — это не бумажная формальность, а реальный срок проекта. Готовые сертификаты на компоненты сокращают этот срок в разы.
Готовый ПАК в этом смысле — это не столько «коробка с железом», сколько чужой опыт прохождения всех перечисленных граблей, упакованный в продукт с гарантиями и поддержкой. Наша задача как вендора была именно в том, чтобы заказчик не узнал про каждый из этих пунктов на собственном опыте — через инцидент в проде.