Зачем я купил мини-ПК с «AI» ради локальной нейросети и на что реально способен его NPU

1 Окт в 12:58 Прокомментировать Просмотры: 5

Кратко. Я приобрел мини-ПК на базе Ryzen AI 9 365, чтобы запустить массивную локальную модель на NPU. Изначально выбор пал на Windows ради заманчивой связки NPU+iGPU, которая в итоге оказалась неработоспособной. Последовали танцы с бубном вокруг драйверов NPU и неожиданное открытие: нейропроцессор видел лишь половину установленной оперативной памяти. Перебравшись на Proxmox, я наконец развернул Qwen3.6–35B–A3B посредством FastFlowLM прямо на хосте. Теперь модель функционирует в режиме 24/7: скорость prefill достигает примерно 200 токен/с, а decode — 13–17 токен/с. По ходу дела выяснилось, что NPU обрабатывает исключительно один запрос одновременно, аварийно завершается с ошибкой double free при преждевременном обрыве соединения со стороны клиента, а также запросто выгружает крупную LLM из памяти ради крошечной эмбеддинг-модели. Ниже представлен подробный отчет со всеми граблями, мини-инструкцией и цифрами.

Маршрут статьи: все грабли разложены строго в хронологическом порядке их освоения.

Предыстория

Мой прошлый домашний сервер функционировал на базе Ryzen 7 5800U, лишенном как дискретной графики, так и NPU. Локальные большие языковые модели крутились прямо на центральном процессоре, однако при обработке объемных промптов драгоценное время уходило не на генерацию осмысленного ответа, а на банальное чтение:

Этап	Токены	Затраченное время	Производительность
Prefill (анализ промпта)	7943	245,1 с	32,4 ток/с
Decode (генерация текста)	36	5,0 с	7,05 ток/с
Итого	7979	250 с	—

Выходило так, что 99% времени модель попросту читала. В этот момент маркетинговые лозунги AMD прозвучали крайне заманчиво: утверждалось, что NPU создан именно для ускорения prefill. Беру! Мотивацию отказаться от облачных решений в пользу локального железа я подробно распишу в третьем акте, там же мы подведем финансовый итог.

Я колебался между мини-компьютерами на базе Ryzen AI 9 365 и Ryzen AI 9 HX PRO 370. В результате остановился на Ryzen AI 9 365 (оснащен графикой Radeon 880M и NPU XDNA2), доукомплектовав его 64 ГБ оперативной памяти. Поначалу такой объем казался избыточным, но практика показала, что это абсолютный минимум.

Мини-ПК FIREBAT на Ryzen AI 9 365 — Мини‑ПК FIREBAT на Ryzen AI 9 365

Если вдаваться в детали, выбор пал на модель FIREBAT на Ryzen AI 9 365. «Голая» коробка без SSD и RAM обошлась в 30 000 рублей, накопитель перекочевал со старого мини-ПК, а комплект планок DDR5-4800 объемом 64 ГБ (2 × 32 ГБ) потянул еще на 40 000 рублей. Итоговая сумма составила около 70 000 рублей (~$825), причем память обошлась дороже самого системного блока.

Инструменты для запуска LLM на NPU

Первое осознание суровой реальности: привычный софтовый стек здесь бессилен.

llama.cpp / Ollama / LM Studio понятия не имеют о существовании NPU. Они задействуют процессор, либо видеокарту через Vulkan/ROCm, в то время как NPU остается не у дел.
Lemonade Server от AMD обещает заманчивую гибридную схему: NPU обсчитывает prefill, а встроенное видеоядро берет на себя decode. Однако эта магия работает исключительно с заранее подготовленными AMD моделями формата ONNX и официально поддерживается только на Windows. Ассортимент моделей невелик: в актуальной версии Ryzen AI 1.8 это Llama 3.2 1B/3B, Llama 3.1 8B, Qwen3 1.7B/4B/8B, семейство Qwen2.5 до 7B, Mistral 7B и Phi-4-mini. Потолок ограничен 8 миллиардами параметров (хотя в прошлых релизах проскакивали Qwen2.5–14B и Qwen3-14B).
FastFlowLM (flm) представляет собой специализированный рантайм для работы с NPU от AMD. Он поднимает API, совместимый с OpenAI, а веса подтягивает из собственной репозитории на Hugging Face в специфическом формате .q4nx. Имеются сборки под Windows и Linux, причем в каталоге присутствует даже мультикадаровая Qwen3.6–35B–A3B с поддержкой компьютерного зрения.

