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