Локальный запуск моделей на Ryzen AI Halo

Возможно, эта публикация выглядит несколько запоздалой, ведь сегодня подобные устройства стоят примерно в два-три раза дороже той цены, по которой я приобрел свой экземпляр еще до скачка стоимости памяти и комплектующих. Однако, во-первых, софт не стоит на месте, и то, что функционировало год назад, сейчас запускается совершенно иначе. Во-вторых, наверняка кто-то, подобно мне, приобрел эту игрушку, отложил её в сторону и так и не выкроил время на установку Linux ради заветной объединенной видеопамяти объемом 120 ГБ…

Я посвятил весь уик-энд тестированию различных конфигураций. Если раньше официальные руководства от AMD выручали безотказно, то сегодня ландшафт изменился: обновились дистрибутивы Linux, ядро, библиотека llama.cpp и версионность драйверов. В этой статье я не только поделюсь актуальным мануалом по настройке, но и продемонстрирую показатели производительности, на которые стоит рассчитывать с этим мини-ПК. Данный опыт в значительной степени применим и к другим графическим решениям от AMD.

С некоторыми нюансами не удалось разобраться с налету — готовых ответов в поисковиках не нашлось. Тем не менее, энтузиасты активно обсуждают их на Reddit, документируют в репозиториях GitHub, да и в комментариях на SE7ENе под новостями о подобных гаджетах постоянно всплывают технические детали.

Краткий обзор платформ на AI 395

Ведущие производители уже выпустили решения на базе процессора Ryzen AI Max+ 395: это GmkTec, Minisforum, Beelink, IceBook, а несколько месяцев назад собственное устройство представила и сама AMD (заметка на SE7ENе). Существует также ноутбук от Asus, однако его существенным минусом является жесткое ограничение по TDP, из-за которого он не способен выдавать заявленные 140 Вт мощности.

Все эти мини-ПК схожи по архитектуре, но я могу подробно рассказать лишь о своем:

• SSD-накопитель на 2 ТБ со скоростью чтения/записи около 6000 МБ/с.

• Производительный 16-ядерный процессор со встроенной графикой (эксперты оценивают её уровень примерно наравне с RTX 4060).

• На материнской плате вокруг процессора распаяны чипы памяти: в сумме это 128 ГБ стандартов DDR5, функционирующих на частоте 8000 МГц.

  Даже если в какой-то момент этот компьютер перестанет использоваться для задач искусственного интеллекта, он останется мощной рабочей станцией общего назначения, например, для компиляции тяжелого софта…

Почему Linux предпочтительнее?

В операционной системе Windows архитектура работы с видеопамятью устроена иначе: через BIOS мы можем зарезервировать максимум 96 ГБ, оставляя системе 32 ГБ. Если же локальной модели потребуется 102 ГБ, она просто не запустится. Архитектуры типа MoE (Mixture of Experts) в любом случае постоянно перекачивают слои между системной и видеопамятью, и это копирование отнюдь не бесплатно, хотя физически данные находятся на тех же самых микросхемах. Кроме того, фоновые службы Windows регулярно вызывают просадки скорости инференса. Такой сетап абсолютно непригоден для роли стабильного сервера: Windows любит перезагружаться по ночам, из-за чего запущенный API внезапно оказывается недоступен.

В Linux реализована превосходная технология TTM (Translation Table Manager). Я не углублялся в низкоуровневые детали её работы, но концептуально она близка к унифицированной памяти в чипах Apple: в BIOS мы выставляем минимальные 512 или 1024 МБ, а видеоподсистема динамически забирает из ОЗУ ровно столько, сколько ей необходимо, позволяя задействовать под VRAM практически все 128 ГБ.

Подготовка устройства

1. Переходим в BIOS: по умолчанию там может быть выставлено стандартное значение видеопамяти в 32 или 64 МБ. Устанавливаем минимально возможный объем.

2. Инсталлируем Ubuntu (под нее оптимизировано максимальное количество готовых решений). Я выбрал свежую десктопную версию 26.04, вышедшую в апреле этого года. Поскольку сервер с нейросетями стоит на полке под телевизором и параллельно выполняет роль медиацентра для воспроизведения тяжелых видеофайлов, с которыми штатный плеер телевизора не справляется, графическая оболочка мне пригодится.

3. Открываем конфигурационный файл /etc/default/grub и прописываем следующие параметры:

   GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ttm.pages_limit=30720000 amdgpu.gttsize=120000"

4. Выполняем команды sudo update-grub и перезагружаем систему. Проверяем результат с помощью терминала:

   sudo dmesg | grep "amdgpu.*memory"

   В выводе должно отобразиться нечто подобное:

   

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

   sudo usermod -a -G render,video $LOGNAME

   После этого перелогиниваемся (завершаем сеанс и заходим снова), чтобы изменения прав вступили в силу.

   На этом этапе операционная система развернута, драйвер amdgpu функционирует корректно, память выделена, а SSH настроен для удаленного управления.

