Инференс и оптимизация AI на Google Coral: деплой на Edge TPU

Инференс на CPU упирается в задержку: что меняет Google Coral

На периферии модель не укладывается в бюджет времени отклика: кадр приходит быстрее, чем конвейер выдаёт результат, и очередь растёт. Буфер переполняется, устройство начинает отбрасывать кадры или считать по устаревшей картинке, и реакция приходит с опозданием на несколько циклов. Облачный вызов проблему не снимает, а добавляет зависимость от канала связи: просел канал — встала вся логика, включая аварийные сценарии. Поэтому смотрим на ускоритель инференса на периферии — Google Coral здесь один из разбираемых вариантов.

Ускоритель переносит матричные операции с центрального процессора на отдельный блок. Ресурсы встраиваемого процессора освобождаются под захват кадра, предобработку и передачу результата — под работу, которую он делает предсказуемо и без конкуренции за вычислительные блоки.

Задержка отклика модели становится ровной: среднее время здесь менее важно, чем верхний перцентиль, и именно он перестаёт уползать на пиковой нагрузке. Обработка кадров на устройстве идёт локально, поэтому качество канала связи больше не определяет, работает ли сценарий.

На стенде результат проверяется измеримо: доля кадров, потерянных из-за переполнения буфера, разброс задержки между кадрами, тепловой режим корпуса при непрерывной работе. Замеры до и после переноса показывают, где узкое место уходит, а где остаётся — например, если предобработка кадра сама съедает бюджет времени. Дальше разбираем, как это закрывается на практике.

Что даёт вынос инференса на периферию: измеримые эффекты

Вынос вывода модели на периферию меняет не столько скорость, сколько профиль отказов: система перестаёт зависеть от канала связи и внешних сервисов. Google Coral — один из вариантов такой платформы, и эффект на нём виден в измеримых величинах.

Время отклика в десятках миллисекунд

Сигнал обрабатывается на месте, поэтому задержка определяется только вычислением и не растёт при перегрузке сети. Для сортировочного конвейера или линии контроля это разница между аварийной остановкой механизма и плавным торможением.

Автономная работа устройства

Модель, веса и правила фильтрации лежат на носителе рядом с ускорителем, поэтому распознавание продолжается при полностью отключённом внешнем канале. После восстановления связи буфер уходит наверх пакетом — без потери событий и ручной сверки.

Локальная обработка данных

Видеопоток и телеметрия не покидают периметр: наружу уходят только метаданные и агрегаты. Это снимает основную нагрузку с канала и упрощает работу с чувствительными данными.

Устойчивость к обрыву канала

Уходит целый класс инцидентов: разрыв связи, перегрузка сети и недоступность внешнего сервиса больше не останавливают распознавание. Доля отказов, привязанных к каналу, сокращается до нуля — остаются только отказы самого оборудования, которые диагностируются локально.

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

Google Coral: режимы подключения и сравнение вариантов

Акселераторы Google Coral выпускаются в нескольких форм-факторах, и выбирают между ними не по скорости вывода, а по способу встраивания в готовое устройство. Практика упирается в три вещи: пропускная способность интерфейса, ограничения по памяти под конкретную модель и совместимость с контроллером на стороне хоста.

Модуль расширения: минимум вмешательства в железо

Ставится поверх существующего компьютера, поэтому узел собирается быстро и без пересборки корпуса. Потолок здесь задаёт шина: если она делится с камерой, акселератор простаивает, а кадры теряются. Проверяем это нагрузочным прогоном до того, как заказана механика.

Одноплатный модуль: предсказуемость вместо гибкости

Здесь память и интерфейсы распаяны производителем, поэтому поведение узла повторяемо от экземпляра к экземпляру. Обратная сторона — модель придётся уложить в заданный бюджет памяти заранее, а расширение возможно только через внешние интерфейсы. Такой вариант берут, когда изделие тиражируется, а не собирается в единичном экземпляре.

Между крайностями выбор сводится к одному вопросу: где в узле узкое место — в шине, в памяти или в контроллере.

Этапы внедрения: от аудита модели до передачи в эксплуатацию

