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

Экономия от выбора правильного метода: до 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% — мы фиксировали такую у нескольких клиентов.

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

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