NVIDIA CUDA или AMD ROCm для локального ИИ в 2026 году?

Для большинства команд, которые разворачивают локальный ИИ в 2026 году, NVIDIA CUDA остается менее рискованным выбором. AMD ROCm стоит брать не из симпатии к открытому стеку и не ради красивой цены ускорителя, а когда конкретные модели, версии библиотек и режимы нагрузки уже проверены на конкретной AMD GPU. Если такой проверки нет, разницу в цене быстро съедают часы инженеров.

Это не означает, что ROCm годится только для экспериментов. PyTorch давно работает с HIP, vLLM выпускает сборки для ROCm, а llama.cpp поддерживает HIP наряду с CUDA. Разрыв теперь не в наличии базовой функции, а в ширине проверенных комбинаций, скорости появления новых ядер и количестве неприятных исключений. Выбор следует начинать с рабочей нагрузки и памяти, затем считать энергию и сопровождение, и лишь потом сравнивать цену серверов.

Выбор определяется рабочей нагрузкой

CUDA подходит как исходный вариант, если команда обучает модели, часто меняет архитектуры, использует свежие методы квантования или хочет запускать чужие репозитории без отдельного проекта по портированию. У этого решения больше готовых бинарных пакетов, примеров и контейнеров. Когда в репозитории написано только pip install, автор чаще всего проверял именно CUDA, даже если чистый PyTorch-код способен работать через HIP.

ROCm имеет смысл, когда нагрузка стабильна и укладывается в официальную матрицу совместимости. Хороший кандидат выглядит так: Linux зафиксированной версии, поддерживаемая AMD GPU, одна или две модели, известный формат весов, измеримый профиль запросов и команда, готовая держать собственный образ контейнера. В таком контуре более подходящий объем памяти или конфигурация сервера может перевесить неудобства программного стека.

Не смешивайте три разных решения. Первое решение касается разработки и обучения в PyTorch. Второе касается высоконагруженной выдачи через vLLM. Третье касается компактного локального запуска квантованных GGUF-моделей через llama.cpp. Один производитель GPU может выиграть в первом сценарии и проиграть в третьем, поэтому фраза «нам нужна платформа для ИИ» слишком расплывчата для закупки.

Я использую короткую развилку:

1. Для исследовательской команды с меняющимся кодом выбираю CUDA, если нет жесткого ограничения по поставке или памяти.
2. Для стабильного сервиса на vLLM рассматриваю ROCm только после теста нужной модели, квантования и параллелизма.
3. Для автономного помощника на llama.cpp сравниваю конкретные GPU по памяти, скорости и мощности, потому что разрыв между платформами здесь меньше.
4. Для смешанного парка считаю стоимость двух наборов образов, мониторинга и компетенций. Она часто выше выгоды от гибкости закупок.

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

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

PyTorch скрывает различия только на уровне Python

Обычный код PyTorch часто не требует правок при переходе с CUDA на ROCm. Документация PyTorch прямо говорит, что HIP-сборка сохраняет интерфейсы torch.cuda: устройство по-прежнему задается как cuda, а torch.cuda.is_available() работает для обоих стеков. Это удачное инженерное решение, но из него делают слишком широкий вывод о полной взаимозаменяемости.

Проблемы начинаются ниже Python API. Пользовательское CUDA-расширение, новый оператор Triton, fused-ядро из репозитория модели или редкий режим torch.compile может иметь отдельную реализацию для HIP, отставать по версии или собираться только из исходников. Само слово cuda в коде не доказывает привязку к NVIDIA, а наличие общего API не доказывает равную поддержку каждого ядра. Это различие команда обязана понимать до покупки.

Проверка бэкенда должна быть частью диагностики, а не догадкой по имени устройства:

import torch

if not torch.cuda.is_available():
    raise RuntimeError("GPU backend is unavailable")

backend = "rocm" if torch.version.hip else "cuda"
print({
    "backend": backend,
    "torch": torch.__version__,
    "cuda_runtime": torch.version.cuda,
    "hip_runtime": torch.version.hip,
    "device": torch.cuda.get_device_name(0),
})

На CUDA результат содержит версию в cuda_runtime и None в hip_runtime. На ROCm картина обратная. Сохраните этот словарь рядом с результатом каждого теста. Без него фраза «на стенде все работало» бесполезна после обновления драйвера.

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