Развёртывание на Edge TPU — не «прошил и забыл»: ускоритель чувствителен к тому, как собрана модель и как к ней поступают данные. Идём по этапам, где каждый опирается на результат предыдущего, поэтому на объект приезжает проверенная сборка, а не эксперимент.

1. Аудит модели. Разбираем архитектуру по слоям: что ускоритель считает аппаратно, а что придётся оставить на центральном процессоре. На выходе — карта узких мест и прогноз по задержке отклика.
2. Подготовка датасета. Убираем дубли и расхождения в разметке, добиваем редкие классы. От этого зависит, насколько честной будет оценка качества после квантизации.
3. Схема размещения. Считаем бюджет по памяти и питанию, выбираем корпус, охлаждение и способ подключения камер. Фиксируем, что обрабатывается в реальном времени, а что уходит в отложенную очередь.
4. Настройка ускорителя. Собираем модель в формат, который понимает плата Google Coral, переводим вычисления в целочисленный вид и калибруем на кадрах с объекта. Качество до и после квантизации сверяем: расхождение остаётся в оговорённых границах.
5. Испытания на объекте. Гоняем систему на живом потоке: свет, движение, перекрытия, нагрев корпуса. Смотрим не средние метрики, а долю верных срабатываний и число ложных тревог за смену.
6. Обучение персонала. Показываем операторам, как читать события, что делать при сбое и как корректно перезапустить узел. Оставляем инструкцию на одну страницу.
7. Передача в эксплуатацию. Отдаём регламент обновления модели, схему стенда и тесты для приёмки. Сопровождаем первый цикл обновления, дальше команда работает самостоятельно.

Что передаём на руки: конфигурации, схемы и регламенты

После сдачи у команды заказчика остаются не только работающие устройства на Google Coral, но и артефакты, по которым систему можно воспроизвести, обслужить и передать другому подрядчику. Без них любое изменение превращается в разбор того, что и где настроено, — поэтому комплект фиксируем и согласуем до старта.

• Конфигурация устройства — профиль прошивки, параметры квантования модели, режим ускорения на сопроцессоре, настройки питания и автоперезапуска после сбоя.
• Схемы подключения и размещения — план монтажа с разводкой питания и сети, точками крепления и требованиями к вентиляции: тепловой режим напрямую влияет на стабильность вывода.
• Политики доступа — кто и по какому каналу обновляет модель, кому доступна телеметрия, как отзываются ключи и что происходит при уходе носителя.
• Регламент обслуживания — периодичность проверок, порядок обновления модели и откат на предыдущую версию, признаки деградации качества, при которых запускается разбор.
• Документация на систему — архитектурная схема, описание потоков данных, журнал изменений и инструкции для сменного персонала: что делать при остановке и как поднять конвейер заново.
• Матрица ответственных — по каждому узлу указан владелец, порядок эскалации и срок реакции на инцидент.

Каждый артефакт лежит в репозитории рядом с кодом и версионируется вместе с ним — при передаче команде не приходится восстанавливать контекст по переписке. Состав комплекта и формат согласуем на старте, чтобы к сдаче не выяснилось, что половина решений существует только в устной договорённости.

Кейс: контроль качества на линии и метрики до и после

На линии упаковки визуальный контроль качества держали два оператора в смену: сверяли маркировку, целостность шва и рисунок упаковки на глаз. Доля пропущенного брака держалась около трёх процентов и заметно росла к концу смены, а каждое ложное срабатывание останавливало поток — спорную единицу снимали и проверяли вручную, план выпуска за смену не выполнялся.

Перевели контроль на инференс прямо у конвейера: камера, обученная модель и ускоритель Google Coral в защищённом корпусе рядом с линией. Кадры не покидают площадку, связь с внешними сервисами не нужна. После перенастройки доля пропущенного брака снизилась до десятых долей процента, число ложных срабатываний — примерно вдвое, а время отклика на линии сократилось до долей секунды. Линия работает без оператора: смена начинается с самопроверки камеры и сверки с эталонным кадром, расхождение сразу поднимает сигнал.

Ограничения, о которых предупреждаем сразу

Решение чувствительно к освещению и геометрии кадра: при смене артикула упаковки эталон и пороги пересобираем вместе с моделью, иначе растут ложные срабатывания. Брак, который оператор ловил на ощупь — деформацию без визуальных признаков, — система не закроет. Поэтому держим архив версий модели и правило отката: если после обновления метрики на контрольной партии проседают, линия возвращается к предыдущей версии за одну операцию.