Мне непременно хотелось запустить модель покрупнее, способную параллельно анализировать изображения — идеальным кандидатом виделась Qwen3.6–35B. Тем не менее, гибридный режим выглядел слишком соблазнительно, чтобы проигнорировать его. В моих фантазиях NPU молниеносно поглощал текст, графика выдавала ответ, и каждый кремниевый блок был занят своим делом. Поскольку гибрид обитает на Windows, эксперимент решено было начать именно с нее.

Акт 1. Windows

Lemonade: знакомство окончено

Первым делом я установил Lemonade и изучил доступный список. Все позиции с пометкой Hybrid оказались скромными малышками, тратить время на которые не было никакого желания. Для желанной Qwen3.6–35B гибридный режим отсутствовал как класс: либо задействуешь NPU через FLM, либо iGPU через llama.cpp, но совместить их нельзя. На этом мечта о синергии испарилась, и я перешел на чистый FLM.

Обновление драйвера NPU превратилось в отдельный квест. Самые свежие пакеты с официального сайта AMD далеко не всегда содержат актуальный драйвер для нейрочипа. Специфический дистрибутив поставляется в составе пакета Ryzen AI Software, но для его скачивания требовалось пройти регистрацию с верификацией региона на предмет санкционных ограничений. Доступа из России, Казахстана и Нидерландов я так и не добился.

Тем не менее, после изрядной порции страданий драйвер удалось обновить, и утилита flm наконец ожила.

Модель на месте, памяти нет

Qwen3.6–35B–A3B успешно скачана, запущена и даже отвечает на запросы. Интегрирую ее в Open WebUI, отправляю сообщение, и тут flm крашится с ошибкой DMA Paging Error 0xc01e0200. Причем сбой происходил не спонтанно, а в моменты, когда интерфейс отправлял пару параллельных запросов — фоновую генерацию заголовка чата и основной текст.

Заглядываю в «Диспетчер задач»:

Windows отображает 47,6 ГБ из имеющихся 64.
Строка «Выделенная память GPU» показывает 15,8 ГБ, из которых занят всего 1 ГБ. BIOS зарезервировал этот объем под встройку превентивно, и теперь эти гигабайты просто простаивают.
«Общая память», доступная для NPU, составляет всего 23,8 ГБ — ровно половину от 47,6 ГБ.

Иными словами, NPU выделяется лишь около 50% видимой оперативной памяти, причем зарезервированный под iGPU объем откусывает кусок и от этой половины. Сама модель весит около 20 ГБ, оставляя на KV-кэш и фоновые запросы всего 3,8 ГБ. Отсюда и нехватка ресурсов.

Лечение заключается в правке настроек BIOS: параметр UMA Frame Buffer Size (он же iGPU Memory) нужно выставить в минимальное значение.

После настройки: ОС видит полные 63,1 ГБ, пул NPU расширился до 31,6 ГБ, а сама модель утилизирует 21,2 ГБ из них.

Ценный вывод для планирующих покупку аналогичного железа: на конфигурациях с 32 ГБ ОЗУ подобная модель нежизнеспособна. В профильном issue #242 владельцы систем с 32 ГБ жалуются, что даже относительно скромная GPT-OSS-20B (~14 ГБ) не может стабильно уместиться в памяти. Расчет простой: вес весов плюс запас на контекст должны помещаться строго в половину доступной RAM за вычетом аппетитов интегрированной графики.