CUDA выигрывает там, где исследователи постоянно приносят новый код. ROCm способен дать нормальный результат на известном наборе операторов, но команда должна относиться к матрице GPU, ОС и версии ROCm как к контракту. AMD публикует такую матрицу отдельно для вычислительных ускорителей и отдельно для Radeon. Запуск на GPU вне списка может получиться, однако неподдерживаемый эксперимент нельзя превращать в производственный SLA.

vLLM требует зафиксировать всю цепочку версий

Для vLLM в 2026 году доступны и CUDA, и ROCm, но удобство установки и ширина комбинаций различаются. Текущая документация vLLM указывает Linux как основную ОС, CUDA GPU с подходящей compute capability и ограниченный перечень архитектур AMD. Для ROCm проект публикует готовые колеса только под определенные версии ROCm и Python, а несовпадающая сборка PyTorch может потребовать сборки vLLM из исходников.

Это не мелкая неприятность установщика. vLLM компилирует много специализированных ядер, поэтому бинарная совместимость зависит от версии PyTorch, драйвера, runtime и параметров сборки. На CUDA тоже можно получить конфликт, если поставить пакет поверх случайного окружения. Разница в том, что для распространенных CUDA-конфигураций готовая дорога обычно шире, а для ROCm быстрее приходится владеть всей сборочной цепочкой.

Я не принимаю сервер vLLM после одного ответа API. Приемочный прогон должен охватывать:

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

Проверяйте наличие конкретного метода квантования в матрице vLLM. Поддержка AMD в заголовке проекта не означает, что AWQ, GPTQ, FP8 и любая новая схема одинаково работают на каждой архитектуре. Особенно опасна закупка под обещание «добавят в следующем релизе». В приемке учитывается только версия, которую можно установить и воспроизвести сейчас.

Контейнер фиксируйте по неизменяемому идентификатору, а не по тегу latest. Рядом храните драйвер хоста, версию микропрограммы, аргументы запуска и небольшой набор контрольных запросов. После обновления сравнивайте не только токены в секунду, но и время до первого токена, хвостовую задержку, пиковую память и долю неуспешных запросов.

Практический вывод прямой: если vLLM составляет основу внутреннего API и команда хочет быстро брать новые модели, CUDA требует меньше оговорок. ROCm можно выбрать для зафиксированного сервиса, когда тест показывает нужную производительность, а образ уже собирается без ручных исправлений. Покупать AMD GPU, а потом выяснять, какая версия Triton собирается на ней сегодня, означает переложить архитектурное решение на дежурного инженера.

llama.cpp заметно сокращает разрыв

llama.cpp лучше подходит для сравнения самих GPU, потому что проект контролирует большую часть пути выполнения и поддерживает несколько бэкендов. CUDA собирается через GGML_CUDA, а ROCm через GGML_HIP. Квантованные файлы GGUF можно переносить между машинами, хотя оптимальные параметры и скорость будут отличаться.

Минимальная проверка выглядит одинаково прозрачно:

# NVIDIA
cmake -S . -B build-cuda -G Ninja -DGGML_CUDA=ON
ninja -C build-cuda

# AMD
cmake -S . -B build-hip -G Ninja -DGGML_HIP=ON
ninja -C build-hip

После сборки прогоните один и тот же файл GGUF с одинаковыми -c, -b, числом потоков CPU и значением -ngl. Запишите вывод встроенного замера отдельно для обработки промпта и генерации. Один общий показатель скрывает важную разницу: GPU может быстро переваривать длинный промпт, но давать скромную скорость последовательной генерации, или наоборот.

Не считайте поддержку нескольких GPU бесплатным удвоением скорости. Матрица функций llama.cpp поясняет, что бэкенды способны использовать несколько устройств, а CUDA-код, который переводится для ROCm через HIP, умеет делить строки между GPU. Этот режим приносит пользу при достаточно быстрой связи, а не при любой паре карт. Через обычные линии PCIe задержка обмена и неравномерная загрузка могут испортить красивую арифметику суммарной памяти.

