Edge AI: деплой моделей на устройствах без облака

Модель работает идеально на сервере с A100. На Jetson Orin или мобильном устройстве — latency 4 секунды, батарея садится за час, модель вылетает по OOM. Разрыв между исследовательским кодом и edge-деплоем — это отдельная инженерная дисциплина.

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

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-энкодер для NLP на мобильном CPU: MobileBERT в fp16 через CoreML на iPhone 15 — 18 мс/инференс. distilbert-base-uncased в ONNX через ort — 42 мс. Разница существенная для real-time.

Проблема не в выборе «квантизировать или нет» — проблема в том, что нет единого ответа. Правильный путь определяется целевым устройством, задачей и допустимой деградацией метрики.

Квантизация: что реально работает

Квантизация бывает трёх видов, и они сильно отличаются по трудоёмкости.

PTQ (Post-Training Quantization) — самый быстрый путь. Берёте обученную модель, прогоняете через calibration dataset (200–1000 примеров), получаете INT8 или INT4 веса. Инструменты: torch.ao.quantization, ONNX Runtime quantization tool, bitsandbytes для LLM. Деградация точности: обычно 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 (Activation-aware Weight Quantization) лучше сохраняет качество при 4-бит квантизации по сравнению с GPTQ. llm-compressor от Neural Magic или autoawq — основные библиотеки.

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

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

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

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

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

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

CoreML Tools автоматически направляет вычисления на ANE (Apple Neural Engine) при правильной структуре модели. Не все операции поддерживаются ANE — кастомные слои падают на CPU. coremltools.convert() с compute_units=ct.ComputeUnit.ALL и профилирование в Xcode Instruments покажут, где узкое место.

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

Задача: обнаружение царапин на металлических деталях в реальном времени, 30 fps, камера подключена к Jetson Xavier NX (16GB).

Исходная модель: YOLOv8l, обученная на 12000 аннотированных изображениях, mAP50 0.91, inference на сервере — 28 мс/кадр. На Jetson Xavier NX в fp16 — 110 мс (9 fps). Не подходит.

Шаги оптимизации:

1. Переход на YOLOv8m — mAP50 0.887 (-2.3%), 68 мс на Jetson
2. Экспорт в TensorRT FP16 через yolo export format=engine half=True — 31 мс (32 fps)
3. INT8 calibration на 500 кадрах из production — 22 мс (45 fps), mAP50 0.879

Итого: деградация метрики 3.5% при 5× ускорении. Для задачи допустимо — оператор всё равно финально верифицирует флаги.

Процесс работы и сроки

Начинаем с профилирования: запускаем модель на целевом устройстве, замеряем latency по слоям, выявляем узкие места. Без этого оптимизация вслепую.

Затем — план оптимизации с оценкой trade-off: каждый метод даёт конкретный прирост скорости при конкретной деградации качества. Вы решаете, что допустимо для вашей задачи.

Сроки: оптимизация готовой модели для конкретного устройства — 2–4 недели. Разработка с нуля под edge-требования (архитектура + обучение + оптимизация + тестирование на железе) — 6–16 недель.