«NPU загружен наполовину»

Модель функционирует, однако мониторинг демонстрирует удручающую пилообразную активность NPU на уровне 50–60%. Первое подозрение — кривая конфигурация. На деле все иначе: у архитектуры MoE с примерно 3 миллиардами активных параметров на токен объем математических вычислений невелик, поэтому нейрочип банально простаивает в ожидании данных из памяти. Согласно официальной документации FLM, пропускная способность NPU составляет порядка 60 ГБ/с против ~125 ГБ/с у интегрированной графики. Генерация упирается в пропускную способность шины памяти, так что 100% загрузки ждать не стоит.

Особенности Open WebUI

Попутно всплыла еще одна проблема: при активации встроенных инструментов Open WebUI сваливается в бесконечный цикл. Модель с 3B активных параметров начинает генерировать повторяющиеся вызовы тулзов (tool_calls), интерфейс возмущается и отправляет всю историю диалога на повторный расчет, инициируя полный повторный prefill. Параметр CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS по умолчанию равен 256; настоятельно рекомендую скрутить его до 2–3.

Акт 2. Переезд на Linux

В этот момент здравый смысл задал закономерный вопрос: ради чего я мучаюсь в окружении Windows? Задумка с гибридом NPU+iGPU благополучно провалилась, работать будет исключительно NPU, а FastFlowLM чувствует себя на Linux ничуть не хуже. К тому же планировалось запустить на сервере полноценные виртуальные машины, возиться с гипервизором под Windows не хотелось от слова совсем. Вердикт: переходим на Proxmox VE 9 (на базе Debian 13).

План А: запуск LLM внутри виртуальной машины

Раз все прочие сервисы работают в изолированных ВМ, логично поместить туда и языковую модель. Классический сценарий: ВМ с Ubuntu, проброс устройства внутрь и запуск flm. Фиаско. Встроенную графику еще можно прокинуть через VFIO, а вот NPU — нет, программный стек к этому банально не готов. На форуме Proxmox профильная ветка так и озаглавлена: «iGPU funktioniert — NPU aktuell nicht».

План Б: развертывание FLM прямо на хосте

Драйвер NPU интегрирован непосредственно в ядро хостовой системы, поэтому flm устанавливается прямо на Proxmox, бок о бок с гипервизором. Математика распределения памяти выглядит следующим образом: из 64 ГБ около 21 ГБ забирает модель, 10–15 ГБ уходит под нужды виртуалок. Виртуальным машинам выделяется строго зарезервированный объем RAM без механизмов dynamic memory/ballooning, иначе в разгар инференса хост может столкнуться с нехваткой страниц под буферы выполнения flm.

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

Мини-руководство: развертывание FLM на Proxmox 9 / Debian 13

Компонент	Характеристика
Процессор	AMD Ryzen AI 9 365 с графикой Radeon 880M (NPU XDNA2)
ОЗУ	64 ГБ, UMA Frame Buffer в BIOS выставлен на минимум
Операционная система	Proxmox VE 9.2 (на базе Debian 13 trixie)
Ядро ОС	7.0.2-6-pve, драйвер `amdxdna` на уровне ядра, прошивка NPU 1.1.2.64
Интерфейс XRT	Пакеты `libxrt2` / `libxrt-npu2` версии 2.25.0–4 (deb-пакеты из ветки Debian sid)
FastFlowLM	Версия 1.0.5
Модель	`qwen3.6-moe:35b-a3b`: объем ~20 ГБ, архитектура MoE, ~3B активных параметров, поддержка мультимодальности

1. Убеждаемся, что ядро видит нейропроцессор

uname -r                 # свежее ядро, у меня 7.0.2-6-pve
lsmod | grep amdxdna     # драйвер успешно подгружен
ls -l /dev/accel/        # должен присутствовать узел accel0
dmesg | grep -i xdna     # микрокод загрузился без ругани

