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

Главная ловушка самосбора — иллюзия совместимости. Каждый компонент по отдельности работает, но вместе они могут давать сбои. GPU-драйвер совместим с CUDA, CUDA нормально работает в контейнерах — отдельно всё отлично. Но под нагрузкой начинаются утечки памяти на стыке слоёв, а сетевой стек, который прекрасно держит обычный трафик, при распределённом обучении сталкивается со специфическими паттернами нагрузки, приводящими к потере данных или деградации каналов. Проблема в том, что протестировать компонент легко, а протестировать систему из компонентов под реальной ИИ-нагрузкой — дорого, долго и требует экспертизы, которой в момент закупки железа обычно ни у кого нет: её нарабатывают по ходу эксплуатации, на тех самых граблях. В «Скала^р МИИ» этот путь интеграционного тестирования прошли один раз и зафиксировали результат как продукт: заказчик получает уже протестированную связку «железо + ОС + Kubernetes + GPU-стек + сетевой стек», а не набор спецификаций, которые предстоит свести вместе самостоятельно.

Второй распространённый грабли — выбор 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), до 64 ГБ vRAM с пропускной способностью 800–1200 ГБ/с, поддержка TensorFlow, PyTorch, PaddlePaddle, OpenCL и MetaX Compute SDK. При этом все платформы доступны через одинаковые оптимизированные контейнеры с PyTorch, TensorFlow, JAX, PaddlePaddle, MATLAB и библиотеками, так что выбор железа не превращается в отдельный проект по пересборке софтверного стека.

Третий, и, пожалуй, самый недооценённый аспект — сеть. По опыту «Скала^р», именно здесь «незаметно» теряется производительность. Команда месяцами отлаживает «странные тормоза» при распределённом обучении, а в итоге оказывается, что RDMA-трафик между GPU и трафик резервного копирования конфликтуют, или что коммутаторы не справляются с пиковыми нагрузками. В ПАК «Скала^р МИИ» сетевой стек уже настроен и протестирован под ИИ-нагрузки, включая распределённое обучение и инференс. Это избавляет от необходимости самостоятельно разбираться в тонкостях RDMA, RoCE и других протоколов, которые критичны для масштабирования.

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

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