Как деплоить audio-event модель на устройство
Модель распознавания аудио-событий должна работать на колонке/камере с CPU и ограничениями по latency, privacy и батарее. Как это спроектировать?
Короткий ответ
Нужен легкий on-device detector: quantization, distillation, streaming windows, early exit, локальная обработка приватного аудио и cloud fallback только при явном разрешении/событии.
Полный разбор
Для устройства важно не только качество, но и ограничения: CPU, память, задержка, энергопотребление, приватность. Поэтому используем маленькую модель, quantization, distillation, pruning или mobile-friendly архитектуру.
Serving может быть двухступенчатым: дешевый wake-up/event detector постоянно слушает короткие окна, а более дорогая модель запускается только на подозрительных событиях. Для приватности лучше обрабатывать аудио локально и не отправлять сырой звук в облако без необходимости и согласия.
Мониторинг сложнее, чем на сервере: нужны anonymized counters, opt-in telemetry, shadow evaluation на разрешенных данных, версии моделей, rollback. Метрики: latency, CPU/memory, false alarms per day, battery impact, crash rate, disable rate.
Теория
Edge ML - это trade-off между качеством, latency, стоимостью устройства и приватностью. Большая server-модель не всегда применима.
Типичные ошибки
- Предложить всегда отправлять аудио в облако.
- Не обсудить CPU/память/latency.
- Забыть про rollout и rollback модели на устройствах.
Как отвечать на собеседовании
- Сразу назови on-device constraints.
- Предложи two-stage detector и quantization.