GMKTec EVO X2 (у меня такой), но есть еще много
GMKTec EVO X2 (у меня такой), но есть еще много

Статья может показаться запоздалой и сейчас такие коробочки стоят ну раза 2-3 дороже чем я ее покупал год назад до повышения цен на память и комплектующие. Но, во-первых есть изменения в софте и то что работало год назад - сейчас иначе запускается, во-вторых вдруг кто-то как и я поигрался и отложил это устройство и руки так и не дошли чтобы даже поставить Linux и получить возможность объединенной видеопамяти на 120Gb...

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

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

Кратко AI 395 платформах

Разные производители уже сделали устройства на данном процессоре Ryzen AI Max+ 395, GmkTec, Minisforum, Beelink, IceBook и несколько месяцев назад даже сам AMD (новость на хабре). Есть еще ноутбук от Asus, но там минус, что он ограничен по TPD и не выжимает полные 140 ватт своей мощности.

Все они похожие, но я только о своем могу говорить:

  • 2Тб SSD скоростью около 6000мб/с

  • достаточно мощный 16 ядерный процессор с мощной встройкой (как говорят на уровне 4060)

  • вокруг процессора на плате распаяны чипы памяти, память 128Gb DDR5 со скоростью 8000.

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

Почему Linux лучше?

На Windows видеопамять устроена иначе, т.е. мы в биосе выбираем максимально возможные 96Gb, остается для системы 32 Gb и если модель хочет 102Gb, то не загрузится, всякие MoE модели всё равно гоняют между оперативной и видеопамятью слои и это копирование не совсем бесплатно дается, хотя физически всё хранится на одних и тех же чипах. Помимо этого, у Windows частенько какие то фоновые операции происходят что снижает скорость инференса, это не годится для сервера, т.к. само любит перезагружаться ночами и внезапно запущенная апи снова недоступна.

На Linux есть интересная технология TTM, я сильно не вникал как это работает, но что-то похожее на объединенную память в Apple, т.е. в BIOS мы выставляем самый минимум 512 или 1024мб, а видеокарта берет сколько ей лимитировали из оперативной памяти, в Linux можно задействовать почти все 128Gb памяти под VRAM.

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

  1. Заходим в BIOS, там, вероятно, стоит 64 или 32 видеопамять, выставляем самый минимум, который можно.

  2. Ставим Ubuntu (под нее куча всего готового), я поставил 26.04, она вышла в апреле этого года, поставил десктопную, т.к. нейрокомп стоит на полочке под телевизором в качестве сервера, предоставляет мне api, и еще планирую использовать как медиаприставку, воспроизводить видео которые мой телевизор сам не может осилить.

  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"

    У меня что то такое:

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

    sudo usermod -a -G render,video $LOGNAME

    Потом нужно перелогиниться (выйти и зайти), чтобы права применились.

    На данном этапе система установлена, драйвер amdgpu работает, память выделена, ssh тоже установлен и можно уже по сети всё остальное делать.

Коротко о вычислениях на видеокартах AMD

У Nvidia есть CUDA и под нее адаптирована llama.cpp, а вот у AMD есть два варианта ROCm и Vulkan. Я настроил себе оба, т.к. у них есть свои плюсы и минусы и некоторые модели нестабильно могут себя вести на Vulkan.

Устанавливаем ROCm + llama.cpp

Еще в начале лета я просто делал всё по инструкции и у меня сразу работало, но недавно решил обновиться и вбил apt update как всё сломалось...

вот так всё крашилось при выполнении первого промпта
вот так всё крашилось при выполнении первого промпта

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

я скачал именно compute+graphic, т.к. еще и фильмы буду на нем смотреть...
я скачал именно compute+graphic, т.к. еще и фильмы буду на нем смотреть...

В финале мы выполняем команду чтобы проверить что всё ок

rocminfo| grep " gfx"

Нам вернет что то такое, и теперь мы понимаем что у нас gfx1151

Name: gfx1151

Теперь идем по ссылке и качаем готовую сборку llama.cpp из Lemonade SDK, из пункта выше мы помним что у нас 1151, поэтому ищем там сборочку 1151 для ubuntu

Нужно сделать несложные действия:

  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

обратите внимание, вулкан показывает вулкан а тут rocm
обратите внимание, вулкан показывает вулкан а тут rocm

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

