Мы разрабатываем 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 требования и предложим архитектуру.