ROCm и Vulkan для локального запуска LLM на GPU AMD: руководство на 2026 год

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

При локальном размещении LLM эти два бэкенда находятся на разных уровнях стека. ROCm — это вычислительная платформа AMD под PyTorch, vLLM и SGLang, тогда как Vulkan — переносимый API GPU, который движки уровня llama.cpp используют для запуска квантованных моделей на широком спектре оборудования.

Это руководство сравнивает два бэкенда по каждому движку — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI и LocalAI — с командами сборки, проверками устройств и режимами отказа, которые маскируются под проблемы производительности. Если вы только знакомитесь с ландшастом хостинга, начните с обзора размещения LLM, где описаны семейства инструментов, которые мы подробно разбираем в этой статье.

ROCm против Vulkan: краткий ответ

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

Что такое ROCm и Vulkan на самом деле

ROCm — это вычислительная платформа

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

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

ROCm 10.0.0, выпущенная 26 августа 2026 года, построена на TheRock (система сборки и релизов AMD с ROCm 7.14), валидирует PyTorch 2.13, vLLM 0.27 и SGLang 0.5.15 и официально добавляет поддержку RDNA 4 для gfx1200 (RX 9060/9060 XT/9050) и gfx1201 (RX 9070/9070 XT/9070 GRE, серия Radeon AI PRO R9700). Матрица совместимости ROCm по-прежнему является авторитетным источником для точной комбинации GPU и операционной системы, а не форумное сообщение, которое случайно использует то же маркетинговое семейство.

Vulkan — переносимый интерфейс GPU

Vulkan — это API графики и вычислений, реализованный драйвером GPU. При локальном размещении LLM это обычно означает, что движок инференса поставляется или компилируется с вычислительными шейдерами, которые выполняются через реализацию Vulkan, такую как Mesa RADV на Linux или драйвер вендора на Windows.

Vulkan не предоставляет «out-of-the-box» платформу PyTorch, сравнимую с ROCm. Его практическая сила уже, но полезна: движок уровня llama.cpp может использовать один и тот же дизайн бэкенда на AMD, Intel, Nvidia и другом поддерживающем Vulkan оборудовании без установки специфичного для вендора стека машинного обучения.

Это различие объясняет большинство решений. Если приложение предлагает только путь через HIP или PyTorch, Vulkan не в состоянии его спасти; если же приложение уже основано на llama.cpp и GGUF, установка всего стека ROCm может решить проблему, которой у вас не было.

Матрица поддержки движков в 2026 году

ROCm не подразумевает Safetensors, и Vulkan не формально подразумевает GGUF. Полезная связь исходит от движков: llama.cpp может читать один и тот же GGUF как со своей HIP-, так и с Vulkan-сборкой, тогда как серверы, нативные для PyTorch, используют ROCm и обычно потребляют репозитории моделей Hugging Face.

Это делает инвентарь моделей архитектурным ограничением. Библиотека тщательно выбранных GGUF-квантований естественно указывает на llama-server, Ollama, LM Studio или LocalAI; развертывание, построенное вокруг тензорного параллелизма, непрерывного батчинга и нативных для фреймворка весов, указывает на ROCm с vLLM или SGLang. Для более широкого ландшафта движков за пределами бэкендов AMD — зрелость API, вызов инструментов и готовность к продакшену в дюжине инструментов — см. наше сравнение Ollama, vLLM, LM Studio, LocalAI и других инструментов локального размещения LLM.

llama.cpp: самое чистое сравнение ROCm и Vulkan

llama.cpp открывает доступ к обоим бэкендам без изменения файла модели или HTTP-клиента. Это самое честное место для сравнения ROCm и Vulkan, так как токенизатор, параметры сэмплинга, шаблон чата, квантование и поведение сервера могут остаться фиксированными.

Текущая документация по сборке llama.cpp использует GGML_HIP для ROCm и GGML_VULKAN для Vulkan. Старым статьям, рекомендующим GGML_ROCM или удаленные флаги Makefile, не следует доверять без проверки текущих опций CMake проекта.

Сборка Vulkan-бэкенда на Ubuntu

