Послуги Edge AI та оптимізації моделей

Edge AI: Розгортання Моделей на Пристроях без Хмари

Модель працює ідеально на сервері з A100. На Jetson Orin або мобільному — latency 4 секунди, батарея садиться за годину, модель вилітає з OOM. Розрив між дослідницьким кодом та edge-деплоєм — це окрема інженерна дисципліна.

Чому Просто "Експортувати Модель" Не Працює

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-енкодер для NLP на мобільному CPU: MobileBERT в fp16 через CoreML на iPhone 15 — 18 мс/інференс. distilbert-base-uncased в ONNX через ort — 42 мс. Різниця істотна для real-time.

Проблема не у виборі "квантизувати або ні" — проблема в тому, що немає єдиної відповіді. Правильний шлях визначається цільовим пристроєм, задачею та допустимою деградацією метрики.

Квантизація: Що Реально Працює

Квантизація трьох видів, сильно різняться по трудомісткості.

PTQ (Post-Training Quantization) — найшвидший шлях. Беремо навчену модель, прогоняємо через calibration dataset (200–1000 прикладів), отримуємо INT8 або INT4 ваги. Інструменти: torch.ao.quantization, ONNX Runtime quantization tool, bitsandbytes для LLM. Деградація: зазвичай 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 (Activation-aware Weight Quantization) краще зберігає якість при 4-біт квантизації порівняно з GPTQ. llm-compressor або autoawq — основні бібліотеки.

Прунінг та Дистиляція

Структурний прунінг видаляє цілі канали або шари. torch.nn.utils.prune — базовий інструмент. Для transformer-моделей — прунінг attention heads. Результат: ResNet-50 після видалення 40% каналів з fine-tuning — розмір -35%, latency -28%, top-1 accuracy -1.2%.

Knowledge distillation — учимо маленьку student-модель імітувати велику teacher. Класичний підхід через KLDivLoss на soft labels. Більш ефективний — feature distillation на промежуточних шарах. Hugging Face надає DistilBERT: 66M vs 110M параметрів, -40% latency, -3% на GLUE benchmark.

Комбінований підхід працює краще: дистиляція → прунінг → QAT. Збільшує час розробки, але дає максимальний ефект на обмеженому залізі.

Цільові Платформи та Інструменти

TensorRT — головний інструмент для NVIDIA edge. Не просто експорт: TRT будує граф з fusion операторів, вибирає оптимальні ядра під конкретну архітектуру GPU/DLA. YOLOv8m на Jetson AGX Orin у TRT INT8 дає 78 fps проти 22 fps у fp16 PyTorch.

CoreML Tools автоматично направляє обчислення на ANE (Apple Neural Engine) при правильній структурі. Не всі операції підтримуються ANE — кастомні шари падають на CPU. Профілювання в Xcode Instruments покажуть, де вузьке місце.

Практичний Кейс: Детекція Дефектів на Лінії

Задача: обнаруження царапин на металічних деталях в реальному часі, 30 fps, Jetson Xavier NX (16GB).

Оригінальна модель: YOLOv8l, навчена на 12000 аннотованих зображеннях, mAP50 0.91, inference на сервері — 28 мс/кадр. На Jetson Xavier NX в fp16 — 110 мс (9 fps). Не підходить.

Кроки оптимізації:

1. Перехід на YOLOv8m — mAP50 0.887 (-2.3%), 68 мс на Jetson
2. Експорт в TensorRT FP16 через yolo export format=engine half=True — 31 мс (32 fps)
3. INT8 calibration на 500 кадрах з production — 22 мс (45 fps), mAP50 0.879

Результат: деградація метрики 3.5% при 5× прискоренні. Для задачі допустимо — оператор все рівно фінально верифікує флаги.

Процес Роботи та Терміни

Починаємо з профілювання: запускаємо модель на цільовому пристрої, вимірюємо latency по шарам, виявляємо вузькі місця. Без цього оптимізація вслід.

Потім — план оптимізації з оцінкою trade-off'ів: кожен метод дає конкретний прирост швидкості при конкретній деградації якості. Ви вирішуєте, що допустимо для вашої задачі.

Терміни: оптимізація готової моделі для конкретного пристрою — 2–4 тижні. Розробка з нуля під edge-вимоги (архітектура + навчання + оптимізація + тестування на залізі) — 6–16 тижнів.