AMD Advancing AI 2026: как выбрать инференс-кластер — AMD или NVIDIA

Если вы планируете корпоративный инференс-кластер, вопрос «AMD или NVIDIA» нельзя решать по пиковому числу операций или презентационному тесту одной модели. После AMD Advancing AI 2026 выбор инференс-кластера требует проверки всей цепочки: модель, фреймворк, контейнер, сеть, хранилище, мониторинг и команда эксплуатации. Ниже — сравнительная таблица, пошаговый план пилота, схема расчёта TCO и критерии, по которым можно принять решение без преждевременной привязки к одной экосистеме.

Что AMD Advancing AI 2026 действительно меняет для закупки

AMD Advancing AI 2026 проходит 22–23 июля 2026 года в Сан-Франциско, а ключевое выступление Lisa Su запланировано на 23 июля в 9:30 по тихоокеанскому времени. В официальной программе акцент сделан не только на ускорителях, но и на инфраструктуре, масштабировании, разработке, сетевом взаимодействии и практических корпоративных сценариях. (amd.com)

Для закупочной команды это важнее, чем отдельный анонс GPU. Сигнал мероприятия состоит в том, что AMD пытается продавать не изолированный ускоритель, а платформу для построения AI Factory — от вычислительных узлов и программного стека до Ethernet-сети и инструментов эксплуатации.

В программе AMD есть отдельная сессия о переходе от AI-кластеров к AI Factory и сетевом транспорте. В описании упоминается MRC поверх RoCEv2, включая распределение пакетов, адаптивное восстановление и передачу сигналов перегрузки. Это не означает автоматического превосходства AMD в каждом проекте, но показывает, где нужно искать реальные ограничения: в межузловом обмене, отказоустойчивости и согласованности сетевой архитектуры. (amd.com)

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

Почему выбор инференс-кластера начинается с рабочей нагрузки

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

На практике нужно разделить минимум пять сценариев:

1. Большая языковая модель с длинным контекстом. Здесь критичны объём памяти, пропускная способность памяти, KV-кэш, межGPU-соединения и поведение при параллельной обработке запросов.
2. RAG-сервис. Важны не только токены в секунду, но и задержка поиска, скорость чтения векторного хранилища, передача документов и стабильность ответа при смешанной нагрузке.
3. Реальное время и Agent-сценарии. Здесь важнее p95 и p99 задержки, чем средняя производительность. Один медленный вызов инструмента может ухудшить весь пользовательский сценарий.
4. Пакетный инференс. Например, массовая классификация документов или обработка изображений. В таком случае допускается более высокая задержка одного задания, но важны загрузка GPU, стоимость часа и автоматическое масштабирование.
5. Обучение, дообучение и инференс в одном кластере. Для такой схемы необходимо оценивать изоляцию ресурсов, приоритеты очередей, сброс кэшей и влияние фоновых задач на SLA.

Поэтому запрос «AMD или NVIDIA для запуска большой модели» сам по себе неполный. Сначала определите размер модели, тип квантования, длину контекста, размер батча, целевую задержку, долю пиковых часов и допустимое время восстановления.

AMD или NVIDIA: рабочая матрица для предприятия

Это не рейтинг производителей. Это матрица риска. Если ваш сервис уже содержит собственные CUDA-ядра, специализированные плагины и оптимизации под конкретную цепочку NVIDIA, стоимость миграции может оказаться выше экономии на оборудовании. Если приложение построено на стандартном PyTorch и контейнерном запуске, AMD может пройти проверку значительно проще.

Официальная документация ROCm публикует матрицу совместимости по версиям фреймворков, операционных систем и GPU. Например, в актуальной ветке документации отдельно перечисляются поддерживаемые версии Linux, архитектуры CDNA и RDNA, а также версии PyTorch. Такой документ нужно использовать как обязательный фильтр перед закупкой, а не как справочную страницу после поставки оборудования. (rocm.docs.amd.com)

В каких случаях AMD может быть рациональнее

AMD имеет смысл рассматривать в четырёх типах проектов.

Первый — новый сервис без глубоких CUDA-зависимостей. Если команда разворачивает API для LLM, RAG или пакетной обработки с поддерживаемыми контейнерами, вы можете сравнивать платформы по фактической стоимости запроса и стабильности.

Второй — стратегия снижения зависимости от одного поставщика. Даже если основной кластер останется на NVIDIA, отдельный AMD-пул может выполнять пакетные задачи, тестирование, резервную обработку или менее критичные модели.

Третий — крупный кластер, где важна гибкость архитектуры. В этом случае нужно оценивать не только GPU, но и стоимость сетевого оборудования, серверных узлов, энергопотребления, охлаждения, поддержки и доступности запасных компонентов.

Четвёртый — команда уже умеет работать с Linux, контейнерами и открытыми inference-фреймворками. Для такого коллектива переход на ROCm обычно менее болезненный, чем для команды, которая привыкла решать все проблемы готовыми CUDA-рецептами.