В Proxmox 9 все это работает «из коробки». На более старых ядрах порой выскакивает ошибка Incompatible firmware protocol — в таком случае требуется обновление ядра.

2. Установка XRT и FastFlowLM

Рантайм FLM опирается на библиотеку XRT (компоненту пользовательского пространства для работы с NPU). В стабильной ветке trixie нужных пакетов нет, поэтому вместо подключения репозитория sid целиком я просто скачал два готовых deb-пакета:

cd /tmp wget https://github.com/ROCm/FastFlowLM/releases/download/v1.0.5/fastflowlm\_1.0.5\_debian13\_amd64.deb wget http://deb.debian.org/debian/pool/main/x/xrt/libxrt2\_2.25.0-4\_amd64.deb wget http://deb.debian.org/debian/pool/main/x/xrt/libxrt-npu2\_2.25.0-4\_amd64.deb apt install -y ./libxrt2_2.25.0-4_amd64.deb ./libxrt-npu2_2.25.0-4_amd64.deb \ ./fastflowlm_1.0.5_debian13_amd64.deb

flm validate # проверка ядра, устройства, прошивки и memlock — все должно гореть зеленым

Версии пакетов в репозиториях со временем меняются: если ссылка выдает 404, актуальные имена файлов следует искать на packages.debian.org/sid/libxrt2.

Ограничение memlock. Для работы FLM требуется лимит заблокированной памяти unlimited, в противном случае не удастся выделить буферы под нужды NPU. Установочный пакет прописывает этот параметр самостоятельно. Если команда ulimit -l в SSH-сессии возвращает иные значения, это обусловлено особенностями неинтерактивных оболочек.

3. Загрузка модели

flm list                        # ✅ файлы на месте, ⏬ ничего качать не нужно
flm pull qwen3.6-moe:35b-a3b    # вес ~20 ГБ, процедуру лучше выполнять внутри tmux

4. Оформление системной службы systemd

# /etc/systemd/system/flm-serve.service
[Unit]
Description=FastFlowLM serve (qwen3.6-moe:35b-a3b)
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/flm serve qwen3.6-moe:35b-a3b --host 0.0.0.0 --port 52625 --ctx-len 131072
Restart=on-failure
RestartSec=5
User=root
[Install]
WantedBy=multi-user.target

Верный признак того, что сервер успешно инициализировался, а не тихо скончался на этапе Loading model:

[FLM]  WebServer started on port 52625 with 10 I/O threads

Директивы Restart=on-failure и явное указание --ctx-len здесь прописаны не ради красоты — необходимость этого станет очевидна в третьем акте.

5. Финальная проверка

root@proxmox:~# curl http://localhost:52625/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"qwen3.6-moe:35b-a3b","messages":[{"role":"user","content":"Привет! /no_think"}]}'

{
"model": "qwen3.6-moe:35b-a3b",
"choices": [{ "message": { "role": "assistant", "content": "Привет! Чем могу помочь?" },
"finish_reason": "stop" }],
"usage": {
"prompt_tokens": 16,
"completion_tokens": 9,
"kv_token_occupancy_rate_percentage": 0.019,
"prefill_duration_ttft": 2.7097,
"decoding_duration": 0.6241,
"prefill_speed_tps": 5.90,
"decoding_speed_tps": 14.42
}
}

Помимо привычных полей в блоке usage, FLM возвращает внутренние метрики движка: детальное время и скорость обработки prefill и decode. Сохраните эти данные, они еще сослужат службу.