После того, как выполните команду 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, то будет еще и там искать, чтобы эта переменная всегда была заполнена - добавляем в ~/.bashrc и при каждом входе оно будет прописываться.

Теперь можно попробовать запустить, у меня вот такой скрипт (модель подложил из 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 \
  "$@"

У меня вообще на каждую модель, на каждый квант, на каждый вариант llama есть такие скрипты в стиле ./runQwen3Coder.sh запускаю единовременно одну модель.

llama сама подгрузит несколько файлов, указать в параметре -m нужно только первый фрагмент gguf (00001-of-03)

Ну и проверить можно так (с другого устройства или на локалхост)

curl http://192.168.1.12:8080/v1/chat/completions    -d '{
    "messages": [
      {"role": "user", "content": "Привет, как тебя зовут?"}
    ] 
}'
теперь, у нас есть api к которому можно подключать агентов, которые будут за вас писать код
теперь, у нас есть api к которому можно подключать агентов, которые будут за вас писать код

Vulkan

это я друзьям хвастался в мессенджере
это я друзьям хвастался в мессенджере

llama.cpp на ROCm мы сделали, но давайте еще сделаем на вулкане, на нем есть кое-какой прирост, но не все модели на нем хорошо работают.

Я не нашел готовых билдов (а может и не искал) и дипсик мне помог скомпилировать 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

В разделе про llama ROCm есть скрин, где показано как llama видит vulkan

Как запускать модели - всё как и выше было, только путь до llama-server поменялся.

Испытания моделей

Для создания бенчмарков я просил Qwen и Deepseek мне написать скрипты на python, первое что я проверил - это заполнение контекста, оптимальное значение искал бинарным поиском, но достаточно просто начать с максимума, который модель поддерживает, если в llama выставить контекст 500к, а модель больше 260к не поддерживает, то это значение автоматом по максимуму урежется.

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

Аналогичным способом я тестировал скорость моделей (с отключением кеширования промпта)

без кешировани
без кешировани

Если промпт кешируется, то он быстрее обрабатывается, вот пример, так что при работе с реальным кодом, когда один и тот же контекст будет отправляться от запроса к запросу будет сильное ускорение при незначительных изменениях проекта (смотреть на Prefill):

с кешированием, тот же Coder Next Q8 весом 84 гигабайта
с кешированием, тот же Coder Next Q8 весом 84 гигабайта

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

Сравнение с Nvidia RTX5060ti 16Gb

Первое, что я захотел проверить - а насколько вообще эта встройка медленнее чем моя 5060ti (когда то самая дешевая из 16 гиговых).

Для испытаний я попробую выбрать примерно схожие параметры запуска Qwen 3 Coder 30B Q4, это моделька MoE и почти влезает в мою видеокарту, сразу скажу, на моем стационарном ПК стоит 3200 DDR4 оперативная память, на DDR5 обычно намного лучше ситуация, когда слои не влезают в VRAM.

Параметр

Значение

-ngl 38

38 из 48 слоев загрузить в VRAM

-c 15000

Размер контекста - 15000 токенов

-ctk q8_0 -ctv q8_0

Квантование кеша q8

Инференс на

Скорость токенов в сек
при заполнении контекста на 15000 токенов

Nvidia RTX 5060ti 16gb

19.8 ток/сек

AI Max+ 395 (ROCm)

12.3 ток/сек

AI Max+ 395 (Vulkan)

13.8 ток/сек

Что то тут прямо ужасно, несмотря на то что память ддр5 - слои в памяти прямо убивают всю скорость... Вероятно, дело в той самой технологии ТТМ, которая делает объединенную память. Теперь попробуем на Ai Max загрузить все слои в VRAM -nlg 99

Инференс на

Скорость токенов в сек
при заполнении контекста на 15000 токенов

AI Max+ 395 (ROCm)

30.3 ток/сек

AI Max+ 395 (Vulkan)

53.7 ток/сек

Тут мы уже видим что на ROCm в 1.5 раза быстрее nvidia, а вот на Vulkan показывает в 2.7 раз лучшую скорость. Ну тут понятно, Nvidia скорее всего обращается в медленную память, а тут всё в VRAM.

