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

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

Real-time Edge AI — пересечение двух жёстких требований: инференс должен завершаться в строго фиксированное время, и это должно происходить локально, без сети. Промышленные роборуки, автомобильные ADAS-системы, медицинские мониторы жизненных показателей — везде опоздание на 10 мс означает либо брак, либо авария.

Что отличает real-time от "просто быстрого"

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

Классификация по жёсткости:

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

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 2024 с 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 (Data Watchpoint and Trace). Инференс простых нейросетей (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 операции: 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 для критических буферов.

Сроки: 16–28 недель

Hard RT с сертификацией (ISO 26262/IEC 61508) — верхняя граница. Soft RT для промышленного мониторинга — 12–16 недель. Сложность определяется не моделью, а верификацией timing properties.