Тут же бросается в глаза интересная особенность: скорость prefill составляет всего 5,9 ток/с при объеме промпта в 16 токенов. Это не баг. У модели Qwen3.6–35B–A3B на NPU зафиксирована постоянная задержка инициализации в районе 2,7 секунды на любой запрос — фаза prefill разбивается примерно на 4900 последовательных обращений к NPU для обработки экспертных блоков (issue #710). На коротких запросах эти 2,7 секунды доминируют над всем временем ответа, тогда как на длинных промптах эта задержка нивелируется.

Акт 3. Ради чего затевалась вся эта история

Теперь перейдем к мотивации. Мои автоматизированные сервисы генерируют множество запросов размером до 32k токенов, суммарно потребляя около 6 млн токенов за сутки (5,5 млн входящих и 0,5 млн исходящих). По расценкам облачных провайдеров (актуальным на сентябрь 2026 года), в финансовом выражении это выглядит следующим образом:

Модель	Стоимость ввода/вывода за 1M токенов, $	В сутки	В месяц	В год
DeepSeek Flash	0,15–0,30 / 0,60–1,20	$1,1–2,3	$34–68	$411–821
DeepSeek V4 Pro	0,66–1,32 / 1,98–3,96	$4,6–9,2	$139–277	$1 686–3 373
OpenAI GPT-5.6 Luna	0,20 / 1,20	$1,7	$51	$621
OpenAI GPT-6 Sol	2 / 10	$16	$480	$5 840
Claude Haiku 4.5	1 / 5	$8	$240	$2 920
Claude Sonnet 5	2 / 10	$16	$480	$5 840
Claude Opus 5.5	4 / 20	$32	$960	$11 680

Расчеты приведен без учета кеширования промптов и пакетных скидок. У DeepSeek разброс цен отражает дифференциацию на ночные и дневные тарифы.

Для наглядности: весь мини-ПК обошелся мне примерно в $825. При сопоставлении с расценками Claude Sonnet 5 или GPT-6 Sol железо окупается менее чем за два месяца; при сравнении с Claude Haiku 4.5 срок окупленности составляет около 3,5 месяцев, а в сравнении с бюджетным DeepSeek Flash инвестиции окупятся за год-два.

Поначалу я, само собой, пользовался бесплатными API. На практике они продемонстрировали чудовищную нестабильность: примерно половина обращений завершалась ошибками, запускались каскады повторных попыток (ретраев), которые также падали, превращая работу в сплошную полосу сбоев. Локальная установка решает обе проблемы разом: платишь за железо один век, а падает модель исключительно по твоей вине. Ну, почти.

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

Сюрприз 1: прыгающее время отклика

Запросы идентичного объема отрабатывались то за 35 секунд, то внезапно за 170. Внутренние метрики FLM быстро расставили всё по местам: NPU обслуживает строго по одному запросу за раз. У утилиты flm serve есть FIFO-очередь (управляется параметром --q-len, по умолчанию равным 10), но никакого параллелизма физически нет.

Два запроса поступили одновременно. Расчетное время выполнения второго составляло 55,6 с, но фактическое выросло до 114,7 с. Разница в точности равна длительности обработки первого запроса.

Сюрприз 2: ошибка double free

Очередь — полбеды. У HTTP-клиентов по умолчанию был выставлен таймаут в 120 секунд. Если запрос подолгу простаивал в очереди, клиент терял терпение и отменял соединение. В этот момент FLM при попытке прервать фазу prefill аварийно завершался, утягивая за собой всю накопившуюся очередь:

Client disconnected; cancelling active request
Prefill Cancelled
Clearing context...
double free or corruption (!prev) # или банальный SIGSEGV

Худший сценарий реализовался, когда один из сервисов единовременно запулил 26 параллельных запросов с параметром max_tokens: 70000. Очередь раздулась до предела, лавина отмен обрушила сервер, и flm лег окончательно. Данный баг зафиксирован разработчикам под номером #608.

Что помогло стабилизировать систему:

Увеличение клиентских таймаутов до нескольких минут (у меня задано 20 минут для тяжелых задач). Уж лучше пусть подождет, чем обрывает соединение.
Активация директивы Restart=on-failure в systemd: демон поднимает упавший flm примерно за 15 секунд. Баг остался нерешенным, но по крайней мере перестал будить меня среди ночи.
Явное задание параметра --ctx-len. Значение по умолчанию составляло 32k, и промпты объемом около 38k токенов приводили к ошибке max length reached during prefill с последующим падением.
Вынос тяжелых промптов в облачные API. Обработка простыней текста на 38k токенов занимала у NPU по 6–7 минут, блокируя всю остальную очередь. Такие задачи проще делегировать вовне.

Сюрприз 3: Connection limit reached (10)

Когда к NPU стали стучаться уже три независимых микросервиса, каждый со своими аппетитами к многопоточности, в логах FLM начали регулярно мелькать записи Connection limit reached (10), rejecting new connection. Каждый отдельный сервис вел себя прилично, но о существовании соседей понятия не имел.

Первой мыслью было установить --q-len 1, чтобы принудительно заставить FLM сериализовать входящий поток. Стало только хуже: один зависший запрос намертво оккупировал единственный слот, а остальные клиенты получали пятисотую ошибку. Очередь глубиной 10 хотя бы растягивала задержки, тогда как очередь в единицу превращала просадку в тотальный отказ. Пришлось вернуть параметры по умолчанию.

Рабочим решением оказалось развертывание шлюза-контроллера на входе — прокси LiteLLM (llm-proxy), установленного перед flm для ограничения глобального трафика.

Фейс-контроль llm-proxy перед NPU — Фейс‑контроль llm‑proxy перед NPU

model_list: model_name: flm-chat litellm_params: model: openai/qwen3.6-moe:35b-a3b api_base: http://:52625/v1 api_key: "not-needed"

general_settings: master_key: os.environ/LITELLM_MASTER_KEY global_max_parallel_requests: 3 # жесткий лимит на все запросы к NPU store_prompts_in_spend_logs: true # иначе в логах запросов будет зиять "Data Not Available"

Использование различных model_name для единого бэкенда позволяет легко отслеживать в логах аппетиты каждого конкретного клиента без настройки виртуальных ключей и БД.
Проверку жизнеспособности (liveness probe) для прокси следует вешать на /health/liveliness. Стандартный эндпоинт /health опрашивает сам flm, который под нагрузкой может отвечать секундами.
Не стоит доверять графе TTFT в логах LiteLLM: для не-стриминговых запросов она отображает общее время выполнения. Истинный TTFT фиксируется в поле prefill_duration_ttft внутри блока usage от FLM.

Сюрприз 4: неугомонный режим мышления (thinking)

Бизнес-логике сервисов требовался строгий JSON, а не пространные рассуждения модели. Ни параметр enable_thinking: false, ни chat_template_kwargs, ни попытки отключить рассуждения через промпт для Qwen3.6 в связке с flm не возымели эффекта — это известная особенность самой модели, проявляющаяся также в vLLM, SGLang и llama.cpp. Реально помогал только оператор /no_think непосредственно в тексте запроса: без него выдавался ответ объемом в 59 токенов с рассуждениями, а с ним — мгновенный результат. Для принудительного получения строгого JSON этого оказалось достаточно.

Сюрприз 5: эмбеддинги вытесняют основную модель

Для организации семантического поиска потребовалась генерация векторных представлений (эмбеддингов). В каталоге FLM присутствует модель embed-gemma:300m, активируемая ключом --embed 1. Пока NPU свободен, все работает великолепно — один вектор размерности 768 просчитывается за 0,29 секунды. Однако под нагрузкой рядом с тяжелой 35B моделью подобные запросы подвисают на минуты, после чего в логах начинает пестреть:

[ERROR] Unsupported model family or non-llm: "embed-gemma"

Следствием этого становилась выгрузка 35B модели из памяти, загрузка легковесной llama3.2:1b, генерация эмбеддинга ею и последующая мучительная перезагрузка тяжеловесной Qwen обратно. Всё это сопровождалось несколькими минутами простоя для всех потребителей.

Проблема была решена элегантно: та же самая модель embeddinggemma-300M в квантовании GGUF Q8_0 была запущена через llama.cpp на центральном процессоре (CPU), аккуратно прописавшись отдельным маршрутом в том же llm-proxy. Результат превзошел ожидания: 0,06–0,11 секунды на запрос и 15 параллельных обращений подряд без единого сбоя. Маленькой модели NPU оказался попросту не нужен, зато исчез риск разрушить общую очередь вычислений.

Метрики и цифры

Все приведенные ниже замеры получены для модели Qwen3.6–35B–A3B на системе с Ryzen AI 9 365 под управлением FLM 1.0.5 на реальных запросах из логов в условиях отсутствия очереди.

Характер запроса	Вход, токенов	Выход, токенов	Prefill, токен/с	Decode, токен/с
Тестовое «Привет» из curl	16	9	5,9	14,4
Текстовый документ	1 046	192	109,1	17,1
Изображение + промпт	1 127	61	99,1	16,9
Текстовый документ	5 699	98	193,2	15,6
Текстовый документ	6 135	103	196,9	15,7
Текстовый документ	6 902	405	205,6	15,7
Объемный документ	17 653	1 187	209,9	13,3
Объемный документ	17 980	1 375	211,4	13,2

с учетом фиксированных накладных расходов в ~2,7 с на запрос, подробнее см. в разделе ссылок.

Скорость prefill и decode от размера промпта

Картина предельно ясна: чем больше объем входного промпта, тем выше эффективная скорость prefill (фиксированные издержки размазываются по большому объему) и тем ниже скорость генерации decode (по мере заполнения KV-кэша). Обработка изображений по скорости незначительно уступает текстовым запросам сопоставимого размера. Прикидывая производительность на промптах в диапазоне 5–18k токенов, получаем около 200 токен/с на prefill и 13–16 токен/с на decode.

Официальные бенчмарки FLM для той же модели (на стенде с Ryzen AI 7 350 и 96 ГБ ОЗУ)

Контекст	Prefill, токен/с	Decode, токен/с
1k	102	17,5
32k	281	11,2

Мои замеры демонстрируют отличную сходимость с официальными данными: на промптах в 1k токенов показатели практически идентичны.

Сравнение CPU, NPU и дискретной RTX 3090

По сравнению со старым центральным процессором прогресс колоссален: прирост скорости prefill примерно в 6 раз, а генерации — в 2 раза. Среднее время обработки вызова сократилось с ~513 с до ~78 с, хотя здесь сказывается не только аппаратное ускорение NPU, но и ликвидация узких мест в очереди запросов.

В противостоянии с полноценной дискретной видеокартой NPU ожидаемо проигрывает подчистую: на той же квантованной в Q4 модели RTX 3090 выдает prefill на уровне 2400–2600 токен/с (превосходя соперника в 13 раз) и скорость генерации 60–75 токен/с (опережая в 4–5 раз). Сильные стороны NPU лежат в иной плоскости: абсолютная тишина, скромное энергопотребление и возможность запускать 35-миллиардную модель в корпусе размером с коробку из-под печенья.

Итог: имеет ли затея смысл

Определенно да, если:

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

Категорически нет, если:

критически важен параллелизм обработки (NPU один, очередь тоже единая);
необходима высокая интерактивность: скорость генерации 13–17 токен/с для живого общения маловата;
объем модели вместе с контекстом превышает половину доступной оперативной памяти.

А доводилось ли вам экспериментировать с нейропроцессорами от AMD или Intel? Удалось ли кому-нибудь запустить гибридный режим NPU+iGPU под Linux с моделями крупнее 8B? Обязательно делитесь опытом в комментариях: профильной информации по теме исчезающе мало, и любые практические наработки на вес золота.