А давайте возьмем ту же самую модель, но с квантованием Q3, качество у нее конечно самое низкое, но будет возможность загрузить в VRAM Nvidia все слои...

Чтобы ничего не вылетало при заполнении контекста на 15000, мне пришлось уменьшить контекст как в параметрах, так и в тесте до 10000 токенов, параметры -nlg 99 -c 10000

Инференс на

Скорость токенов в сек
при заполнении контекста на 10000 токенов

Nvidia RTX 5060ti 16gb

85.5 ток/сек

AI Max+ 395 (ROCm)

37.9 ток/сек

AI Max+ 395 (Vulkan)

61.4 ток/сек

При заполнении контекста только на 5000 токенов Nvidia может выдавать 105+ токенов, а при 10к только 85.5, поэтому, не спешите говорить что у вас при начале диалога выжимает 200+, забейте сперва контекст...

Тут мы видим ровно то, что и требовалось доказать, если модель влезает на 100% вместе с контекстом на видеопамять, то полноценная видеокарта, несмотря на то что это не 5090, а всего слабенькая 5060 будет намного мощнее. Второй момент - Vulkan дважды выигрывал в тестах на +60%. Значит, не зря я его компилировал! Ну и наш Ai Max выигрывает с толстыми моделями, т.к. все слои в видеопамять (если ее так можно назвать) и позволяет выгрутить контекст на все 260к токенов (не советую, чем больше контекст тем тупее).

Ну а еще я вижу что встройка жмет 61 токен, а нвидиа 85, и это не в 10 раз и даже не в 2 раза просадка, т.е. камушек вполне годный, учитывая что вместе с 16 ядерным процессором потребление 140 ватт.

Тестируем разные модели на Ryzen

Остальные модели сравнивать между двумя устройствами не имеет смысла, на моем ПК не быстрая память DDR4, в видеопамять не залезают даже 27B модели, я хочу просто показать что примерно можно крутить на этом мини-ПК и какой производительности можно достичь.

Будем тестировать с контекстом 5000 (небольшой чат), 15000 (небольшой проект), ну и что-то среднее, вроде 45000 токенов. Те модели, которые уже на 15к будут показывать меньше 10 токенов дальше пытать не буду, т.к. это целая вечность несколько прогонов сделать.

Сразу скажу - методика тестирования не претендует быть идеальной, но эти скрипты на python дают повторимый результат сравнимый с тем что модель может в чате (если ей скинуть большой кусок текста), поэтому в качестве сравнения вполне сгодится, этими бенчмарками я обкатывал примерные параметры, размеры батчей и т.д. и добивался максимальных результатов.

Qwen 3 Coder 30B

Первой протестируем "рабочую лошадку" qwen 3 coder, моделька может и старая, но код лопатит вполне, Q3 говорят крайне тупая, Q4 уже сносно работает, а Q8 это что-то почти без потери качества (почти). Тут важный момент, поправьте если не прав, но есть две скорости - первая это Prefill, т.е. парсинг самого промпта, а потом генерация ответа (Decode), я укажу оба значения, т.к. это важно.

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

Запускаю вот таким скриптом
#!/bin/bash

export LD_LIBRARY_PATH="/opt/rocm/lib:$LD_LIBRARY_PATH"
export HSA_OVERRIDE_GFX_VERSION=11.5.1

LLAMA_DIR="/data/llama"
MODEL_PATH="/data/models/Qwen3-Coder-Next-GGUF-Q8/Qwen3-Coder-Next-Q8_0-00001-of-00003.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-q8 \
  --metrics \
  -n 8192 \
  "$@"

Модель

Размер

Заполнение контекста (ток)

Скорость ROCm (ток/с)

Скорость Vulkan (ток/с)

Qwen3-Coder-30B-A3B-Instruct-Q4_K_M

18Gb

5000

Decode: 57.5
Prefill: 1419

Decode: 63.8
Prefill: 1095

15000

Decode: 43
Prefill: 1014

Decode: 53.5
Prefill: 613

45000

Decode: 28
Prefill: 535

Decode: 29.8
Prefill: 241

Qwen3-Coder-30B-A3B-Instruct-Q8_0

32.48Gb

5000

Decode: 44.5
Prefill: 1507.3

Decode: 47.9
Prefill: 1151

15000

Decode: 37.5
Prefill: 1057.3

