Розгортання ML-моделей на Edge з AWS IoT Greengrass

Розгортання ML-моделей на Edge через AWS IoT Greengrass

Типова картина: на заводі 200 PLC і камер, але модель навчена в SageMaker. Вручну оновлювати бінарники на кожному пристрої — помилки та простої. Ми налаштовуємо AWS IoT Greengrass v2 — runtime для запуску ML-компонентів на Edge без SSH. Моделі з SageMaker їдуть у деплой на thing group «factory-line-1», а централізоване управління флотом — з zero-touch provisioning. За 5 років ми впровадили Greengrass на 30+ промислових об'єктах і гарантуємо стабільність в умовах перебоїв мережі.

Архітектура Greengrass v2

Nucleus — Greengrass core runtime на Java. Управляє lifecycle компонентів, IPC і локальним брокером MQTT (Moquette). Компоненти — атомарні одиниці деплою: AWS managed (готові) та custom (ваш код). Deployment — JSON-документ з набором компонентів і версій. AWS консоль або CLI відправляє його на пристрій, Nucleus застосовує.

Cloud (AWS): SageMaker → Model artifact in S3 IoT Greengrass Deployment → targets: thing group "factory-line-1"

Edge device: Greengrass Nucleus ├── aws.greengrass.SageMakerEdgeManager ├── aws.greengrass.DlrInferenceService (DLR runtime) └── com.company.InferenceApp (custom component)

Чому Greengrass для Edge ML?

Централізоване управління — тільки одне: замінив Deployment, і всі 500 пристроїв отримали нову модель. Staged rollout з canary (спочатку 5%, потім 100%) та автоматичний rollback при помилці. Device Shadow зберігає поточну версію моделі та статус, синхронізація cloud ↔ edge працює навіть при тимчасовому розриві мережі.

ML Inference компоненти

SageMaker Edge Manager компілює моделі через SageMaker Neo для конкретного заліза (ARM, x86, GPU). Оптимізовані бінарники + Edge Agent (gRPC daemon) на пристрої.

# edge agent gRPC client
import agent_pb2, agent_pb2_grpc
channel = grpc.insecure_channel('unix:///tmp/sagemaker_edge_agent_example.sock')
stub = agent_pb2_grpc.AgentStub(channel)

# завантаження моделі
stub.LoadModel(agent_pb2.LoadModelRequest(
    url=f's3://bucket/model.tar.gz',
    name='defect-detector'))

# інференс
response = stub.Predict(agent_pb2.PredictRequest(
    name='defect-detector',
    tensors=[tensor]))

DLR (Deep Learning Runtime) — альтернатива Edge Manager. TVM-compiled моделі, підтримка TFLite, XGBoost, LightGBM. Легший, без gRPC оверхеду. На CPU DLR часто швидший у 2 рази.

import dlr
model = dlr.DLRModel('/greengrass/v2/work/model', 'cpu')
result = model.run({'input': numpy_array})

Порівняння SageMaker Edge Manager та DLR

Як організувати оновлення моделей без простоїв?

Класичний pain point Edge ML — як оновити модель на 500 пристроях. Greengrass вирішує це нативно.

Згідно з документацією AWS, Greengrass v2 підтримує staged rollout з автоматичним відкатом.

Workflow:

1. SageMaker навчає нову версію моделі.
2. Артефакт завантажується в S3.
3. Оновлюється версія компонента в Greengrass.
4. Створюється новий Deployment на thing group.
5. Nucleus на кожному пристрої завантажує дельту, застосовує, rollback при помилці.

Staged rollout: Deployment з canary — спочатку 5% пристроїв (thing group subset), моніторинг CloudWatch метрик, потім 100%.

Local shadow для стану: AWS IoT Device Shadow зберігає поточну версію моделі, статус інференсу, custom metrics. Синхронізація cloud ↔ edge навіть при тимчасовому розриві мережі.

Кастомний компонент для інференсу

recipe.json:

{
  "RecipeFormatVersion": "2020-01-25",
  "ComponentName": "com.company.QualityInspection",
  "ComponentVersion": "1.0.0",
  "ComponentDependencies": {
    "aws.greengrass.DlrInferenceService": {"VersionRequirement": ">=1.6.0"}
  },
  "Manifests": [{
    "Platform": {"os": "linux"},
    "Lifecycle": {
      "Install": "pip3 install -r requirements.txt",
      "Run": "python3 {artifacts:path}/inference.py"
    },
    "Artifacts": [
      {"URI": "s3://my-bucket/inference.py"},
      {"URI": "s3://my-bucket/model.tar.gz", "Unarchive": "ZIP"}
    ]
  }]
}

Stream Manager для великих даних

greengrass.StreamManager — локальний буфер для edge → cloud передачі. Коли мережа нестабільна — дані буферизуються локально (до 256 MB), після відновлення — автоматично відправляються в Kinesis/S3/IoT Analytics. Параметри налаштовуються: розмір буфера, частота експорту, політика при переповненні.

Fleet Management

Thing Groups + Attributes: factory-line-1, factory-line-2 — різні моделі для різних ліній. Attribute: firmware_version, camera_model — для conditional deployment.

Greengrass CLI для діагностики:

greengrass-cli component list          # запущені компоненти
greengrass-cli logs get --component com.company.QualityInspection
greengrass-cli deployment create ...   # локальний деплой для налагодження

CloudWatch метрики: стандартні ComponentRunning, ComponentBroken. Кастомні через EMF (Embedded Metrics Format) — будь-які метрики з edge коду безпосередньо в CloudWatch.

План впровадження та терміни

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

• Аудит поточної інфраструктури та моделі (сумісність з Greengrass, вимоги до заліза).
• Проєктування архітектури: вибір між SageMaker Edge Manager та DLR, склад компонентів, схема деплою.
• Налаштування Greengrass Nucleus та компонентів (aws managed + custom).
• Інтеграція з існуючими системами (SCADA, MES, Kafka).
• Staged rollout та моніторинг (CloudWatch, алерти).
• Документація з експлуатації та навчання команди.
• Гарантія стабільної роботи протягом 30 днів після запуску.

Підтримувані платформи

Linux (arm64, armv7, x86_64). Мінімум: 512 MB RAM, 1 GHz CPU. Протестовано: Raspberry Pi 4, NVIDIA Jetson, BeagleBone, промислові x86 IPC. Windows (x86_64): Greengrass v2.9+, обмежений набір компонентів.

Терміни та вартість

Перший Greengrass деплой з готовою моделлю — від 1 тижня. Кастомні компоненти, fleet management, staged rollout, інтеграція з існуючою SCADA/MES — 4–6 тижнів. Вартість розраховується індивідуально після аудиту. Оцінимо ваш проект — зв'яжіться з нами. Використовуєте Greengrass і хочете знизити операційні витрати? Замовте консультацію — ми підберемо оптимальну архітектуру.

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