Розгортання ML-модулів на Azure IoT Edge: практичний посібник

При розгортанні ML-моделей на периферії клієнти часто стикаються з вузьким місцем — мережевою latency та вартістю передачі даних. Ми пропонуємо перевірене рішення на Azure IoT Edge: моделі виконуються локально, в контейнерах, з оркестрацією з хмари. Це знижує затримки до мілісекунд і економить до 40% на трафіку. Наш досвід — понад 5 років в IoT Edge, більше 30 впроваджень для промислових проєктів, включаючи автоматизацію контролю якості та предиктивну діагностику обладнання.

Як розгорнути ML-модель на Azure IoT Edge?

Azure IoT Edge запускає контейнери (modules) на Edge-пристроях з оркестрацією через IoT Hub. ML-моделі з Azure Machine Learning пакуються в Docker-образ і деплояться через deployment manifest. Інтеграція з Azure Stream Analytics, Cognitive Services, ONNX Runtime — все під капотом.

IoT Edge runtime — два системних контейнери: edgeAgent управляє lifecycle модулів по deployment manifest, edgeHub — локальний брокер MQTT/AMQP, маршрутизація повідомлень та буферизація при розриві зв'язку.

Deployment manifest (JSON) визначає, які модулі запускати, їх параметри та маршрути:

{
  "modulesContent": {
    "$edgeAgent": {
      "properties.desired": {
        "modules": {
          "MLInference": {
            "type": "docker",
            "settings": {
              "image": "myregistry.azurecr.io/ml-inference:1.2.0",
              "createOptions": "{\"HostConfig\":{\"Devices\":[{\"PathOnHost\":\"/dev/video0\"}]}}"
            }
          }
        }
      }
    },
    "$edgeHub": {
      "properties.desired": {
        "routes": {
          "MLToCloud": "FROM /messages/modules/MLInference/* INTO $upstream"
        }
      }
    }
  }
}

Підготовка ML-модуля через Azure Machine Learning

Робочий процес: навчання на compute cluster → реєстрація моделі в Model Registry → створення IoT Edge пакета через Model.package() → push контейнера в ACR → оновлення manifest. Змінюємо версію образу — IoT Hub автоматично розгортає оновлення на цільову групу.

Чому ONNX Runtime — найкращий вибір для Edge-інференсу?

ONNX Runtime — кроссплатформений движок з апаратною оптимізацією. На Intel CPU з OpenVINO прискорення в 2,5–3 рази відносно чистого Python; на NVIDIA Jetson через TensorRT — до 5 разів. Automated deployment через IoT Hub в 10 разів швидше ручного оновлення кожного пристрою. Приклад hardware-aware сесії:

import onnxruntime as ort

opts = ort.SessionOptions()
opts.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL
opts.intra_op_num_threads = 4

providers = ['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']

session = ort.InferenceSession('model.onnx', opts, providers=providers)

def infer(image_np):
    input_name = session.get_inputs()[0].name
    return session.run(None, {input_name: image_np})

Готові образи Microsoft: mcr.microsoft.com/azureml/onnxruntime:latest-openvino для Intel, :latest-jetpack для Jetson.

Взаємодія модулів на Edge

Module Twin і Direct Methods

Через module twin змінюємо параметри на льоту (confidence threshold, версія моделі) без перескладання контейнера:

async def twin_patch_handler(patch):
    if 'modelVersion' in patch:
        await update_model(patch['modelVersion'])
    if 'confidenceThreshold' in patch:
        global THRESHOLD
        THRESHOLD = patch['confidenceThreshold']

module_client.on_twin_desired_properties_patch_received = twin_patch_handler

async def method_handler(method_request):
    if method_request.name == "GetStats":
        payload = {"fps": current_fps, "detections_today": counter}
        return MethodResponse.create_from_method_request(
            method_request, 200, payload)

Direct Methods — синхронний виклик з хмари (timeout 30 с). Використовується для діагностики, перезавантаження модуля, отримання статистики.

Message Routing

edgeHub маршрутизує повідомлення за source, topic, властивостями. Приклад: всі кадри з роздільною здатністю вище Full HD відправляються в модуль HiResProcessor, а детекції з впевненістю >0.9 — одразу в хмару:

FROM /messages/modules/Camera/* WHERE $body.width > 1920 INTO modules/HiResProcessor/inputs/frames
FROM /messages/modules/MLInference/* WHERE $body.confidence > 0.9 INTO $upstream

Azure Stream Analytics на Edge

Для real-time агрегації без хмари: середня температура за вікно 30 с, аномалії — все локально. Результати відправляються в інший модуль або в хмару при появі мережі.

SELECT
    System.Timestamp() as EventTime,
    AVG(temperature) as AvgTemp,
    COUNT(*) as Anomalies
INTO AlertOutput
FROM TemperatureInput TIMESTAMP BY EventTime
GROUP BY TumblingWindow(second, 30)
HAVING AVG(temperature) > 75 OR COUNT(*) > 10

Порівняння методів деплою

Порівняння бекендів інференсу

Fleet Management через IoT Hub

Device Provisioning Service (DPS) — zero-touch provisioning: пристрій при першому запуску реєструється в DPS, автоматично призначається в IoT Hub і отримує деплой. Automatic Deployments з target condition tags.location = 'factory-A' — розгортання по групах з пріоритетами.

Моніторинг: Azure Monitor + built-in метрики (connected devices, messages/day). Custom метрики через send_message() з application properties для фільтрації в Log Analytics.

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

• Аудит інфраструктури та вимог до інференсу
• Розробка та контейнеризація ML-модуля (ONNX / TensorRT / OpenVINO)
• Налаштування deployment manifest та маршрутизації
• Інтеграція з DPS для масштабування
• Документація з експлуатації та навчання команди
• Технічна підтримка на етапі впровадження

Гарантуємо стабільну роботу під навантаженням: latency p99 < 200 мс на Jetson Nano з моделлю YOLOv5, uptime 99.9% при втраті зв'язку до 4 годин.

Терміни: 3–6 тижнів

Базовий деплой з Azure ML моделлю — 1–2 тижні. Кастомні модулі, ASA Edge, OPC Publisher інтеграція з промисловим обладнанням, DPS fleet provisioning — 5–6 тижнів. Оцініть ваш проєкт — зв'яжіться для консультації. Замовте аудит вашої інфраструктури, щоб отримати точні терміни та вартість.

Azure IoT Edge documentation

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 години. Замовте безкоштовне профілювання прямо зараз.