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

Проектируем и внедряем системы искусственного интеллекта: от прототипа до production-ready решения. Наша команда объединяет экспертизу в машинном обучении, дата-инжиниринге и MLOps, чтобы AI работал не в лаборатории, а в реальном бизнесе.
Показано 1 из 1Все 1564 услуг
Разработка AI-системы реального времени для Edge-устройств
Сложный
~2-4 недели
Часто задаваемые вопросы

Направления AI-разработки

Этапы разработки AI-решения

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    949
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1183
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    921

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

Как это делается: пошаговый процесс

  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 с 5+ лет опыта — оптимизировали более 150 моделей для граничных устройств. Без профилирования и правильного выбора квантизации или дистилляции проект обречён. Разрыв между исследовательским кодом и edge-деплоем — отдельная инженерная дисциплина, мы помогаем её освоить за 2–16 недель под ключ. Услуги Edge AI и оптимизация моделей — это не просто экспорт, а системная работа с железом.

Почему просто «экспортировать модель» не работает

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 — основные библиотеки.

Метод Время реализации Деградация точности Инструменты
PTQ 1–2 дня 0.5–2% (до 8% на детекции) torch.ao, ONNX RT, bitsandbytes
QAT 1–3 недели 0.1–0.5% torch.ao.prepare_qat, TF Quantization
GPTQ/AWQ 3–7 дней 1–3% (LLM) autoawq, llm-compressor

Экономия от выбора правильного метода: до 350 000 ₽ в год на облачных инстансах за счёт снижения latency и энергопотребления. Стоимость проекта рассчитывается индивидуально — диапазон от 100 000 до 500 000 ₽ в зависимости от сложности модели.

Прунинг и дистилляция

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

Knowledge distillation — обучаем маленькую student имитировать большую teacher. Классика через KLDivLoss на soft labels. Feature distillation на промежуточных слоях эффективнее. Hugging Face DistilBERT: 66M vs 110M параметров, -40% latency, -3% на GLUE. Согласно Wikipedia, это техника сжатия модели.

Комбинированный подход: дистилляция → прунинг → QAT. Даёт максимальный эффект на ограниченном железе. Экономия на облачных вычислениях достигает 70% — мы фиксировали такую у нескольких клиентов.

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

Платформа Предпочтительный формат Инструмент Специфика
NVIDIA Jetson TensorRT engine trtexec, torch2trt INT8 calibration, DLA offload
Apple Silicon / iOS CoreML (.mlmodel) coremltools ANE (Neural Engine) автоматически
Android TFLite (.tflite) tf.lite.TFLiteConverter GPU delegate, NNAPI
x86 CPU ONNX + ORT onnxruntime AVX-512, VNNI
Arm Cortex TFLite / ONNX ort-arm, tflite XNNPACK, NEON
Qualcomm NPU QNN (.dlc) Qualcomm AI Hub Hexagon DSP

TensorRT — главный инструмент для NVIDIA edge. TRT строит граф с fusion операторов, выбирает оптимальные ядра. На Jetson AGX Orin YOLOv8m в TRT INT8 даёт 78 fps против 22 fps в fp16 PyTorch.

Практический кейс: детекция дефектов на производственной линии

Задача: обнаружение царапин на металле в реальном времени, 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 часа. Закажите бесплатное профилирование прямо сейчас.