Установите заголовки Vulkan, компилятор шейдеров и заголовки SPIR-V, затем убедитесь, что драйвер может перечислить целевой GPU:

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

На системе с гибридным iGPU и дискретным GPU заслуживает внимания порядок перечисления. GGML_VK_VISIBLE_DEVICES может ограничить llama.cpp конкретным устройством Vulkan, и в стартовом логе должно быть указано имя выбранной карты, а не просто сообщено о наличии устройства Vulkan.

Сборка бэкенда ROCm или HIP

Сначала убедитесь, что ROCm идентифицирует GPU и сообщает ожидаемую цель gfx. Целевую карту можно опустить, чтобы собирать для GPU в текущей системе, но ее закрепление уменьшает работу компиляции, если вы знаете оборудование развертывания.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

Замените gfx1201 на целевое значение, сообщенное для фактической карты — это значение соответствует RX 9070/9070 XT/9070 GRE и серии Radeon AI PRO R9700 в RDNA 4, тогда как gfx1200 покрывает серию RX 9060, а gfx1100/gfx1101/gfx1102 покрывают линейки RX 7900/7800/7700/7600 в RDNA 3. Не копируйте HSA_OVERRIDE_GFX_VERSION в производственный сервис только потому, что это помогло кому-то загрузить неподдерживаемый GPU; переопределение может позволить загрузить код, но оно не превращает это оборудование в валидированную платформу.

Бенчмаркируйте одну и ту же нагрузку, а не два дефолта

Используйте один файл GGUF, одни и те же настройки flash-attention, один и тот же оффлоад слоев и повторяющиеся запуски. Обработка промпта (pp) и генерация токенов (tg) нагружают систему по-разному, при этом сервер с длинным контекстом также добавляет аллокацию KV-кэша и давление на память, которые короткий синтетический бенчмарк упустит.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

Результаты сообщества иллюстрируют, почему универсальный победитель вводит в заблуждение, и цель RDNA 4 gfx1201 — самый ясный недавний пример. В одной отправке на RX 9070 XT в той же машине Vulkan достиг примерно 143 токенов/с против 128 токенов/с у ROCm в тесте генерации 7B Q4_0, но последующие отправки показали меньшие разницы по мере изменения сборок; обсуждения Vulkan и ROCm также содержат значительные различия в результатах обработки промпта и условиях тестирования. Отдельное, более детальное выполнение OpenBenchmarking.org на RX 9070 XT с llama.cpp b6401 показало, что Vulkan впереди на декодировании в нескольких моделях класса 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0), но позади HIP при обработке промпта на более длинных длинах промпта — два бэкенда меняются местами в зависимости от того, какую фазу вы измеряете.

Разрыв может также пойти в другую сторону, и сильно, для конкретных форм моделей. Открытая проблема llama.cpp документирует, что Vulkan на gfx1201 становится в 4,7–6,7 раз медленнее, чем HIP, при генерации токенов, когда скрытый размер модели достигает 4096 или более (эффективная пропускная способность декодирования падает примерно до 70–100 ГБ/с на карте с 640 ГБ/с), тогда как более маленькая модель 4B со скрытым размером 2560 не показывает такой регрессии ни на одном из бэкендов. Относитесь к каждому числу здесь как к снимку одной сборки, одного драйвера и одной формы модели — а не как к правилу, которое обобщается на тип квантования, архитектуру модели, flash attention, размеры батчей, версию драйвера, тепловое состояние или коммит llama.cpp.

Ollama на AMD: удобно, но проверяйте бэкенд

Ollama официально поддерживает перечисленные GPU AMD через ROCm и теперь документирует дополнительный охват AMD через Vulkan на Windows и Linux. Ее текущая страница поддержки оборудования говорит, что Vulkan включен по умолчанию, если бэкенд установлен, поддерживает GGML_VK_VISIBLE_DEVICES для выбора устройства и может отключать Vulkan с помощью OLLAMA_VULKAN=0.

