Запит завжди починається однаково: «Ми ввімкнули AI‑фічу, і тепер ноутбуки гарячі, вентилятори ревуть, а черга у helpdesk виглядає як атака відмови в обслуговуванні.» Хтось пропонує «просто використовувати CPU, це нормально». Інша людина радить купити GPU для всіх, і так скромний запит перетворюється на слухання бюджету.
NPUs існують тому, що обидва цих інстинкти зазвичай помилкові в продакшні. CPU можуть виконувати AI, так. Вони також можуть смажити тости.
Це не означає, що ви хочете, аби вони весь день працювали як тостер, коли одночасно виконують ваші таблиці, відеодзвінки та захисні агенти.
NPUs, простою мовою: що це (і чого це не є)
NPU (Neural Processing Unit) — це спеціалізований акселератор, створений для ефективного виконання математики нейронних мереж:
багато операцій множення‑додавання, щільна лінійна алгебра та відповідні шаблони руху даних.
Мета не «найшвидше за будь‑яку ціну», а «достатньо швидко при дуже низькому споживанні енергії, із передбачуваною затримкою,
не захоплюючи всю систему».
У сучасних клієнтських системах (ноутбуки, планшети, телефони) NPU зазвичай інтегрований на кристалі або в упаковці разом із CPU,
часто з спільною пам’яттю та міжз’єднанням. У серверах частіше зустрічаються дискретні акселератори (GPU, TPU, карти для inference),
бо там більші ліміти потужності й охолодження і важчі робочі навантаження. Але та сама логіка лишається:
перемістити правильні обчислення на правильний рушій.
Чого NPU не є:
- Не заміна для GPU, якщо ви тренуєте великі моделі або виконуєте масовий пакетний inference.
- Не магія, якщо ваше вузьке місце — пропускна здатність пам’яті, диск I/O або повільний pre/post‑processing.
- Не автоматично швидший для кожної моделі; покриття операторів, квантування та підтримка фреймворку визначають результат.
Чому існують NPUs: обмеження, які CPU не можуть відмінити
CPU — це універсал. Він зроблений, щоб робити мільйон різних речей прийнятно добре: розгалужений код, робота ОС, шифрування,
мережі, різна бізнес‑логіка — усі ті гострі кути, що роблять програмне забезпечення «реальним». CPU також побудований навколо
низької затримки доступу до кешів, широкого спекулювання та складної керуючої логіки. Це дорого в силіконі та енергії.
Натомість інференс нейронних мереж часто домінують:
- Матрицеві множення (GEMM) і операції, схожі на згортки.
- Висока арифметична інтенсивність, коли пере використання даних хороше, але тиск на пропускну здатність пам’яті, коли ні.
- Математика низької точності (INT8, FP16, BF16), яку CPU може робити, але не так ефективно за ват як спеціалізований двигун.
NPUs існують тому, що «модель витрат» для клієнтського AI жорстока:
- Потужність: Користувачі відразу помічають розряд батареї та шум вентиляторів. Хмарні рахунки — інша проблема; користувачі цього не чують.
- Термічний режим: Тривалий інференс на CPU може призвести до тротлінгу, і тоді все інше теж уповільнюється.
- Затримка: Особливості на пристрої (розмиття фону, транскрипція, wake‑word, покращення зображення) потребують низької та стабільної затримки.
- Конкурентність: CPU також має виконувати ОС, браузер, EDR‑агента та інші автозапуски вашої компанії.
Якщо ви колись бачили, як ноутбук намагається транскрибувати аудіо на CPU під час відеодзвінка, ви бачили цей фільм.
Поворот сюжету завжди однаковий: у лабораторії фіча «лише 10 мс на кадр», а в полі вона перетворюється на
«випадкові стрибки до 200 мс і зустріч перетворюється на слайд‑шоу».
Реальність «AI на CPU»: що відбувається насправді
Так, CPU можуть виконувати інференс. Сучасні x86 і ARM ядра мають векторні розширення (AVX2/AVX‑512 на x86; NEON/SVE на ARM),
і існують тоновані бібліотеки (oneDNN, варіанти BLAS, вендорні ядра), що роблять пристойну роботу.
Але «пристойно» не те саме, що «дешево і передбачувано».
У продакшні інференс на CPU провалюється у кількох повторюваних способах:
1) Ви вдаряєтеся в стіну пам’яті, а не в стіну обчислень
Багато завдань інференсу фактично пов’язані з пропускною здатністю пам’яті, особливо коли ваги не вміщаються в кеш.
Можна мати багато векторних обчислювальних ресурсів і все одно постійно простоювати в очікуванні даних.
Коли CPU простає, він споживає енергію, не роблячи багато корисного, а ваша затримка стає нестабільною.
2) Ви боретесь із планувальником
CPU використовують тайм‑слайсинг. Це й має бути. Але для реалістичних AI‑фіч важливі пріоритети та прерваність.
ОС, фонові сервіси та інші додатки перериватимуть ваші інференс‑трейди.
Якщо «оптимізувати» шляхом прив’язки ядер або нарощення кількості потоків, ви можете виграти тест, але програти користувацький досвід.
3) Вибір точності стає продуктним вибором
Інференс на CPU зазвичай потребує квантування (INT8, іноді INT4), щоб бути конкурентоспроможним.
Квантування — це не просто ручка продуктивності; воно впливає на точність моделі, стабільність виходу та поведінку в краєвих випадках.
В корпоративному контексті «точність регресувала для деяких акцентів» стає питанням відповідності та HR, а не просто технічною нотаткою.
4) Ви платите податок інтеграції
Щоб «AI на CPU» працював добре, потрібно вибрати правильний рантайм, правильні ядра, правильну конфігурацію потоків
і правильний формат моделі. Це можливо. Але це робота. NPUs існують, щоб зменшити витрати повторення цієї роботи
по флоту.
Є одне сухе правило, що дійсне: якщо модель «гарно» працює на робочій станції розробника, очікуйте, що на середньому ноутбуку вона працюватиме «гостро».
Ваш середній ноутбук — це місце, куди йдуть щастя.
Всередині коробки: як NPUs будують по‑іншому
На високому рівні NPU — це конвеєр, призначений для операцій з тензорами. Деталі різняться у вендорів, але теми послідовні:
Потік даних проти спекуляції
CPU виграють у непередбачуваних контрольних потоках. NPUs припускають протилежне: обчислювальний граф відомий, операції повторювані,
і найкраще, що ви можете зробити — тримати дані в русі через MAC‑блоки з мінімальною керуючою накладною витратою.
Менше передбачення гілок, менше складності out‑of‑order, більше стабільної пропускної здатності.
Локальна пам’ять і тайлінг — пріоритет
NPUs зазвичай мають локальні пам’яті, схожі на SRAM (scratchpad), якими явно керує компілятор/рантайм.
Це не випадковість; так уникають звернень до DRAM при кожному повторному використанні ваг або активакцій.
Рантайм нарізає тензори на тайли, що поміщаються локально, виконує шматок роботи й переходить далі.
Низька точність — за замовчуванням
NPUs найщасливіші, коли ви даєте їм INT8/INT16/FP16/BF16 та операції, які вони розпізнають.
Вони часто мають спеціальні інструкції для злитих операцій (наприклад, згортка + активація або GEMM + bias + активація),
оскільки злиття економить пропускну здатність і зменшує кількість звернень у пам’ять.
Передбачувана затримка — продуктова вимога
У клієнтських пристроях «відчуття» важить більше за пікову пропускну здатність. Це визначає вибір архітектури:
обмежені черги, апаратні планувальники й ізоляція, щоб NPU міг виконувати фоні AI‑задачі, не відбираючи обід у CPU.
Корисна ментальна модель: CPU проєктують навколо керування. GPU — навколо пропускної здатності.
NPU — навколо пропускної здатності на ват з компіляторно‑керованою пам’яттю.
NPU vs GPU vs CPU: обираємо компроміс
Якщо потрібно вирішити, де виконувати інференс, користуйтеся таким підходом: що ви оптимізуєте — вартість, затримку, енергію чи інженерний час?
Неправильна відповідь — «що доступне». Так CPU опиняється з 80% роботи, а NPU тихо чекає, поки ви перестанете бути креативними.
CPU: найкраще для «склеювання», малих моделей і «має працювати скрізь»
- Плюси: універсальна доступність; відмінний для pre/post‑processing; просте відлагодження; зрілий інструментарій.
- Мінуси: обмеження по енергії/терміні; змінна затримка під навантаженням; часто прив’язаний до пам’яті; збільшення потоків може шкодити.
- Коли використовувати: модель невелика, цикл роботи низький, або портативність важливіша за пікову ефективність.
GPU: найкраще для великої пропускної здатності і тренувань (і багатьох випадків інференсу)
- Плюси: масивний паралелізм; зріла екосистема; сильна підтримка FP16/BF16; відмінна батч‑пропускна здатність.
- Мінуси: енергоспоживання; дискретні GPU додають вартість/складність; малі реальні задачі реального часу страждають від накладних витрат запуску.
- Коли використовувати: великі моделі, високі вимоги до пропускної здатності або тренування. Або ви вже в середовищі GPU і це дешевше операційно.
NPU: найкраще для інференсу на пристрої з жорсткими бюджетами потужності і затримки
- Плюси: відмінний perf/W; може працювати завжди‑увімкненими задачами; ізолює AI‑роботу від CPU; добрий для приватності (без кругових викликів у хмару).
- Мінуси: прогалини в покритті операторів; інструменти різняться; конвертація моделі може бути болючою; ризик вендор‑локінгу.
- Коли використовувати: ви постачаєте клієнтські фічі по флоту і потрібні передбачувана батарея/терміки та консистентний користувацький досвід.
Жарт, як і обіцяли: NPU схожий на навантажувач — чудово переміщає піддони, погано пише листи, і все одно його за щось звинувачують.
Цікаві факти та коротка історія
Десять коротких фактів, щоб відшліфувати інстинкти. Це не тривіальні факти; вони пояснюють, чому екосистема виглядає так, як виглядає.
- Нейронні акселератори не нові. DSP‑и й ранні ASIC для inference існували задовго до того, як «NPU» стало маркетинговим терміном; просто вони не були модними.
- Мобільні пристрої рухали ранній розвиток NPU. Телефони потребували on‑device зору й мови без підсмаження батареї, що штовхнуло вендорів до виділених блоків.
- Квантування стало мейнстрімом через енергію. INT8 інференс не запровадили тому, що інженерам подобається менша точність; його запровадили через батареї.
- Tensor‑ядра змінили очікування. Тензорні блоки GPU популяризували змішану точність і зробили «спеціалізовану матричну математику» частиною планування AI.
- Стек компілятора став стратегічним. Для NPU компілятор і оптимізатор графів можуть мати таке ж значення, як і силікон. Іноді навіть більшу.
- Покриття операторів — реальне обмеження. Якщо NPU не підтримує оп чи шаблон злиття, ви відкотитесь на CPU/GPU і продуктивність впаде.
- Маркетингові «TOPS» ховають складну частину. Пікові тера‑операції часто припускають ідеальні ядра, ідеальний тайлінг і нуль витрат на рух даних. Реальність виставляє рахунок за пам’ять.
- On‑device AI — це також історія про приватність. Обробка аудіо/відео локально зменшує експозицію даних і юридичні ризики, що тихо подобається підприємствам.
- Windows та Linux дозрівають нерівномірно. Деякі NPU мають першокласну інтеграцію в ОС; інші виглядають як шкільний проєкт, прилаштований до драйвера.
- Edge‑inference все більше про оркестрацію. «Акселератор» — це не лише чип; це формат моделі, рантайм, планування, політика живлення та обсервабельність.
Швидкий план діагностики: знайти вузьке місце оперативно
Коли AI‑фіча «повільна», у вас є близько 20 хвилин, перш ніж хтось запропонує переписати все на Rust.
Ось план дій, що працює на ноутбуках, робочих станціях розробників і edge‑боксах.
По‑перше: підтвердіть, де реально виконується інференс
- Ціль: Чи виконується модель на CPU, GPU, NPU — або «стрибає» між ними?
- Чому: Змішане виконання часто виглядає як «використовує акселератор», тоді як насправді багато опів падає на CPU через відсутність підтримки.
По‑друге: вирішіть, чи ви compute‑bound або memory‑bound
- Ціль: Ядра завантажені обчисленнями або простягаються в очікуванні пам’яті й промахів кеша?
- Чому: Якщо ви memory‑bound, «більше потоків» — це як підливати бензин у вогонь.
По‑третє: перевірте термічний і енергетичний тротлінг
- Ціль: Система знижає тактову частоту під тривалим навантаженням?
- Чому: Тротлінг перетворює графіки продуктивності на сучасне мистецтво: різкі сплески і важко обґрунтувати.
По‑четверте: профілюйте весь конвеєр, а не тільки модель
- Ціль: Виміряйте декодування, зміну розміру, витяг ознак, токенізацію та пост‑обробку.
- Чому: Часто «модель» — лише половина затримки; решта — ваш glue‑код і I/O.
По‑п’яте: перевірте покриття операторів / частоту відкатів
- Ціль: Визначити, які опи не підтримуються на NPU і де відбувається fallback.
- Чому: Одна неподтримана операція в неправильному місці може змусити цикл копій пристрій→хост, який руйнує продуктивність і енергоефективність.
Один операційний вислів, щоб не забувати реальність, перефразовано, бо точність важлива: перефразована ідея
— Gene Kranz:
«Суворий і компетентний» перемагає «хитромудрого», коли системи під тиском.
Практичні завдання: команди, виводи та рішення (12+)
Ці завдання розроблені для реального світу: у вас є коробка, рантайм моделі і скарга.
Кожне завдання включає команду, приклад виводу, що означає вивід, і яке рішення ви приймаєте далі.
Команди орієнтовані на Linux, бо тут видно механіку. Якщо ви на Windows/macOS, принципи все одно застосовні.
Завдання 1: Визначити можливості CPU, важливі для inference (AVX/AVX‑512 тощо)
cr0x@server:~$ lscpu | egrep -i 'Model name|Socket|Thread|Core|Flags'
Model name: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
Socket(s): 2
Core(s) per socket: 16
Thread(s) per core: 2
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... avx2 avx512f avx512bw avx512vl ...
Значення: Маєте AVX2 і AVX‑512. Багато CPU‑бібліотек для inference вибиратимуть різні ядра залежно від цих прапорців.
Рішення: Якщо AVX‑512 відсутній у цільовому флоті, не бенчмаркьте лише на Xeon у девелоперській машині й не оголошуйте перемогу. Будуйте бази на репрезентативному обладнанні.
Завдання 2: Перевірити, чи ядро бачить акселератор, схожий на NPU
cr0x@server:~$ lspci -nn | egrep -i 'neural|npu|vpu|accelerator|inference'
00:0b.0 Processing accelerators [1200]: Intel Corporation Device [8086:7d1d] (rev 01)
Значення: PCI‑шар бачить «processing accelerator». Це початок, але не доказ, що його можна використовувати.
Рішення: Продовжуйте до перевірок драйвера і рантайму. Якщо нічого не з’являється, можливо, пристрій інтегрований і експонується інакше, або просто у вас немає NPU.
Завдання 3: Підтвердити, що драйвер завантажений (і не падає мовчки)
cr0x@server:~$ lsmod | egrep -i 'vpu|npu|accel|ivpu|amdxdna'
ivpu 151552 0
accel_core 32768 1 ivpu
Значення: Модулі ядра присутні. Це зменшує ймовірність, що ви застрягли в CPU‑фолбеку через відсутність драйверів.
Рішення: Якщо модулі не завантажені, перевірте dmesg на предмет помилок прошивки та ініціалізації перед тим, як звинувачувати рантайм.
Завдання 4: Прочитати dmesg щодо ініціалізації акселератора та проблем з прошивкою
cr0x@server:~$ dmesg -T | egrep -i 'ivpu|npu|vpu|firmware|accel' | tail -n 20
[Mon Jan 12 09:02:11 2026] ivpu 0000:00:0b.0: enabling device (0000 -> 0002)
[Mon Jan 12 09:02:11 2026] ivpu 0000:00:0b.0: loading firmware intel/vpu/vpu_37xx.bin
[Mon Jan 12 09:02:12 2026] ivpu 0000:00:0b.0: initialized successfully
Значення: Прошивка завантажена і пристрій ініціалізовано. Якщо ви бачите повторні скидання або «failed to load firmware», очікуйте, що продуктивність буде «тільки CPU».
Рішення: Спершу виправте прошивку/драйвер. Налаштування моделі не допоможе, якщо акселератор не працює.
Завдання 5: Підтвердити масштабування частоти CPU і виявити ризик тротлінгу
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Значення: У вас встановлено powersave. Добре для батареї; можливо, погано для бенчмарків латентності.
Рішення: Для контрольованих тестів переключіться на performance. У продакшні дотримуйтеся політик живлення, але вимірюйте в їх межах.
Завдання 6: Змінити governor для прогону бенчмарку (тільки контрольовані тести)
cr0x@server:~$ sudo bash -lc 'for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > $c; done'
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
Значення: Ви зменшили варіативність частоти.
Рішення: Якщо продуктивність значно покращилася, проблема «AI повільний» може бути політикою живлення, а не архітектурою. Вирішіть, чи можна запитати вищий QoS для навантаження.
Завдання 7: Виміряти насичення CPU і тиск планувальника під час inference
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server) 01/12/2026 _x86_64_ (64 CPU)
09:10:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
09:10:02 AM all 78.12 0.00 3.10 0.02 0.00 0.55 0.00 18.21
09:10:02 AM 12 99.00 0.00 0.80 0.00 0.00 0.20 0.00 0.00
09:10:02 AM 13 98.50 0.00 1.00 0.00 0.00 0.50 0.00 0.00
Значення: Декілька ядер завантажені по максимуму; загалом CPU високо завантажений. Це вказує або на single‑stream compute‑bound, або на прив’язку потоків.
Рішення: Якщо затримка важлива, розгляньте меншу кількість потоків з кращою локальністю кеша, або перенесіть гарячий шлях на NPU/GPU, якщо підтримується.
Завдання 8: Виявити тиск пам’яті та свопінг (тихий вбивця інференсу)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 31Gi 27Gi 1.2Gi 196Mi 3.0Gi 2.1Gi
Swap: 8.0Gi 3.4Gi 4.6Gi
Значення: Використовується swap. Це червоний прапорець для латентності і джиттера інференсу.
Рішення: Зменшіть розмір моделі, використайте квантування або застосуйте ліміти пам’яті. Якщо потрібно виконувати локально — уникайте свопінгу за будь‑яку ціну.
Завдання 9: Підтвердити, чи ви не I/O‑bound через завантаження моделі
cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 01/12/2026 _x86_64_ (64 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
42.10 0.00 2.80 18.60 0.00 36.50
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 320.0 86000.0 0.0 0.00 12.40 268.8 10.0 512.0 1.20 4.10 92.00
Значення: Висока зайнятість диска й iowait під час прогонів. Можливо, ви вимірюєте завантаження моделі та page‑faults, а не обчислення.
Рішення: Розігрівайте модель у пам’ять, обережно використовуйте memory‑mapped ваги і розділяйте «startup latency» від «steady‑state inference latency».
Завдання 10: Перевірити топологію NUMA (серверний inference часто спотикається тут)
cr0x@server:~$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 128790 MB
node 0 free: 12410 MB
node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 128733 MB
node 1 free: 80210 MB
Значення: Пам’ять нерівномірно вільна між NUMA‑вузлами. Якщо процес працює на вузлі 0, а виділення пам’яті йде на вузол 1, латентність йде вбік.
Рішення: Закріпіть процес і його алокації пам’яті до того самого NUMA‑вузла для відтворюваних результатів, особливо для CPU‑inference.
Завдання 11: Запустити з NUMA‑pinning, щоб зменшити віддалений доступ до пам’яті (бенчмарк)
cr0x@server:~$ numactl --cpunodebind=0 --membind=0 ./inference_bench --model ./models/model.int8.onnx --threads 16
model_load_ms=420
p50_latency_ms=18.2
p95_latency_ms=23.9
throughput_qps=54.1
Значення: Поліпшена хвостова латентність зазвичай вказує, що раніше ви платили за віддалені NUMA‑штрафи.
Рішення: Якщо не можете закріпити в продакшні, принаймні виявляйте NUMA і уникайте патологічних розміщень у конфігурації менеджера сервісів.
Завдання 12: Підтвердити, які спільні бібліотеки ви дійсно використовуєте (вибір ядра має значення)
cr0x@server:~$ ldd ./inference_bench | egrep -i 'onnx|dnn|mkl|openvino|cuda|tensorrt'
libonnxruntime.so.1 => /usr/local/lib/libonnxruntime.so.1 (0x00007f8c1c000000)
libmkl_rt.so.2 => /opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_rt.so.2 (0x00007f8c17000000)
Значення: Ви використовуєте ядра на базі MKL (добре для CPU). Якщо ви очікували провайдера виконання на NPU, його тут немає.
Рішення: Виправте конфігурацію рантайму. Не бенчмаркьте «тільки CPU» і не називайте це «повільний NPU».
Завдання 13: Трасувати переключення контексту та міграції (джерело джиттера)
cr0x@server:~$ pidof inference_bench
24817
cr0x@server:~$ sudo perf sched record -p 24817 -- sleep 10
cr0x@server:~$ sudo perf sched latency | head
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms
inference_bench:24817 | 9521.330 | 8212 | 0.141 | 7.882
Значення: Багато переключень і деякі нетривіальні максимальні затримки. Для реального часу‑подібного inference ці спайки проявляються як помітні затримки для користувача.
Рішення: Розгляньте зменшення кількості потоків, встановлення афінітету CPU або перенесення навантаження з CPU, якщо потрібна консистентна латентність.
Завдання 14: Спостерігати сигнали енергії/термічного тротлінгу (на системах, що їх експонують)
cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 --num_iterations 3
CPU Avg_MHz Busy% Bzy_MHz TSC_MHz PkgTmp PkgWatt
- 1890 72.15 2620 2400 92 54.30
- 1710 74.02 2310 2400 96 55.10
- 1605 76.40 2100 2400 99 55.40
Значення: Температура зростає, і ефективний MHz падає. Це поведінка тротлінгу або її початок.
Рішення: Якщо вам потрібен тривалий інференс, NPU (або правильно охолоджений GPU) краще підходить. Інакше зменшіть duty cycle, зменшіть модель або прийміть нижчу якість.
Завдання 15: Підтвердити обмеження cgroup CPU (контейнери люблять дивувати)
cr0x@server:~$ cat /sys/fs/cgroup/cpu.max
200000 100000
Значення: Процес обмежений до еквіваленту 2 CPU. «Чому повільно» може бути «бо ви наказали йому бути повільним».
Рішення: Відрегулюйте ліміти CPU або підігнайте модель під квоту. І ще: не порівнюйте бенчмарки контейнера з bare‑metal без згадки про кап.
Завдання 16: Перевірити hugepages і статус THP (може впливати на доступи до великих ваг)
cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
Значення: THP у режимі madvise. Чи допомагає це — залежить від алокатора й шаблону доступу.
Рішення: Якщо ви бачите накладні витрати на page‑fault і збій TLB у профілюванні, експериментуйте з налаштуваннями THP у контрольованому тесті. Не міняйте це на всьому флоті як «фікс продуктивності» без доказів.
Три корпоративні міні‑історії з поля бою
Міні‑історія 1: Інцидент через неправильне припущення
Середня компанія випустила «on‑device summarization» для внутрішніх нотаток із зустрічей. Архітектори порахували:
модель була квантизована, CPU‑inference у тихій лабораторії виглядав прийнятним, і NPU «буде пізніше».
План розгортання припускав, що «CPU завжди доступний» означає «CPU завжди доступний для цієї задачі».
Через два дні після релізу підскочили звернення в техпідтримку. Користувачі скаржилися, що відеодзвінки пригальмовують і машини гарячі.
IT помітили погане: сканування endpoint‑захисту тайм‑аутилося, бо CPU був завантажений настільки, що інші агенти пропускали свої вікна. Нічого не падало, але все стало гірше за раз — класичний повільний інцидент.
Неправильне припущення було тонким: команда вимірювала середню затримку на інференс, а не девюті‑цикл.
У продакшні фіча працювала постійно у фоні, щоб «залишатися готовою». Використання CPU стало стійким,
термічний запас заповнився, CPU знизив частоту, і хвостова затримка всього іншого пішла нелінійно вгору.
Виправлення було оперативним, не героїчним. Вони перемістили завжди‑увімкнену частину (витяг ознак і маленькі embed‑представлення)
на NPU там, де підтримується, і змінили поведінку продукту: підсумки генерувалися за вимогою, а не передбачувано постійно. Також додали правило «зменшувати частоту під навантаженням» на основі температури CPU і метрик затримки планувальника.
Ключовий урок: якщо ваша AI‑фіча є безперервною, ставтеся до неї як до демона. Демони потребують бюджетів, а не оптимізму.
Міні‑історія 2: Оптимізація, що обернулася проти
Інша компанія випустила edge‑пристрій для реального часу виявлення аномалій у відеопотоці.
Інженер з продуктивності помітив, що блоки згортки моделі були дружні до NPU, а pre‑processing виконувалися на CPU.
Він вирішив «оптимізувати», перенісши pre‑processing у кастомний GPU‑shader на системах з дискретними GPU,
а inference залишився на NPU. На папері: паралелізм! У слайдах: синергія!
Насправді вони створили податок на рух даних. Кадри йшли CPU → GPU для pre‑processing, потім GPU → CPU пам’ять,
потім CPU → NPU. Кожен перехід передбачав синхронізацію, копії та періодичні конвертації форматів. Середня пропускна здатність виглядала прийнятною,
але p95 латентність погіршилася й споживання енергії зросло. Система почала перегріватися й раніше тротлити, перетворивши твіку на проблему надійності.
Найгірше: налагодження стало складнішим. Конвеєр мав три планувальники (CPU, драйвер GPU, рантайм NPU),
і таймінги залежали від точних версій драйверів. Вони женилися за «випадковими» стрибками, які насправді були взаємним очікуванням черг і точок синхронізації між пристроями.
Вони відкликали розбитий пайплайн і зробили нудну зміну: тримати pre‑processing на CPU з векторизованими ядрами,
але пакетувати його так, щоб ефективно годувати NPU. Менше переходів, менше точок синхронізації, менше енергії, краща хвостова латентність.
Пікова FPS трохи впала, але система перестала поводитися так, ніби її переслідують привиди.
Другий жарт, і на цьому все: додати акселератор, щоб виправити латентність — як додати смугу на дорогу, щоб вирішити затори — інколи ви просто зробили затор ширшим.
Міні‑історія 3: Нудна, але правильна практика, що врятувала день
Велике підприємство розгорнуло ноутбуки з NPU і функцією шумоприглушення на дзвінки, керованою AI.
Пілот пройшов добре. Масштабне розгортання — ні. Користувачі в одному регіоні повідомляли, що фіча працює іноді,
потім мовчки зупиняється, потім повертається після перезавантаження. Класична «перемежована» поведінка — те, що точить тижні.
У команди була одна перевага: вони наполягли на нудній, старій практиці на початку — інвентаризація обладнання та драйверів по всьому флоту,
з версіонованими базовими конфігураціями і виявленням дрейфу. Кожен кінцевий пристрій звітував ID чипсету, версії драйверів і чи пройшов рантайм NPU простий self‑test.
Дані швидко показали патерн: уражені машини мали певну збірку драйвера, розгорнуту через регіональний update‑ring.
Драйвер завантажувався, але ініціалізація прошивки інколи падала після сну/пробудження. Рантайм тоді відкатувався на CPU,
і політика енергії тротлила CPU під тривалими дзвінками, що виглядало як «непостійна» AI‑фіча.
Оскільки у них була база, вони могли відкотити цей ринг і зафіксувати відому‑добру версію драйвера, поки вендор виправляв помилку.
«Нудна» частина — інвентар, поетапні релізи і self‑test — перетворила перемежований безлад на контрольовану регресію.
Урок: NPU — це апарат. Апарат потребує управління життєвим циклом. Ставтеся до нього як до кластера, а не як до магічного ко‑процесора.
Типові помилки: симптом → корінь → виправлення
Ось часті режими відмов, які я бачу, коли команди «додають підтримку NPU» і потім дивуються, чому нічого не покращилося.
1) Симптом: використання NPU близьке до нуля; CPU завантажений
Корінь: Рантайм використовує CPU через відсутність провайдера, неподтримані опи або помилку ініціалізації пристрою.
Виправлення: Перевірте ініціалізацію пристрою в dmesg, підтвердьте, що провайдер рантайму увімкнений, і інспектуйте, які опи падають у фолбек. Конвертуйте модель у підтримуваний набір операторів.
2) Симптом: середня затримка покращилася, але p95/p99 погіршилися
Корінь: Синхронізація між пристроями, черги або pre/post‑processing на CPU стають драйвером хвосту.
Виправлення: Мінімізуйте переходи між пристроями, зливайте опи де можливо і профілюйте весь конвеєр. Якщо потрібно — ізолюйте інференс‑потоки або перемістіть pre/post на той самий пристрій.
3) Симптом: відмінно на мережі живлення, жахливо на батареї
Корінь: Зміни governor‑а, PL1/PL2 ліміти або система віддає пріоритет енергоефективності й знижує частоту CPU/GPU, тоді як NPU залишається недовикористаним.
Виправлення: Використовуйте OS‑API для QoS живлення, переконайтеся, що inference дійсно виконується на NPU, і тестуйте в реалістичних режимах живлення. Відрегулюйте duty cycle і розмір моделі.
4) Симптом: «NPU швидкий» у вендорському демо, повільний у вашому додатку
Корінь: Демо використовує модель, підготовлену для NPU (підтримувані опи, ідеальні макети, квантизована), а ваша модель тригерить шляхи фолбеку.
Виправлення: Переекспортуйте модель з сумісними опами; застосуйте квантування під час навчання або пост‑тренувальне квантування, перевірене на ваших даних; використовуйте вендорські інструменти для перевірки покриття операторів.
5) Симптом: використання CPU впало, але батарея все одно страждає
Корінь: Ви перемістили обчислення з CPU, але збільшили трафік пам’яті, пробудження пристрою або постійну фонову роботу.
Виправлення: Додайте бюджет активності. Виконуйте модель лише при потребі, пакетування роботи і уникайте тримання акселератора в високому енергетичному стані постійно.
6) Симптом: інференс іноді зависає або тайм‑аутиться після сну/пробудження
Корінь: Помилки життєвого циклу драйвера/прошивки або рантайм не коректно обробляє скидання пристрою.
Виправлення: Виявляйте здоров’я пристрою, перезапускайте провайдера рантайму при збої і фіксуйте версії драйверів на відомо‑робочих збірках з поетапним розгортанням.
7) Симптом: «Більше потоків» робить CPU‑inference повільнішим
Корінь: Трошення кеша, насичення пам’яті або перепідписка потоків з іншими навантаженнями.
Виправлення: Налаштуйте кількість потоків відповідно до підсистеми пам’яті; використовуйте NUMA‑pinning на серверах; вимірюйте. Перестаньте думати лінійно про масштабування.
8) Симптом: NPU‑шлях швидкий, але якість виходу погіршилася
Корінь: Агресивне квантування або різні ядра/точність, що впливають на чисельність обчислень.
Виправлення: Перевірте якість на репрезентативних даних; віддавайте перевагу квантуванню з урахуванням під час навчання, коли можливо; використовуйте пер‑канальне квантування і калібруйте на реальних входах.
Чеклісти / покроковий план
Покроково: вирішити, чи використовувати CPU, GPU чи NPU
- Класифікуйте навантаження: інтерактивне (жорстка латентність), фонова (чутлива до енергії), пакетна (черга, пропускна здатність) або змішане.
- Виміряйте duty cycle: як часто виконується inference і скільки часу триває? «Іноді» перетворюється на «постійно» з однією зміною продукту.
- Профілюйте розклад конвеєра: препроцесинг, inference, постпроцесинг, I/O та копії між пристроями.
- Перевірте покриття апаратного забезпечення: яка частка флоту має NPU, здатний виконати вашу модель? Не оптимізуйте для 5%, якщо лише ці 5% не є критичними.
- Перевірте покриття операторів: чи може цільовий NPU виконати ваш граф без значних фолбеків?
- Оберіть точність і перевірте якість: INT8 може бути потрібним для продуктивності NPU; переконайтеся, що це не ламає крайові випадки.
- Встановіть бюджети: відсоток CPU, стан живлення, термічний поріг і SLO по латентності.
- Заплануйте поведінку фолбеку: якщо NPU падає, ви переходите на CPU, вимикаєте фічу чи деградуєте якість?
- Впровадьте обсервабельність: записуйте, який пристрій виконав inference, версію моделі, точність і частоту фолбеків.
- Розгортайте в кілька етапів: особливо драйвери/прошивки. Ставтеся до стека NPU як до оновлення ядра.
Операційний чекліст: перед увімкненням AI‑фічі по всьому флоту
- Визначте цілі p50 і p95 латентності для інтерактивних шляхів; визначте середній енергетичний бюджет для фонових задач.
- Тестуйте в режимах енергозбереження / низької потужності і під «гіршими нормальними» навантаженнями (відеодзвінок + браузер + EDR).
- Перевірте поведінку після сну/пробудження і обробку скидання пристрою.
- Підтвердьте час завантаження моделі і слід пам’яті; уникайте свопінгу.
- Переконайтеся, що ваш рантайм логує «вибір пристрою» і «фолбек‑опи» щонайменше на debug‑рівні.
- Фіксуйте версії драйверів/рантайму по рингах; майте швидкий план відкату.
Питання та відповіді (FAQ)
1) Чи NPUs лише для ноутбуків і телефонів?
Ні. Термін «NPU» найчастіше з’являється у клієнтських пристроях, бо там важлива енергоефективність.
У серверах такий самий концепт існує як inference‑акселератори, але їх частіше брендують GPU, TPU або карти.
2) Якщо в мене є NPU, чи завжди слід використовувати його для інференсу?
Тільки якщо ваша модель і рантайм дійсно добре лягають на нього. Якщо покриття операторів погане, ви відкотитесь на CPU і програєте.
Також деякі задачі (токенізація, парсинг, бізнес‑логіка) як і раніше належать CPU.
3) Що насправді означає «TOPS»?
Пікова теоретична пропускна здатність за ідеальних умов. Це стеля, а не прогноз.
Реальний обмежувач часто — пропускна здатність пам’яті, покриття операторів і частка графа, що дійсно прискорюється.
4) Чому NPUs так дбають про квантування?
Бо низька точність збільшує продуктивність на ват і зменшує потребу в пропускній здатності пам’яті.
Але квантування може змінити поведінку моделі; треба перевіряти якість, а не лише швидкість.
5) Чи може NPU допомогти конкретно з LLM‑ами?
Іноді — для менших або квантизованих моделей і для специфічних операторів. Але багато клієнтських NPU оптимізовані під графи для візії/аудіо.
Інференс LLM часто є memory‑bound і може не мапитися гладко без ретельної підтримки ядер і рантайму.
6) Яка найбільша причина, чому «підтримка NPU» не покращує продуктивність?
Фолбек. Одна неподтримана операція може змусити переходи між пристроями або виконання на CPU для великих частин графа.
Завжди вимірюйте, які опи виконувалися де.
7) Чи NPUs надійніші за GPUs?
Різні режими відмов. NPUs інтегровані і часто простіші в енергопостачанні/керуванні, але зрілість драйверів/рантаймів різна.
GPU мають зрілі стеки в багатьох середовищах, але додають складність і енергоспоживання. Надійність — це в основному управління життєвим циклом і обсервабельність.
8) Що логувати в продакшні, щоб уникнути здогадок?
Логувати пристрій виконання (CPU/GPU/NPU), версію моделі і точність, кількість фолбек‑опів, затримку інференсу (p50/p95)
і будь‑які помилки ініціалізації/скидання пристрою. Без цього ви будете дебажити «враження».
9) Як вирішити, чи перемістити препроцесинг на NPU також?
Віддавайте перевагу триманню даних на одному пристрої, коли це можливо, але не примушуйте. Якщо препроцесинг малий і розгалужений — CPU підходить.
Переносьте його тільки коли копії домінують або акселератор має виділену підтримку для цих опів.
10) Який найпростіший «виграш» для CPU‑inference, якщо я не можу використовувати NPU?
Квантуйте, налаштуйте кількість потоків, уникайте свопу і виправте NUMA‑розміщення на серверах. Потім профілюйте конвеєр.
Більшість повідомлень «CPU повільний» насправді означають «пам’ять повільна».
Практичні наступні кроки
Якщо ви відповідаєте за доставку AI‑фічі на реальні машини, зробіть наступне:
- Виміряйте, де виконується робота (CPU vs NPU vs GPU) і як часто відбувається фолбек.
- Профілюйте кінцево‑в кінцевий латентність, а не тільки час виконання моделі.
- Встановіть бюджети: використання CPU, тепловий запас і вплив на батарею — це вимоги, а не післядумки.
- Оберіть стратегію моделі: квантуйте з перевіркою якості або прийміть нижчу продуктивність. Не думайте, що отримаєте і те, й інше даремно.
- Операціоналізуйте апарат: базові версії драйверів, поетапні релізи і плани відкату. Ставтеся до включення NPU як до зміни ядра.
NPUs тут не тому, що CPU «погані». Вони тут, бо фізика груба, батареї маленькі, а користувачі скаржаться негайно.
Кладіть правильну роботу на правильний силікон і тримайте системи нудними. Нудні системи масштабуються.