Decode: 39.0
Prefill: 656

45000

Decode: 25.2
Prefill: 565.8

Decode: 30.9
Prefill: 242

Ситуация интересная, когда мы даем большой промпт - кучи файлов, длинный, чат, то он сперва парсится (prefill) а потом на него генерится ответ (decode), и вот Q8 при заполнении контекста на 45к дает prefill 565 токенов в секунду на ROCm и 242 на вулкане, и наоборот Decode 25.2 на ROCm и 30.9 на vulkan. Обратился к гуглу с этим вопросом и он как будто обосновал такое поведение, но я пока буду копать, неужели нельзя задействовать лучшие стороны двух технологий?

Описание гугла (осторожно ИИ)

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

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

Внимательное посмотрите корреляцию между ROCm/Vulcan на разных размерах контекста. Далее мы проведем похожий опыт, но на следующем поколении Qwen Coder Next и там картинка совсем-совсем иная.

Qwen 3 Coder Next 80B

Эта моделька - продолжение Qwen 3 Coder 30B, но более массивная и на 16 гиговой видеокарте едва шевелится... Я кодировал на ней с квантом Q8 - неспешно можно запиливать средние проектики (на каком нибудь KiloCode).

Модель

Размер

Контекст

Скорость ROCm (ток/с)

Скорость Vulkan (ток/с)

Qwen3-Coder-Next-Q4_K_M

48.49 Gb

5000

Decode: 44.3
Prefill: 838.4

Decode: 52.9
Prefill: 783

15000

Decode: 41
Prefill: 785

Decode: 48.8
Prefill: 778

45000

Decode: 35.3
Prefill: 634.3

Decode: 41.4
Prefill: 631

Qwen3-Coder-Next-Q8_0

84.8 Gb

5000

Decode: 34.9
Prefill: 745.4

Decode: 39.8
Prefill: 744.4

15000

Decode: 33.5
Prefill: 775.0

Decode: 38.2
Prefill: 750.4

45000

Decode: 28.5
Prefill: 634.7

Decode: 32.7
Prefill: 613.4

У меня получились следующие выводы

  1. Next не деградирует при увеличении контекста, у него стабильно около 700 токенов в prefill и значительно меньше деградирует скорость decode, при контексте в 45к разницы с Qwen 3 Coder 30B уже нет.

  2. Скорость между Q4 и Q8 не двухкратная, а качество лучше.

  3. Скорость Decode почти сравнима у Next и 30B, видимо потому что и там и там активных параметров 3B, т.е. нагрузка примерно равна.

Заключение

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

  • Описать настройку Qwen Code, Claude Code, OpenCode, Hermes, KiloCode и других инструментов на свой API.

  • Попробовать запустить плотные модели, ну или модели у которых не 3, а 4B активных параметров, поискать интересные модели, которые запустятся на этом железе, вероятно есть маленькие модельки которые могут кодировать не хуже квенов.

  • Попробовать еще ускорить Vulkan

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

Поигравшись немного и запилив несколько мини-проектиков я вполне доволен, да, не очень быстро, пишешь промпт, идешь пить чай, через полторы минуты кучу файлов, конфигов, тысячи строк кода, всё заполнено, только запускай и проверяй. Бесплатно, локально, по качеству ну вполне пригодно, медленно, но быстрее некоторых api в часы пик.

Буду признателен если поделитесь своим опытом - какие параметры позволяют выжать максимум на таком ограниченном железе, может быть посоветуете интересные модельки для кодирования.

Комментарии (2)


  1. yar3333
    21.09.2026 17:50

    Супер! Рекомендую попробовать модель https://huggingface.co/unsloth/Qwen3.6-35B-A3B-MTP-GGUF - именно в mtp режиме, должно быть более юзабельно (как в смысле скорости, так и качества, next - это всё-таки прошлое поколение, по моему опыту, она сильно уступает 3.6).


  1. yar3333
    21.09.2026 17:50

    И было бы интересно какая скорость будет на vLLM, всё-таки он чуть более оптимизирован, чем llama.cpp, хотя обычно результаты сравнимы (у меня на процентов ~5% быстрее на моей 4-gpu конфигурации, но если идут несколько запросов в параллель - то позволяет выжать x2 в суммарной скорости генерации).