Это значимое улучшение по сравнению с периодом, когда совет по Vulkan зависел от экспериментальных сборок. Это также делает некоторые старые учебники устаревшими: установка недокументированного переключателя и предположение, что служба выбрала Vulkan, — более слабое доказательство, чем чтение журнала сервера.

sudo systemctl edit ollama

Для диагностики добавьте drop-in, а не экспортируйте переменные только в интерактивной оболочке:

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Затем перезагрузите, перезапустите и проверьте как расположение процессов, так и сообщения об обнаружении:

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

Ищите указанное GPU, выбранную библиотеку, аллокацию модели и процент GPU. Лог, показывающий тайм-аут обнаружения, за которым следует успешный HTTP-ответ, может означать, что Ollama молча переключился на CPU. Для повседневного набора команд вокруг этого сервиса шпаргалка по Ollama CLI — более быстрый справочник.

Ollama превосходна, когда получение модели и стабильный локальный API важнее, чем контроль бэкенда. Если цель — повторяемые тесты ROCm против Vulkan, «голый» llama-server — лучший инструмент, так как каталог сборки делает бэкенд явным.

vLLM и SGLang делают ROCm выбором — но сначала проверьте покрытие ядер для семейства GPU

vLLM и SGLang не являются приложениями Vulkan. Их пути на AMD опираются на ROCm, PyTorch и оптимизированные HIP-ядра, поэтому выбор одного из этих движков уже выбрал вычислительную платформу.

Текущее руководство vLLM на ROCm от AMD рекомендует предсозданный контейнер и публикует согласованные образы для ROCm, PyTorch, Python и vLLM. Эта связь полезна: она заменяет крупное упражнение по разрешению зависимостей версионированным элементом развертывания.

На момент написания AMD документирует этот образ ROCm 10 для vLLM 0.27:

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

Используйте образ, выбранный для точного семейства GPU в документации AMD; образы RDNA и CDNA не всегда взаимозаменяемы. Для производственного сервера закрепите полный тег или дайджест и валидируйте драйвер хоста, прежде чем винить vLLM в сбое инициализации.

Совершенно новые поколения GPU — самый острый граничный случай, и RDNA 4 является реальным, задокументированным примером, а не теоретическим риском. Независимое тестирование на RX 9070 XT (gfx1201) в начале 2026 года показало, что vLLM на ROCm 7.2 молча переключается на де-квантование FP32 для весов модели FP8 — потому что gfx1201 еще не было распознано в детектировании платформы vLLM — что полностью обошло матричные ускорители GPU и дало лишь 48 токенов/с, в отличие от 62 токенов/с от llama-server на Vulkan, работающего с GGUF-квантованием сопоставимой модели на той же карте. Урок обобщается: стек ROCm/PyTorch может успешно загрузиться на новой архитектуре и при этом работать в оптимизированном fallback-пути без сообщения об ошибке. Всегда подтверждайте, какой путь ядра фактически выполнялся (через rocprof, заметки профилирования вендора или известную хорошую базовую пропускную способность для GPU), прежде чем доверять единственному результату «он стартовал нормально» на оборудовании, выпущенном в пределах последних одного-двух циклов релизов.

Причина принять более крупную операционную поверхность ROCm, когда покрытие ядер подтверждено, — это архитектура пропускной способности, а не просто несколько дополнительных токенов/с в тесте одиночного пользователя. Непрерывный батчинг, квантование, нативное для фреймворка, тензорный параллелизм, поведение планировщика и окружающий инструментарий PyTorch — это реальный случай для перехода на vLLM, и если вы взвешиваете, оправдан ли этот переход вообще, наш гид по миграции с Ollama на vLLM перечисляет сигналы нагрузки.

TGI: поддержка ROCm с более узкой целью

Hugging Face документирует образ AMD для Text Generation Inference, но его опубликованная валидация сосредоточена на оборудовании Instinct MI210, MI250 и MI300. Руководство TGI для AMD использует образ 3.3.5-rocm и перечисляет неподдерживаемые функции ROCm, поэтому его не следует обобщать как обещание для каждой карты Radeon. Наш гайд по установке TGI подробно покрывает настройку этого образа ROCm.