llama.cpp также предлагает Vulkan, но его следует оценивать как отдельный бэкенд. Он полезен для переносимости и некоторых настольных конфигураций, однако наличие Vulkan не превращает неподдерживаемую ROCm GPU в эквивалент поддерживаемого вычислительного ускорителя. Если нужен обслуживаемый сервер, выбирайте тот путь, для которого команда может воспроизвести сборку и получить диагностику.

Для небольшого числа пользователей, фиксированной GGUF-модели и одной GPU AMD может оказаться вполне разумной. Здесь объем памяти нередко важнее доступа к самому свежему fused-ядру. Если тот же сервер должен завтра перейти на vLLM, обучать адаптеры и принимать экспериментальные модели, преимущество llama.cpp нельзя переносить на весь стек.

Память нужно считать до выбора модели GPU

Для локального ИИ объем видеопамяти задает предел раньше, чем пиковые терафлопсы. Если модель не помещается вместе с KV-кэшем и рабочими буферами, команда будет выгружать слои в оперативную память, сокращать контекст или делить нагрузку между GPU. Каждый такой выход меняет задержку, энергопотребление и сложность.

Начните с веса модели. Грубая нижняя оценка равна числу параметров, умноженному на байты одного параметра: около двух байт для FP16 или BF16, одного для 8 бит и половины байта для 4 бит. Реальный файл и размещение занимают больше из-за метаданных, шкал квантования, выравнивания и временных буферов. Поэтому 70-миллиардная модель в 4 битах имеет около 35 ГБ только сырых весов, а практический бюджет должен быть выше.

Второй потребитель памяти, KV-кэш, растет с контекстом и числом одновременных последовательностей. Для обычного multi-head attention порядок величины можно проверить формулой:

KV bytes ≈ 2 × layers × hidden_size × bytes_per_value × tokens × sequences

Множитель два учитывает ключи и значения. В моделях с grouped-query attention размер зависит от числа KV-голов и получается меньше, поэтому берите конфигурацию самой модели, а не универсальный калькулятор из чужой заметки. vLLM также резервирует память под выполнение и управляет блоками кэша, так что совпадение арифметической суммы с паспортным объемом GPU еще не гарантирует запуск.

Оставляйте запас под пик, а не только под состояние после загрузки. Для сервиса полезно измерить память при самом длинном разрешенном запросе и максимальной параллельности. Для обучения к весам добавляются градиенты, состояния оптимизатора и активации; потребность может многократно превысить размер файла весов. Квантованная инференс-конфигурация на 24 ГБ ничего не говорит о возможности дообучения той же модели.

Сравнивать CUDA и ROCm по памяти следует на уровне доступных конфигураций сервера. Одна GPU достаточного объема почти всегда проще пары меньших GPU: меньше обмена, меньше точек отказа и предсказуемее задержка. Если AMD-конфигурация дает нужный объем на одном поддерживаемом ускорителе, это весомый аргумент. Если ради экономии приходится брать неподдерживаемую настольную карту и прятать ограничения за выгрузкой на CPU, экономия существует только в смете закупки.

Энергопотребление измеряется работой, а не TDP

Паспортная мощность GPU не равна расходу всего сервера. В счет входят CPU, память, накопители, вентиляторы, блоки питания и потери преобразования. TDP или power limit помогает оценить охлаждение и верхнюю границу, но не отвечает, сколько энергии уйдет на миллион токенов или ночное дообучение.

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

energy_kWh = average_power_W × duration_hours / 1000

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

Утилиты nvidia-smi и amd-smi дают телеметрию устройства, но для сравнения серверов нужен внешний измеритель или данные управляемого блока питания. Программный датчик GPU не видит остальную систему. Сверяйте оба источника: первый помогает найти троттлинг и неравномерную загрузку, второй показывает то, за что организация платит.

Ограничение мощности часто дает лучший результат на ватт, но его надо тестировать на нужной задержке. Уменьшение лимита, которое экономит 15 процентов мощности и удлиняет ответ на 40 процентов, повышает энергию на запрос. Я не использую такие проценты как прогноз для другой GPU, это пример того, почему считать надо произведение мощности на время.

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

Настольная GPU и серверный ускоритель решают разные задачи

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

