Типичные ошибки при выборе edge-вычислителя для AI-пилота
Edge-вычислитель — сердце пилота: именно на нём крутится модель прямо в цеху, без облака. Ошибка выбора всплывает не сразу, а через месяц работы: плата троттлит на жаре, не тянет реальную скорость линии или оказывается без драйверов под нужный ускоритель. Заменить железо после старта дороже, чем выбрать правильно, поэтому ниже — семь ошибок с конкретными сценариями. Материал дополняет гайды edge-платы для пилота: NPU или GPU и edge computing на производстве.
1. Выбор по TOPS, а не по своей модели
Пиковые TOPS в спецификации — синтетический максимум на удобной для вендора операции и удобной разрядности. Реальная скорость зависит от вашей модели, разрядности (INT8 против FP16), разрешения кадра и препроцессинга.
Сценарий отказа: берут модуль с заявленными 26 TOPS, уверенные, что запаса хватит с избытком, а на своей модели детекции в FP16 при разрешении 1280 плата отдаёт 12 кадров в секунду вместо нужных 30 — потому что паспортные TOPS измерены в INT8 на другой архитектуре. Линия уже смонтирована, менять поздно.
Что сделать: проверять не по паспорту, а прогоном именно своей модели на образце платы до закупки, в той разрядности и при том разрешении, что пойдут в прод. Один образец платы за несколько тысяч рублей экономит переделку всей линии.
2. Проигнорировали тепловой режим цеха
Лабораторные бенчмарки снимают при комнатной температуре. В цеху у пресса, печи или литейки бывает +45 и выше, и вычислитель без радиатора или в тесном герметичном боксе уходит в тепловой троттлинг: частота падает, FPS проседает, детекция начинает опаздывать за конвейером.
Сценарий отказа: плата, стабильно дававшая 30 FPS на столе инженера, на линии после 40 минут работы под нагрузкой прогревается и сбрасывает частоту, FPS падает до 18, и каждая третья деталь проезжает точку контроля до того, как модель успевает вынести вердикт.
Что сделать: закладывать тепловой режим как обязательный пункт. Проверяют рабочий диапазон платы, тип охлаждения (активное или пассивное), реальную температуру в точке установки под нагрузкой, а не паспортную, и запас корпуса на отвод тепла.
3. Не заложили запас питания и его качество
Модуль с NPU под нагрузкой потребляет кратно больше, чем на холостом ходу, а цеховое питание с просадками и наводками от частотников и сварки добьёт слабый БП.
Сценарий отказа: плата уходит в перезагрузку на пике инференса — самый неуловимый класс сбоев, потому что на столе с лабораторным БП всё стабильно, а на линии перезагрузки случаются раз в несколько часов и всегда в момент максимальной нагрузки. Ищут причину неделями, грешат на софт.
Что сделать: считать питание по пиковому, а не среднему потреблению, с запасом и защитой от просадок. Проверять поведение при кратковременной потере питания и корректный перезапуск. Смежная тема — выбор плат по питанию — в гайде платы разработки: выбор по питанию.
4. Купили ускоритель без экосистемы драйверов
Красивые TOPS бесполезны, если под ускоритель нет стабильного рантайма, конвертера вашей модели и поддержки нужного фреймворка.
Сценарий отказа: закупили экзотический ускоритель с отличными цифрами, а его SDK не конвертирует вашу архитектуру модели без потери точности, сообщество мёртвое, последнее обновление год назад. Команда две недели воюет с тулчейном вместо запуска и в итоге всё равно откатывается на более скромную, но поддерживаемую платформу.
Что сделать: проверять экосистему до железа. Есть ли SDK, конвертируется ли ваша модель без деградации, поддержан ли фреймворк, живо ли сообщество и выходят ли обновления. Скучная, но поддерживаемая платформа почти всегда выгоднее яркой, но брошенной.
5. Заложили облачную зависимость там, где нужен локальный инференс
Если политика безопасности цеха запрещает выход наружу, а связь нестабильна, инференс должен быть полностью локальным.
Сценарий отказа: архитектуру построили с распознаванием в облаке ради экономии на железе, а служба безопасности предприятия не согласовала выход данных цеха наружу — проект встал на этапе согласования. Или согласовали, но канал в цеху рвётся, и при каждом обрыве линия слепнет.
Что сделать: фиксировать требование локального инференса на старте — оно определяет и класс платы, и всю архитектуру. Уточнить политику безопасности до выбора железа, а не после.
6. Один вычислитель на всё без плана масштабирования
Пилот на одной камере запускают на плате, которую физически невозможно размножить на десять линий: снята с производства, дефицитна, существует только как dev-kit без промышленного корпуса.
Сценарий отказа: пилот удался, решают масштабировать на весь цех — а плата, на которой он работал, доступна поштучно у одного поставщика, без промышленного форм-фактора и с неясным сроком жизни. Масштабирование упирается в железо, и весь стек приходится переносить на другую платформу заново.
Что сделать: ещё на пилоте проверять, что выбранная платформа доступна серийно, имеет промышленный вариант в корпусе с креплением и заявленный срок поддержки.
7. Не предусмотрели обновление модели на месте
Модель дообучают: появляются новые дефекты, меняется деталь. Если на плату нельзя безопасно выкатить новую версию без выезда инженера к каждой линии, сопровождение съедает экономику.
Сценарий отказа: обучили улучшенную модель, но развернуть её можно только вручную на каждом из двенадцати узлов по цехам, а неудачное обновление одного узла останавливает линию без возможности быстрого отката.
Что сделать: закладывать механизм обновления в архитектуру пилота — выкат по сети с автоматическим откатом на прошлую версию при сбое и без длительной остановки линии.
Мини-кейс: почему прогон на образце окупается
Условный расклад. Под пилот детекции выбрали модуль с заявленными 26 TOPS, уверенные в двукратном запасе. На своей модели в FP16 при разрешении 1280 плата отдала 12 FPS вместо нужных 30 — паспортные TOPS были в INT8 на другой операции. Плюс через 40 минут под нагрузкой у пресса плата прогрелась и сбросила частоту ещё на треть. Смонтированную линию пришлось переводить на другой вычислитель, потеряв две недели. Образец платы за несколько тысяч рублей и прогон своей модели в проде-разрядности до закупки закрывали оба риска.
Что проверить на образце до закупки
Минимальная программа испытаний образца: FPS на вашей модели в проде-разрядности и разрешении; удержание FPS под тепловой нагрузкой в течение хотя бы часа, а не первые минуты; отсутствие перезагрузок на пиковом потреблении при просадках питания; конвертация модели без потери точности штатным SDK; наличие промышленного корпуса и серийной доступности платформы; работоспособность выката новой версии модели с откатом. Если хоть один пункт не проходит на образце — он не пройдёт и на линии, только дороже.
Что это значит для внедрения на вашей линии
Edge-вычислитель выбирают не по строчке TOPS в паспорте, а по практическим осям: тянет ли именно вашу модель на нужном FPS, выживает ли в тепловом режиме точки установки, есть ли под него драйверы и серийная промышленная версия, и как на него выкатывать обновления. Прогон своей модели на образце платы до закупки закрывает большую часть рисков за несколько тысяч рублей. С подбором класса вычислителя под конкретную модель и скорость линии помогаем на старте.