Не существует пути Vulkan для TGI, с которым можно было бы сравнить. Если TGI — фиксированное требование, выберите поддерживаемое оборудование ROCm и воспроизведите задокументированный контейнер; если движок обсуждаем, текущая поддержка vLLM и SGLang заслуживает оценки перед началом нового развертывания на AMD.

LM Studio: переключайте рантаймы вместо пересборки

LM Studio упаковывает несколько рантаймов инференса и открывает управление рантаймами через команду lms. Ее документация по рантаймам поддерживает перечисление, загрузку, выбор, обновление и удаление рантаймов, что делает эксперименты ROCm против Vulkan доступными без поддержки отдельных исходных деревьев.

lms runtime ls
lms runtime get
lms runtime select

Запустите один и тот же GGUF с той же длиной контекста, оффлоадом на GPU, настройкой flash-attention и промптом. Сравнивайте время до первого токена, скорость генерации, время загрузки и пиковую память, а не судите о бэкенде по одному короткому ответу чата.

Упаковка рантаймов не устраняет специфичные для бэкенда дефекты. Например, проблема LM Studio 2026 года на R9700 сообщала о зависании большой модели в конце загрузки ROCm, тогда как рантайм Vulkan загрузил ее, тогда как отдельная проблема с запасом памяти Vulkan описывала противоположный результат при заполнении VRAM. Это индивидуальные отчеты, но вместе они делают правильный операционный вывод: держите запасной рантайм и оставляйте запас памяти.

LocalAI: выбирайте образ так же, как и бэкенд

LocalAI предоставляет отдельные варианты контейнеров ROCm или hipblas и Vulkan. Ее руководство по ускорению GPU документирует образы gpu-hipblas для вычислений AMD и образы gpu-vulkan для переносимого пути, поэтому тег контейнера, скопированный из гайда по CUDA, не обнаружит правильный бэкенд «в автоматическом режиме». Быстрый старт LocalAI покрывает общую настройку; специфичный для бэкенда выбор контейнера — это то, что добавляет этот раздел.

Контейнеру ROCm нужны /dev/kfd и /dev/dri, тогда как Vulkan обычно нужно соответствующее устройство рендера под /dev/dri. Закрепите тег релиза для реального сервиса; latest и master полезны для диагностики, но делают откат и сравнение производительности необоснованно расплывчатыми.

# Образ ROCm или HIP
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Образ Vulkan
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

Примеры тегов отражают документацию, доступную на момент публикации; подтвердите текущие имена реестра перед автоматизацией загрузки. Что более важно, не выводите ускорение только по имени контейнера — проверьте отладочный лог LocalAI и наблюдайте за использованием GPU во время запроса.

Что изменилось в упаковке ROCm 10

ROCm 10 — это не просто очередное незначительное обновление пакета. Гид по переходу на TheRock от AMD говорит, что пакеты ROCm Core SDK теперь используют префикс amdrocm-, корневой каталог установки с версией — /opt/rocm/core-10.0, и несколько устаревших пакетов были объединены.

Именно поэтому команда из старой статьи ROCm может возвращать «пакет не найден» даже в правильно настроенном репозитории. Например, HIPCC теперь поставляется из amdrocm-llvm, компоненты BLAS объединены в amdrocm-blas, и полная системная установка может использовать мета-пакет Core SDK для всех архитектур или специфичный для семейства GPU — карты RDNA 4 используют семейный тег gfx120X-all (суффикс пакета -gfx1200-gfx1201), о чем стоит знать, прежде чем отправляться искать имя пакета только для gfx1201, которое не существует.

Мета-пакет amdrocm настраивает альтернативы и совместимые символьные ссылки под /opt/rocm. Минимальная или кастомная установка может не предоставлять те же пути, поэтому сценарии сборки, которые хардкодят /opt/rocm/bin/hipcc, должны либо использовать hipconfig, либо явно устанавливать ROCM_PATH.

