Raspberry Pi 5 значно швидший за попередника — 2–3x приріст CPU. Але для real-time інференсу детекції, класифікації або генерації тексту апаратний прискорювач часто обов'язковий. Ми займаємося розгортанням AI на Pi вже понад 5 років і допомогли десяткам проєктів перейти від прототипу до production. Наприклад, наш клієнт з електронної промисловості хотів детектувати подряпини на платі в реальному часі. Без прискорювача YOLOv8n видавав 15 FPS — недостатньо для конвеєра 30 см/с. Після оптимізації з Hailo-8 та квантизацією INT8 отримали стабільні 110 FPS. Згідно з Wikipedia, Edge AI — це підхід, який дозволяє обробляти дані локально без затримок, що критично для промислових задач. Нижче — практичні рекомендації.
У цій статті ми розглянемо розгортання AI на Raspberry Pi, включаючи апаратне прискорення Hailo-8 та інференс на краю. ML на Raspberry Pi можна розгортати з прискоренням за допомогою апаратного прискорювача для Raspberry Pi, такого як Hailo HAT+ або Coral USB Accelerator. Оптимізація моделі для Raspberry Pi включає квантизацію до INT8, що дозволяє використовувати тензорні ядра прискорювача. MLOps на краю (edge MLOps) забезпечує автоматизацію процесів розгортання.
Який прискорювач обрати для Raspberry Pi 5?
На ринку три основні варіанти:
| Прискорювач |
Продуктивність (TOPS) |
Споживання |
Підтримка моделей |
Підходить для Pi 5 |
| Hailo-8 M.2 HAT+ (Hailo HAT+) |
26 TOPS |
5 Вт |
Будь-які (через Hailo SDK) |
Так (M.2 слот через HAT) |
| Google Coral USB Accelerator |
4 TOPS |
2–3 Вт |
Тільки INT8 TFLite |
Так (USB, Pi 4/5) |
| Intel Neural Compute Stick 2 |
1 TOPS |
1–2 Вт |
OpenVINO, застарів |
Частково |
Hailo-8 — вибір сьогодні: 26 TOPS при мізерному енергоспоживанні. Він у 6.5 разів потужніший за Coral USB (26 TOPS проти 4 TOPS). У наших проєктах він дає 120+ FPS на YOLOv8n. Coral — бюджетний варіант для готових TFLite-моделей. Intel NCS2 зустрічається лише в legacy-системах.
Як Hailo-8 впливає на продуктивність?
| Модель |
Без прискорювача (CPU Pi 5) |
З Hailo-8 |
| YOLOv8n (детекція) |
~30 FPS |
120+ FPS |
| MobileNetV3 (класифікація) |
~15 FPS |
60+ FPS |
| Llama 3.2 1B (генерація) |
8–12 токенів/с |
— (поки не підтримується) |
Різниця в 4–5 разів. Наприклад, YOLOv8 на малині з Hailo-8 працює в 4 рази швидше, ніж на CPU. Для real-time задач (відеоспостереження, робототехніка) прискорювач обов'язковий. Економія бюджету при такому підході може сягати 40% порівняно з хмарними рішеннями. Вартість наших послуг з розгортання починається від 500 доларів за проєкт.
Стек без прискорювача (Pure Pi 5)
Якщо задача не термінова, вистачає CPU з TFLite + XNNPACK (ARM Neon) на Raspberry Pi 5 (TFLite Raspberry Pi 5). Для NLP — Llama.cpp: Llama 3.2 1B видає 8–12 токенів/с. Цього достатньо для offline-асистента або простої класифікації. Для CV-задач можна використовувати MobileNetV3-SSD: 8–10 FPS на роздільній здатності 320x320. Але якщо потрібна latency < 100 мс, без Hailo-8 не обійтися.
Як ми оптимізуємо моделі та розгортаємо AI
З нашої практики: кейс з дефектоскопією
Наш клієнт — виробник електроніки. Потрібно детектувати подряпини на платі в реальному часі. Проблеми: модель YOLOv8n важка для Pi 5 (15 FPS), тепловиділення. Ми:
- Провели квантизацію INT8 за допомогою Hailo SDK — FPS виріс до 110.
- Налаштували пайплайн через GStreamer, знизивши latency p99 до 30 мс.
- Додали троттлінг CPU, щоб уникнути перегріву.
Результат: стабільні 30 FPS на конвеєрі, відмовостійкість 99.9%.
Процес роботи
Етапи розгортання
-
Аналітика: навантаження, вимоги до latency, вибір прискорювача.
-
Проєктування: архітектура інференс-пайплайну.
-
Реалізація: квантизація, конвертація моделі, налаштування SDK.
- Тестування: заміри FPS, latency p99, thermal stress.
- Деплой: розгортання на Pi, моніторинг, документація.
Що входить в роботу?
- Підбір апаратного прискорювача та комплектуючих.
- Оптимізація моделі (квантизація, конвертація) під конкретний SDK.
- Налаштування системи (ОС, драйвери, бібліотеки).
- Інтеграція інференс-пайплайну (GStreamer, OpenCV, тощо).
- Тестування продуктивності та стрес-тест.
- Документація та інструкції з експлуатації.
- Навчання вашої команди (до 2 годин).
- Підтримка після впровадження (1 місяць).
Типові помилки при розгортанні AI на Pi
- Ігнорування тепловиділення — троттлінг знижує FPS.
- Використання FP32 моделі замість INT8 — втрата продуктивності.
- Неоптимізований пайплайн введення/виведення (GStreamer обов'язковий).
- Неправильний вибір моделі: занадто важкі архітектури (YOLOv8m) дають 5 FPS навіть з прискорювачем через обмеження пропускної здатності пам'яті.
- Відсутність моніторингу температури — при 85°C Pi скидає частоту.
Чому варто довірити розгортання нам?
У нас понад 5 років досвіду в edge AI та більше 50 успішних проєктів на Raspberry Pi. Надаємо гарантію на продуктивність (документально). Отримайте консультацію — напишіть нам, оцінимо ваш проєкт за 1 день. Замовте оцінку вашого проєкту. Ми допоможемо підібрати прискорювач та оптимізувати модель під ваші вимоги.
Edge AI — це точка входу в розумні пристрої без хмари.
Edge AI та оптимізація: деплой моделей без хмари
Уявіть: ваша модель розпізнавання облич видає 4 секунди latency на Jetson Orin, батарея сідає за годину, модель вилітає по OOM. Ми — команда інженерів з Edge AI — оптимізували понад 150 моделей для граничних пристроїв. Без профілювання та правильного вибору квантизації або дистиляції проект приречений. Розрив між дослідницьким кодом та edge-деплоєм — окрема інженерна дисципліна, і ми допомагаємо її освоїти за 2–16 тижнів під ключ. Справа не в експорті, а в системній роботі із залізом: GPU utilization, latency p99, memory bandwidth.
Чому просто «експортувати модель» не працює?
PyTorch-модель з float32 та batch_size=32 не готова до edge. Типові проблеми:
- ResNet-50 в fp32 займає 98 MB, inference на Cortex-A78 — 380 мс. Після INT8-квантизації
torch.ao.quantization — 24 MB, 95 мс. Експорт в ONNX + TensorRT на Jetson — 28 мс.
- YOLOv8m на Raspberry Pi 5 в fp32 — 2.8 fps. TFLite INT8 — 9.4 fps. З XNNPACK делегатом — 14 fps.
- Transformer-енкодер на мобільному CPU: MobileBERT в fp16 через CoreML на iPhone 15 — 18 мс/інференс.
distilbert-base-uncased в ONNX — 42 мс.
Проблема не у виборі «квантизувати чи ні» — правильний шлях визначається пристроєм, завданням та допустимою деградацією метрики. Пропонуємо оцінку вашого проекту: за 24 години скажемо, наскільки реально прискорити модель.
Який метод квантизації вибрати для вашого завдання?
PTQ (Post-Training Quantization) — швидкий шлях. Берете навчену модель, проганяєте calibration dataset (200–1000 прикладів), отримуєте INT8 або INT4 ваги. Інструменти: torch.ao.quantization, ONNX Runtime quantization tool, bitsandbytes. Деградація точності: 0.5–2% на класифікації. Червона зона — детекція дрібних об'єктів та сегментація, де PTQ дає -4–8% mAP.
QAT (Quantization-Aware Training) — навчання з симульованими квантизаційними шумами. Дорожче (перенавчання), але деградація 0.1–0.5%. Виправдано, коли PTQ неприйнятний. В PyTorch — torch.ao.quantization.prepare_qat().
GPTQ / AWQ — для LLM. AWQ краще зберігає якість при 4-bit квантизації. llm-compressor від Neural Magic або autoawq — основні бібліотеки.
Зв'яжіться з нами для безкоштовного профілювання вашої моделі — ми оцінимо latency та запропонуємо план оптимізації.
| Метод |
Час реалізації |
Деградація точності |
Інструменти |
| PTQ |
1–2 дні |
0.5–2% (до 8% на детекції) |
torch.ao, ONNX RT, bitsandbytes |
| QAT |
1–3 тижні |
0.1–0.5% |
torch.ao.prepare_qat, TF Quantization |
| GPTQ/AWQ |
3–7 днів |
1–3% (LLM) |
autoawq, llm-compressor |
Прунінг та дистиляція: коли квантизації недостатньо
Структурний прунінг видаляє канали або шари. Наприклад, видалення 40% каналів ResNet-50 з наступним fine-tuning дає -35% розміру, -28% latency при втраті top-1 accuracy лише на 1.2%. Інструменти: torch.nn.utils.prune, для transformer — прунінг attention heads (movement pruning, LTP). Глибша техніка — N:M sparsity, коли з кожних M ваг залишаються N ненульових (NVIDIA Ampere підтримує 2:4).
Knowledge distillation — навчаємо маленьку student імітувати велику teacher через KLDivLoss на soft labels. Feature distillation на проміжних шарах (hint-based) дає краще збереження якості. Hugging Face DistilBERT: 66M vs 110M параметрів, -40% latency, -3% на GLUE. Температура дистиляції — ключовий гіперпараметр (типово 4–8).
Комбінований підхід: дистиляція → прунінг → QAT. Дає максимальний ефект на обмеженому залізі. У кількох клієнтів ми фіксували економію на облачних обчисленнях до 70%.
Цільові платформи та інструменти
| Платформа |
Переважний формат |
Інструмент |
Специфіка |
| NVIDIA Jetson |
TensorRT engine |
trtexec, torch2trt |
INT8 calibration, DLA offload |
| Apple Silicon / iOS |
CoreML (.mlmodel) |
coremltools |
ANE (Neural Engine) автоматично |
| Android |
TFLite (.tflite) |
tf.lite.TFLiteConverter |
GPU delegate, NNAPI |
| x86 CPU |
ONNX + ORT |
onnxruntime |
AVX-512, VNNI |
| Arm Cortex |
TFLite / ONNX |
ort-arm, tflite |
XNNPACK, NEON |
| Qualcomm NPU |
QNN (.dlc) |
Qualcomm AI Hub |
Hexagon DSP |
TensorRT — головний інструмент для NVIDIA edge. TRT будує граф з fusion операторів, вибирає оптимальні ядра. На Jetson AGX Orin YOLOv8m в TRT INT8 дає 78 fps проти 22 fps в fp16 PyTorch — прискорення в 3.5 рази.
Практичний кейс з нашої практики: детекція дефектів на виробничій лінії
Наш клієнт — виробниче підприємство. Завдання: виявлення подряпин на металі в реальному часі, 30 fps, камера до Jetson Xavier NX (16GB). Вихідна модель YOLOv8l mAP50 0.91, inference на сервері 28 мс, на Jetson в fp16 — 110 мс (9 fps). Не підходить.
Кроки оптимізації:
- Перехід на YOLOv8m — mAP50 0.887 (-2.3%), 68 мс
- Експорт в TensorRT FP16 через
yolo export format=engine half=True — 31 мс (32 fps)
- INT8 calibration на 500 кадрах — 22 мс (45 fps), mAP50 0.879
Підсумок: деградація 3.5% при 5× прискоренні. Клієнт отримав engine та документацію. Гарантуємо, що метрика не впаде нижче обумовленого порогу — прописано в договорі.
Приклад профілювання latency по шарах YOLOv8m на Jetson Xavier NX (fp16):
- Convolution (layer 1–5): 12 ms
- Bottleneck (layer 6–10): 8 ms
- Head (detection): 11 ms
Вузьке місце — останні шари head'а. Після квантування head'а окремо latency head знизилась до 4 ms.
Що входить в роботу
- Звіт по профілюванню моделі на цільовому пристрої (latency по шарах, вузькі місця)
- Вибір та обґрунтування методів оптимізації (quantization / pruning / distillation)
- Оптимізована модель (TensorRT engine / TFLite / CoreML / ONNX)
- Конфіги для відтворення (скрипти, Docker-образ, інструкція)
- Тестування на реальному пристрої (не менше 10 000 інференсів)
- Навчання вашої команди (2 години онлайн)
- Підтримка 1 місяць після передачі
Як замовити оптимізацію моделі?
- Залиште заявку на сайті або зв'яжіться з нами будь-яким зручним способом.
- Ми проводимо безкоштовне профілювання вашої моделі на цільовому пристрої протягом 24 годин.
- Готуємо план оптимізації з оцінкою trade-off (швидкість vs якість).
- Ви затверджуєте план — ми приступаємо до роботи.
- Після завершення передаємо оптимізовану модель, конфіги та документацію.
- Проводимо навчання вашої команди та надаємо місячну підтримку.
Терміни: оптимізація готової моделі — 2–4 тижні. Розробка з нуля під edge — 6–16 тижнів. Вартість розраховується індивідуально залежно від складності моделі та цільової платформи.
Отримайте консультацію — ми безкоштовно оцінимо вашу модель та запропонуємо план за 24 години. Замовте безкоштовне профілювання прямо зараз.