Но AMD не стоит выбирать только потому, что «открытая экосистема должна быть дешевле». Если в проекте нет инженера, отвечающего за версии ROCm, драйвера, контейнеры и производительность ядер, потенциальная экономия быстро превращается в операционные затраты.

Где NVIDIA сохраняет наиболее сильное преимущество

Для существующих корпоративных сервисов главным аргументом NVIDIA остаётся не только ускоритель, а накопленный программный слой. CUDA Toolkit включает библиотеки, инструменты отладки и оптимизации, компилятор и runtime для масштабирования приложений от одной GPU до крупных установок. (docs.nvidia.com)

NVIDIA также публикует эталонные архитектуры для инференса, RAG и дообучения. В документации AI Enterprise программный слой описан как согласованный набор компонентов для production-сценариев, а аппаратная часть может адаптироваться под конкретную инфраструктуру. (docs.nvidia.com)

Это даёт предприятию несколько практических преимуществ:

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

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

ROCm и CUDA: как провести честное сравнение

Сравнение ROCm и CUDA нужно проводить на одной модели, одном наборе запросов и одинаковом режиме обслуживания. Минимальный протокол состоит из следующих шагов.

Шаг 1. Зафиксируйте программный состав

Запишите версию Linux, драйвера, ROCm или CUDA, PyTorch, inference-сервера, контейнерного runtime и библиотек квантования. Не допускайте ситуации, когда AMD тестируется на свежем стеке, а NVIDIA — на оптимизированной production-сборке.

Шаг 2. Проверьте базовый запуск модели

Запустите модель в исходном формате и в целевом квантовании. Зафиксируйте, загружается ли она полностью, сколько памяти занимает, работает ли KV-кэш и не появляются ли скрытые переходы на CPU.

Шаг 3. Проверьте пользовательский сценарий

Используйте реальные шаблоны запросов: короткий вопрос, длинный документ, несколько параллельных пользователей, вызов инструмента Agent и поток RAG-контекста. Одна синтетическая строка не показывает поведение системы.

Шаг 4. Измерьте не только среднее значение

Соберите:

• время до первого токена;
• скорость генерации;
• p50, p95 и p99 задержки;
• число успешных запросов в минуту;
• пиковое потребление памяти;
• долю загрузки GPU;
• ошибки и перезапуски;
• время восстановления после остановки узла.

Шаг 5. Проверьте кастомные операции

Если проект содержит CUDA-ядра, нестандартные операции, собственные плагины или особые механизмы внимания, проведите отдельную AMD GPU миграционную оценку. Не засчитывайте тест успешным только потому, что импорт PyTorch завершился без ошибки.

Шаг 6. Повторите тест после перезапуска

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

AMD рекомендует использовать контейнерные образы с предустановленным PyTorch для ROCm как один из основных вариантов установки. Это снижает число ручных расхождений между машинами, но не отменяет проверку совместимости драйвера, ОС и GPU. (rocm.docs.amd.com)

Сеть, хранилище и планировщик меняют итог

Кластер с быстрыми GPU может показывать слабый результат, если данные медленно перемещаются между узлами или модели постоянно загружаются из удалённого хранилища.

Проверьте четыре уровня:

1. Сеть внутри узла. Как соединены ускорители и какая пропускная способность доступна между ними?
2. Сеть между узлами. Как ведёт себя all-reduce, обмен KV-кэшем и распределённый запуск при росте числа пользователей?
3. Хранилище моделей. Сколько времени занимает холодный старт нового экземпляра и что происходит при одновременной загрузке нескольких моделей?
4. Планировщик. Может ли он изолировать ресурсы, учитывать память GPU, перемещать сервис после сбоя и не допускать конфликтов между batch- и realtime-нагрузкой?

В эталонных документах NVIDIA инфраструктура рассматривается как связка вычислений, сети, хранения, мониторинга, валидации и break-fix-процессов, а не как набор отдельных серверов. (docs.nvidia.com)

Для AMD аналогичный подход особенно важен: преимуществом может стать открытая и гибкая Ethernet-архитектура, но фактический результат нужно подтверждать на конкретных коммутаторах, сетевых картах, библиотеках коллективных операций и настройках перегрузки.

Как считать совокупную стоимость владения

Не сравнивайте только цену GPU или сервера. Используйте формулу:

TCO за период = оборудование + сеть + хранилище + лицензии + миграция + эксплуатация + энергия и охлаждение + стоимость простоев.

В расчёт следует включить:

• серверные узлы и ускорители;
• коммутаторы, сетевые карты, кабели и резервные компоненты;
• локальное и общее хранилище;
• поддержку программного стека;
• зарплату инженеров, которые будут сопровождать ROCm или CUDA;
• адаптацию контейнеров и кастомных ядер;
• время на обучение команды;
• энергопотребление при реальной, а не паспортной загрузке;
• стоимость задержки запуска;
• потери от недоступности сервиса во время миграции.

У AMD может быть привлекательная экономика на уровне оборудования, но её нужно сравнивать с затратами на адаптацию и эксплуатацию. У NVIDIA часть стоимости может быть выше из-за программной подписки, инфраструктурных компонентов или зависимости от конкретной цепочки поставок, но запуск существующего CUDA-сервиса часто требует меньше изменений.