Краткий экскурс в вычисления на графике AMD

Если для экосистемы Nvidia стандартом де-факто является CUDA, под которую идеально оптимизирована llama.cpp, то владельцы карт AMD могут выбирать между двумя бэкендами: ROCm и Vulkan. Я настроил оба варианта, поскольку у каждого есть свои сильные и слабые стороны, а отдельные языковые модели на Vulkan могут вести себя нестабильно.

Установка ROCm и llama.cpp

Еще в начале лета весь процесс сводился к точному следованию официальному мануалу, однако после недавнего выполнения заурядного апдейта через apt update вся эта конструкция благополучно разрушилась…

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

В финале проверяем работоспособность командой:

rocminfo| grep " gfx"

В ответ мы должны получить строку, подтверждающую, что наше железо идентифицировано как архитектура gfx1151:

Name: gfx1151

Теперь переходим по ссылке и загружаем готовую сборку llama.cpp из репозитория Lemonade SDK. Учитывая выявленный ранее идентификатор 1151, ищем билд для Ubuntu под версию 1151.

Выполняем стандартную последовательность действий:

1. Скачивание через wget.

2. Распаковка архива (unzip).

3. Наделение файлов llama-cli и llama-server правами на запуск.

mkdir ./llama && cd ./llama
wget ...ссылка...
unzip ./filename.zip
rm ./filename.zip
chmod +x ./llama-cli ./llama-server

Проверяем корректность обнаружения устройств: ./llama-cli --list-devices

Полагаете, на этом всё? Как бы не так. Из-за изменений в свежих сборках или особенностей линковки свежих драйверов уборочные библиотеки могут не подхватываться автоматически.

В процессе выполнения sudo amdgpu-install система выводит путь к расположению библиотек — в моем случае это /opt/rocm/lib.

После непродолжительных поисков и экспериментов решение оказалось банальным — прописать путь в переменные окружения:

echo 'export LD_LIBRARY_PATH="/opt/rocm/lib:$LD_LIBRARY_PATH"' >> ~/.bashrc
source ~/.bashrc

Учитывайте, что экосистема стремительно развивается: если раньше библиотеки складывались в /opt/rocm-7.2/, то теперь используется стандартный путь /opt/rocm/. Если вы читаете эту инструкцию позже сентября 2026 года, пути возможно придется скорректировать. Механизм аналогичен переменной PATH: добавляя кастомные директории из /opt в LD_LIBRARY_PATH, мы заставляем систему искать динамические библиотеки в нужном месте при каждом запуске сессии.

Теперь всё готово к старту. Я использую следующий исполняемый скрипт (модель предварительно перенесена из LM Studio с основного компьютера):

#!/bin/bash
export LD_LIBRARY_PATH="/opt/rocm/lib:$LD_LIBRARY_PATH"
LLAMA_DIR="/data/llama"
MODEL_PATH="/data/models/Qwen3-Coder-Next-GGUF-Q6/Qwen3-Coder-Next-Q6_K-00001-of-00002.gguf"

cd "$LLAMA_DIR" || exit 1

./llama-server \
  -m "$MODEL_PATH" -ngl 99 -fa on \
  -c 262144 -b 8192 -ub 512 -t 6 \
  -lm mlock --host 0.0.0.0 --port 8080 \
  -np 1 -cb --cache-reuse 512 \
  -a qwen3-coder-next-q6 --metrics -n 8192 \
  "$@"

Лично у меня для каждой модели, каждого уровня квантования и бэкенда заготовлены подобные скрипты вроде ./runQwen3Coder.sh, и в каждый момент времени активна ровно одна модель.

Движок llama автоматически подтягивает разделенные файлы, поэтому в параметре -m достаточно указать путь исключительно к первому фрагменту GGUF (например, 00001-of-03).

Работоспособность API проверяется стандартным запросом через cURL (с другого хоста или локально):

curl http://192.168.1.12:8080/v1/chat/completions    -d '{
    "messages": [
      {"role": "user", "content": "Привет, как тебя зовут?"}
    ] 
}'

Vulkan

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

Готовых бинарников я не обнаружил (либо плохо искал), поэтому при помощи DeepSeek успешно собрал llama под Vulkan из исходников:

sudo apt update && sudo apt install -y git \
build-essential cmake libvulkan-dev glslc spirv-headers mesa-vulkan-drivers

Убеждаемся, что система распознает графический адаптер:

vulkaninfo | grep -i "deviceName"

cd /data
git clone https://github.com/ggml-org/llama.cpp.git llama-vulkan
cd llama-vulkan
cmake -B build -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

# Верификация сборки
./build/bin/llama-cli --list-devices

В разделе про ROCm-версию llama приложен скриншот, наглядно иллюстрирующий, как утилита распознает Vulkan-устройство.

 

Источник