Два изменения диагностики легко пропустить. ROCm SMI было удалено в пользу AMD SMI, и ROCm Bandwidth Test достиг конца поддержки; сценарии, вызывающие rocm-smi или rocm-bandwidth-test, должны перейти на amd-smi и инструменты замены от AMD, а не переустанавливать произвольные устаревшие пакеты.

Контейнеры по-прежнему зависят от хоста

Контейнер ROCm несет библиотеки пользовательского пространства, а не замену ядра драйвера. Хост должен открывать /dev/kfd и /dev/dri, его драйвер должен быть совместим со стеком контейнера, и пользователь сервиса должен иметь разрешение открывать эти устройства.

Контейнеры Vulkan имеют похожую границу вокруг драйвера Vulkan и узла рендера на хосте. Упаковка легче, но неверный ICD, отсутствие членства в группе рендера или случайно выбранный iGPU по-прежнему могут превратить рабочий образ контейнера в сервис, работающий на CPU или нестабильный.

Дискретные GPU, APU и старые карты Radeon

Дискретные GPU RDNA 3 и RDNA 4

Текущие модели Radeon RX 7000, RX 9000 и Radeon AI Pro имеют самый сильный случай для тестирования обоих бэкендов llama.cpp. Поддержка ROCm теперь явна для многих целей gfx110x и gfx120x, тогда как Vulkan через текущий Mesa RADV или драйвер вендора на Windows достаточно зрел, чтобы быть основным путем, а не отчаянной мерой. Для аппаратной стороны этого решения — VRAM, пропускная способность, питание и цены между вендорами — см. наше сравнение GPU для ИИ-нагрузок в 2026 году.

Не превращайте бенчмарк 7B в правило для плотной модели 27B или модели mixture-of-experts. Формы матриц, активные параметры, квантованные ядра, длина промпта и давление на память могут изменить порядок, и производительность бэкендов значительно изменилась между ревизиями llama.cpp — регрессия скрытого размера gfx1201, отмеченная выше, является конкретным случаем именно такого рода сдвига.

APU Ryzen и общая память

Системы с большим объемом памяти Ryzen AI Max необычно интересны, потому что GPU может получить доступ к пулу общей памяти гораздо большего размера, чем предлагает обычная дискретная потребительская карта. ROCm 10 перечисляет текущие семейства Ryzen AI, тогда как рантаймы llama.cpp с поддержкой Vulkan также могут использовать iGPU без создания окружения PyTorch.

Вместимость — это не пропускная способность. То, что модель помещается в 64 ГБ или 96 ГБ выделенной общей памяти, не означает, что она будет декодировать, как дискретная карта с 32 ГБ, и агрессивная аллокация контекста может вызвать голодание операционной системы даже когда приложение сообщает о достаточной памяти GPU. Та же дисциплина бюджета VRAM, которая применяется к дискретным картам NVIDIA и AMD, применяется и здесь — см. [KV Cache на GPU с 16 ГБ](/llm-performance/optimization/kv-cache-16gb-long-context/“Вместите контекст LLM от 32K до 128K в 16 ГБ VRAM, рассчитывая стоимость KV-кэша, выбирая точность кэша и безопасно настраивая llama.cpp, vLLM или Ollama”) для лежащей в основе математики бюджета, которая не зависит от бэкенда.

Машины с гибридным iGPU и dGPU нуждаются в явном выборе устройства. Недавний отчет llama.cpp описывал чрезмерное резервирование системной памяти, когда неиспользуемый iGPU оставался видимым рядом с R9700; это неподтвержденная проблема, но это хорошая причина открывать только то устройство, для которого предназначен сервис.

Старое и неподдерживаемое оборудование Radeon

Vulkan, как правило, является первым путем для старой Radeon, потому что покрытие графических драйверов шире, чем набор поддерживаемых вычислительных целей ROCm. Проекты на основе ROCm также отмечают, что более новые релизы rocBLAS удалили ядра для некоторых старых целей, поэтому принуждение к близлежащему значению gfx не может восстановить код, который больше не поставляется.

Переопределение допустимо для лабораторного эксперимента с четкими ожиданиями сбоев. Это плохая основа для автономного API, потому что следующее обновление ROCm или приложения может заменить терпимое несоответствие сбоем запуска или неверным результатом.