Практический показатель — стоимость миллиона успешных запросов при заданном SLA. Он полезнее, чем стоимость одного ускорителя:

стоимость запроса = месячная стоимость кластера / число успешных запросов за месяц.

Если при этом AMD показывает меньшую стоимость запроса, но значительно больший процент ошибок или более длинный p99, сравнение нельзя считать завершённым.

План миграционного пилота с NVIDIA на AMD

Для существующего CUDA-проекта используйте поэтапную схему.

1. Составьте реестр зависимостей. Отдельно отметьте PyTorch, CUDA-ядра, библиотеки внимания, сервер инференса, плагины, мониторинг и контейнеры.
2. Выделите одну модель и один API. Не переносите сразу весь парк сервисов.
3. Соберите воспроизводимый контейнер. Зафиксируйте версии, переменные окружения и команды запуска.
4. Проверьте функциональную эквивалентность. Ответы, форматы, таймауты и обработка ошибок должны совпадать.
5. Сравните производительность на реальных запросах. Не используйте только vendor benchmark.
6. Добавьте смешанную нагрузку. Объедините обычные запросы, длинный контекст, RAG и Agent-вызовы.
7. Запустите теневой трафик. AMD-сервис получает копию запросов, но не влияет на пользовательский ответ.
8. Переведите небольшой процент трафика. Установите критерии отката заранее.
9. Проверьте обновление и восстановление. Успешный пилот должен включать не только запуск, но и эксплуатационный цикл.
10. Примите решение по классу нагрузки. Возможно, AMD будет выгоден для batch-инференса, а NVIDIA останется для latency-sensitive сервисов.

Такой подход снижает риск и не заставляет компанию выбирать между полным отказом от NVIDIA и полной зависимостью от неё.

Как использовать Mac для проверки клиентской части

Mac не заменяет серверный GPU-кластер, но удобен как отдельная среда для проверки того, что часто ломается вне самого инференса: API-клиенты, Agent-логика, SSH-доступ, переменные окружения, вебхуки, CI/CD и обработка ошибок.

Рабочий сценарий можно организовать так:

1. На Mac хранится клиентский код и тестовые сценарии без производственных секретов.
2. Через SSH или защищённый удалённый доступ выполняется подключение к AMD- и NVIDIA-средам.
3. Один и тот же набор запросов отправляется на два endpoint.
4. Результаты сохраняются в едином формате.
5. Различия в токенизации, таймаутах, потоковой выдаче и ошибках фиксируются отдельно от GPU-метрик.
6. После изменения контейнера повторяется тот же тестовый набор.

Для изолированной разработки и проверки Agent-сценариев можно использовать удалённую среду Mac для технических пилотов. Если нужно заранее оценить период тестирования, параметры доступа и формат оплаты, полезно посмотреть условия и тарифы аренды Mac. Ранее опубликованный материал о тестировании кластерных сценариев через Thunderbolt 5 также помогает отделить локальную разработку от серверного эксперимента.

Важно: Mac в этом процессе отвечает за разработку и валидацию клиентского контура. Решение о закупке AMD или NVIDIA должно основываться на серверном тесте с целевыми ускорителями, сетью и рабочим SLA.

Самые дорогие ошибки при выборе платформы

Ошибка 1 — переносить vendor benchmark в свой SLA. Результат производителя может использовать другой размер батча, длину контекста, тип квантования и версию сервера.

Ошибка 2 — считать совместимость по импорту библиотеки. Успешный запуск PyTorch ничего не говорит о кастомных ядрах, памяти, p99 и восстановлении.

Ошибка 3 — забывать про команду. Если у вас нет специалистов по ROCm, это не запрещает AMD, но стоимость поддержки нужно заложить в TCO.

Ошибка 4 — тестировать только одну модель. Платформа может хорошо работать с одной архитектурой и плохо — с другой из-за оператора, квантования или механизма внимания.

Ошибка 5 — не проверять сеть. При масштабировании задержка межузлового обмена может стать основным ограничением раньше, чем вычислительная мощность GPU.

Ошибка 6 — выбирать единую платформу слишком рано. Гибридная схема иногда разумнее: NVIDIA для критичных CUDA-зависимых сервисов, AMD для новых или пакетных задач после подтверждённого пилота.

Итоговая рекомендация

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

AMD может дать более привлекательную стратегию диверсификации и конкурентную экономику, но только при дисциплинированной проверке ROCm, контейнеров, сетевой схемы и эксплуатационных процедур. Поэтому для большинства компаний разумнее начинать не с крупной закупки, а с ограниченного пилота на реальном API и реальном графике запросов. Если ваша команда пока не готова приобретать большой кластер, но уже должна проверить Agent-логику, интерфейсы и кроссплатформенную разработку, аренда Mac в ZovCloud позволит отделить безопасный этап разработки от дорогостоящего решения о серверной инфраструктуре.