Переход с ускорителей NVIDIA на MetaX — что переносится, а что переделывается

Замена ускорителей NVIDIA на MetaX рассматривается там, где сроки поставки и доступность оборудования становятся определяющими наравне с производительностью. Решение принимается не по одной цифре из спецификации, а по трём группам вопросов: что происходит с программным обеспечением, что меняется в инфраструктуре стойки и какие задачи переносятся без переработки, а какие потребуют дополнительной работы.

Разберём, что переносится напрямую, где возникают затраты на переход, как проверить пригодность замены на своей нагрузке и какие данные нужны для расчёта конфигурации. Направления описаны на страницах ускорителей NVIDIA и ускорителей MetaX.

Что переносится без переработки

• Стандартные фреймворки обучения. Модели, описанные средствами распространённых библиотек, переносятся сборкой под программный стек MetaX без изменения кода модели.
• Типовые операции. Свёртки, матричные умножения, нормализация, механизмы внимания реализованы в библиотеках производителя и вызываются теми же средствами фреймворка.
• Форматы контрольных точек и данных. Веса и наборы данных не привязаны к платформе, конвертация не требуется.
• Схема распределённого обучения. Разделение по данным и по слоям модели остаётся прежним, меняется библиотека коллективных операций.
• Средства контейнеризации и планирования задач. Запуск в контейнерах и распределение по узлам через планировщик сохраняются, подменяется образ с драйверами и библиотеками.

Где возникают затраты на переход

• Написанные вручную вычислительные ядра. Код, написанный под архитектуру NVIDIA напрямую, переносится через средства миграции программного стека MetaX, но требует проверки и, как правило, доводки по производительности.
• Сторонние библиотеки в бинарном виде. Компоненты, поставляемые без исходных текстов и собранные под одну платформу, заменяются аналогами или исключаются из тракта.
• Инструменты профилирования. Средства анализа производительности свои у каждого производителя, и команда тратит время на освоение.
• Оптимизации под конкретную архитектуру. Подобранные размеры пакетов, разбиения и режимы смешанной точности подбираются заново — перенесённые без проверки, они дают неоптимальную загрузку.
• Проверка численной сходимости. Обучение прогоняется на контрольном наборе и сравнивается с прежним результатом, особенно при работе в пониженной точности.
• Эксплуатация. Система наблюдения за состоянием ускорителей, журналы и правила реакции на отказ настраиваются под новую платформу.

Что меняется в инфраструктуре

Какие задачи переносятся легче других

• Инференс типовых моделей. Самый предсказуемый сценарий: модель конвертируется в формат исполнения, замеряется пропускная способность и задержка, результат сравнивается напрямую.
• Дообучение готовых моделей. Объём кода невелик, зависимости стандартные, проверка занимает дни, а не недели.
• Компьютерное зрение и обработка изображений. Операции покрыты библиотеками производителя.
• Обучение крупных языковых моделей с нуля. Переносится сложнее: важны и объём памяти, и скорость межсоединения, и зрелость библиотек коллективных операций.
• Задачи с нестандартными вычислительными ядрами. Требуют отдельной оценки трудоёмкости до принятия решения.

Как проверяется пригодность замены

• Выбирается контрольная нагрузка — та, что реально занимает основную часть вычислительного времени, а не синтетический тест.
• Замеряются время шага обучения либо пропускная способность инференса при одинаковой длине последовательности и размере пакета.
• Проверяется загрузка ускорителя: низкая загрузка означает, что узкое место в тракте данных или в сети, а не в вычислителе.
• Сравнивается результат по качеству модели, а не только по скорости.
• Считается стоимость решения целиком — узлы, сеть, питание и охлаждение, — а не цена одной карты.
• Оценивается срок поставки: при равной производительности доступность оборудования часто и определяет выбор.

Что прислать для расчёта конфигурации

• Задачи: обучение с нуля, дообучение или инференс, и какие модели используются.
• Размер моделей и требуемый объём памяти на ускоритель.
• Используемые фреймворки и наличие собственных вычислительных ядер.
• Действующее оборудование, если часть узлов сохраняется.
• Доступная мощность и схема охлаждения стоек.
• Планируемый рост кластера и сроки, к которым нужны узлы.

Частые вопросы

Можно ли смешивать ускорители двух производителей в одном кластере? В пределах одной задачи — нет: коллективные операции требуют однородных узлов. В пределах площадки — можно, разделив кластер на пулы и направляя задачи в нужный пул планировщиком.

Сколько занимает перенос типовой задачи? Инференс распространённой модели проверяется за несколько дней. Обучение с собственным кодом — от нескольких недель, причём основное время уходит не на запуск, а на доводку производительности.

Нужно ли менять серверные платформы? Не всегда. Проверяется исполнение ускорителя, число слотов, мощность блоков питания и схема охлаждения. Часть платформ принимает карты обоих производителей без переделки.

Как оценить результат, если сравнивать не с чем? Берётся задача, которая уже выполняется на действующем оборудовании, и замеряется на обеих платформах в одинаковых условиях. Сравнение по паспортным цифрам производительности без такой проверки ненадёжно.

Что делать с обучением команды? Освоение программного стека начинается с инференса на одном узле — это даёт опыт сборки, запуска и профилирования до того, как переносится основная нагрузка. Параллельно настраивается инфраструктура кластера.

Что мы делаем

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

Пришлите описание задач, размеры моделей и параметры стоек на sale@tkasiatorg.ru — предложим конфигурацию, посчитаем узлы и сеть и дадим спецификацию с ценами и сроками поставки.