Linux против Windows для бэкендов LLM на AMD

Linux — естественный хост ROCm для продакшен-инференса. Он предлагает самую широкую поддержку движков, устоявшуюся маппинг устройств контейнера, текущие драйверы Vulkan Mesa и операционные инструменты, ожидаемые в развертываниях vLLM и SGLang.

Windows имеет настоящую поддержку ROCm для перечисленного оборудования, но экосистема приложений остается более узкой. Для настольного инференса GGUF через llama.cpp, Ollama или LM Studio Vulkan обычно является более спокойной точкой старта; используйте ROCm, когда приложение предоставляет поддерживаемый путь Windows и конкретная функция или бенчмарк это обосновывает.

WSL2 следует рассматривать как третью платформу, а не синоним нативного Linux. Согласуйте задокументированный драйвер Windows от AMD, дистрибутив WSL, релиз ROCm и пакет фреймворка как одну поддерживаемую комбинацию.

Чек-лист верификации перед обслуживанием трафика

Начните ниже уровня приложения. Если драйвер не может перечислить правильное устройство, изменение флагов модели — лишь переупорядочивание симптома.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# Путь ROCm
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Путь Vulkan
vulkaninfo --summary

Затем проверьте движок. Вывод запуска должен называть ROCm или Vulkan, называть целевой GPU и сообщать, что слои модели или тензоры были размещены на нем; наконец, память и использование GPU должны расти, пока выполняется запрос.

# Наблюдайте за GPU AMD, пока в другом терминале отправляются запросы
watch -n1 amd-smi monitor

# Базовая проверка API, совместимого с OpenAI, для llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Записывайте драйвер, рантайм, коммит движка или дайджест образа, контрольную сумму файла модели, контекст, настройки батчей и командную строку при каждом бенчмарке. Без этих метаданных число токенов в секунду — это анекдот, который не переживет следующее обновление — и как показывают и fallback vLLM на gfx1201, и регрессия скрытого размера Vulkan выше, правдоподобное на вид число может скрывать молча неоимизированный путь кода.

Режимы отказа, похожие на производительность бэкенда

Молчаливый fallback на CPU

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

Молчаливый fallback точности (новое оборудование, новые ядра)

Сервер запускается, использование GPU выглядит разумным, и ошибок нет — но фреймворк молча переключился на неоимизированный числовой путь, потому что способность вычислений или строка архитектуры GPU еще не были распознаны. Именно это произошло с ядрами FP8 vLLM на gfx1201; исправление — проверять код детектирования платформы самого фреймворка или трекер проблем для вашей точной строки GPU перед доверием единственному числу пропускной способности на поколение GPU, выпущенное в пределах последних одного-двух циклов релизов.

Выбрано неверное GPU

Настольный компьютер на Ryzen может открывать iGPU как устройство Vulkan 0, а дискретный Radeon — как устройство 1. Ограничьте видимые устройства и подтвердите полное имя устройства в логе; не предполагайте, что нумерация стабильна после изменения драйвера или BIOS.

Несовпадение цели ROCm

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

Несовпадение драйвера и пользовательского пространства

В контейнере текущие библиотеки ROCm, но драйвер хоста относится к более старому потоку релизов. Тайм-ауты во время обнаружения, ошибки запуска ядра или fallback на CPU более вероятны, чем чистое сообщение, объясняющее границу версий.

Путаница с ICD Vulkan

Установлено более одной реализации Vulkan, и загрузчик выбирает неожиданный ICD. Осмотрите vulkaninfo, удалите случайные дубликаты или явно выберите намеренный ICD и устройство, а не накладывайте другой SDK поверх проблемы.

Оценка VRAM не оставляет операционного запаса

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

Практическая процедура выбора бэкенда

Шаг 1: выберите поведение обслуживания

Если цель — один или два локальных пользователя, файлы GGUF и простой endpoint, совместимый с OpenAI, начните с llama-server, Ollama или LM Studio. Если цель — непрерывный батчинг, высокая конкурентность, модели, нативные для фреймворка, или тензорный параллелизм, начните с vLLM или SGLang и примите ROCm как часть дизайна.

