Що сталося

Вихідна машина на Ryzen 7 5800U без відеокарти майже весь час витрачала на читання довгого промпта, а не на відповідь. Маркетинг AMD обіцяв виграш саме на цій фазі, і автор обрав FIREBAT на Ryzen AI 9 365: коробка плюс пам’ять вийшли приблизно в 70 тис. ₽. Звичний стек llama.cpp / Ollama / LM Studio NPU не використовує. Lemonade від AMD обіцяв гібрид, але лише для заздалегідь підготовлених малих моделей на Windows. Для Qwen3.6–35B лишилася окрема середовище виконання FastFlowLM (flm) із каталогом моделей під NPU.

На Windows драйвер NPU довелося добувати окремо, а після запуску з’ясувалося, що NPU бачить близько половини оперативки, яку показує система, плюс налаштування плати заздалегідь відрізають шмат під вбудовану графіку. Модель близько 20 ГБ плюс кеш і другий запит уже не вміщувалися — лікувалося мінімумом UMA Frame Buffer у налаштуваннях плати. Гібрид так і не знадобився, тому автор переїхав на Proxmox VE 9: NPU у віртуалку не прокидається, а flm запустився просто на хості поруч із гіпервізором. Пам’ять віртуалкам зафіксували жорстко, без «повітряної кулі», щоб у момент виводу моделі хост не лишився без сторінок.

Коли до сервера підключилися сервіси з добовим потоком близько 6 млн токенів, виявилися обмеження заліза. Один NPU — як одна каса в магазині: черга є, паралельної роботи немає. Клієнт із таймаутом 120 с скасовував запит під час читання промпта, і flm падав із пошкодженням пам’яті, забираючи всю чергу. Окремо модель для векторних представлень на тому ж NPU іноді вивантажувала велику модель заради маленької. Робочий контур: довгі таймаути, Restart=on-failure, явний --ctx-len, проксі зі спільною стелею паралелізму та ембедінги на CPU через llama.cpp.

Чому це важливо

Локальна велика модель обіцяє тишу, передбачуваний рахунок і незалежність від чужого API. Цифри автора для його профілю навантаження показують, що залізо близько $825 окупається за місяці проти дорогих хмарних тарифів — і за рік‑два проти найдешевших. Але NPU тут не заміна відеокарті: проти RTX 3090 він програє в рази і за читанням, і за генерацією. Виграш в іншому — енергоспоживання, шум і компактність.

Для продакшену важливіша не пікова швидкість на одному запиті, а поведінка під чергою. Один потік, падіння на скасуванні, витіснення моделі ембедінгами — це вже архітектура сервісу, а не «поставив і забув». Без спільного входу перед NPU кілька клієнтів самі влаштовують шторм, який один чип не перетравить.

На практиці

Текст — докладний розбір із цифрами, а не універсальна рекомендація купити будь‑який міні‑ПК з наліпкою «ШІ». Має сенс, якщо потрібна велика модель із сумішшю експертів цілодобово в тихій коробці, навантаження фонове, промпти довгі, відповіді короткі. Слабо пасує для живого чату на 13–17 ток/с і для сценаріїв зі справжньою паралельністю.

1. Рахуйте доступну NPU пам’ять як приблизно половину RAM мінус резерв налаштувань плати під вбудовану графіку; 32 ГБ для моделі ~20 ГБ зазвичай мало.
2. Не чекайте гібрида NPU і вбудованої графіки на великих моделях: для 35B автор пішов на чистий NPU через flm.
3. На Proxmox тримайте flm на хості: прокидання NPU у ВМ поки сире.
4. Перед NPU поставте один проксі зі спільним лімітом паралелізму; таймаути клієнтів робіть довшими за найгіршу чергу.
5. Ембедінги й наддовгі промпти краще вивести з NPU, щоб не витісняти основну модель і не блокувати чергу на хвилини.

Підсумок

Міні‑ПК з NPU може тягнути серйозну локальну LLM цілодобово, якщо прийняти, що чип — одна черга, а не ферма. Автор дійшов до стабільної зв’язки Proxmox + FastFlowLM + Qwen3.6–35B і зрозумілих швидкостей на довгих промптах. Ціна питання — пам’ять, драйвери, дисципліна клієнтів і окремий шлях для задач, які NPU ламають.