Ми розробляємо 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 застосувань.
Класифікація за жорсткістю:
| Клас | WCET порушення | Приклади |
|---|---|---|
| Hard RT | Катастрофа (safety) | ABS, медичний кардіостимулятор |
| Firm RT | Результат марний | Аудіообробка, фінансові ордери |
| Soft RT | Деградація якості | Розпізнавання жестів, AR-overlay |
Чому 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 мс.
| Параметр | Jetson Orin | Intel Core Ultra | PolarFire | STM32H7 |
|---|---|---|---|---|
| TOPS | до 275 INT8 | до 10 NPU | <1 FPGA | <0.1 |
| Типовий jitter | <50 мкс | <100 мкс | <10 мкс | <5 мкс |
| Тип RT | Hard | Soft/Firm | Hard | Hard |
| Енергоспоживання | 15-60 Вт | 15-28 Вт | <5 Вт | <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 для критичних буферів.
Як це робиться: покроковий процес
- Аналіз реальних вимог до латентності та жорсткості RT.
- Вибір апаратної платформи за критеріями TOPS, jitter, енергоспоживання.
- Оптимізація моделі з урахуванням WCET constraint (pruning, quantization, fixed shapes).
- Інтеграція з RTOS та налаштування детермінізму (CPU affinity, memory locking).
- Верифікація 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 вимоги та запропонуємо архітектуру.