Розробка AI-системи реального часу для Edge-пристроїв

Ми розробляємо AI-системи реального часу для Edge-пристроїв — від концепції до впровадження під ключ. Наш досвід: 8+ років у hard real-time, 30+ проєктів у промисловості, автоспорті та медицині. Нещодавно на проєкті для автономного дрона з детекцією перешкод на Jetson Orin ми зіткнулися з jitter латентності до 200 мс через неоптимальне планування потоків — це призводило до частих збоїв. Перехід на детерміноване планування та WCET-верифікацію знизив p99 latency до 15 мс. Real-time Edge AI — перетин двох жорстких вимог: інференс має завершуватися в строго фіксований час, і це має відбуватися локально, без мережі. Промислові роборуки, автомобільні ADAS-системи, медичні монітори — всюди запізнення на 10 мс означає брак або аварію. Згідно з Wikipedia, WCET аналіз дає гарантію часу виконання, критичну для safety-критичних систем.

Що відрізняє real-time від "просто швидкого"

Звичайна оптимізація женеться за середнім часом інференсу. Real-time вимагає гарантованого worst-case execution time (WCET). P99 latency важливіша за середнє: якщо 99% запитів обробляються за 5 мс, але 1% займає 50 мс — система непридатна для hard real-time застосувань.

Класифікація за жорсткістю:

Чому hard real-time критичний для Edge AI?

На відміну від хмарного AI, де затримка мережі додає недетермінізм, Edge AI вимагає детермінізму на рівні мікросекунд. Наприклад, керування приводом робота: команда має прийти за 1 мс після обробки зображення, інакше позиціонування збивається. TensorRT з FP8 precision дає вдвічі меншу латентність на тій же архітектурі — це пряме порівняння зі звичайним CUDA-інференсом. Наш підхід знижує jitter в 10 разів порівняно з типовим Linux-інференсом без детермінізму.

Як забезпечити детермінований час інференсу?

Апаратна база

NVIDIA Jetson Orin NX/AGX До 275 TOPS (INT8). CUDA Ampere + 1.5 MB L2 cache. TensorRT з FP8 precision. Latency determinism через CUDA streams з пріоритетами та NVDLA для фіксованих топологій (нульовий jitter на NVDLA vs GPU).

Intel Core Ultra (Meteor Lake) + NPU Integrated NPU на 10 TOPS. OpenVINO з NPU plugin. Перевага: shared memory з CPU, немає PCIe latency overhead. Підходить для soft/firm RT задач.

Microchip PolarFire SoC + RISC-V Hard real-time RTOS на RISC-V cores, FPGA fabric для інференсу. Детермінізм FPGA + гнучкість Linux в одному чипі.

STM32H7 / RP2040 (TinyML hard RT) Cortex-M7 @ 480 MHz + FPU. TFLite Micro з CMSIS-NN. Cycle-accurate profiling через DWT. Інференс простих нейромереж (CNN keyword detection) за <1 мс.

Програмний стек

RTOS шар FreeRTOS з configUSE_PREEMPTION=1 та configUSE_TIME_SLICING=0 для детермінованого планування. Задача інференсу на максимальному пріоритеті. Критичні секції (taskENTER_CRITICAL) для атомарних операцій з периферією.

Zephyr RTOS: більш сучасний, CONFIG_PREEMPT_ENABLED, вбудований stack overflow detection, нативний devicetree для периферії.

Інференс з детермінованими латентностями

TensorRT Execution Context:
- setOptimizationProfile() → фіксує batch=1
- enqueueV3() → async CUDA stream
- cudaStreamSynchronize() → блокуюче очікування

Без memory allocations в hot path.
Без Python runtime.

Запобігання jitter

• CPU affinity: інференс-потік піниться на ізольоване ядро (isolcpus=2 в bootargs)
• Memory: mlock()/mlockall() — заборона свопінгу сторінок моделі
• Interrupts: irqbalance off, IRQ affinity налаштована вручну
• NUMA-aware allocation на multi-die системах

Архітектурні патерни

Double-buffering для сенсорних даних: Камера/сенсор пише в буфер A, інференс читає з буфера B. По готовності кадру — атомарний swap вказівників. Немає очікування, немає копіювання.

Pipeline parallelism:

[Capture] → [Preprocess] → [Inference] → [Postprocess] → [Actuate]
   stage0       stage1        stage2         stage3          stage4

Кожен stage — окремий потік з FIFO чергою між ними. Throughput = 1/max(stage_latency), не сума всіх stage.

Deadline-aware scheduling: EDF (Earliest Deadline First) для м'якого RT. При Linux: SCHED_DEADLINE з параметрами runtime/deadline/period. Ядро гарантує процесорний час до дедлайну.

Перериванням керований інференс (interrupt-driven): Немає polling. GPIO переривання від сенсора → ISR виставляє флаг → RT-потік негайно пробуджується. Latency від події до початку інференсу: <50 мкс на Cortex-M7.