Шаг 2: проверьте официальную поддержку оборудования

Сопоставьте точную цель GPU, версию операционной системы, ядро и драйвер в текущей матрице ROCm. Для Vulkan подтвердите целевой GPU через vulkaninfo и используйте текущий драйвер, а не предполагайте, что наличие libvulkan.so доказывает полезную вычислительную поддержку. Если GPU из самого нового поколения архитектуры, также проверьте код детектирования платформы конкретного фреймворка или открытые проблемы для этой точной цели gfx — официальная поддержка и поддержка оптимизированных ядер не всегда выходят вместе.

Шаг 3: установите простейшую рабочую базовую линию

Для GGUF это обычно Vulkan, так как он меняет меньше системных компонентов. Для движка PyTorch используйте закрепленный контейнер ROCm от AMD, а не собирайте torch, Triton, AITER и vLLM из не связанных последних версий.

Шаг 4: бенчмаркируйте промпты, похожие на продакшен

Измеряйте обработку промпта, время до первого токена, скорость декодирования, пиковую память и поведение при конкурентных запросах. Включите контекст и паттерн вызова инструментов, который будет использовать реальный сервис; микробенчмарк в 128 токенов не предсказывает сессию агента в 100 000 токенов.

Шаг 5: держите запасной вариант развертываемым

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

Та же процедура как поток решений:

Итоговый вердикт: ROCm или Vulkan для размещения LLM на AMD?

Vulkan является лучшим дефолтом для локального инференса GGUF, когда важны переносимость, скорость настройки, поддержка Windows или покрытие старых Radeon. Больше не разумно описывать его как inherently медленный; на некоторых последних комбинациях Radeon и llama.cpp он является более быстрым бэкендом, а на других он близок настолько, что побеждает меньшее операционное трение.

ROCm — правильный выбор, когда движок построен вокруг PyTorch, когда AMD Instinct и многографическое вычисление центральны, или когда протестированная сборка HIP выигрывает фактическую модельную нагрузку. Ее экосистема значительно сильнее в 2026 году, но новая упаковка и строгие слои совместимости по-прежнему вознаграждают закрепленные версии и дисциплинированную верификацию — и на самом новом поколении RDNA в частности, проверка того, что оптимизированный путь ядра фактически выполнялся, не является опциональной.

Для поддерживаемой рабочей станции на Radeon моя рекомендация намеренно не романтическая: сначала установите Vulkan, добавьте ROCm, когда движок или бенчмарк оправдают сложность, и держите обе сборки llama.cpp, если машина регулярно обслуживает разные формы моделей. Лучший бэкенд AMD — это не постоянная характеристика карты; это характеристика карты, движка, модели, драйвера и нагрузки вместе.

Ссылки

• Примечания к выпуску ROCm 10.0.0
• Матрица совместимости ROCm
• Переход ROCm на TheRock и маппинг пакетов
• Инструкции по сборке llama.cpp для HIP и Vulkan
• Поддержка оборудования AMD и Vulkan в Ollama
• Руководство по инференсу и обслуживанию vLLM от AMD
• Hugging Face TGI на GPU AMD
• Управление рантаймами LM Studio
• Ускорение GPU в LocalAI
• Обсуждение производительности Vulkan в llama.cpp
• Обсуждение производительности ROCm в llama.cpp
• Angelov, I. “Local LLM Inference on AMD RX 9070 XT — Vulkan vs ROCm Benchmarks on RDNA4.” digtvbg.com, март 2026. https://digtvbg.com/blog/llama-server-vulkan-rdna4-vllm-rocm-benchmark/
• “ROCm Vs. Vulkan Llama.cpp RDNA4 Radeon RX 9070 XT Benchmarks.” OpenBenchmarking.org. https://openbenchmarking.org/result/2509078-NE-ROCMVSVUL92
• "[Vulkan] Pathological token-generation slowdown on RX 9070 XT (gfx1201) for models with hidden_size >= 4096." Проблемa на GitHub llama.cpp.