В этом материале
Архитектуру CPU выбирают вместе с программным стеком и профилем задачи. Одинаковое число vCPU у Arm и x86 не означает одинакового числа физических ядер или полезной производительности.
Предложение Arm-сервера может выглядеть привлекательным для подготовки данных или CPU-инференса. Но переход с x86 затрагивает не только процессор: могут измениться сборки библиотек, контейнеры и доступные оптимизации. Владельцу оборудования полезно представить архитектуру как характеристику конкретной конфигурации, а финансовому партнёру — учитывать стоимость проверки переноса.
Начните с программной совместимости
Перечислите движок модели, библиотеки, расширения и форматы данных. Уточните наличие подходящих сборок для выбранной архитектуры и операционной системы. Успешный запуск основного языка программирования не доказывает совместимость всех зависимостей приложения.
AWS Graviton представляет семейство Arm-процессоров для облачных задач. Документация CPU-бэкенда vLLM описывает поддерживаемые варианты установки и требования. Проверяйте нужный вариант по зафиксированной версии ПО, а не по общей фразе о поддержке CPU.
Сохраните отдельно компоненты, которым требуется пересборка или замена. Они формируют реальный объём пилота.
Не сравнивайте только количество vCPU
Способ предоставления вычислительной единицы зависит от сервиса и архитектуры. В одном случае vCPU может соответствовать аппаратному потоку, в другом условия определяются иначе. Проверяйте документацию конкретного предложения.
Для собственной машины укажите физические процессоры, ядра и потоки. Дополните паспорт объёмом и конфигурацией RAM. Такой набор позволяет обсуждать перенос без предположения, что одинаковые числовые ярлыки дают одинаковую работу.
Отдельно проверьте, получает ли виртуальная машина выделенный или разделяемый CPU-ресурс. Это влияет на сопоставимость длительных испытаний.
Выберите переносимую задачу
Возьмём условную подготовку текстового корпуса. Зафиксируйте входные файлы, этапы очистки и результат токенизации. Затем выполните один процесс, несколько параллельных и полный цикл обновления данных.
Для CPU-инференса добавьте точную модель, формат весов и ограничения контекста. Проверяйте корректность результата вместе со временем выполнения. Если для одной архитектуры используется другой формат, это должно быть явно видно в отчёте.
Сравнивайте готовое приложение, а не случайную арифметическую операцию, которая удобна одной из платформ.
Посчитайте стоимость переноса
Включите инженерное время, подготовку образов, повторные проверки и сопровождение нескольких архитектур. Иногда экономия отдельного ресурса сопровождается дополнительной работой команды; иногда перенос оказывается простым и полезным.
Не переносите измеренный результат CPU на GPU-часть автоматически. Поддержка ускорителя, драйвера и соединений проверяется отдельно. Увеличенная RAM также не заменяет видеопамять, если модель должна выполняться на карте.
Полезно сохранить возможность возврата к прежнему окружению. Тогда отрицательный результат пилота ограничится согласованными расходами проверки.
В отчёте о переносе отдельно отметьте инструменты наблюдения и восстановления. Успешное выполнение модели ещё не подтверждает, что команда сможет диагностировать сбой или собрать прежний образ на другой архитектуре. Проверочный запуск должен включать эти обычные эксплуатационные действия.
Практические выводы
Для будущего GPU-пула особенно важно понимать совместимость CPU-части с выбранной картой и движком.
Сначала прочитайте CPU и GPU-хостинг и воспроизводимый стек.