Для ROCm граница между «запускается» и «официально поддерживается» особенно важна. Матрица AMD перечисляет сочетания GPU, ОС и версий ROCm для вычислительных нагрузок, а Radeon имеет отдельные условия. Переменная окружения или неофициальный патч иногда заставляет программу увидеть другую архитектуру, но такой прием не добавляет тестирование производителя, запасные части или предсказуемое обновление. Для лаборатории это допустимый эксперимент. Для сервиса с обязательным временем восстановления это технический долг с первого дня.

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

Windows подходит для рабочих станций и llama.cpp, если именно этот путь прошел тест. vLLM в своей основной документации ориентируется на Linux и не заявляет нативный Windows как основной производственный путь. WSL и сторонние сборки полезны разработчику, но добавляют слой, который придется обновлять и диагностировать. Я не закладываю их в серверный проект без отдельного владельца и приемочного теста.

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

Часы сопровождения способны отменить экономию

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

Типичный сбой развивается предсказуемо. Команда проверяет PyTorch на рабочей станции и видит доступную GPU. Затем ставит vLLM в существующее окружение, где версия PyTorch не совпадает с той, под которую собраны ядра. Пакет либо падает при импорте, либо требует сборки. Во время сборки выясняется, что версия ROCm не соответствует образу, а обновление ROCm требует другой поддерживаемой версии ОС. Один несовпавший пакет превращается в изменение хоста.

На CUDA похожая цепочка начинается со слишком старого драйвера или случайной смеси библиотек. Документация NVIDIA описывает обратную совместимость новых драйверов со старыми CUDA-приложениями и ограниченную совместимость внутри основной ветки toolkit, но это не разрешение смешивать любые версии. PTX JIT, новые функции драйвера и динамические библиотеки создают исключения. Контейнер не заменяет драйвер ядра на хосте.

Считайте трудозатраты в часах на месяц по четырем работам:

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

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

Для небольших команд CUDA обычно дешевле сопровождать, даже когда оборудование дороже. Для команды, которая уже эксплуатирует Linux-кластеры на AMD, умеет собирать ядра и держит узкий каталог моделей, ROCm не создает тех же накладных расходов. Компетенция меняет экономику, поэтому чужой расчет совокупной стоимости нельзя вставить в свою закупку.

Запишите стоимость сопровождения в той же таблице, где стоят оборудование и электричество. Умножьте часы плановых обновлений на внутреннюю стоимость инженера, добавьте ожидаемое время проверки каждой новой модели и резерв на внеплановый сбой. Не нужно придумывать точность до тенге: диапазон с честными допущениями полезнее нуля, который появляется потому, что труд штатной команды ошибочно считают бесплатным.

Пилот должен закончиться протоколом приемки

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

Протокол должен содержать модель GPU, объем памяти, версии ОС, драйвера, runtime, PyTorch, vLLM или коммит llama.cpp, формат весов и все аргументы запуска. Приложите исходные результаты: задержку первого токена, устойчивую скорость, пиковую память, среднюю мощность со стены и ошибки. Среднее без худшего наблюдаемого результата скрывает именно тот сбой, который увидит пользователь.

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

Заранее задайте проходные условия. Например: модель загружается после чистого развертывания; контрольные ответы не содержат поврежденных токенов; сервис выдерживает нужную параллельность без выхода за память; перезапуск восстанавливает работу; предыдущий образ откатывается без переустановки хоста. Числа зависят от вашего сервиса, но формулировки должны допускать однозначное «да» или «нет».

Не меняйте сразу две переменные. Если CUDA-кандидат работает с FP8, а ROCm-кандидат с 4-битным GGUF, вы сравниваете разные модели обслуживания. Сначала добейтесь одинакового формата и движка. Затем отдельно изучите оптимальную конфигурацию каждой платформы и честно отметьте, какие различия меняют качество ответа.

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

CUDA остается вариантом по умолчанию, ROCm требует причины

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

Выбирайте AMD ROCm, если конкретная поддерживаемая GPU дает заметное преимущество по памяти или конфигурации, нагрузка зафиксирована, Linux-стек входит в официальную матрицу, а пилот подтвердил нужные функции. ROCm особенно уместен, когда организация уже владеет сборочной цепочкой и хочет снизить зависимость от одного поставщика. Независимость требует второго набора компетенций, иначе она остается строкой в презентации.

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

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