Верифікація real-time властивостей

WCET аналіз:

• Статичний: AbsInt aiT, Bound-T — аналіз бінарного коду без запуску
• Динамічний: багаторазові прогони з worst-case input (максимальне навантаження на всі гілки)
• Measurement-based: DWT cycle counter на Cortex-M, perf на Linux

Профілювання:

# CUDA event timing (ns-точність)
start = torch.cuda.Event(enable_timing=True)
end = torch.cuda.Event(enable_timing=True)
start.record()
model(input)
end.record()
torch.cuda.synchronize()
ms = start.elapsed_time(end)

Стрес-тестування jitter: cyclictest (Linux RT) — вимірює латентність пробудження потоку під навантаженням. Цільові значення: max jitter <100 мкс для firm RT, <10 мкс для hard RT (PREEMPT_RT патч).

Оптимізація моделі під RT вимоги

Звичайний ML пайплайн оптимізує accuracy. RT-пайплайн оптимізує accuracy при жорсткому WCET constraint.

Structured pruning vs unstructured: Unstructured pruning (обнулення ваг) не прискорює на реальному залізі — нулі все одно обробляються. Structured pruning (видалення каналів/голів) дає реальне прискорення та передбачуване WCET.

Fixed-shape operations: Dynamic shapes (змінна довжина послідовності в Transformer) — джерело недетермінізму. Для RT: паддінг до фіксованої довжини + TensorRT explicit batch mode.

Уникнення операцій з непередбачуваним часом:

• Sort, topK — O(n log n) worst-case
• Dynamic memory allocation (new/malloc) — заборонено в ISR та RT threads
• File I/O — тільки memory-mapped files (mmap)

Функціональна безпека

Для automotive (ISO 26262 ASIL-B/D) та industrial (IEC 61508 SIL-2/3):

Redundancy: dual-channel inference з voter (2-of-2 або 2-of-3). Незалежні апаратні блоки.

Watchdog: hardware watchdog таймер. Якщо інференс завис — reset. Типовий timeout: 2× WCET.

Error detection: ECC DRAM обов'язковий. CRC перевірка ваг моделі при завантаженні. Runtime checksums для критичних буферів.

Як це робиться: покроковий процес

1. Аналіз реальних вимог до латентності та жорсткості RT.
2. Вибір апаратної платформи за критеріями TOPS, jitter, енергоспоживання.
3. Оптимізація моделі з урахуванням WCET constraint (pruning, quantization, fixed shapes).
4. Інтеграція з RTOS та налаштування детермінізму (CPU affinity, memory locking).
5. Верифікація WCET та stress-testing jitter.

Що входить в роботу

• Оптимізована та верифікована модель (TensorRT/OpenVINO/TFLite)
• Конфігурація RTOS з детермінованим плануванням
• Набір тестів WCET та stress-test jitter-а
• Звіт з профілюванням та worst-case аналізом
• Інтеграція в вашу систему (драйвери, біндинги)
• Документація та навчання команди
• 3 місяці підтримки після релізу

Строки: 12–28 тижнів

Hard RT з сертифікацією (ISO 26262/IEC 61508) — верхня межа. Soft RT для промислового моніторингу — 12–16 тижнів. Складність визначається не моделлю, а верифікацією timing properties. Зв'яжіться з нами, щоб оцінити ваш проєкт — ми підберемо оптимальне рішення під ключ. Замовте аудит вашого проєкту — ми оцінимо real-time вимоги та запропонуємо архітектуру.

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 та запропонуємо план оптимізації.

Прунінг та дистиляція: коли квантизації недостатньо

Структурний прунінг видаляє канали або шари. Наприклад, видалення 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%.

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

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). Не підходить.

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

1. Перехід на YOLOv8m — mAP50 0.887 (-2.3%), 68 мс
2. Експорт в TensorRT FP16 через yolo export format=engine half=True — 31 мс (32 fps)
3. 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 місяць після передачі

Як замовити оптимізацію моделі?

1. Залиште заявку на сайті або зв'яжіться з нами будь-яким зручним способом.
2. Ми проводимо безкоштовне профілювання вашої моделі на цільовому пристрої протягом 24 годин.
3. Готуємо план оптимізації з оцінкою trade-off (швидкість vs якість).
4. Ви затверджуєте план — ми приступаємо до роботи.
5. Після завершення передаємо оптимізовану модель, конфіги та документацію.
6. Проводимо навчання вашої команди та надаємо місячну підтримку.

Терміни: оптимізація готової моделі — 2–4 тижні. Розробка з нуля під edge — 6–16 тижнів. Вартість розраховується індивідуально залежно від складності моделі та цільової платформи.

Отримайте консультацію — ми безкоштовно оцінимо вашу модель та запропонуємо план за 24 години. Замовте безкоштовне профілювання прямо зараз.