Чем компиляция под ускоритель отличается от обычного экспорта?

Обычный экспорт отдаёт модель в формате, который считает универсальный процессор: граф остаётся как есть, слои работают в плавающей точке. Компиляция модели под Google Coral — другой процесс: граф разбирают на операции, которые ускоритель исполняет нативно, а остальное переписывают эквивалентной заменой или оставляют процессору.

Ключевое отличие — квантование весов: веса и активации приводятся к целочисленному виду, а масштабы подбираются калибровкой на представительной выборке реальных данных. Ошибка на этом шаге почти незаметна: сборка проходит, но точность проседает точечно — на отдельных классах и на редких входных данных.

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

После преобразования прогоняем эталонный набор и сравниваем с исходной моделью — не только итоговую метрику, но и расхождения по каждому классу. Считаем долю примеров, где решение изменилось: общая метрика может остаться на месте, а ошибки — поменяться местами.

Резервный режим держим всегда: тот же граф в плавающей точке на процессоре или предыдущая собранная версия с зафиксированными параметрами. Переключение выполняется конфигурацией, без пересборки приложения, — страховка на случай, когда в реальных данных появляется класс, которого не было в калибровочной выборке.

Точность после квантования, обновления моделей, тепловой режим

Квантование под Edge TPU — ускоритель Google Coral — почти всегда сдвигает точность, вопрос лишь в том, насколько и где. Мы сравниваем не среднюю метрику, а распределение ошибок по классам: усреднённая просадка часто скрывает провал на редком классе.

Ниже — сомнения, которые всплывают на приёмке: что делать с точностью, как менять модель на устройстве, как ведёт себя модуль в нагретом шкафу и что остаётся в журнале при отказах.

Как обновить модель на устройстве, не останавливая контур?

Артефакт модели едет с версией и подписью, устройство забирает его с сервера и применяет после самопроверки на калибровочном наборе. На флеше живут две версии, поэтому откат — одна команда.

Что будет, когда шкаф нагреется?

Ускоритель уходит в троттлинг: отклик растёт, очередь копится, без ограничения скорости появляются пропущенные кадры. В контур встроен контроль температуры и бюджета отклика — при перегреве поток ставят на паузу или уводят на соседний узел.

Обратная совместимость и журналирование отказов

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

Обсудим задачу: что нужно для оценки и плана работ

Чтобы оценка и план работ опирались на факты, а не на предположения, нам нужны исходные данные по объекту — то, что определяет выбор вычислительного модуля, режим работы модели и запас по теплу. Разброс вводных часто решает, уложится ли задача в один компактный ускоритель вроде Google Coral или потребует другой конфигурации. Ниже — что стоит прислать в первом сообщении, чтобы мы вернулись с расчётом, а не с уточняющими вопросами.

• Класс задачи и модель. Детекция, классификация, сегментация или трекинг — сколько классов, какой объём входных данных, есть ли уже обученная модель и в каком виде она сохранена.
• Текущая схема обработки. Где и чем считаете сейчас: на сервере, на встраиваемом модуле или вручную; как данные попадают в систему и в каком формате.
• Требования по времени отклика. Какой отклик считается приемлемым, нужна ли обработка потока в реальном времени или допустима пакетная; что происходит при пропуске события.
• Условия эксплуатации. Температура, пыль, вибрация, влажность, доступ к вентиляции — от этого зависит тепловой режим и частота троттлинга под нагрузкой.
• Питание и корпус. Доступная линия питания, её стабильность, габариты корпуса, точки крепления и возможность обслуживания без демонтажа конструкции.
• Сеть и интеграция. Как результаты уходят в учётную систему: локальная сеть, беспроводное соединение, последовательный интерфейс; какие протоколы уже приняты на объекте.
• Целевые метрики качества. Допустимая доля пропусков и ложных срабатываний, нужна ли фиксация логов и выгрузка сомнительных случаев на дообучение.

Опишите задачу в свободной форме — даже если часть пунктов пока неизвестна, этого хватит, чтобы определить узкие места и вернуться с оценкой и планом работ.