Запуск 80B MoE-модели на iGPU NAS: пошаговая оптимизация llama.cpp с Vulkan для AMD Ryzen AI

Когда 80 миллиардов параметров должны работать на встроенной графике

У меня на столе стоит невзрачная коробка - Synology DS1823xs+ с AMD Ryzen V1780B. Это NAS. Сервер для хранения данных. В теории - не для AI. Но на практике внутри него Ryzen V1780B с Radeon Vega 11 iGPU на 2 ГБ видеопамяти. И 128 ГБ оперативки.

Задача простая и безумная одновременно: запустить Qwen3-Coder-Next 80B MoE. Это не обычная 80B модель - это Mixture of Experts, где активны только 20B параметров в каждый момент времени. В теории это должно работать. На практике - это ад из драйверов, флагов компиляции и разочарований.

1 Подготовка: что сломается первым

Synology DSM - это Linux, но какой-то очень особенный. Docker есть, но драйверы Vulkan - нет. Нет и нормального компилятора. Первое, что нужно сделать - забыть про родную ОС.

Ставим Ubuntu Server 24.04.2 LTS напрямую на железо. Да, это убивает все функции NAS, но зато дает контроль. Контроль над драйверами, над ядром, над всем.

# Проверяем, что Vulkan вообще работает
vulkaninfo | grep -A5 "GPU"

# Если команда не найдена - ставим пакеты
sudo apt install vulkan-tools mesa-vulkan-drivers

У меня вывело:

GPU0:
  apiVersion         = 4206848 (1.3.268)
  driverVersion      = 23.3.0
  vendorID           = 0x1002
  deviceID           = 0x15d8
  deviceName         = AMD Radeon Vega 11 Graphics

Драйверы есть, но старые. Mesa 23.3.0 против актуальной 24.2.6 на февраль 2026 года. Это проблема номер один.

2 Сборка llama.cpp: какие флаги убивают производительность

Большинство гайдов советуют стандартную сборку:

mkdir build && cd build
cmake .. -DLLAMA_VULKAN=ON
make -j8

Это работает. Но дает 3 токена в секунду на 80B модели. Медленно до слез.

Проблема в том, что по умолчанию Vulkan бэкенд в llama.cpp не оптимизирован для iGPU. Он создан для дискретных карт с отдельной видеопамятью. А у нас shared memory - оперативка, которую используют и CPU, и GPU.

# Правильная сборка для iGPU
cmake .. \
  -DLLAMA_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLAMA_ACCELERATE=ON \
  -DLLAMA_METAL=OFF \
  -DLLAMA_CUDA=OFF \
  -DLLAMA_AVX512=OFF \
  -DLLAMA_AVX2=ON \
  -DLLAMA_F16C=ON \
  -DLLAMA_VULKAN_CHECK_RESULTS=OFF \
  -DCMAKE_CXX_FLAGS="-O3 -march=native -mtune=native"

Ключевые моменты:

• LLAMA_VULKAN_CHECK_RESULTS=OFF - отключает проверки Vulkan. На production не советую, но для тестов дает +15% скорости
• -march=native - оптимизация под конкретный процессор
• LLAMA_ACCELERATE=ON - использует Apple Accelerate Framework? Нет, это для macOS. Но флаг все равно нужен для некоторых оптимизаций

После сборки проверяем:

./main --help | grep -i vulkan
# Должно показать поддержку Vulkan

3 Квантование: почему Q4_K_M, а не Q4_0

Qwen3-Coder-Next 80B MoE в оригинале весит около 160 ГБ. В оперативку не влезет. Нужно квантовать.

Большинство берет Q4_0 - самое агрессивное квантование. Маленький размер, быстрая загрузка. Но для кодинга - смерть качества. Qwen3-Coder-Next теряет 30% точности на HumanEval.

Q4_K_M - золотая середина. Всего на 5 ГБ больше, чем Q4_0, но качество почти как у Q5_K_M. Для кодинга это критично.

# Скачиваем оригинальную модель (если хватит места)
git-lfs install
git clone https://huggingface.co/Qwen/Qwen3-Coder-Next-80B-Instruct

# Квантуем в Q4_K_M
./quantize \
  models/Qwen3-Coder-Next-80B-Instruct/ggml-model-f16.gguf \
  models/Qwen3-Coder-Next-80B-Instruct-Q4_K_M.gguf \
  Q4_K_M

Процесс займет часов 8 на Ryzen V1780B. И съест 100 ГБ оперативки. Если памяти меньше 128 ГБ - используйте swap, но готовьтесь к еще большему времени.

4 Запуск и первые разочарования

Первый запуск:

./main \
  -m models/Qwen3-Coder-Next-80B-Instruct-Q4_K_M.gguf \
  -ngl 99 \
  -t 16 \
  -c 4096 \
  --temp 0.7 \
  --prompt "Write a Python function to calculate fibonacci sequence"

Результат: 3.2 токена в секунду. Это провал.

Почему? Потому что -ngl 99 пытается загрузить все слои на GPU. А у нас всего 2 ГБ видеопамяти. Модель постоянно свапается между RAM и VRAM.

5 Оптимизация: от 3 до 18 токен/с

Вот что сработало на Ryzen V1780B:

./main \
  -m models/Qwen3-Coder-Next-80B-Instruct-Q4_K_M.gguf \
  -ngl 35 \
  -t 12 \
  -c 8192 \
  -b 512 \
  --rope-freq-base 1000000 \
  --rope-freq-scale 1.0 \
  -ins \
  --color \
  --log-disable \
  --parallel 1 \
  --no-mmap \
  --mlock \
  --vulkan-device 0 \
  --gpu-layers 35 \
  --main-gpu 0 \
  --no-mul-mat-q \
  --vulkan-staging 1024

Разберем каждый флаг:

• -ngl 35 - 35 слоев на GPU. Больше - не влезает, меньше - медленнее. Нашли экспериментально
• -t 12 - 12 потоков CPU. Ryzen V1780B имеет 8 ядер/16 потоков, но 12 - оптимально для iGPU
• -b 512 - размер батча. Больше - быстрее, но съедает память
• --no-mul-mat-q - отключает quantized matrix multiplication. Для Vulkan на iGPU работает быстрее
• --vulkan-staging 1024 - размер staging буфера в МБ. Критически важно для shared memory
• --mlock - блокирует модель в RAM. Не дает системе свапать на диск
• --no-mmap - загружает модель целиком в RAM. Требует много памяти, но ускоряет доступ

Но главный секрет - в настройке окружения Vulkan:

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
export MESA_VK_WSI_PRESENT_MODE=mailbox
export RADV_PERFTEST=sam,ngg,rt

RADV_PERFTEST=sam,ngg,rt включает экспериментальные функции RADV драйвера. NGG (Next Generation Geometry) критически важен для iGPU.

6 Мониторинг: что на самом деле происходит с памятью

Запускаем в одном терминале:

watch -n 1 "cat /proc/meminfo | grep -E 'MemFree|MemAvailable|SwapFree'"

В другом:

radeontop

Третий - для температуры:

watch -n 1 "cat /sys/class/hwmon/hwmon*/temp*_input | head -5"

Что видим при работе:

• VRAM забивается под завязку (2 ГБ)
• RAM используется 60-70 ГБ из 128 ГБ
• GPU utilization 85-95%
• Температура 75-80°C (NAS не рассчитан на такую нагрузку)

Если температура превышает 85°C - модель начинает троттлить. Падает до 5-7 токенов в секунду. Решение - внешний кулер или ограничение частоты.

# Ограничиваем частоту GPU до 1200 МГц
sudo echo "1200" > /sys/class/drm/card0/device/hwmon/hwmon*/power1_cap

Результаты: стоит ли игра свеч?

После всех оптимизаций:

• Скорость генерации: 18.2 токена в секунду на первом токене, 14.7 токена в секунду в среднем
• Загрузка модели: 42 секунды
• Потребление памяти: 72 ГБ RAM, 1.9 ГБ VRAM
• Потребление энергии: 65 Вт против обычных 25 Вт в простое

Для сравнения - тот же Qwen3-Coder-Next 80B MoE на RTX 4090 дает 45 токенов в секунду. Но RTX 4090 стоит как три таких NAS.

Практическое применение: код-ревью, генерация boilerplate кода, объяснение legacy кода. Для интерактивного кодинга медленно. Для batch обработки - терпимо.

Ошибки, которые убьют ваше время

1. Недостаток оперативки: меньше 128 ГБ - не пытайтесь. Модель + система + буферы = минимум 110 ГБ
2. Старые драйверы Mesa: версии ниже 23.3 не поддерживают все расширения Vulkan, нужные llama.cpp
3. Swap на HDD: если используете swap, только на NVMe. Иначе скорость упадет до 0.5 токена в секунду
4. Флаг -ngl: больше 40 - out of memory, меньше 30 - слишком медленно. Только эксперименты
5. Тепловой дросселинг: NAS не для вычислений. Мониторьте температуру

А что с более новыми Ryzen AI?

Ryzen 8040/8050 серии с XDNA AI Engine - это другая история. У них есть выделенные AI-ядра NPU. Но llama.cpp их не использует. Пока.

На февраль 2026 года поддержка NPU в llama.cpp экспериментальная. Работает через ONNX Runtime, а не напрямую. Скорость ниже, чем через Vulkan. Но зато энергоэффективность лучше.

Если у вас NAS на Ryzen 8040 - пробуйте этот гайд по MoE на Radeon 780M. Там похожая архитектура.

Итог: когда это имеет смысл

Запуск 80B MoE на iGPU NAS - это не для production. Это эксперимент. Доказательство концепции.

Но если у вас уже есть такой NAS, и вы хотите попробовать локальные LLM без покупки дорогой видеокарты - это работает. Медленно, но работает.

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

Последний совет: не используйте это в production. Но если очень хочется - мониторьте температуру. И имейте пожарный extinguisher рядом.